NTAG216 (HF NExT) Setup Help

Awesome, I would love to hear about the shell command then.

Will do, thanks.

No problem :wink:.

Is this a blank (‘factory’) NTAG216?

Pretty much yes. I tried locking it with NFC Tools first where it always says operation suceeded no matter what password you type in, same with removing it. Then I tried using the DNFC app to lock it, just to find myself on a forum scrolling through the posts on why it cannot be changed → it’s already set that way by DT, so you don’t have to set it up via DNFC :slight_smile: . So yeah, I can successfully authenticate via shell using the standard DNGR password, plus wrote one test txt record to it. No other changes beside that. It should be fully operational.

Still mobile at the moment but you could use the dangerous things support tool and write a blank ndef to it for step 1.

Did you write anything large to it already?

Sorry for the delay, time difference between EU and NA.

Done. Thanks.

Nope. Just two pretty much empty text records and a rickroll link :slight_smile: .

the password may be NExT If not DNGR

There is some great info in @DonFire post, although it is specifically for the xSIID, :blinky_green: it has some good she’ll info

here’s the support tool if you don’t already have it

1 Like

I have already managed to authenticate using the DNGR password via Shell. Thanks for the other links :slight_smile: .

1 Like

Im curious to your reasoning for wanting to set PROT to 1b and for setting AUTHLIM to 111b?

Im not too sure of many scenarios where the counter is used on an NTAG21x other than for failed auth. Plus setting AUTHLIM to any value opens the card up for malicious forced locking by means of purposefully failing auth as many times possible.

Are you also considering setting NFC_CNT_PWD_PROT to 1b as well?

Effectively, I want to store some data on my chip, which are not meant to be read/overwritten without a password. As far as I know, the AUTHLIM is the only real tool serving for the anti-bruteforce job. I don’t really mind getting locked out of it myself if someone was to attack it. It’s meant to supply me with some key data in case I forget it, but I doubt someone is about to wipe both my memory and lock my chip at the same time. I can always get a new chip and set it up the same way I did the last one following this guide, not that big of a deal really.

Not sure what the NFC_CNT_PWD_PROT value does, but the PROT one seems like what I’m looking for.

This is the only thing I would suggest against setting authlim. The reason is that it will totally brick your chip from being read if ever triggered, and since the information on the chip is so important that you want to block unauthorized reads, it would be conceivable that loss of access to that data also be a serious concern. The thing about authlim is that it doesn’t have to be triggered all in one session… though it easily could be. If you don’t read the data that often (and provide a valid PWD_AUTH), then authlim could be triggered over the course of many encounters, each incrementing the counter by just a few attempts at a time.

Other than that it seems this has all been sorted.

EDIT… ok i just read this…

well ok then :slight_smile:

I’m having a hard time realizing in which exact scenarios the authlim gets incremented. Everytime there’s a wrong PWD_AUTH command set to it? Or whenever there’s a read attempt, regardless of wheter there’s a PWD_AUTH command sent beforehand?

Is that a confirmation that the commands stated in the original post are in their correct form then?

Also, what about this value? Should I be concerned about it in my use case?

And lastly, I’d like to have this answered as well if possible :slight_smile: .

yep, every failed PWD_AUTH counts toward authlim

looks to be yes

It just means that in order to issue a read counter command you’d have to be auth’d first or not… set or not set… meh.

basically that will depend on the app’s ability to handle it… DT Support Tool just issues commands, it doesn’t do auth tho so it won’t work afterwards… dunno about NFC Tools but TagWriter should try to prompt you for a password and then use that to properly read and update/write to your tag.

So all this basically does is prevent the readers from reading the uid and first few pages without auth = zero effect in my use case, right?

I guess I’ll have to try and see for myself then :sweat_smile:.

This is explained in the ntag datasheet.

If AUTHLIM is not set to 0 then a counter is kept of attempts to read a the protected area that do not authenticate successfully. When that counter reaches AUTHLIM then the protected area is permanently locked, and can never be read again. Successfully authenticating and reading the protected area before it is permanently locked resets the counter.

All this depends on NXP actually following their own datasheet of course.


Okay so I have tried writing to it with AUTH0 set to 04 and there is no password prompt from the app. Even after manually setting the correct 32bit password in the app preferences, it still returns “Read only, can not store.”.

Not being able to authenticate before reading is not that big of a problem anyway, I can always disable PROT manually and then read.

Now it’s probably safe to say this thread should contain enough information to achieve the configuration specified by me above :slight_smile: . Huge thanks for help people. When I bought my NExT from DT, all I needed it for was the LF side, but thought I might as well add the HF side on top since it’s in one capsule and not that expensive anyway. However, after achieving this configuration on the HF side, I’m more than happy with what this product provided me with. YOU GUYS ROCK :heart:


Apologies if I missed it, but are you using a Test Card for all of this or directly on your NExT?

If you need a test card, there are a few places you can get them, but I know KSEC stock them


If you are looking to do more testing and on different products in the future, I would definitely recommend one of their KSECs test card bundle or magic card pack , you could also get these from other places, but as far as I know KSEC are the only ones that do the bundles.


Directly on my NExT, since I did not know I was going to do any of this and thus didn’t know I’d need one. Now I was too impatient and also somewhat confident on my skill so far with the commands, thinking I understand how they work by now. So I did a hard test which worked :slight_smile: .

hmm no not at all hah :slight_smile: the UID can ALWAYS be read because it’s part of the ISO14443A standard. Regardless of getting it by reading the memory pages where it resides, it will always be transmitted as part of the ISO14443A communication protocol under the PICC SELECT process.

As for the other pages like 03 where the CC lives, maybe not… probably not… honestly I’ve never tried.

This is probably because you only set AUTH0 and have not set the PROT bit to 1. If PROT is 0 then you get exactly what you get - free open reads but must PWD_AUTH to write… just like it’s saying.

PROT cannot be disabled, it tells the chip how to handle memory pages protected from the page specified by AUTH0 to the end of memory. When set to 0 then those pages will be open to read without PWD_AUTH but the ISO14443A session must PWD_AUTH before those pages can be written to. When PROT is set to 1 then those pages can not be read until the session has a successful PWD_AUTH. There is no “disabled” setting for the PROT bit.

This is also true of the password. There is no way to “remove the password”… there will always be a value, even if it’s the factory default FF FF FF FF, it means it will be set to FF FF FF FF and there is no way to remove it. This is an important concept to understand, because the setting which dictates WHEN the password is required and for what commands / functions are set elsewhere such as AUTH0. The problem comes when people think they “have disabled or removed the password”, then set AUTH0 to something like 04 and wonder why they can’t now write data… because in their minds they “removed the password”… you can see how this misunderstanding could potentially cause problems later on.

1 Like