Cannot write to new xnt tag, strange password format?

Support
1

Hey all,

Got a new xnt tag implanted not too long ago and haven’t been able to write to it since. Shortly after installing it I used an Android phone and Dangerous NFC to set a 4-digit password. Since then, however, I haven’t been able to write to the tag and usually get error messages when using NXP TagWriter or NFC Tools. NFC Tools says it is still writable and is password protected.

From reading previous posts in the forum, it looks like both TagWriter and NFC Tools format their passwords a little weird. Particularly when it comes to setting Auth0 to “04,” which as far as I can tell is the case with my tag.

How can I get access to my tag again?

Here is the info I pulled from the tag:

Get Version: 00 04 04 02 01 00 13 03
Page 00: 04 56 E5 3F
Page 01: 12 FF 38 80
Page 02: 55 48 0F 00
Page 03: E1 12 6D 00
Page 04: 03 00 FE 00
Page 05: 00 00 00 00

Page E2 :00 00 00 BD
Page E3 :04 00 00 04
Page E4 :00 05 00 00

From the full NXP scan:

** TagInfo scan (version 4.24.4) 2018-10-29 16:11:56 **
Report Type: External

– IC INFO ------------------------------

IC manufacturer:

NXP Semiconductors

IC type:

NTAG216

– NDEF ------------------------------

No NDEF Message present:

– EXTRA ------------------------------

Memory size:

888 bytes user memory

  • 222 pages, with 4 bytes per page

IC detailed information:

Full product name: NT2H1611G0DUx
Capacitance: 50 pF

Version information:

Vendor ID: NXP
Type: NTAG
Subtype: 50 pF
Major version: 1
Minor version: V0
Storage size: 888 bytes
Protocol: ISO/IEC 14443-3

Configuration information:

ASCII mirror disabled
NFC counter: disabled
No limit on wrong password attempts
Strong load modulation enabled

Originality check:

Signature verified with NXP public key

– FULL SCAN ------------------------------

Technologies supported:

ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible

Android technology information:

Tag description:

  • TAG: Tech [android.nfc.tech.NfcA, android.nfc.tech.MifareUltralight, android.nfc.tech.Ndef]
  • Maximum transceive length: 253 bytes
  • Default maximum transceive time-out: 618 ms

Detailed protocol information:

ID: 04:56:E5:12:FF:38:80
ATQA: 0x4400
SAK: 0x00

Memory content:

