If I get an xSIID, can I store a link or vCard that will automatically open, and also more arbitrary plaintext data? (I’m thinking of storing hand-encrypted backup/restore codes for my online accounts)
theoretically, yes. In reality, it depends on NDEF implementation / how hard it is to recover those codes. You can either add a NDEF record with a plain text type and hope the phone opens the first record automatically, or you can manually write data near the end of your tag (idk if that breaks NDEF storage, I could probably try it)
Assuming this is the xSIID, you could store the data in the 2nd kB of data, since that is not supported for NDEF records.
Do you have an example string (mainly length / number of them) that you want to store? I’m happy to try stuff out on my NTAG I2C test card for you.
Oh, and final question - are you an iPhone or android user?
Thanks for the reply! I’ve seen you around on here sharing a lot of a brilliant info in understandable ways. Appreciate that 
Yes, this would be the xSIID. I’ve read about that 2nd kB of data that’s inaccessible by NFC readers. But this still be read and written? What exactly is the capability of the 1st kB that the second one doesn’t have?
Let’s say my example string to store is something like:
Binance:
CEHNTOEBJSAJSMVQ
Facebook:
9083097845
34875983475
3847583745
93485345
GitHub:
ed4ac-92ba3a
4b982-cd2a89
Google:
2857 8838
1002 3948
Instagram:
2857 8838
2857 8838
2857 8838
Patreon:
sa8e-e83e-bceb-39ee
Reddit:
847774
9294311
(note: these are all fake)
Maybe a bit longer. Under 1,000 UTF8 characters seems doable for what I want to do. (I still have to figure out how to encrypt though, hopefully that won’t add to the character count.)
And then let’s say I want to have an NDEF record on the chip as well, that I can put a link to my website on, or my WiFi info.
I’m an iPhone user.
Could you test a setup like this? That would be amazing!
It would awesome to be able to read and write data to the 2nd kB because the recovery data I need is just plain text that doesn’t have to be NFC-enabled, as long as I can access it in an emergency (e.g., using an app I could download on a friend’s cell phone).
Thanks for the help!
2 Likes
Or just use something like popl and you can change everything on the page and leave the static url on your chip
1 Like
This is where shit gets kinda murky - NFC support for iPhones is a relatively recent thing, so idk how easy accessing that 2nd kB of data would be. Personally I’m an android user, but I do have access to iPhones (with thick cases… idk if I can actually use them very well 
)
This is quite complicated, and has kinda changed over time / as DT has changed how they program the implants in the factory. The short version is that the chip has been setup (for newer stock) so that only the first kB (actually 872 bytes) is usable for NDEF storage, due to no current phone app / system properly reading more NDEF data than that from a chip of this type.
Going back to the first part of this question, you can still read and write the 2nd kB of data, just not as / using NDEF. I had the same question, but I have experimented on the test card and yes, the 2nd sector is manually writable.
1 Like
Now for the other part of this: the actual implementation of storing those strings. The first thing is that you may want a delimiter (specific character / data which signifies the end / start of a string) - this then requires more space as well.
You also need to decide whether you want to ‘remember’ the data format, or if you want to make it very obvious - e.g. storing Instagram, Reddit, etc. with the strings. Same with a delimiter - you could use the ASCII / unicode for space, or newline.
Then we get into encoding and encryption:
Encoding is the easier one, with the most obvious being the ascii / unicode numbers represented in hexadecimal. This is basically storing it in plain-text, which if you’re storing the corresponding sites with the strings, is a bad idea.
You mentioned encryption, and this is probably a very good idea. The challenging part is that most / many only focus on letters, not a combination of letters and numbers.
Something kinda between encryption and encoding is increasing all ascii codes by a set number, though this is relatively easy to decode / easy to pick up on.
For testing purposes, I’ll just try it plaintext, with \ as a main delimiter for different sites and / as a code delimiter.
1 Like
Testing with plaintext is fine, I can encrypt any given string (including newlines to delineate individual codes) as ASCII using
$ openssl enc -aes256 -e -in example.txt -a -nosalt
(assuming a file example.txt containing the example in my previous post).
Putting the output of this into a file,
$ openssl enc -aes256 -e -in example.txt -a -nosalt > example.enc.txt
and entering an example password, let’s say dangerous when prompted results in a file example.enc.txt:
oZh+8+GOFTddsIGUx/EiuyQg23x9chPTZRDu1Je/Vdspx09xiIrqCV39KpcDh+fB
dX1OycNMsOCBW1ByHRjDzbtBTnbOA5ckuLnEmE6XxxxJv8fxFTdG6y6S58lULy7v
gvCMswVOdVq33DiK+fvcDm0L4FZi4PKTduymjJ+yqYZWQM0pDikJOcm81mhCVlZc
py2//hj4wzLFW+n7dLzBPQFSn7KXC9mQOjmNdPXoW372tEGNte4sE494SwR6JcaM
rpIMGoj8WTfymSSXFAEjR3hNXpkrFxVozj1e35IPa2LkmN0S1ocgzHvoj4gPrzaY
Now, running:
$ openssl enc -aes256 -d -in example.enc.txt -a -nosalt
should output the text of the original example!
I think this all means that if I can write plaintext to the chip, and retrieve it later, I can achieve my goal! To reiterate, my goal is to store recovery codes for internet accounts in xSIID memory, encrypted with a passphrase I store in my brain, so I will never lose them and be able to access my accounts in case of an emergency where I don’t have my phone, computer, or other 2FA items.
Requirements for this system to work:
-
Method of reading data off chip is ubiquitous enough
- I need to be able to do it within about a day if I lost my phone/laptop
- Downloading an app onto a friend’s phone, for example would be appropriate
-
Method of decrypting data on chip is ubiquitous enough
- unix’s
opensslseems common enough, access to a unix computer should be doable
- unix’s
-
Key is memorizable
-
openssl encsupports generation of keys from a password so I can choose whatever password I want and memorize that
-
As long as requirement 1 is met, I think I’m good to go!
3 Likes
So I’ve just tried reading the data back using raw commands with NFC shell, and apparently it doesn’t like reading more than 63 pages of information continuously using the FAST_READ command. Still, you can use multiple FAST_READ commands to read all of the data that you want.
The commands I used to read back the data from sector two, having stored the data starting at page 07:
C2FF
01000000
3A0745
3A4656
A brief explanation:
- The first two lines select sector 1 (the 2nd kB of data) - C2 being the sector select command, and 01 being the sector to select
- The third line uses the FAST_READ command 3A to read data from pages 07 - 45 inclusive
- The fourth line the reads the remaining data from page 46 - 56
3 Likes
This is so awesome! Thank you for testing this for me!!
Can you share how you loaded on the data using the NXP app? (Maybe this is super obvious I’ve just never used the app before.)
As for requirement 1, though:
Method of reading data off chip is ubiquitous enough
1 Like
This is where it gets interesting… I don’t think the NXP app, even on Android can load the data. Personally, I used raw page write commands with NFC shell on my OG Pixel.
Since manually converting every character into those commands sucks I used a short java program, because that’s what I’m comfortable with. I’m probably gonna try to port it to JS on a website and I’ll host it on netlify / github.
Here’s the start of the commands so you can see what it looks like:
C2FF // Change sector
01000000 // Sector 1
A2076F5A682B // Write to page 07 6F 5A 68 2B (oZh+)
Full command list
C2FF
01000000
A2076F5A682B
A208382B474F
A20946546464
A20A73494755
A20B782F4569
A20C75795167
A20D32337839
A20E63685054
A20F5A524475
A210314A652F
A21156647370
A21278303978
A21369497271
A21443563339
A2154B706344
A216682B6642
A2176458314F
A21879634E4D
A219734F4342
A21A57314279
A21B48526A44
A21C7A627442
A21D546E624F
A21E4135636B
A21F754C6E45
A2206D453658
A2217878784A
A22276386678
A22346546447
A22436793653
A22535386C55
A2264C793776
A2276776434D
A2287377564F
A22964567133
A22A3344694B
A22B2B667663
A22C446D304C
A22D34465A69
A22E34504B54
A22F6475796D
A2306A4A2B79
A23171595A57
A232514D3070
A23344696B4A
A2344F636D38
A235316D6843
A236566C5A63
A2377079322F
A2382F686A34
A239777A4C46
A23A572B6E37
A23B644C7A42
A23C50514653
A23D6E374B58
A23E43396D51
A23F4F6A6D4E
A2406450586F
A24157333732
A2427445474E
A24374653473
A24445343934
A24553775236
A2464A63614D
A2477270494D
A248476F6A38
A24957546679
A24A6D535358
A24B4641456A
A24C5233684E
A24D58706B72
A24E4678566F
A24F7A6A3165
A25033354950
A25161324C6B
A2526D4E3053
A253316F6367
A2547A48766F
A2556A346750
A256727A6159
1 Like
Very exciting! Happy to help if you’d like.
So writing/rewriting the secret info to an implanted chip will be a kind of hard (location android phone, run script, send commands via NFC Shell), but reading it will be much easier. Better than the other way around!
Is there a reason you start writing at page 07 of sector 1?
If you’re looking for an easy way to encrypt/decrypt NDEF on android, I made an app a while ago that does that very thing with OpenPGP APIs. So you can store text in this form:
And then on scan of that encrypted tag:
It will decrypt with your PGP keys through the same app. You just need to also have the OpenKeychain application installed with a keyset made. Just in case you want a different way to store your secrets:)
I use it constantly, with it only taking about 3 seconds to encrypt or decrypt text.
2 Likes
Mainly safety… if the change sector command fails, then it won’t try to overwrite the TLVs in page 4-6, the CC in page 3? and page 0-2 with UID etc. You can start at 0 if you really want / are certain you have a good coupling
This will need to be confirmed with an iPhone, but certainly with an android phone, yes
1 Like
That’s a very nice looking app! I’d certainly give it a shot
@identity is an iPhone user though (which means they might not even be able to do my way)
Ah, didn’t catch that. It really is a pain to get as much functionality out if these little buggers through iOS.
Is there any chance your app could be modified to support second sector data? Or does it support the NDEF record not being the first one?
1 Like