Hi,
I have my xNT since 2014 and I just figured out that I have the same CC : Question for a newbie about the lock of NFC chip - #9 by Satur9
My chip was ordered from dangerous things.
What can I do about that ? Did we got a bat batch?
Byte 2 is the NDEF size byte, and while 6D is the normal and suggested size for NTAG216, it does not fully utilize all physical user memory of the chip, but for … reasons … NXP chose 6D as their capability container size for the NTAG216.
A value of 6F is not standard, but should not cause any actual usability problems unless you push your data size to the limit, then it may (I would have to calculate this) push into the configuration bytes… but that problem can be averted if you can get your chip protected… which I see from your ticket you have tried but receive an error.
Can you post the full scan data of chip, or at least blocks E1 through E6?
Also what app did you use on your iPhone to get the raw tag data with?
Yes I got the error when I tried the DNFC app on a friend’s phone.
I don’t have android, so I wanted to try for the first time the app that I know for sure will handle the tags properly. I’m pretty aware of the fact that data-sheets are poorly made and contain many errors, manufacturers make a poor jobs on making decent documentation and even worst: many developers have a poor understanding on the different Tags technology and how to handle them properly so I never tried to use any third party app on iOS since 2014. (And also because until last month I never had an iPhone with NFC capability… 
)
So on my friend’s android phone my tag give him the bad CC error. I decided to dig the forum and the NXP data-sheet and yep I have a different CC from the standard NTAG216… wired… I still wanted to check the other registers with my phone…
But unfortunately on iOS we doesn’t have DNFC yet so I tried first Smart NFC
This is the only app (AFAIK) that can issue custom commands to the chip but it has a hard time to read correctly the tag (maybe because of the bad CC?)
I tried to issue the commend get version (60)
And the tag correctly reply 00:04:04:02:01:00:13:03
The other one that I use is NFC Tools and this one successfully read the user memory and can export the raw data.
This is the very first time I try to actually use the advance features of the N216 tag. Until now I was just using wiegand readers that read the UID for home access and I don’t think I ever set the OTP myself.
I may have tried to scan my tag with my Nintendo switch / Nintendo DS for fun to see if the antenna was beefy enough to get the tag (and they are) and I don’t think they set the bit to 6D (I hope not)
Ok well the CC cannot be changed back from 6F to 6D because page 03 used otp bits in it’s memory blocks. They can only go from 0 to 1 so you’re stuck with 6F… but again this should not have anything to do with problems writing… on iOS specifically it’s very likely to be a problem with a corrupted ndef message. Can you use smart NFC to format the tag or clear it somehow?
I can see from page 04 that you have an incomplete ndef message there… android can handle this but I bet iOS is choking on this.
2 Likes
Your thread about the xSIID memory is really interesting. Especially the part that show how to calculate the CC memory bytes.
So if I understand it correctly, 6F should be the correct value as it indicates 888 bytes of user memory.
0x6F = 111 in decimal so 111 x 8 = 888 bytes
instead of
0x6D = 109 and Thad give us 109 x 8 = 872 bytes
according to the data sheet. (But NXP throw away the last bits for legacy reasons?)
Did someone already tried to actually use the last pages of the 888 user memory to see if it doesn’t write into config bits ?
I’ll try to zeroed the user memory and bitlock my CC and all sensitives bits such as AUTH LIMIT and other annoying things that may break the tag.
If the “non standard” CC doesn’t affect the normal use of the tag (except for some pedantic app that won’t process the tags for not having a standard value) I’m perfectly ok with that
This will depend on a lot of things… but in short the setting has no impact on chip behavior it’s only meant as an indicator to the NFC compliant application performing the interaction… so you can definitely write to it with a direct write command… but whether or not an app will include that last memory page in it’s page map for writing ndef messages to, that’s another story… does the app calculate it’s own map and do direct write or does the app rely on Android nfc library to do all that? See what I mean it can get complex with software.
I wouldn’t bother to lock those bytes just set auth0 to E1 is enough, even with the default password