[00] * 04:56:E5 3F (UID0-UID2, BCC0)
[01] * 12:FF:38:80 (UID3-UID6)
[02] * 55 48 0F 00 (BCC1, INT, LOCK0-LOCK1)
[03] * E1:12:6D:00 (OTP0-OTP3)
[04] +r 03 00 FE 00 |…|
[05] +r 00 00 00 00 |…|
[06] +r 00 00 00 00 |…|
[07] +r 00 00 00 00 |…|
[08] +r 00 00 00 00 |…|
[09] +r 00 00 00 00 |…|
[0A] +r 00 00 00 00 |…|
[0B] +r 00 00 00 00 |…|
[0C] +r 00 00 00 00 |…|
[0D] +r 00 00 00 00 |…|
[0E] +r 00 00 00 00 |…|
[0F] +r 00 00 00 00 |…|
[10] .r 00 00 00 00 |…|
[11] .r 00 00 00 00 |…|
[12] .r 00 00 00 00 |…|
[13] .r 00 00 00 00 |…|
[14] .r 00 00 00 00 |…|
[15] .r 00 00 00 00 |…|
[16] .r 00 00 00 00 |…|
[17] .r 00 00 00 00 |…|
[18] .r 00 00 00 00 |…|
[19] .r 00 00 00 00 |…|
[1A] .r 00 00 00 00 |…|
[1B] .r 00 00 00 00 |…|
[1C] .r 00 00 00 00 |…|
[1D] .r 00 00 00 00 |…|
[1E] .r 00 00 00 00 |…|
[1F] .r 00 00 00 00 |…|
[20] .r 00 00 00 00 |…|
[21] .r 00 00 00 00 |…|
[22] .r 00 00 00 00 |…|
[23] .r 00 00 00 00 |…|
[24] .r 00 00 00 00 |…|
[25] .r 00 00 00 00 |…|
[26] .r 00 00 00 00 |…|
[27] .r 00 00 00 00 |…|
[28] .r 00 00 00 00 |…|
[29] .r 00 00 00 00 |…|
[2A] .r 00 00 00 00 |…|
[2B] .r 00 00 00 00 |…|
[2C] .r 00 00 00 00 |…|
[2D] .r 00 00 00 00 |…|
[2E] .r 00 00 00 00 |…|
[2F] .r 00 00 00 00 |…|
[30] .r 00 00 00 00 |…|
[31] .r 00 00 00 00 |…|
[32] .r 00 00 00 00 |…|
[33] .r 00 00 00 00 |…|
[34] .r 00 00 00 00 |…|
[35] .r 00 00 00 00 |…|
[36] .r 00 00 00 00 |…|
[37] .r 00 00 00 00 |…|
[38] .r 00 00 00 00 |…|
[39] .r 00 00 00 00 |…|
[3A] .r 00 00 00 00 |…|
[3B] .r 00 00 00 00 |…|
[3C] .r 00 00 00 00 |…|
[3D] .r 00 00 00 00 |…|
[3E] .r 00 00 00 00 |…|
[3F] .r 00 00 00 00 |…|
[40] .r 00 00 00 00 |…|
[41] .r 00 00 00 00 |…|
[42] .r 00 00 00 00 |…|
[43] .r 00 00 00 00 |…|
[44] .r 00 00 00 00 |…|
[45] .r 00 00 00 00 |…|
[46] .r 00 00 00 00 |…|
[47] .r 00 00 00 00 |…|
[48] .r 00 00 00 00 |…|
[49] .r 00 00 00 00 |…|
[4A] .r 00 00 00 00 |…|
[4B] .r 00 00 00 00 |…|
[4C] .r 00 00 00 00 |…|
[4D] .r 00 00 00 00 |…|
[4E] .r 00 00 00 00 |…|
[4F] .r 00 00 00 00 |…|
[50] .r 00 00 00 00 |…|
[51] .r 00 00 00 00 |…|
[52] .r 00 00 00 00 |…|
[53] .r 00 00 00 00 |…|
[54] .r 00 00 00 00 |…|
[55] .r 00 00 00 00 |…|
[56] .r 00 00 00 00 |…|
[57] .r 00 00 00 00 |…|
[58] .r 00 00 00 00 |…|
[59] .r 00 00 00 00 |…|
[5A] .r 00 00 00 00 |…|
[5B] .r 00 00 00 00 |…|
[5C] .r 00 00 00 00 |…|
[5D] .r 00 00 00 00 |…|
[5E] .r 00 00 00 00 |…|
[5F] .r 00 00 00 00 |…|
[60] .r 00 00 00 00 |…|
[61] .r 00 00 00 00 |…|
[62] .r 00 00 00 00 |…|
[63] .r 00 00 00 00 |…|
[64] .r 00 00 00 00 |…|
[65] .r 00 00 00 00 |…|
[66] .r 00 00 00 00 |…|
[67] .r 00 00 00 00 |…|
[68] .r 00 00 00 00 |…|
[69] .r 00 00 00 00 |…|
[6A] .r 00 00 00 00 |…|
[6B] .r 00 00 00 00 |…|
[6C] .r 00 00 00 00 |…|
[6D] .r 00 00 00 00 |…|
[6E] .r 00 00 00 00 |…|
[6F] .r 00 00 00 00 |…|
[70] .r 00 00 00 00 |…|
[71] .r 00 00 00 00 |…|
[72] .r 00 00 00 00 |…|
[73] .r 00 00 00 00 |…|
[74] .r 00 00 00 00 |…|
[75] .r 00 00 00 00 |…|
[76] .r 00 00 00 00 |…|
[77] .r 00 00 00 00 |…|
[78] .r 00 00 00 00 |…|
[79] .r 00 00 00 00 |…|
[7A] .r 00 00 00 00 |…|
[7B] .r 00 00 00 00 |…|
[7C] .r 00 00 00 00 |…|
[7D] .r 00 00 00 00 |…|
[7E] .r 00 00 00 00 |…|
[7F] .r 00 00 00 00 |…|
[80] .r 00 00 00 00 |…|
[81] .r 00 00 00 00 |…|
[82] .r 00 00 00 00 |…|
[83] .r 00 00 00 00 |…|
[84] .r 00 00 00 00 |…|
[85] .r 00 00 00 00 |…|
[86] .r 00 00 00 00 |…|
[87] .r 00 00 00 00 |…|
[88] .r 00 00 00 00 |…|
[89] .r 00 00 00 00 |…|
[8A] .r 00 00 00 00 |…|
[8B] .r 00 00 00 00 |…|
[8C] .r 00 00 00 00 |…|
[8D] .r 00 00 00 00 |…|
[8E] .r 00 00 00 00 |…|
[8F] .r 00 00 00 00 |…|
[90] .r 00 00 00 00 |…|
[91] .r 00 00 00 00 |…|
[92] .r 00 00 00 00 |…|
[93] .r 00 00 00 00 |…|
[94] .r 00 00 00 00 |…|
[95] .r 00 00 00 00 |…|
[96] .r 00 00 00 00 |…|
[97] .r 00 00 00 00 |…|
[98] .r 00 00 00 00 |…|
[99] .r 00 00 00 00 |…|
[9A] .r 00 00 00 00 |…|
[9B] .r 00 00 00 00 |…|
[9C] .r 00 00 00 00 |…|
[9D] .r 00 00 00 00 |…|
[9E] .r 00 00 00 00 |…|
[9F] .r 00 00 00 00 |…|
[A0] .r 00 00 00 00 |…|
[A1] .r 00 00 00 00 |…|
[A2] .r 00 00 00 00 |…|
[A3] .r 00 00 00 00 |…|
[A4] .r 00 00 00 00 |…|
[A5] .r 00 00 00 00 |…|
[A6] .r 00 00 00 00 |…|
[A7] .r 00 00 00 00 |…|
[A8] .r 00 00 00 00 |…|
[A9] .r 00 00 00 00 |…|
[AA] .r 00 00 00 00 |…|
[AB] .r 00 00 00 00 |…|
[AC] .r 00 00 00 00 |…|
[AD] .r 00 00 00 00 |…|
[AE] .r 00 00 00 00 |…|
[AF] .r 00 00 00 00 |…|
[B0] .r 00 00 00 00 |…|
[B1] .r 00 00 00 00 |…|
[B2] .r 00 00 00 00 |…|
[B3] .r 00 00 00 00 |…|
[B4] .r 00 00 00 00 |…|
[B5] .r 00 00 00 00 |…|
[B6] .r 00 00 00 00 |…|
[B7] .r 00 00 00 00 |…|
[B8] .r 00 00 00 00 |…|
[B9] .r 00 00 00 00 |…|
[BA] .r 00 00 00 00 |…|
[BB] .r 00 00 00 00 |…|
[BC] .r 00 00 00 00 |…|
[BD] .r 00 00 00 00 |…|
[BE] .r 00 00 00 00 |…|
[BF] .r 00 00 00 00 |…|
[C0] .r 00 00 00 00 |…|
[C1] .r 00 00 00 00 |…|
[C2] .r 00 00 00 00 |…|
[C3] .r 00 00 00 00 |…|
[C4] .r 00 00 00 00 |…|
[C5] .r 00 00 00 00 |…|
[C6] .r 00 00 00 00 |…|
[C7] .r 00 00 00 00 |…|
[C8] .r 00 00 00 00 |…|
[C9] .r 00 00 00 00 |…|
[CA] .r 00 00 00 00 |…|
[CB] .r 00 00 00 00 |…|
[CC] .r 00 00 00 00 |…|
[CD] .r 00 00 00 00 |…|
[CE] .r 00 00 00 00 |…|
[CF] .r 00 00 00 00 |…|
[D0] .r 00 00 00 00 |…|
[D1] .r 00 00 00 00 |…|
[D2] .r 00 00 00 00 |…|
[D3] .r 00 00 00 00 |…|
[D4] .r 00 00 00 00 |…|
[D5] .r 00 00 00 00 |…|
[D6] .r 00 00 00 00 |…|
[D7] .r 00 00 00 00 |…|
[D8] .r 00 00 00 00 |…|
[D9] .r 00 00 00 00 |…|
[DA] .r 00 00 00 00 |…|
[DB] .r 00 00 00 00 |…|
[DC] .r 00 00 00 00 |…|
[DD] .r 00 00 00 00 |…|
[DE] .r 00 00 00 00 |…|
[DF] .r 00 00 00 00 |…|
[E0] .r 00 00 00 00 |…|
[E1] .r 00 00 00 00 |…|
[E2] .r 00 00 00 BD (LOCK2-LOCK4, CHK)
[E3] .r 04 00 00 04 (CFG, MIRROR, AUTH0)
[E4] .r 00 05 – -- (ACCESS)
[E5] +P XX XX XX XX (PWD0-PWD3)
[E6] +P XX XX – -- (PACK0-PACK1)

