Dangerous NFC app issues

yes it takes the hex value of the ascii bytes and writes the char value of those bytes as the password… so if your password is AMAL then it’s 41 4D 41 4C that gets written to page E5 as the password. I wish other stupid ass apps did that, but they transform it in some stupid way so if you type AMAL as your password in TagWriter then it doesn’t work… also doesn’t work between NFC Tool and TagWriter either because they both transform the data in some other odd way that is undisclosed.

Because we were not aiming for anything but securing the tag… at the time we figured the password as written would be easily used by TagWriter or NFC Tools and left the wheels that were already invented alone… but alas, it no workie that way.

The goal was to quickly and easily secure the config bytes with something that wasn’t the default… it was not considered to be the end user’s actual go-to… it doesn’t even do anything once the tag is secured… so again we figured wrong… bad us… and then other things got in the way and we never got back to it… but @hoker seems to be up for a challenge, so we are exploring things to give the DTNFC app a total overhaul.

1 Like

Oh also… the DT NFC app has been made open source now too… so if you want to mod it, you can!

5 Likes

Right. So… what you’re saying is, if I protect a tag with the Dangerous NFC app, I’m SOL if I want to write an NDEF record into the tag with TagWriter and NFC Tool afterwards. That’s unfortunate - but clearly miles better than writing something with either of those apps and then being SOL because you don’t know the damn password they set.

Good to know before I bring any of those app anywhere close to my doNExT :slight_smile:

I think what I’ll do is play with the Proxmark3’s NTAG sim, see if it’ll let me record the transaction, then get TagWriter or NFC Tool to write a NDEF to the Proxmark3, then work out what the password it set was.

With any luck, the app implements a simple transform function that I’ll be able to work out. If not, I could run several passwords into the app until I find one that happens to be transformed into an ASCII string that I can input in the Dangerous NFC app. Like, say, I use “GRAA” in TagWriter and it turns out to make 0x41 0x4d 0x41 0x4c “AMAL” in the 32 bit value.

I must say, this whole business is way more stupid and complicated that it needs to be… No fault of DT’s of course (apart perhaps that I don’t much like not being able to set 0xDEADBEEF as a password in the Dangerous NFC app), but I really wonder why I have to jump through those loops to use MY fucking password in MY fucking tag. Why is it that all NFC apps always want to do stuff like that behind your back? Gee…

I’m almost tempted. Never done any Android development - mainly because I still quite can’t wrap my head around using a telephone for things other than placing phone calls :slight_smile: - but that might be the incentive I needed to get into that.

Not at all. The password is set by DT NFC but ALSO the AUTH0 byte is set to E2, meaning only pages E2 and greater are affected by the password protection feature. Those pages are just the config bytes (including the password itself).

What I am saying is that if you want to change the password, set it to factory, or change the AUTH0 byte setting or PROT bit in the access byte, then you will kinda sorta be SOL. You can only do that (currently) with TagWriter or NFC Tools and so, you have to use NFC Shell or some other tool that will let you send an PWD_AUTH command to allow write access to the config bytes, then change your password back to default FF FF FF FF, then use TagWriter or NFC Info to do what you want. Using NFC Shell, you’d have to send the following commands;

1B AA BB CC DD [PWD_AUTH] [your password bytes in hex]
A2 E5 FF FF FF FF [WRITE] [PAGE E5] [default password]

Great idea… I’ve not had time to sniff out how TagWriter or NFC Tools changes the data you type into what it puts on the tag as a password… it’s a good idea … definitely looking forward to seeing any info you gleen.

Hmm yes, indeed. That’ll teach me to read everything before I hit reply. Or not… :slight_smile: Thanks for the clarification.

1 Like

Okay, I traced TagWriter and it uses the straight 32 bit value that’s entered in hex in the app. No problems there. I locked and unlocked a tag many times with it, and the trace always shows the password exactly as I entered it.

HOWEVER!

I used the Dangerous NFC app to lock the tag with the password ABCD (so, in theory, 0x41424344 right?) and now I’m locked out. TagWriter says the tag is password-protected, and the trace shows the reader does a HALT right after TagWriter serves it 0x41424344 as a password.

Okay I’ve worked out the problem: the Dangerous NFC app indeed sets the correct password (here “ABCD” in ASCII - 0x41424344) but also sets the PACK to “DT” (0x4454). However, TagWriter expects the PACK to be 0x0000.

So, if you want to rescue a tag from the Dangerous NFC app and make it usable again with TagWriter, you need to use NFC Shell to authenticate with the chip, then set the PACK to 0x0000:

NFC Shell commands (for an NTAG 216):

1B xx xx xx xx [4 ASCII chars of the Dangerous NFC app pwd]
A2 E6 00 00 00 00

The NFC Shell window should show:

TX: 1Bxxxxxxxx
RX: 4454
TX: A2E600000000
RX: 0A

This is yet another case of an NFC app trying to be too clever - in this case, the Dangerous NFC app setting its own incompatible-with-everything-else PACK.

Now I’ll get cracking on NFC Tools…

1 Like

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 :frowning:

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…