I came across this post when looking for a way to possibly read-protect my nXT. However, I wanted to clarify a couple of things:
First, are the writes in “Send these commands” section correct? I’m referring to:
1B h1 h2 h3 h4
A2 E3 04 00 00 04
A2 E4 00 01 00 00
It seems that in a later response, Amal may have provided the wrong command and that using these could inevitably lock a config bit. Amal gives an alternate command of A2 E3 08 00 00 04. It appears that this command should replace the second command in the original (for protecting memory contents), but I’m not positive. If so, and the original instructions are wrong, then the original post should be edited or deleted.
Second, it appears that the Android NFC Shell app is no longer available. Are there any Android or PC alternatives? NFC Tools has an advanced section that can send individual commands and receive responses, but I’m hesitant to use it for more than some basic commands.
I used Dangerous NFC to protect my xNT implant with a password. My understanding is that this means that I should be able to send a PWD_AUTH command to the chip and receive a response. I read that DNFC changed the PACK response to 44:54. And when using NFC Tools to send a 1B:00:00:00:00, the response I receive is Error: I/O Failurer, but when I send a 1B:WW:XX:YY:ZZ where w, x, y, z are hex codes for the ascii characters of the password I set with Dangerous NFC, I receive a 44:54 result, which aligns with the original post. Is it safe then to perform the rest of the commands to read or write lock the tag?
In a previous post, Aman said:
The password (PWD) and acknowledgment (ACK) bytes default to FF FF FF FF and 00 00, respectively. Dangerous NFC changes the password to whatever you specify, and also sets the ACK to 44 54 (“DT”)… well this makes just about every other app out there shit the bed when it tries to perform an AUTH to first unlock the password page so it can write an update
This seems accurate as neither the NFC tools app or NXP Tag writer are able to successfully change the password set by DNFC. What is the reasoning for sending a non-default PACK response to a successful password? Is there a danger to having the PACK respond with 00:00, or to having another tool be able to change the password? Once the lock bits are protected and assuming that the user doesn’t forget the password, it seems safe to allow other tools access.