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.
ok so what happened when you tried to auth first? did you get the PACK back when you auth’d or a NAK or?
I would maybe auth, then try to write the PWD back to factory default of FF FF FF FF and see if that works… a scan with taginfo should show a default pw if set
Sorry, I should have been more clear. When I attempted to auth with 1B XX XX XX XX the first line gave a 0000 response, the second command of A2 E4 00 05 00 00 came back with NAK
To change the password to FF FF FF FF, I would run:
A2E5FFFFFFFF correct?
The only thing I can think of is that my bit values are off for the cfg byte… I’ll grab an ntag216 test tag and try this out for funsies and see if I get the same result.
I’m surprised by the taginfo output tho… can you post the last few pages of taginfo full scan data now that you’ve reset the password to factory default?
So PWD and PACK should always be XX when read as the chip refuses to report it.
When setting the PWD and PACK without password protection its a straight foward write command. Also looking at NXP’s datatsheet writing both will not return a acknowledgement.
Also I noticed the AUTH0 is set to FF that is the first page protected by the password so shouldn’t be FF.
Another note:
A2 E4 00 05 00 00
This isn’t right what are you trying to write here ACCESS and AUTHLIM???
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.
Unless I am misreading it you are saying E4 should be 05 (access) 00(rfui) 00(rfui) 00(rfui)
That would make access 00000101 which would be a default AUTHLIM of 5. Given that everything else is disabled I would have thought that AUTHLIM should be 0
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;
PROT = 0 is password protection method. The default 0 enables full read access but requires PWDAUTH to write. Setting to 1 means you cannot read or write without PWDAUTH first.
CFGLCK = 0 because you don’t want to lock your config. This is OTP btw, so setting it to 1 locks all your config pages, so don’t fuck with this.
RFU = 0 because it just is
NFC_CNT_EN = 0 this counter is not enabled by default
NFC_CNT_PWD_PROT = 0 NFC counter protection (by PWDAUTH) is not enabled by default
AUTHLIM = 0 to disable authlim because holy shit you don’t want to enable DoS against your tag by sending enough bad PWDAUTHs to lock out your tag
As for byte 1 which is RFU, who fucking knows, it’s just 05 on factory default tags from NXP so might as well leave it set to 05. Therefore, E4 default is 00 05 00 00. Make sense?
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.