XSIID - password protecting the data inside your xSIID chip?

Are any of you xSIID users password protecting the data inside your xSIID chip? :thinking:

Admittedly no,

I want to play around with some ntag cards to get a feel for it before I mess with the xsiid as I really don’t wanna mess it up or accidentally set the locking bit

Somewhat? There’s always a password set, and on my test card I’ve set it to require the password to write to any of the 1st sector user data. My xSIID, I haven’t bothered yet

So not on the xSIID chip implant? :confused:
I got a couple of NFC cards and stickers and they all take password locks no problem. But I can’t figure out to lock an xSIID yet.

It’s the exact same chip. What exactly are you having trouble with?

Also are you using an iPhone?

I have Android, iPhone and macOS with ACR122 all with NFC Tools app.

And what is your goal with setting password settings on the xSIID?

Well I was showing it to a friend, and let her change my saved website link from her phone. So the immediate question she asked was, can you lock it so no one else can change it?

Definitely, especially if you use NFC Shell on android. So the goal is to set a password (or keep the default one) and allow reading but not writing of all data without the password?

Give me a few minutes, I’ll write up the NFC shell commands needed, along with a short explanation / references to the datasheet.

1 Like

In Japan the majority of users have iPhone. I just have an Android to test stuff when developing. So if there is a solution with iPhone would be best.

If you’re writing an app, the same commands will work…

I’m not an iPhone user sorry, so idk what apps support what

I see, NFC Shell is that an Android app?

Yes, it allows you to send raw commands to NFC chips (of certain types I believe, idk if it supports iso14b / iso15)

1 Like

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:


If you want to change the password too, here’s the short way:


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:


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!


Was wondering how long the split would take @Pilgrimsmaster :slight_smile:


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.