Hello, I’d like to perform these steps in order to set up my new NTAG216 exactly the way I want it.
Clear all records in the user memory segment. - Done via DT Support app.
Create a text file record with desired content and write it to the tag. - Will be done through a third party app, no shell command needed.
Set PWD to desired value. - A2 E5 XX XX XX XX
Set AUTH0 to protect user memory segment. - A2 E3 04 00 00 04
Set PROT to 1b & Set AUTHLIM to 111b. - A2 E4 87 05 00 00
Some of these steps have a NFC Shell command already issued to it, that is the case when I think I’ve managed to sort them out. I’m asking you to look at the steps, check the commands which I think I’ve sorted out, and hopefully come up with how the other commands should look like, so that I can set up my NTAG216 with confidence, knowing I’m not going to brick it :).
After hopefully sorting out this configuration process, I have a few more questions I’d like to have answered if possible. How to use third party app’s functionality (DT Support Tool, NFC Tools, etc.) after having PROT set to 1? These kinds of apps usually allow you to perform certain actions, but to my knowledge, there’s no real way of having them send a B1 command before doing either of those actions. The only app which I know which I can authenticate through before doing anything else is the NFC Shell, but that one does not allow me to read/write NDEF records, or does it?
2 should be done by app, especially if you want the data wrapped in an NDEF text record. Otherwise if you just want raw binary data stored, you can use she’ll commands and split it up yourself across memory pages.
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 . 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.
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.
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?
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 TagWritershould try to prompt you for a password and then use that to properly read and update/write to your tag.
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 . 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
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.
.
. 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.
it has some good she’ll info
.