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.
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 writingwithout PROT - failure even with password set in preferences. I tried readingwith 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.
1B XX XX XX XX - Authenticate
A2 E4 00 05 00 00 - Disable PROT & AUTHLIM
1B XX XX XX XX - Authenticate
A2 E3 04 00 00 E2 - Set AUTH0 to protect only memory pages from E2 onward.
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…
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.
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…