I think the reason that doesn’t work is that the exploit I’d is their “empty” state. They clear the memory to the exploit id so when you scan the card again it doesn’t have it in the memory. The fix would be to not scan the whole memory, just the number of addresses corresponding to the number of registered ids. That way it won’t see the “empty” memory as a valid user id
it doesnt make much sense for that to be the case tho. as the even parity bits and column even parity for an em410x id of FFFFFFFFFF would be 0. so the payload sent to the reader would have to be a correct 64 bit payload every time for it to authorise as the FFFFFFFF ID.
it being due to some empty memory buffer doesnt make sense even if you are just thinking of the ID and not the actual way EM410X works. as F is a positive value. if it was really due to empty storage it would be 0000000s and that would have the even parity but a value header of 1111111111
That’s why I put “empty” in quotes. It could be that they have a memory block for the ids that they initialize to FFFFFFFF when they want to indicate that it’s not a valid id. It would be interesting to sump the memory and see if that’s the case.
i think its less of a buffer memory problem and more of just its baked in for some unknown reason probably factory quality testing if you think about it. turn it on, have it scan an emulated UID that never has to change and then move on to the next one.
A blank EEPROM will be all FF’s same with flash, If it does not store the 64 bits (encoded data) but rather the actual ID then with 40 bits (5 Bytes), then yes a default slot would have FFFFFFFFFF id
Kind of think of it more like the Weigand … it’s encoded to transmit, but only the actual UID is used in the backend. but that would cause every single refresh when not in use to cause it to open the door/activate whatever its hooked up to
Let’s just be clear… these is no such thing as an empty anything when it comes to digital memory. There is always a value. A bit is always zero or one. There isn’t any 3rd option for the bit to not exist. Therefore, at some point, the system needs to agree on and design around what represents “empty”. In the ASCII chart, character 0 represents null or no value… but it is a value. But why would eeprom follow ASCII convention? Why couldn’t the firmware developer choose all FF bytes as their “empty”? There’s simply no reason to favor 00 over FF.
I think what’s most likely is laziness over extra effort. To intentionally put a back door for FF is extra effort, but putting an index counter and shift all the “slots” in memory every time you remove an ID from memory…that’s a lot of effort. What is absolutely the MO of most software developers is to simply scan through memory slots until you find the ID and overwrite i with FF and jump out… because “nobody is going to have a card with all FF” … and it’s far easier this way.
To test the amount of laziness here… we could add the two tags. Add tag A, then tag B, then tag A again… remove tag A, the test with tag A. If they were super lazy, the second time you added tag A, it would have been written a second time. Then when you removed it, it would have removed the first one and stopped checking memory, leaving the second addition in memory. This would be the ultimate lazy approach… because “who would add the same card twice?”.
Granted it’s effort to check for an ID already in the system when adding, but two identical IDs doesn’t hurt anything… but when removing, the choice to dump out or keep looking and removing IDs is a tossup, because both approaches are practically equal effort… so hard to say.
My point here is that you can’t really reverse engineer the code without seeing it, but you can probably make assumptions based on the human nature of a badly paid Chinese coder who doesn’t give two shits about outliers in a country that is riddled with key cloners that would work with the very thing they are working on… so why bother.