Lock Bits already altered

Hey guys,
got my xNT implanted yesterday and tried reading it today with NFC Tools.
It worked so I wanted to secure it using the Dangerous Things NFC App before I do anything else.
The first time it said “Tag lost” or smth like that and after that it always prints “Error: Lock bits already altered”.

Screenshot from the support tool

Is it already locked with my password or did i f*ck something up?
And how would I go about using the other settings from the app if I can’t get past the initial screen?

arough

hey there, sorry for the delay… no you didn’t fuck it up… but the app only got half the job done… we need to update the app to allow it to inspect every single block separately and take the necessary action. for now your “static lock bits” are disabled, but your “dynamic lock bits” are not… not ideal. Keep an eye on the DNFC app for updates.

2 Likes

Hey! Sorry to bring this back up, but have the app updated yet? I’m running into the same issue, I haven’t set a password or anything on it yet, I can write to it no problem, just when it comes to setting a password it says the lock bits are already altered. Here’s the data that the support app scans from chip.

Are you using a NExT or an xNT? All of the NExT (and probably the newer xNTs) have their lock bits already configured at the factory. The default password is “DNGR”.

Edit: default password for NExT implants is “NExT”

Does that address your need, or did you have an end goal? Maybe we can help.

2 Likes

Oh! I must have missed that, thank you so much! You were correct, I have the NExT chip in my hand. :smile:

Hm, I’m trying to remove the default password to put my own. “DNGR” wasn’t one of them, and according to the NExT product page, the default password would be “NExT” under the “NExT NTAG216 Security” drop-down, but that isn’t working either. Now, I’m positive I did not set a password yet, as my own password that I would use isn’t working either, and I recall it saying “Write Error” when trying to set my own password . Could something went wrong with the chip?

So, I checked out this post:

And then I tried to change the password on my NExT using TagWriter. Here is a guide for how to do that under section 4.2.3:

I went to:
Protect tags > Password protection > Current Password > Change Password
Then I entered NExT (4E 45 78 54) as my current password, and put another one in as my new password. Unfortunately it didn’t work. Maybe somebody else can tell you why. I’m out of ideas.

2 Likes

Hmm, what’s odd in my situation though is that it even though it says it’s password protected, I can still write to the chip without a password, unlike in dmo1222s situation where he wasn’t able to write to it at all. :thinking: I’ll do some more digging and see if I can figure out this password situation lol Maybe NFC Tools did somethin to it. :man_shrugging:

I can write to my NExT without a password, that’s the default. There is a password assigned to every NExT, but I don’t think they are in password protection mode by default. It has something to do with these bytes

1 Like

Ah, okay! Didn’t know that was the default behavior, that’s nice to know though. But sadly, I still haven’t figured out how to solve this yet :confused: I’ll let you guys know if I figure out the issue/password.

The AUTH0 byte dictates at which memory page password protection begins to apply to all subsoquent memory pages. The default value of AUTH0 is FF, which effectively leaves all pages unprotected by the password feature. Both the Dangerous NFC app and our pre-programming of the NExT sets AUTH0 to E2, which leaves the user memory pages unprotected by the password (and fully writable).

Within the CFG byte there is a PROT bit… the PROT bit defines the PROTECTION scheme used by the password feature. Leaving PROT set to 0 means that the password feature only protects pages defined by AUTH0 against unauthenticated writes… in effect, you must authenticate your session with the correct password before you can write to any protected pages. This includes configuration pages and the PASSWORD bytes in page E5. As you can see, this means if you set AUTH0 to FF or any page value after E5, anyone could write new PWD bytes without first having to authenticate. This is not good, so we protect all configuration bytes by default. If you set PROT to 1 then you must authenticate with the password first before you can read or write any pages protected by AUTH0.

Just one other oddity to point out… the UID of the NTAG216 chip is stored in the first couple memory pages, however if you set PROT to 1 and AUTH0 to the first page 01, this does not mean you are effectively making it impossible to read the tag UID without first authenticating. The UID is communicated during the ISO14443A announcement and selection process, so even though the UID is stored in the first couple pages, you cannot password protect the UID from being read.

3 Likes

One more follow-up… within the ACCESS byte there are two bits that should never be messed with… CFGLCK and AUTHLIM.

2019-10-28_13-55-19-firefox

You can see why;

If AUTHLIM is not equal to 000b, each negative authentication verification is internally counted. The count operation features anti-tearing support. As soon as this internal counter reaches the number specified in AUTHLIM, any further negative password verification leads to a permanent locking of the protected part of the memory for the specified access modes. Specifically, whether the provided password is correct or not, each subsequent PWD_AUTH fails. Any successful password verification, before reaching the limit of negative password verification attempts, resets the internal counter to zero.

We password protect pages from E2 down because some NFC apps ignore the capability container (CC) in page 03 which defines the amount of memory space this tag has associated for use with NFC data, and will just keep writing data right overtop of these config pages.

1 Like

I am having the same issues but now when I try to read the tag for support all of the entries say “null”. What am I missing? I can’t get my Vivokey to read at all and the xLED doesn’t appear to work either. I had them installed yesterday and I have had zero luck with any of them.

You’re going to need to wait for the swelling to subside before you can do any reliable testing. Even without the swelling you’re going to need to practice a bit to find the sweet spot on your phone. What phone do you have, and have you tried the X Field Detector or the Diagnostic Card with it?

OK, the swelling is gone, and I got my Vivokey Spark 2 registered. I can see a very faint light when I use the wedge keyboard reader and I can detect the NExT chip but when I use the Dangerous Things app to try to read it, I enter a password and when it tries to read the chip it says “lock bits already altered”. Have I screwed something up? I’m going to reread this thread and see if I’ve missed something but I can be extraordinarily dense sometimes so don’t leave me hanging too long if I don’t respond again with the proverbial “duh” moment.

Also, am I correct in thinking that the response and range of the chips will become more robust as time goes by, right now I have to sort of be right on top of the chip with the wedge reader to activate it.

Also, any recommendations for software to use for read/write and otherwise play and experiment with my new implants? :stuck_out_tongue_winking_eye:

Nope, the NExT does not require the use of the Dangerous NFC app because we secure it at the factory… we decided to do this during manufacture because there really is no good reason to make the customer do it, nor any good reason to keep the chip in a factory but vulnerable state.

Yes it will get better, but also you will get better at positioning your phone too. Remember location AND rotation (orientation) of the phone matters, so get really familiar with that sweet spot with the X Field Detector included in the kit.

5 Likes