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 
.
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 
. 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 
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
https://cyborg.ksecsolutions.com/product/ksec-ntag216-xnt-next/
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 .
hmm no not at all hah 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.
I did not make such mistakes. I tried all the combinations, as I’m not a beginner with working such things. I don’t want this to sound like I’m not humble and grateful for your guidance. It just took me a while to understand the structure of the memory and the commands. I tried writing without PROT - failure even with password set in preferences. I tried reading with PROT - failure even with password set in preferences. This means there is probably no app out there which can authenticate before doing either of those actions, so I’ll probably write my own, but that’s not in the near future. Maybe with a little luck, sometime this year since I’m currently developing Android apps anyway.
By disabling it, I meant manually setting the protection boundaries to where they have no effect at all, do my thing, then turn it back on.
For reading
For writing
ah ok… well, this approach is not necessary… once you PWD_AUTH with the 1B command, your ISO14443A session will be considered to be in an authenticated state.You do not need to change PROT or AUTHLIM. Any data which was protected by PROT 1b and AUTH0 byte will be accessible can read it without issue. Also the counter for authentication attempts will be reset to 0 upon successful PWD_AUTH, so there is no need to change AUTHLIM. Once field power is removed (tag removed from reader) the ISO14443A session ends and the next attempt to read protected memory will be blocked until a successful PWD_AUTH
The same is true here, you do not need to change AUTH0 after authentication, those protected memory pages will be accessible for the duration of your ISO14443A session after a successful PWD_AUTH.
this part is the confusing bit… my guess is the password is not set correctly in the app. tagwriter should perform as expected without issue. Are you setting the password in tagwriter as ASCII or hex data?
@hoker is working on a new version of Dangerous NFC that will have all kinds of support for these kinds of situations. It is open source…
Didn’t tag writer use to make a change to the password you provide? I’m sure it used to change it slightly.
Of course, I’m well aware of any of those things. This does not solve my problem at all though → THE INTENTION IS TO USE THE FUNCTIONALITY OF READING / WRITING NDEF RECORDS, not splitting up the bits. Of course you could authenticate and then read by shell. But this approach is not viable if only because of what we talked about here:
The summary of what I think about this problem. → Unless I really messed up setting up the password in TagWriter prerferences, there is no app which allows you to send authentication command and then perform NDEF record reading or writing. What you can do is either my approach here
or authenticate, read and write with NFC Shell, but you would have to work with splitting up the memory bits, as you stated.
To answer the rest:
I’m not sure the preference of setting the password in the app is intended for authentication at all. It behaves rather awkward. My guess is it’s intended for setting the password. I don’t think it gives you the authentication ability at all. Also, it’s value goes back to it’s default after performing any interaction with the chip, either read or write. Strange.
I’m setting it as HEX, since the placeholder (default value of the field) in the app is FFFFFFFF as well.
Could very well be the issue why it does not work for authenticating as well. But the way these apps behave are not very well programmed in general IMO. As soon as you get an error indicating the authentication could be required, the user should get a prompt for entering the password and then the app should run the commands again, adding the authentication on top.
Sorta… but that’s a very old problem, and it was when you were allowed to enter ASCII data only, and in particular more than 4 bytes of ASCII data as the “password”… it then converted that in some odd way to 4 hex bytes to actually set the password with… then it was incompatible with every other app and you could not NFC shell it either.
Doing some testing now on an NTAG216…
Yeah so the problem is that TagWriter has a bug with password retention.
First set the tag up for read protection.
Can’t read with TagInfo. Success.
Go to TagWriter preferences, set the password.
Exit preferences screen and try to read tag data… days empty which is not true. There is a URL record written in there.
Go back to preferences and see the password is default FF FF FF FF.
I think the default display of the factory default password (FF FF FF FF) is actually a security setting… meaning you can’t get someone’s password by going there and looking… but… I also don’t think it’s actually saving the user entered password, or passing it the password to the chip either… pulling out Proxmark3 to sniff traffic…
Ok I see my password was wrong in TagWriter… fixed…
Still getting the same tag empty result though.
Getting proxmark3…
Ok here’s the sniff log from the Proxmark3. I attempted to read tag data with TagWriter.
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 1056 | Rdr |26(7) | | REQA
2228 | 4596 | Tag |44 00 | |
12432 | 17200 | Rdr |50 00 57 cd | ok | HALT
103072 | 104064 | Rdr |52(7) | | WUPA
105316 | 107684 | Tag |44 00 | |
115264 | 117728 | Rdr |93 20 | | ANTICOLL
132464 | 142992 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
144164 | 147684 | Tag |04 da 17 | |
155648 | 158112 | Rdr |95 20 | | ANTICOLL-2
159300 | 165188 | Tag |72 d5 38 80 1f | |
173200 | 183664 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
184916 | 188500 | Tag |00 fe 51 | |
474224 | 478992 | Rdr |50 00 57 cd | ok | HALT
699056 | 700048 | Rdr |52(7) | | WUPA
701300 | 703668 | Tag |44 00 | |
711728 | 722256 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
723444 | 726964 | Tag |04 da 17 | |
734080 | 744544 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
745796 | 749380 | Tag |00 fe 51 | |
857488 | 862256 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
863444 | 884244 | Tag |04 84 3a! 32! 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | !crc|
952432 | 957136 | Rdr |30 04 26 ee | ok | READBLOCK(4)
958388 | 959028 | Tag |00(4) | |
1068928 | 1073632 | Rdr |30 04 26 ee | ok | READBLOCK(4)
3752400 | 3753392 | Rdr |52(7) | | WUPA
3754644 | 3757012 | Tag |45! 00 | |
3765120 | 3775648 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
3776836 | 3780356 | Tag |0c! da 17 | |
3788288 | 3798752 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
3799892 | 3803604 | Tag |01! fd! a2 00! | |
3897072 | 3901840 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
3903028 | 3923828 | Tag |04 a4! 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | !crc|
3966496 | 3971200 | Rdr |30 04 26 ee | ok | READBLOCK(4)
3972452 | 3973092 | Tag |00(4) | |
4048528 | 4053232 | Rdr |30 04 26 ee | ok | READBLOCK(4)
6268512 | 6269504 | Rdr |52(7) | | WUPA
6270756 | 6273124 | Tag |44 00 | |
6280464 | 6290992 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
6292180 | 6295700 | Tag |04 da 17 | |
6303280 | 6313744 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
6314996 | 6318580 | Tag |00 fe 51 | |
6387680 | 6392448 | Rdr |50 00 57 cd | ok | HALT
6493248 | 6494240 | Rdr |52(7) | | WUPA
6495492 | 6497860 | Tag |44 00 | |
6506048 | 6516576 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
6517764 | 6521284 | Tag |04 da 17 | |
6528496 | 6538960 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
6540212 | 6543796 | Tag |00 fe d1! | |
6612880 | 6617584 | Rdr |30 02 10 8b | ok | READBLOCK(2)
6618836 | 6639636 | Tag |1f 48 0f 00 e1 10 6d 00 04 84 2a 22 72 d5 38 80 69 7d | ok |
6971440 | 6976208 | Rdr |50 00 57 cd | ok | HALT
7053664 | 7054656 | Rdr |52(7) | | WUPA
7055908 | 7058276 | Tag |44 00 | |
7075792 | 7086320 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
7087508 | 7091028 | Tag |04 da 17 | |
7098480 | 7108944 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
7110196 | 7113780 | Tag |00 fe 51 | |
7686304 | 7691072 | Rdr |50 00 57 cd | ok | HALT
7796736 | 7797728 | Rdr |52(7) | | WUPA
7799172 | 7799364 | Tag |01(0) | |
7809168 | 7819696 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
7820884 | 7824404 | Tag |04 da 17 | |
7832368 | 7842832 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
7844276 | 7845236 | Tag |7f(6) | |
7897984 | 7901600 | Rdr |60 f8 32 | ok | EV1 VERSION
7902788 | 7914436 | Tag |00 04 04 02 01 00 13 03 b1 ad | ok |
7964016 | 7968784 | Rdr |50 00 57 cd | ok | HALT
8049504 | 8050496 | Rdr |52(7) | | WUPA
8051748 | 8054116 | Tag |44 00 | |
8072592 | 8083120 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
8084308 | 8087828 | Tag |0c! da 17 | |
8095792 | 8106256 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
8107508 | 8111092 | Tag |00 fe 51 | |
8824144 | 8828912 | Rdr |50 00 57 cd | ok | HALT
8951280 | 8952272 | Rdr |52(7) | | WUPA
8953524 | 8955892 | Tag |44 00 | |
8973648 | 8984176 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
8985364 | 8988884 | Tag |05! db! 17 | |
8996464 | 9006928 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
9008180 | 9011764 | Tag |00 fe 51 | |
9063856 | 9068624 | Rdr |50 00 57 cd | ok | HALT
9189616 | 9190608 | Rdr |52(7) | | WUPA
9191860 | 9194228 | Tag |44 00 | |
9202560 | 9213088 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
9214276 | 9217796 | Tag |04 da 17 | |
9225008 | 9235472 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
9236724 | 9240308 | Tag |00 fe 51 | |
9304144 | 9308912 | Rdr |50 00 57 cd | ok | HALT
9426592 | 9427456 | Rdr |29(6) | |
9428532 | 9428788 | Tag |00(1) | |
9439040 | 9449568 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
9450756 | 9454276 | Tag |04 da 17 | |
9472720 | 9483184 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
9484436 | 9488020 | Tag |00 fe 51 | |
9551584 | 9556352 | Rdr |50 00 57 cd | ok | HALT
9680752 | 9681616 | Rdr |29(6) | |
9682644 | 9682900 | Tag |00(1) | |
9693056 | 9703584 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
9704772 | 9708292 | Tag |04 de! 17 | |
9716624 | 9727088 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
9796816 | 9800432 | Rdr |60 f8 32 | ok | EV1 VERSION
9801620 | 9813268 | Tag |00 04 04 02 01 00 13 23! b1 ad | !crc|
9854640 | 9859408 | Rdr |50 00 57 cd | ok | HALT
9962896 | 9963888 | Rdr |52(7) | | WUPA
9965332 | 9965524 | Tag |01(0) | |
9975456 | 9985984 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
9998752 | 10009216 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
10010468 | 10014052 | Tag |00 fe 51 | |
10235808 | 10240576 | Rdr |50 00 57 cd | ok | HALT
10324480 | 10325472 | Rdr |52(7) | | WUPA
10326724 | 10329092 | Tag |44 00 | |
10347328 | 10357856 | Rdr |93 70 88 04 84 2a 22 db c8 | ok | SELECT_UID
10359044 | 10362564 | Tag |04 da 17 | |
10370400 | 10380864 | Rdr |95 70 72 d5 38 80 1f d3 30 | ok | SELECT_UID-2
10382116 | 10385700 | Tag |00 fe 51 | |
12137744 | 12142512 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
12143700 | 12164500 | Tag |04 84 2a 22 72 d5 38 80 1f c8! 0f 00 e1 10 6d 00 7e d4 | !crc|
13978432 | 13983200 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
13984388 | 14005188 | Tag |04 84 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | ok |
15871072 | 15875840 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
15877028 | 15897828 | Tag |04 84 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | ok |
17781344 | 17786112 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
17787300 | 17808100 | Tag |04 84 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | ok |
19589216 | 19593984 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
19595172 | 19615972 | Tag |04 84 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | ok |
21389664 | 21394432 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
21395620 | 21416420 | Tag |14! 84 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | !crc|
23175248 | 23180016 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
23181204 | 23202004 | Tag |04 84 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | ok |
24983584 | 24988352 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
24989540 | 25010340 | Tag |04 84 2a 22 72 d5 38 80 1f c8! 0f 00 e1 10 6d 00 7e d4 | !crc|
26770752 | 26775520 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
26776708 | 26797508 | Tag |04 84 2a 22 72 d5 38 80 1f 48 0f 00 e1 10 6d 00 7e d4 | ok |
Ok so it appears there isn’t even a PWD_AUTH attempt being made here. I then simply tried to overwrite the record with TagWriter and that also failed.
This looks like a bug in TagWriter and I will submit it to them now.
Yep