Protecting NTAG216 implants w/PM3

Hi all,

With there being some discussion about if Dangerous NFC is currently ‘safe’, I decided to protect my new flexNExT by sending raw commands. I used a PM3 since I’d have to borrow an Android phone for NFC Shell, and my ACR122u is currently stuck in the postal system.

For anyone curious, here are the commands needed to protect your tag, and set the password to DNGR. Ignore any comment lines! Also of note, this doesn’t verify or try to write the Capability Container, double check it is correct before proceeding!

This was done using Iceman fork, the commands should be similar for official, but double check.

I always recommend you should do this on a test card first before touching your implant, just in case!

// Select card, keep field active
hf 14a raw -s -p

//Set Static Lock
hf 14a raw -p -c A2 02 00000F00

//Set Dynamic Lock
hf 14a raw -p -c A2 E2 00007F00

//Set PASS
hf 14a raw -p -c A2 E5 444E4752

//Set PACK
hf 14a raw -p -c A2 E6 44540000

//Set AUTH0 to E2
hf 14a raw -p -c A2 E3 040000E2

//Turn off field
hf 14a raw -c

//PASSWORD - DNGR: 44 4E 47 52
//PACK            -  DT:       44 54

Neat idea that!

The one thing I’d add to that recipe is authenticating with the default password after the select. If you blindly run down those instructions and the chip already has a password, it’ll run into the same problem as the current version of the DT app.

1 Like

That’s a fair point, I sort of omitted that and the CC check since there’s no logic in this. I might turn this into a lua script and put suitable checks as it goes.

This all sort of assumes the chip is in ‘factory default’ which should be manually verified, if the password has been set it may not be default anyway, and unlike DNFC, you can always authenticate and run these commands again, so shouldn’t be left in a weird state even if a write does fail.

That’s kind of my beef with the DT app - one of them anyway: if the chip isn’t factory default, it’ll leave it in a half-configured state and it’s irreversible. What it does is final and the entire sequence has to work the first time, so it should take all necessary precautions before doing its thing.

I get that, but also just being a list of commands it can’t ‘halt’ itself if it detects an issue, nor does any of this need to work the first time (you can always authenticate and run again, unlike the app which will fail)

Running hf mfu info is a great way to check it first, will confirm that the Page 03 CC is valid, and also tell you at the bottom if the default FFFFFFFF password was used.

I was more reading your list of commands as something a careful user would run down one by one - a recipe of sorts - rather than something you’d copy/paste blindly into the PM3’s console. So you could have a line in there saying “if the instruction above doesn’t return those bytes, or doesn’t return anything, stop right there”.

But yeah, if you understand it as a copy/paste thing, then you obviously can’t script it.

1 Like