Ok. Holy shit. @MiniAardvark… apologies… @GrimEcho’s post had me re-read through all this… I mean… have you ever worked on something really hard… put in a ton of hours… really feel like you are living and breathing that thing you’ve worked on so hard… then suddenly you come across some of your previous work and you’re like “who’s the moron that did this? what kind of jackass would do such a thing?” only to realize it was you?
That’s just happened to me with this post.
I don’t even want to explain all the errors in what I said above… and there are many… I can’t even fathom why I made these errors… but I did. First off, the base counting thing mentioned above… then I was also getting the bit order wrong when talking about the first byte value… 04 and 08 are both wrong… the correct value to set the prot bit to 1 is 80 no 08… converted to binary, 0x80 is 1000 0000 which matches the LSB notation I gave above for the access byte schema. This is why you were able to still change the page value even after I thought the CFGLCK bit was set… but it wasn’t, because you weren’t changing that page at all… the correct page to set the PROT bit is E4 not E3… I honestly have no idea what the hell I was doing about a year ago… but it’s so embarrassing I want to just kill this whole thread… but I won’t… I will go back and fix it…
So, the proper commands for @MiniAardvark are:
1B h1 h2 h3 h4
A2 E3 04 00 00 04
A2 E4 80 05 00 00
Page E4 contains only one working byte… the ACCESS byte, which is where the PROT bit lives at bit position 7 which is the MSB, not the LSB.
Now, to address @GrimEcho’s remaining questions…
Well that sucks… it’s probably because of the new requirements for app listings. I had to go into the Play console and flip a couple settings on my apps to indicate they were not targeting children. I had 3 apps removed from the Play Store because I failed to mark those config changes before the deadline, so maybe that’s the issue and the author may or may not get around to it. In the mean time, here’s an exported APK of the app you can sideload.
NFC Shell 1.0.apk (15.6 KB)
Yes, the PACK returned is correct and you are authenticated… however you cannot remove the tag from the field… the authenticated session only lasts as long as the chip remains in the field and does not reach the HALT state. Typically it’s best to stack your commands to execute all at once so you don’t have to fiddle with manually inputting commands after you’ve authenticated your session.
The utility of changing the PACK is explained in detail elsewhere in the forum, but it’s a security measure. Basically if someone were to spoof your tag ID to a reader that is armed with a password check, the reader would just hand over the password with an AUTH command. If the PACK is standard, the spoofer could send 00 00 back and the reader would not know anything was wrong… but since the spoofer can’t get the PACK from your chip without the correct password, they would have to attack the reader first… and if the PACK is not sent back or the wrong, standard PACK is sent back, the reader is given that one chance to know something is wrong and possibly take action, like notifying security or disabling the permissions given to that UID/chip (like not opening a door for example). Make sense? The real infuriating thing here is that those app devs are lazy and they do not properly handle several things including lock bits and PACK… back when we first released DNFC, none of the tools properly handled lock bits and every single one of them, including NXP’s TagWriter app, declared that the chip was locked read only when it was not… they simply did no parsing and instead looked at the bits for any non-zero values… if any bits were flipped they just threw up their hands and said “well it’s all fucked, your chip is locked, sorry” and gave up. After much badgering and embarrassment thrown at them, many of them updated their code… but not to properly parse lock bits… they simply removed the lock bit check completely and then just dealt with write errors for truly locked chips instead. At this point, nobody has bothered with properly handling the PWD or PACK stuff. I regret even putting it into DNFC since we didn’t include a way for it to be changed… it’s still on our to-do list but so many other things keep popping up that it keeps getting pushed back. One day it will be updated… one day.
If you want to hear my rantings on other ways developers are lazy… you can read this; https://forum.dangerousthings.com/t/the-xnt-and-the-mysterious-46-48-byte-problem