*:locked & blocked, x:locked,
+:blocked, .:un(b)locked, ?:unknown
r:readable (write-protected),
p:password protected, -:write-only
P:password protected write-only

2

Odd. Did you get an error when trying to use the Dangerous NFC tools app? I ask because E2 shows the dynamic lock bytes are still active, which means the DNFC app did not get to the point of changing password… that happens after writing to page E2 to disable the lock bytes completely. Also, somehow, AUTH0 was set to 04… which the DNFC app does not do… so something tells me that another app was used after DNFC and that app changed the password and set AUTH0 to page 04, which means you must PWD_AUTH first before you can write to any user pages from page 04 down (basically everything).

1 Like
3

@amal, when i use Dangerous NFC and do ‘select password’ and scan my tag, I get 'Error: Lock Bits Already Altered"

What is the best way to issue the PWD_AUTH command and is there a way to ‘reset’ the password or did using another app nuke the tag? (I believe the app used was NFC Tools.)

4

Definitely read this thread slowly and carefully - https://forum.dangerousthings.com/t/can-my-xnt-be-easily-set-to-read-only

5

thanks, @amal

I sideloaded the NFC Shell app and sent the following command:
1B h1 h2 h3 h4
A2 E3 04 00 00 04
A2 E4 80 05 00 00

