Making the NExT read only (with a password)

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.

Screenshot_20210804-123932_Drive
Screenshot_20210804-123959_Drive
Screenshot_20210804-124030_Drive

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 :wink:

edit - i guess it does say that in the doco screenshot but NXP does not play by their own rules :wink:

2 Likes

And that is at least in part why I hate documentation writers and don’t trust documentation.