Now, I want lock my chip with the dangerous things programs but one question, I just need to tape my new password ( 4 digits, exemple 9988) and scan my chip and it’s protect? I’m afraid to make that and lock for life my chip…
Yes, just enter your desired password in to the Dangerous NFC app and scan. It will do the rest to disable your lock bytes and protect your configuration pages with your password, but leave the user writable memory open for read/write operations.
Have you used any other scanners or reader/writers on it yet? Any possibility it was modified by something beforehand?
The CC is a page of OTP bytes that can only be flipped from 0 to 1, but not back again… so the 6D is 0110 1101 in binary, and 6F is 0110 1111… so something flipped that one bit, and it’s not able to be recovered.
The 6D byte in the CC is a size indicator. It tells NFC readers the amount of memory available for NDEF data. It’s values are laid out on page 16 of the NTAG specifications, but I’ll post it here for easy reference;
Are you sure this is an xNT chip? From the support scan, it doesn’t appear to be. The order checks out, and we did ship you an xNT, but the scan data does not appear correct for the xNT.
It would be interesting to know where the problem came from?
I didn’t know until today that I had this problem, too. I got my xNT in 2016 and never noticed the problem, because I tried the Dangerous NFC App on the xNT for the first time today.
I also have other implants (e.g. FlexNT) and they don’t have the wrong CC.
It’s possible that bit in the EEPROM was hit by cosmic radiation (no joke) and flipped. There’s a non-zero chance of that happening, and it seems like a viable explanation considering the small number of people affected.
Normally the ECC on the chip would correct for any erroneous bit-flipping. Unfortunately, those bits in the Capability Container are One Time Programmable, it’s possible the ECC can’t fix them.
more likely it doesn’t even have an error correction routine for this kind of problem, considering these chips are designed for throw-away smart-poster applications.
No idea what’s up here… but the 6F value is incorrect… that byte specifies the maximum NDEF container size possible using the data pages. A setting of 6F is too large and if NDEF software is actually doing it’s job and calculating space with that byte, it will write data overtop of the configuration pages at the end of the tag (pages E2-E6) which could result in some serious trouble.
If you’d like to manually disable your lock bytes and set up protections for your xNT you can use NFC Shell (referenced many times in this forum) and the write command A2 followed by the page number and 4 bytes of data you want to write to that page… do your page re-writes one by one, including password, and then set your auth0 byte to E2 last.
Order 