Except with h1-h4 with the hex values of the password i tried to set on my chip.

It keeps returning ‘NAK’

If the lock bits are showing that I never saved a password on the chip in the first place, however, why would this allow me to regain access to the tag?

6

If it’s returning NAK that means you aren’t providing it the correct password bytes. Otherwise it would be returning the PACK bytes – ‘DT’ if they were set by the Dangerous Things App, and probably ‘00’ otherwise.

Are you sure the password on this tag wasn’t set by NFC Tools? Like @amal said it does look like another app may have been used to secure the tag. Both NFC Tools and NXP TagWriter will set Auth0 to 04, but NFC Tools scrambles or hashes the password so no other app will work to unlock it. :frowning_face:

It might be worth a try to use NFC Tools ‘remove password’ option and see if that works?

3 Likes
7

It worked! I guess I must’ve used NXP TagWriter to try to do the password in the first place. I am able to write and add/remove password fine now.

Just out of curiosity, why do the other apps do this to the Auth0 bit? Or rather, why does DNFC not do this?

8

I figure the other apps set Auth0 to page 4 when you password protect your tag, because they assume you want to write-protect the whole thing. The DT app is more concerned with protecting the ‘important’ pages while leaving the ‘regular’ memory area free to read/write. So it’s more of a protection + ease of use thing.

Personally I think the real question is why neither NFC Tools or NXP TagWriter let the user decide what to set Auth0 to. They’re both ‘all or nothing’ in terms of how they approach the password protection.

9

yep.

