Making the NExT read only (with a password)

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:

A2 E4 00 05 00 00

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;


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?


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:


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

Yeah that all makes sense if nxp lie in the data sheet. :rofl:

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 :sweat_smile: I wonder if they use it during testing and cbf to change it back.



Struggled for a bit but can’t get taginfo to export data so here’s a new screenshot since resetting the default password. Let me know if there is anything else you want a screenshot of

Ok… I did some testing with some bullseye ntag216s…

The screenshot

The rundown

• The first scan authenticates with DNGR (this was an older bullseye tag that was set up as a NExT using the password DNGR), writes a new password to the default value FF FF FF FF, then writes page E3 to FF 00 00 FF. This all works as expected.

• The second scan changes the value of E3 to 00 00 00 FF to prove that the CFG byte being set to FF has no effect on page E3. This works as expected.

• The third scan changes the value of E4 to E4 05 00 00. I leave the RFU byte 1 set to 05 because well, it’s just set this way to begin with and I don’t want to change it. This works.

• The final scan attempts to change E4 back to 00 05 00 00. This fails.


Setting byte 0 of page E4 to 1110 0100 (E4 in hex) results in the entire configuration section locking down… but why? Let’s take a look again at the memory breakdown for the ACCESS byte (byte 0 of page E4);


Notice how bit 0 is on the right side of the bit list, not the left side?

Since E4 = 1110 0100 in binary, and when reading binary the LSB (least significant bit) is on the right side, it means when reading the binary in the “traditional” left to right way, the first 3 bits starting on the left are actually bits 7, 6, and 5 listed on the memory map, or in other words, PROT, CFGLCK, and RFUI, which are all value 1. Your CFGLCK bit is flipped to 1, and your configuration pages are locked.

Basically, NXP is trying to help people out by reversing the bit numbering order in their documentation in order to allow you to simply read the binary left to right as normal, rather than having to reverse it in your head.

1 Like

Gotchya, makes sense. Thanks for all the help and investigating the root cause. I suppose I must have fat fingered something when initially writing the hex. Lucky I locked it in read/write mode rather then read only - good lesson to be more careful I suppose.


1 Like

indeed… we disable the lock bits so it is impossible to lock your memory bytes fully in that way, however you were lucky that in page E3 your AUTH0 byte is FF which means the password itself is meaningless… but yes, it’s fully read/writeable :slight_smile: