Re-reading the app’s screen a bit more closely (and with my reading glasses on ), I can see it WILL set the password no matter what. And it’s probably not designed to talk to a Mifare Classic either… Duh me…
So, how it the password made up? Is it the 4 ASCII characters as 4 bytes verbatim?
That’s not the issue. 4 hex bytes = 8 hex digits = 32 bits. That’s clear.
My question is: if the app asks for a 4 ASCII character password, am I correct thinking it takes those ASCII characters as 4 8-bit bytes as-is and uses them for the 32 bit password value on the chip?
I’m asking because if it is, the app essentially throws away the 8th most significant bit out of every byte (since ASCII is 7 bits) and also doesn’t use unprintable ASCII characters (below 32), which significantly reduces the password space.
That’s also why I’m wondering why it doesn’t directly ask you 8 hex digits.
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.
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
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 - 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.
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.
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:
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.
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…
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.
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?