e4 block is E4 00 – –
Are you sure about that? If so then I’m guessing a write command got mixed up and you wrote E4 00 to page E4 and inadvertently may have tripped the cfg lock bit.
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.
hmm A2 E4 00 05 00 00 coming back NAK, think I should try it with authenticating first?
yes you can try auth first… post results
No dice with Authing first sadly. For completeness here’s a screenshot for the last few blocks
Sorry for the late reply, got rate limited by the forum because I just signed up heh.
1 Like
Well you have clearly passed the Turing test, so I have upped your user lever from new to basic, you should be able to reply more easily /frequently
1 Like
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?
yep that’s it
Alright, set the password to FF FF FF FF and then got the following:
1B FF FF FF FF
0000
A2 E4 00 05 00 00
NAK
re-scanned with taginfo but the output doesn’t look any different, not sure where I should be looking for a default password indicator though
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.
This is also the default value for page E4
Yes so you don’t need a 1B (pw_auth) command befor writing.
Really? That dosnt make sense to me.
If anything should E4 not be 05 00 00 00
RFUI should be 00
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
1 Like
@Zwack im glad its not just me.
I’m really confused because ACCESS by default should be 00 and all RFUI bytes should be 00 aswell
I dont know where everyone’s getting E4 on the ntag216 should be 00 05 00 00 that’s got to be wrong as the structure is ACCESS RFUI RFUI RFUI.
the only situation that makes sense is 05 00 00 00 but like you said that would make AUTHLIM 5 which seemes pointless.
1 Like
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;
7 PROT
6 CFGLCK
5 RFU
4 NFC_CNT_EN
3 NFC_CNT_PWD_PROT
2-0 AUTHLIM
You want all those bits to be 0.
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?
2 Likes
says who? this is an assumption only, and NXP does not play your games 
edit - i guess it does say that in the doco screenshot but NXP does not play by their own rules
2 Likes
And that is at least in part why I hate documentation writers and don’t trust documentation.