Were there any tags you couldn’t revive? They all had the same password, right?
So if i try and it fails, it shouldn’t be a big deal to get in there with NFC Shell and un-ruin my day?
Just to be clear, they were all “alive”. Just denying me authentication with the password.
All of them had 12345678 as a password. The question is this: where did it come from?
- Not from my cellphones - I used two different ones
- Not from a cellphone app - I only had the DT app running on both cellphones
- Not pre-programmed in the cards - I used bullseyes from DT and a NTAG216 card from KSEC
- 99.99% sure not from Android
- Not from the DT app directly - it never set that password when I traced the exchange
So my conclusion is, it came as weird side effect of the DT app writing BD in E2 when it shouldn’t. I totally agree that it sounds completely and utterly unlikely, but when you discount all other possibilities, whatever remains must be the truth 
I can see you want me to give you advice on this, and I won’t, because I don’t know what happened to my tag with that app, and that’s enough to give me the willies running it on my doNExT. I’ll probably end up doing what it does, but manually, and more importantly correctly, and doing the checks it should do before doing something.
If you do run the app and it fails, you can’t reverse all that it did, unfortunately: either it works all the way, or you’re left with a half-configured chip with read-only sectors and there ain’t nothing you can do about it afterwards. The chip will still be functional for reading and writing NDEFs though.
1 Like
Thats the bit I was most looking for, whether it’d be a no harm done attempt, or still leave me in an odd state. I’ll go with the datasheet and manual work to be safe i think.
@Satur9 had a similarly strange thing happen with his implant while using TagWriter … TagWriter suddenly decided to change the auth0 byte to page 04… just out of the blue.
I’ve never used the Dangerous NFC app on my NExT, but tagwriter sure did something while I was mucking about at some point.
I even tried to password authenticate with NFC Shell and change the AUTH0 byte, but haven’t gotten it working yet.
I need to figure out what the CRC bytes are at the end of the PWD_AUTH command
This page says the CRC (checksum) for the default NExT password authentication command should be 5E61, but apparently it’s not.
Actually it’s not necessary, the hardware driver does this for you when passing the command. What about exploring what @anon3825968 discovered… the password being set to 12345678?
Nope, it’s not 12345678 or 00000000
Whatever the hell is going on, I still think the DT app should perform all necessarily checks before doing anything to the chip that can’t be reverse if something fails down the line - and also write correct bits as per the spec.
Any chance of getting an update at some point Amal?
Hoker is working on it as we speak
1 Like
Great news!
This is all getting weird again!
Not with you here… What is?
Just that we now have a report of TagWriter fucking with things when it hadn’t been told to do said fucking.
It just adds to the weirdness in that there don’t seem to be any NFC apps at all that do things properly. Even NFC tools mis-detects card types when it could just Get Version
Yeah that ain’t news. Reread my post above. Fuck TagWriter. In fact, fuck any application - Android or otherwise - that try to be too clever.
There is one application that does exactly what you tell it to. The only limitation is your stupid, squishy brain. NFC Shell will never let you down, but it can also topple empires so proceed with caution
1 Like
Or the other option for exactly what you want is the 14a raw commands on proxmark which is what I just played with.
I put a test card through DNFC and confirmed that it does exactly what it says on the tin, at least in my sample size of 1. Set static and dynamic lock bits correctly, AUTH0 to E2, set the PASS and PACK, no funny business and I can authenticate no problem with the set password.
I’ll make my flexNExT safe by using raw commands just to be sure i have control over the whole process, but from my tiny sample size, seems safe to me too.
So what i read tagwriter does is it takes your password then does some shifting and shit using your uid to get you a “more secure and unique password” great but have not found anything thats says what the duck it does with it.
It used to do this… a long time ago. Recent testing (above) shows they no longer do this and you can just input hex data directly… so it should work if you properly enter the DNGR or NExT password’s hex values for those ascii characters.
1 Like
Lol, my password was DNGR. AUTH0 is E2 now.
4 Likes