Also, I should mention something else: I presented one of my tags to the Dangerous NFC app, the app said “Transceive failed” on that one, and now that tag is hosed: I can’t authenticate with the password I had set (the tag won’t answer the PWD_AUTH command at all). So, caveat emptor…
Not that it discounts your conclusion, but is this also a case of the other NFC apps trying to be clever? Any PACK is a valid PACK isn’t it? Why should the other apps reject it if it isn’t the default 0x0000?
I think all NFC apps at the moment try and be too smart, don’t understand things like partial-password protection, etc. In trying to be smart they all work differently (and different to what the datasheet would imply) - and incompatibility different at that.
I hope the new DT app V2 learns from some of this and becomes multi-platform!
That’s not what I’m saying: I’m saying the Dangerous NFC app should set a PACK that’s compatible with at least one other tool out there. As it is now, it just makes the tag unusable with anything else - at least as far as modifying the password is concerned.
I get that, but shouldn’t every other app also accept any PACK? The other suggestion could be that it sets lock bits but doesn’t set a password, leaving the owner free to set the password using any app they like?
Like, if you issue a password command, the chip doesn’t respond with a rejection, isn’t that a valid authentication?
Why program it to continue if 0x0000 instead of continue if not FAIL?
I’m not arguing that the way the DT app does it isn’t a bit dumb, I’m saying isn’t there equal dumbness on all sides.
Well that depends on what you want to do: if you want to make a convenience app that’s compatible with other stuff (that DT has no control over, like TagWriter) then it should try to adapt to that other stuff. If the idea is to do it all separately, then fine: setting any PACK will do.
The problem is, when you’re done running the Dangerous NFC app, it leaves you with your cojones in the cold because there’s no other app that accepts the PACK it sets. If it had a complete set of features to work with NFC tags, I’d understand. But it doesn’t. So yeah, dumb-di-di-dumb-dumb.
And let’s not forget, it fucked up one of my test Bullseyes. That doesn’t really make me want to run it on my brand-new $269 doNExT…
1 Like
Okay, I’ve tried to run the Dangerous NFC app on another NTAG 216 tag (a card I bought from KSEC) with another phone from another brand, and it fucked up that card too (i.e. “Transceive failed” and now the card won’t answer PWD_AUTH anymore).
Only this time, I did it on the Proxmark3. So I have a trace of the fucked up transaction, if anybody’s interested.
This app is seriously unsafe 
Do a full tag info scan on it and post memory contents. There’s no way in my knowledge to fuck up an ntag 216 to the point where pwd_auth “won’t answer”…
What do you get back when you issue pwd_auth with NFC shell?
Sorry just seeing this… but no that is not the case. I just write that there in page E1 for fun… it’s a normal user data page. The password is stored in page E5 which is not readable, only writable.
1 Like
In short, the question is, do you want standards or don’t you. Standards are there to be conformed to for the benefit of everything and everyone. You seem to be a stickler for adhering to best practices and the best practice is to set a pack to anything but the default. The pack is meant to be arbitrary and non-default for a reason which I can’t explain on this phone keyboard without my thumbs falling off… so basically they suck, we’re not doing anything but adhering to best practices… and they should be pummelled with bug reports until they fix their shit.
Tag lost and transceive failed sometimes pop up on certain phones that have mods to the NFC stack… for a time, samsung was notorious for this due to samsung pay and their interference.
Nothing in the world can, to my knowledge, stop an ntag216 from responding to a pwd-auth request with either an error code or a success pack response. What phone are you using? Can you send a screenshot of nfc Shell’s response or dialogue error pop-up?
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 
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:
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.