Awesome, ok got that one. Couldn’t find anything like that for iOS.
So is there a way to allow normal NFC Tools to put a password?
Maybe… I haven’t really tried it tbh, since I prefer to know what apps do before I use them.
1 Like
Well, all I want is to be able to know is how to put a normal password on the data I save inside the xSIID but can’t find “how” to yet.
Ok, so here are the NFC Shell commands to prevent writing pages 04 onwards (user memory) without the password, keeping the default password of DNGR converted to hex using ascii codes:
1B444E4752
A2E300000004
If you want to change the password too, here’s the short way:
1B444E4752
A2E300000004
A2E5XXXXXXXX
An explanation:
First is the PWD_AUTH command (1B), using the DT set default password of DNGR (44 4E 47 52). This allows us to now write to any protected memory, which if I recall correctly is pages E2 onwards from DT factory.
Then we write (command A2) to page E3, which contains the AUTH0 byte, setting which page onwards is protected by the password set in page E5. For the NTAG I2C plus, user memory in sector one starts at page 4, hence the 04. The other (first) 3 bytes in that page are RFU (reserved for future use) and are thus written as 0.
Finally, a new password can be written (command A2) to page E5… replace XXXXXXXX with 4 bytes worth of hex characters (8 hexadecimal characters). Note that if this goes wrong / if you forget the password, there is no easy way, if at all, to recover. If you want to really be paranoid, here’s how I’d do it:
1B444E4752
A2E3000000FF
A2E5XXXXXXXX
This sets no pages, including password and configuration pages, to be protected, thus making it easy to rectify a mistake. I would then take the chip away from the reader then back into range and send 1BXXXXXXXX, making sure it returns PAK (00 by default). This indicates that the password was successfully set, and then A2E300000004 will write protect the data on the chip.
The datasheet is very helpful: https://dangerousthings.com/wp-content/uploads/doc_NT3H2111_2211.pdf
See page 51 for the PWD_AUTH command, page 55 for the WRITE command, page 14 for the NFC memory map, and pages 27-29 for password and access configuration information. If you wish to look at preventing reading the data on the tag without the password too, look at the NFC_PROT bit in the ACCESS byte… but be careful, there’s some pretty nasty settings in that page.
Also, I’d seriously recommend trying it on a NTAG I2C test card first (I’m happy to do so when I’m back from my holiday on the 11th of January), as I would not like to be responsible for bricking someones xSIID.
Another thing to note is that I’m not sure how apps support writing to password protected tags… it may be necessary to set the AUTH0 byte in page E3 back to E2 or FF to allow apps to easily write to the tag.
Please, do let me know if you need any more information / clarification, though I am off to bed so will respond in the morning. Hope this helps!
5 Likes
Ok, that went a little above my pay grade. (X_X’)!
I was just understanding the Type 4 where you need APDU commands, but I realized this is a Type 2 chip and is a completely different beast when it comes to commands.
It would be nice to have it “just work” with simple apps like NFC Tools that a lot of people is using to save some data on their chips. Is there a way to make it work with NFC Tools? Sorry to ask a lot.
1 Like
Yeah, type 2 chips are a bit different but also easier than type 4 chips. I’ll have an experiment with NFC tools once I get back home, but you’d still use it to write data to your tag. It probably even allows you to enter the password to write new data to the tag once user memory is protected.
As for setting passwords, I’m not sure, but it might work. Honestly, the biggest issue will be setting AUTH0 - for most people’s purposes, either E2 or 04 as options are sufficient (protecting just config, like from DT factory, or protect all of user memory + config), but AUTH0 accepts anything from 00 to FF. Making that simple enough for normal users while not pissing off power users and also not messing up other chips is an issue.
@hoker was building an NFC app, that Might be a consideration for that
also @NixieGeek was building an app, I think it was DF / DF2 centric though…not 100% on that, Haven’t seen it for a while
1 Like
He’s always watching
1 Like
I plan on adding xSIID functionality to my little BioCom app, but first I’m going to prioritize the completion of the DangerousNFC application, which will also hopefully work fully with the xSIID.
2 Likes
Just by the way you answer. Sounds like Android only app. 
Ah, sorry. I missed that you were wanting iOS:P
I can make iOS apps. In fact, I’m working on the VivoKey App for iOS right now.
Just that I haven’t touched Type 2 yet and wouldn’t even know where to start.
Perhaps one day we can work together in something?
I always welcome collaboration:)
Type 2 in general is relatively easy / simple, except for the sheer number of different configuration options different chips have 
You can send custom NFC commands with the Android version of NFC Tools pretty easily. Not sure about Apple, but my understanding is that access to the shell is limited on Apple for “security”.
3 Likes
Very nice! Only potential issue I see is needing to send only one command at a time… which you’d need to send 2 minimum without leaving the field. Either gotta be good at one handed phone holding / typing, or have someone to help you.
DAMN!
OK! Now I need some crash course on Type 2 commands compatible with the xSIID. I know there is that PDF but just opening it on the browser I feel an imminent dyslexia attack.
2 Likes
We got pretty much all the datasheets in the discord as well as the type 2 and 4 command documentation 
always nice to have it all in one place.
1 Like