Dangerous NFC app issues

Timeout.

EDIT: Sorry, I get timeout with the Proxmark3 running the raw command. NFC Shell reports NAK. But same thing really.

To expand on this… pages E5 and E6 cannot be read from, however taginfo will do a pwd_auth attempt with factory default and if it comes back with a pack and not an error code it will know the password and display the default password and pack it responded with in the full data report… but this is not because it read the data from E5 and E6. It’s also a shitty thing to do because I seriously doubt they are checking the config bytes for authlim setting and could mess up a secured tag really bad by systematically checking passwords on tags.

I tried it with a Nokia 4.2 and a Samsung Galaxy J5. I tried a bunch of tags, and I have a 50/50 chance of getting the “transceive failed” message.

I actually know where it happens: when the app fails, the tag sends NAK when it tries to set the dynamic lock bits. It makes no sense to me why it fails there, but what happens then is, the app quits (so doesn’t set the password or the PACK), pukes out the popup and that’s it.

Afterwards, if I try to do a PWD_AUTH in NFC Shell, it reports NAK (but since it won’t show the actual data returned, I suspect it says that because the tag timed out). When I try to do a PWD_AUTH in the PM3, it times out (0 bytes returned).

The tags that have survived the DT NFC app return the PACK when I do a PWD_AUTH, both in NFC Shell and the PM3.

I’m still investigating.

1 Like

Fuck I hope we don’t have counterfeit ntags in the market now…

Well, I ordered 5 Bullseyes with my doNExT. You sent me 5 Bullseyes from the same roll (or Michelle did, I guess). Out of the 5, 2 are fucked up (timeout when doing PWD_AUTH) and 2 are okay. I’m keeping the last one intact for other tests before implanting the doNExT - don’t want to burn all my rounds here.

So that’s not it: you ain’t gonna get a mix of fake and genuine tags in the same roll.

As for the fucked up NTAG 216 from KSEC, you’ll have to ask Kai if it’s the real McCoy :slight_smile:

Not likely no, but not impossible. Smartrac buys diced dies in bulk… we might not know if lots are mixed anywhere along the way… but yes, unlikely.

I’ll see if there is any errata about the ntag216 that might explain this.

I’ve perused the entire documentation, and the only thing I see that suggests a timeout can happen as a normal “response” (or lack thereof) is in the PWD_AUTH protocol description itself:

image

But then it says that for all the functions. Other than that, no mention of a possible timeout. I thought maybe it could occur if the AUTHLIM was exceeded, but no: it should return something even in that case.

I’m at the point where I’m wondering if there are subpar chips coming out of the foundry with the PWD_AUTH function plain and simply disabled, so they can sell the chip anyway, just with something missing. Kind of like in the old days when the math coprocessor in a 486DX was messed up and the CPU was stamped 486SX and sold anyway for less.

Here are the relevant bits of the PM3 traces, if you want to take a look:

  • Successful run of the Dangerous NFC app on an NTAG 216:
 4785392 |    4790096 | Rdr |30  03  99  9a                                                           |  ok | READBLOCK(3)
 4791348 |    4812148 | Tag |e1  10  6d  00  03  00  fe  00  00  00  00  00  00  00  00  00  4a  93   |  ok |
 4866576 |    4875952 | Rdr |a2  03  e1  12  6d  00  da  ef                                           |  ok | WRITEBLOCK(3)
 4931540 |    4932116 | Tag |0a!                                                                      |     |
 4971888 |    4976592 | Rdr |30  02  10  8b                                                           |  ok | READBLOCK(2)
 4977844 |    4998644 | Tag |ff  48  00  00  e1  12  6d  00  03  00  fe  00  00  00  00  00  41  cf   |  ok |
 5041168 |    5050544 | Rdr |a2  02  ff  48  0f  00  01  2f                                           |  ok | WRITEBLOCK(2)
 5106132 |    5106708 | Tag |0a!                                                                      |     |
 5142608 |    5147312 | Rdr |30  e2  1e  6c                                                           |  ok | READBLOCK(226)
 5148564 |    5169364 | Tag |00  00  00  bd  04  00  00  ff  00  05  00  00  00  00  00  00  70  17   |  ok |
 5216512 |    5225824 | Rdr |a2  e2  00  00  7f  bd  2b  9f                                           |  ok | WRITEBLOCK(226) (?)
 5281476 |    5282052 | Tag |0a!                                                                      |     |
 5326496 |    5335808 | Rdr |a2  e5  41  42  43  44  79  63                                           |  ok | WRITEBLOCK(229) (?)
 5391460 |    5392036 | Tag |0a!                                                                      |     |
 5435728 |    5445040 | Rdr |a2  e6  44  54  00  00  80  2b                                           |  ok | WRITEBLOCK(230) (?)
 5500692 |    5501268 | Tag |0a!                                                                      |     |
 5543952 |    5548656 | Rdr |30  e3  97  7d                                                           |  ok | READBLOCK(227)
 5549908 |    5570772 | Tag |04  00  00  ff  00  05  00  00  00  00  00  00  00  00  00  00  39  15   |  ok |
 5635536 |    5644848 | Rdr |a2  e3  04  00  00  e2  fd  3f                                           |  ok | WRITEBLOCK(227) (?)
 5700500 |    5701076 | Tag |0a!                                                                      |     |
  • Failed run of the Dangerous NFC app on an NTAG 216, leaving the chip unable to answer PWD_AUTH:
 9489904 |    9494608 | Rdr |30  03  99  9a                                                           |  ok | READBLOCK(3)
 9495876 |    9516740 | Tag |e1  10  6d  00  03  04  d8  00  00  00  fe  00  00  00  00  00  79  70   |  ok |
 9580640 |    9590016 | Rdr |a2  03  e1  12  6d  00  da  ef                                           |  ok | WRITEBLOCK(3)
 9645620 |    9646196 | Tag |0a!                                                                      |     |
 9688000 |    9692704 | Rdr |30  02  10  8b                                                           |  ok | READBLOCK(2)
 9693972 |    9714836 | Tag |e8  48  00  00  e1  12  6d  00  03  04  d8  00  00  00  fe  00  7e  c8   |  ok |
 9777056 |    9786368 | Rdr |a2  02  e8  48  0f  00  81  bb                                           |  ok | WRITEBLOCK(2)
 9842036 |    9842612 | Tag |0a!                                                                      |     |
 9881200 |    9885904 | Rdr |30  e2  1e  6c                                                           |  ok | READBLOCK(226)
 9887172 |    9907972 | Tag |00  00  00  bd  04  00  00  e1  00  05  00  00  00  00  00  00  31  33   |  ok |
 9969328 |    9978640 | Rdr |a2  e2  00  00  7f  bd  2b  9f                                           |  ok | WRITEBLOCK(226) (?)
 9979908 |    9980548 | Tag |00!                                                                      |     |