yep. sniffing around for a dev who wants to take a crack at updating DNFC… we’re all too busy focused on vivokey atm.

2 Likes
10

Specifically, from the TagInfo content of your first post, I can guess that this is what happened;

  • You ran Dangerous NFC, typed a password, and scanned your tag.

  • DNFC will check your CC (capability container) in page 03 and ensure it’s legit.

  • DNFC will update the two lock bytes in page 02 to accomplish two things; 1) lock page 03 to protect the OTP bits of the CC, and 2) lock the static lock bytes in page 02 making it impossible to make any further changes to the lock bytes, effectively disabling them. This leaves user memory blocks 04-0F unable to be locked. They can still be password protected, but not locked.

  • DNFC then attempted to disable the dynamic lock bytes in page E2 but there was a coupling problem and an error was produced… probably “tag lost” or something similar was displayed. At this point no changes have been made to the dynamic lock bytes protecting pages 10-E6, the password and PACK bytes have not been updated (they are still FF FF FF FF and 00 00 respectively), and the AUTH0 byte has not been changed from its default of FF.

  • You must have then attempted to use another app like NFC Tools or TagWriter to play around with the password setting, and that app then updated the password AND set AUTH0 to 04.

Does that sound accurate?

As mentioned above, only half the lock bytes were updated… the process was interrupted, so the lower lock bytes, password, PACK, and AUTH0 elements were never updated… only page 02 was updated by Dangerous NFC.

The wording of your question is kind of odd though… I’m not sure what you’re asking… but let me put it this way… it is impossible for the chip to NOT have a password. Memory page E5 will always have a value of some kind, even if that value is four null bytes… that is a value… so it is impossible to not have a password. What NXP decided to do was to make FF FF FF FF the “factory default” password… every NTAG216 chip made has FF FF FF FF as the default value stored in page E5… and pretty much every NFC app that knows how to talk to an NTAG216 (or any NTAG2xx) knows the default password is FF FF FF FF… because you cannot read page E5 or E6 from the NTAG216 chip, TagInfo will perform an PWD_AUTH command with FF FF FF FF by default and if it succeeds, it will show FF FF FF FF and then by doing PWD_AUTH it will get back the PACK too and be able to show that… but if the password has been changed, then TagInfo has no way to get the password out of the NTAG216, so it just shows XX, as it has above.

That said, lock bytes have nothing to do with tag access. Lock bytes are about letting an NFC chip be programmed with data and locked forever. In fact, the NFC application that the NTAG216 chip was designed for is called “smart poster” where these cheap tags are put behind printed poster advertisements so people can walk up and tap the poster to do something on their phone… and in those cases you have no reason to update the tags once deployed, and you don’t want people changing the content… hence lock bytes are useful for smart poster applications… but for an implant, lock bytes are utterly useless… so we disable them.

On top of that, there are certain configuration bytes in pages E3 and E4 that are absolutely terrible if set incorrectly… one will lock the configuration pages forever, and there is no way to disable this… and the other is a password counter that will basically count failed password attempts then lock your chip forever… and there is no way to permanently disable this, only turn the counter off… but if could be turned back on and then tripped… so that’s why Dangerous NFC sets AUTH0 to E2 and leaves the user memory bytes alone… if someone maliciously writes to your tag you can just overwrite it… no real harm done… and of course, you can change AUTH0 to fully write-protect the user memory as well if you want… we just didn’t want to over complicate things for customers right out of the gate… especially considering other NFC apps apparently do not handle password setting and authentication the same way… which is irritating and dumb… so again, I’m back to apparently needing to re-invent the wheel and update Dangerous NFC to do what it does now plus everything every other app can do too.

3 Likes
11

That trajectory sounds exactly right.

Thanks for explaining this to me! The chip has been working like a charm, now I just need to figure out what to do with it…

2 Likes
12

This is a surprisingly common issue from Biohackers with whom I’ve spoken. I bought mine for a specific use-case, only to discover the use-case’s door readers are too weak to read the implant.

@dmo1222 - I just read your recent implant article. Funny stuff. Thanks for sharing!