1/ Why do you want to password a LF chip? I mean sure, why not, but who’s going to sneak up on you and reprogram it, realistically?
2/ What does Android have to do with it? Are you trying to use the PM3’s Android client? Because if you try to use a cellphone to reprogram a T5577, that ain’t never going to work.
xEM is a LF chip. You have to use the PM3 for that one. Cellphones won’t work.
Okay then you have a NeXT. If you’re talking to the HF part, you can use a PM3, but not the t55xx commands: those are LF commands.
If you password-protect the LF side (t55xx), it’ll just prevent reprogramming the chip into another configuration.
But since you talk about data, I assume you’re talking about the HF side. If you password-protect it, it depends on what the password protects exactly. You can set pages to be write-only, read-only or entirely inaccessible without a password. What are you trying to achieve exactly?
Also, if you or DT have run the DT app on that chip, it’s already password-protected. If you did it, I hope you remember the password. If DT did it, well I don’t know what they put on it.
Ok. I thought the LF side had SOME capacity for storing information.
I have tried the HF side with the app. It allows me to type in the PW then nothing
No response when close to the reader ( in the phone ).
And I can still completely access all info on the xNT side
I want to make the XNT side. Password protected so it is read only
NOT Locked
I’m not really worried about a person intentionally doing it
More so that a wierd scan or EM field causes corruption of a read write tag
I work around a lot of EM fields regularly.
However I have had an excessive amount of caffeine and got started working on the LF side for some reason.
And now we’re here haha. Thanks for the quick reply as well
In certain configurations, it does. Configured as an EM, it’s just a UID-spewing device essentially.
The app should tell you it’s done, or throw an error if the password protection is already in place. If it doesn’t answer at all, it’s not normal.
The DT app won’t make your chip unreadable (or unwriteable - not the NDEF record anyway). What it does it configure the chip so that it can’t be bricked accidentally. If you want to truly use the password protection to make portions of it unreadable, you’ll have to dive into sending custom commands to the NTAG chip (not sure TagWriter does it).
Be careful when programming the LF side (T5577): those chips can get bricked if you do it without being very careful with coupling. The less you do it - and the more careful you are when you do it - the better.
Your NExT does not need to be protected by the Dangerous NFC app, it is already protected at the factory. The configuration memory pages on your NExT should look similar to this:
The default password for the HF side of the NExT is “NExT” (4E 45 78 54). If you want to change it you will have to include that password as an authentication in any write commands to protected memory pages.
If you want to protect the user memory pages (04-E1) your can change the AUTH0 byte to 04, and it would password protect everything after page 04.
I usually use TagInfo for advanced reading and NFC Shell for advanced writing of HF tags (both Android apps). I usually don’t bother with HF on the proxmark because it’s seldom worth the effort (other than MIFARE). You absolutely need the Proxmark for LF tags though.
I can help you with NFC Shell commands if you want, though you seem to want to use the Proxmark. The community at large should be able to help you with proxmark commands.
Two suggestions just for clarity. I would edit all your references to the xEM and xNT to just say NExT (HF and LF side). While they have the same chips, the NExT is pre-configured while the xNT is not, and they have slightly different antennas because of the form factor. I would also hesitate to use the term “UID” for LF implants. Just ID would be better. UID is reserved for 7 byte ID HF tags that are truly unique.