10015024 |   10019792 | Rdr |50  00  57  cd                                                           |  ok | HALT
1 Like

Anyhow, not running the app on my doNExT until all this is clarified…

Can you sniff the pwd_auth command from NFC shell on a phone? It should be FF FF FF FF still on those tags.

There ya go. Like I said, timeout:

 1549744 |    1557904 | Rdr |1b  ff  ff  ff  ff  63  00                                               |  ok | PWD-AUTH KEY: 0xffffffff
 5642448 |    5647216 | Rdr |50  00  57  cd                                                           |  ok | HALT

NFC Shell reports NAK.

Wow so no tag response at all… sheesh

I think it’s clear from the traces provided by the proxmark3 that the issue is not with the Dangerous NFC app… the command sent to the tag is correct…

 9969328 |    9978640 | Rdr |a2  e2  00  00  7f  bd  2b  9f                                           |  ok | WRITEBLOCK(226) (?)
 9979908 |    9980548 | Tag |00!  

…the chip just errors and from that point on it fails to respond to PWD_AUTH, which has nothing to do with page E2… something is really wrong here.

Son of a bitch… NXP… wtf. Ok, so, when writing E2 byte 03 should always be written as 00 but will always read as BD. No errata on this or the password function but this is what’s supposed to be happening when writing the dynamic lock bytes page on the ntag21x series tags… all based on a lonely footnote in the spec sheet.

FML.

What further confuses me here is that we program all the chips during testing, just before putting into syringes, and byte 03 is a RFU byte, and we push BD during programming too, and we’ve never had this outcome.

Actually, the spec explicitely says RFUI bytes / bits should be written as zero.(table 10, page 19). No oversight from NXP there: the app doesn’t do what it should do for sure.

I did spot that one when I looked at the traces. So I tried to re-issue the write command to E2 with the BD zeroed out (so, a2 e2 00 00 7f 00) on one of the fucked up tags, but it still returned NAK. So I figured it was something else.

So are you saying doing that write with BD messes up the chip permanently? Did you confirm this or is that an educated guess?

If this is undocumented, it might depend on the power supply level, or it might be susceptible to tearing or something. My best guess is, you have the right cellphone(s), or the right combination of some other factors, and you’ve been lucky so far. But I have the right gear to trigger the issue.

If you’re gonna correct the app, I’m gonna order me a bunch of Bullseyes to do a solid round of testing before doing it on the implant, cuz I’ve run out :slight_smile:

No it’s a guess that it may have something to do with it… as you speculated it may be a combination of this and low power or wonky coupling… but still that seems suspect… I’ve always pushed BD and the app has too, even on xNTs with shit couplings and it’s worked fine… this is the first report of this issue I’ve ever seen which is why it makes me wonder about the chip itself being legit.

Have you been running the app on all the Bullseyes you’ve turned into implants lately? No issues?

Just a thought: if NXP changed the die and started to use that byte to lock certain pages that include the password or the PACK, that might explain. On my messed up chips, I can’t write to the PACK page anymore (I should be able to, since the password isn’t set). And the chip would find the password page unreadable even for itself or something.

In other words, the chips might be legit, just a different variant that doesn’t take too well to writing BD in the byte.