E4 in binary is 11100100 so you can see the first 3 bits are 111 and those are authlim bits 0-2… then 00 for bits 3 and 4 and it appears 5 is 1 which is reserved and then bits 6 and 7 are 00 and cfg lock is bit 6 so you lucked out… I think… so first fix page E4 by sending following;
A2 E4 00 05 00 00
This should work now because your page E3 indicates and AUTH0 byte of FF which means everything is writable without authentication.first.
Correct but stupidly taginfo attempts an auth using factory defaults, potentially incrementing the auth counter and potentially impacting authlim. That’s why when the tag has default password it shows as FF FF FF FF in taginfo. Of course when a correct auth occurs you get the PACK… so in this way taginfo can correctly display both when the pwd is set to default.
FF is the default AUTH0 value and basically means no protection.
Correct, but doesn’t hurt and confirms the chip’s password since it cannot be read. This is what I wanted to do - confirm he could update the password to factory default FF FF FF FF. Receiving an ACK on write to page E5 is kinda doing this but sending an auth command confirms it.
The defaults for E4 is 00 05 00 00 and here’s why;
Leftmost byte (byte 0) of page E4 is the ACCESS byte which includes the following bit flags;
Yeah that all makes sense if nxp lie in the data sheet.
When a manufacturer says something in the datasheet its kinda got to be trusted until proven otherwise. I understood everything and was happy with it but the rfui byte being 05 even according to nxp is wrong I wonder if they use it during testing and cbf to change it back.