NExT/NTAG216: Differences between 'locked' and 'blocked'

[Saki]

Hi all!
I got my NExT installed around 3 weeks ago. Now I’m wanting to get another implant in the other hand already!

I’ve set the NTAG216 up so that the AUTH0 protects the whole user memory from being written to, without sending the command 1B (XX XX XX XX).

I used the NFC shell within NFC Tools to send:
1BXXXXXXXX,A2E304000004,A2E400000000.

Where XXXXXXXX is the password set using TagWriter.

This changed the AUTH0 to protect from page 04 onwards. But still allow the tag to be read. Thus, preventing anyone (including myself!) from overwriting the user memory of my implant without sending the 1B command with the password.

A few questions, though:

The datasheet has info in the ‘block locking’ mechanism, that uses the static locking bits to irreversibly make the tag read only. I assume this is applied to 00-03. The LOCK0/1 bytes are 0F00. (00001111 00000000). This makes the CC permanently blocked, with the other static locking bits also not being able to be changed, right? I think this is what DT do during manufacturing, correct?

By setting AUTH0 to 04, everything after 04 should be pwd protected. I am just confused about the full scan I am getting. What is the difference between +r (blocked, readable), *r (blocked and locked, readable) and +p (blocked, pwd protect)? I cant find much info on the differences.

When I did a full scan before, all memory showed as (?p) however now it is showing +r for all user memory. I assume this is just due to requiring the 1B XX XX XX XX command to be sent to make these be writable once more, unless I’ve accidentally permanently blocked writing…

Additionally, E2 Is set as *r, E3-E4 as (.r)… Why are all these not set as +r, in the same as the user memory? I understand r = read only, but what is the difference between unblocked read only, and blocked read only?

I am thinking that because I did not change the dynamic locking bytes, the memory isn’t ‘locked’. Just blocked from being overwritten.

Thanks in advance. I am sorry for such a long post!

[hadoukenboy628]

Any pages marked with * basically cannot be changed. Page E2 shows me that you used the locked prevention on Tagwriter to prevent the data on your ntag 216 from being locked permanently. Read only just temporarily prevents changes until you unprotect the pages again. Pages 0 - 3 are locked permanently as part of the manufacturing process as this chip is not UID changeable.

As far as I can tell, other than the locking bits, you haven’t blocked anything that can’t be undone so your chip is still in fully working order.

@Saki

By setting AUTH0 to 04, everything after 04 should be pwd protected

Yes all pages from 04 will be password protected in the sense that it is read only and in order to write to these pages again you merely need to remove the password protection via Tagwtiter in order to change the data. I’m not sure why your page E4 isn’t 00 05. If you wanted to fully protect the chip against unauthorised reading you would have to change your PROT bits and change page E4 to 80 05.

[amal]

@Saki

The datasheet has info in the ‘block locking’ mechanism, that uses the static locking bits to irreversibly make the tag read only. I assume this is applied to 00-03. The LOCK0/1 bytes are 0F00. (00001111 00000000). This makes the CC permanently blocked, with the other static locking bits also not being able to be changed, right? I think this is what DT do during manufacturing, correct?

Correct.

@Saki

I am thinking that because I did not change the dynamic locking bytes, the memory isn’t ‘locked’. Just blocked from being overwritten.

We also lock the dynamic locking bits the same way we lock the static locking bits… “for your protection”. You can’t change the dynamic locking bits either which is why that page shows *r as it is readable but locked.

[Saki]

Brilliant, thank you both for the explanation!

@hadoukenboy628

not sure why your page E4 isn’t 00 05.

I didn’t want to have the chip be password protected for reads - just for writing!

@hadoukenboy628

Pages 0 - 3 are locked permanently as part of the manufacturing process as this chip is not UID changeable

Ahh that clears up the difference between BL and just pwd protected. Thank you!

@amal

“for your protection”

Funnily enough, the piercer who I went to for the installation mentioned how they were messing around with their implant and ended up permanently having a link to a cat video on it. I assume they just did so by forgetting their password

Really appreciate the answers. Next up… xLED in the same hand for glowy fun, xMagic for unlocking doors at my university in the other…!
I’d be tempted by a xSIID on the same hand as the xMagic, but I’m not sure they would be OK together, or if they’d interfere at all

[amal]

@Saki

I’d be tempted by a xSIID on the same hand as the xMagic, but I’m not sure they would be OK together, or if they’d interfere at all

Yes there is “interference” but this is an application level issue not an ISO14443A standard issue… the standard supports anti-collision for multiple tags in the field at the same time, but almost no applications bother to look beyond the first tag detected, so it’s wide to keep space. Check;

Naming convention for implant locations in the hand

[Saki]

Awesome, thank you so much!
Can’t understate how cool the NeXT is (and DT in general!)
I will definitely be getting at very least an xLED in the same L0 position. Just because… Who doesn’t want to have a glowy LED in their hand??

I am unsure if my piercer would be comfortable doing any of the other spots in the hand, but good to know it’s an option.

So damn amazing that this is something that is possible though. I am very thankful for the work you and the rest of DT have done in order to make this a viable thing!

Cheers