XSIID - "Tag is not NDEF-compliant"

Tried writing business card, failed. Tried putting link on it, worked. Tried putting business card again, failed. Tried link again, get this error now…

In nfctools it now doesnt mention that its writable anymore…

XSIID green
TagWriter - iOS

1 Like

Just so no one wastes there time writing out a nice long and helpful essay… this issue has been solved. The NDEF record on the tag seemed to be corrupt, @Devilclarke posted an NFC shell command on here before that fixes the issue by simply writing a NFC record via commands directly. Devil and I ended up helping @Peter_Alfons_Loch out on the discord server

The commands are:

A20400000000
A20500000000
A2060000031F
A207D1011B55
A20803666F72
A209756D2E64
A20A616E6765
A20B726F7573
A20C7468696E
A20D67732E63
A20E6F6D2FFE

These can be run one at a time or as a block depending on how your app of choice works. I recommend NFC shell on android. Note, running commands directly can be dangerous if you are unsure of the commands so please do not modify the above commands unless you know what you are doing.

11 Likes

Yes this worked, thx again guys.

Cheers @leumas95 save me a job :slight_smile:

1 Like

Hey guys… so… I’ve been playing around myself trying to fix this because apparently NXP isn’t going to fix their TagWriter app to properly format the tag. There are missing TLVs (the 00s in pages 04, 05, and first bit of 06)… those define memory boundaries etc. and should be written as;

A20401037818
A2057702037B
A2067507

Now, if you are wanting to format the tag so it has a blank NDEF message, then the full data would be;

A20401037818
A2057702037B
A20675070304
A207D8000000
A208FE000000

… now… this doesn’t solve shit with TagWriter or NFC Tools, but it is the proper way these tags should be programmed, so I am updating my production process to use these TLVs. The next phase is to just make an Android app that fucking works… iOS 14 TagWriter doesn’t work either… so I went digging with the Proxmark3 … more study is needed but I am totally pissed off and we will sort this out one way or the other.

@hoker … once I get the proper stuff figured out, it might be time to join forces… I don’t have time to write up an Android app update / fix for this, but it appears we are going to have to do this ourselves… I think it might be time to open source the Dangerous NFC app (no idea why it wasn’t before, but whatever) and see about adding some of these woefully lacking features for specific products like the xSIID. You game?

5 Likes

16 posts were merged into an existing topic: DangerousNFC 2.0

Nice one bringing the support stuff back to the forum for everyone, rather than it disappearing into the annals of the discord server.

There are multiple chats for a variety of subjects. We recommend that you go to the DT forum for implant support as the user base is much larger and posting on there means your post can go on to help other in the future.

2 Likes

Ok I have put the info there, tagwriter ios now shows the correct size and smart nfc ios now shows that it can only write the first 1kb

Would anyone be willing to walk me through what those commands actually do individually, or better yet, suggest a good source to learn NFC shell commands? I received an XSIID recently (not installed yet), and I would like to understand the commands before I potentially have to figure out this issue, thanks in advance!

Source: https://www.nxp.com/docs/en/data-sheet/NTAG213F_216F.pdf page 32

The h at the end of the commands just means that it is hexadecimal, they are not written

Caution: You can seriously fuck up your chip with the commands.

Sure. All the NFC Shell commands (and most NFC related things in general) are broken up into hexadecimal bytes. The first byte in each of those lines is A2, which is the “write” command. The second byte (ex: 04) is the page in memory you would like to write to. Each page is broken up into 4 bytes, so for the first commands we’re writing null characters (00) to all four bytes in the fourth page of memory in the xSIID.

All the other commands are similar, except some pages contain valid characters which create an NDEF message that will navigate you to this forum URL. Paste the block of commands into a hex to ASCII converter to see the result in plain text. Don’t forget that zeros are null

1 Like

Thanks! I mostly just want to read up on it, I don’t intend to use many if any commands other than those covered earlier

That makes much more sense! Thank you so much, that helped quite a bit!

2 Likes

Is there any specific reason that the commands start with a space of null characters before the actual writing begins? Also, is there a reason that the first three pages are skipped entirely?

Pages 0, 1, 2, 3 are for configuration. They contain things like the UID and the Capability Container, some of which you cannot change, and some of which you should be very fucking careful changing.

I think Devilclarke left a bunch of empty pages at the beginning before writing the URI NDEF record because the forum URL is not very long, and he wanted to make sure that all the messed up bytes left over from whatever was previously written was completely overwritten. Wouldn’t want any vestigial data left over. Here’s an example of what a very similar NDEF record looks like on my tag using TagInfo, without the empty pages at the beginning:

[04] +r 03 26 D1 01 |␃&.␁|
[05] +r 22 55 00 68 |"U␀h|
[06] +r 74 74 70 73 |ttps|
[07] +r 3A 2F 2F 66 |://f|
[08] +r 6F 72 75 6D |orum|
[09] +r 2E 64 61 6E |.dan|
[0A] +r 67 65 72 6F |gero|
[0B] +r 75 73 74 68 |usth|
[0C] +r 69 6E 67 73 |ings|
[0D] +r 2E 63 6F 6D |.com|
3 Likes

Thanks a lot, you’ve been a lot of help!

2 Likes

I think he was mimicking what TagWriter does by mistake… the null bytes are where the TLV values are supposed to live, but instead of writing those TLVs, TagWriter writes nulls… it’s a bug… but the way Android handles NDEF messages, it keeps reading data until it hits the NDEF message envelope header… then it starts reading the NDEF message, record(s), and payload(s).

3 Likes

Sorry, I keep thinking of new questions… Is it pretty much always the first four pages for configuration, or does it depend on the chip? I don’t want to accidentally overwrite some config data because I thought it was free space…
Also, do the pages always start at 0, or do some start at 1?

For the NTAG chip variants the first four pages are usually the configuration bytes.
NTAG 216: xNT, NExT
NTAG I2C Plus: xSIID

The other chip variants are different. MIFARE has its own janky memory structure. DESFire chips have more of a file system. JavaCard is this whole other thing. The LF chips are all over the place.

In most technology the beginning is index position 0. That makes index position 1 the “second” position. It’s something you have to constantly keep in mind, especially when you’re working so close to the silicon like in this case.

2 Likes

That makes sense, thank you for taking the time to answer my questions!