Hi there,
The home screen on Dangerous NFC explains exactly what is happening;
In layman’s terms;
-
Page 03 contains what’s known as the CC or capability container. This specific memory page is OTP or One Time Programmable. That means all bits in that page are 0 by default, and can be flipped to 1, but never back to 0… they are one-way flips. The CC is what is used to indicate to a reader what purpose this RFID tag is serving. The NFC specification requires that NTAG216 chip based RFID tags must have a specific value written to the CC in order for that RFID tag to be used as an NFC Type 2 tag. Any other value and the tag will not be NFC compliant and will not work with most (pretty much all) NFC readers. This step ensures the CC is correct and updated to the latest NFC spec (1.2 as of this writing).
-
The NTAG216 chip has two sets of lock bytes. The first set are called the “static lock bytes” and are the last two bytes of page 02. The second set are called “dynamic lock bytes” and are the last three bytes of page E2. Each bit all of these lock bytes represent user programmable memory pages. If the lock bit is 0 then the page is writable, if it is 1 then that page is forever locked. These bytes are very powerful and in the case of an implant, server no real purpose since there is no conceivable situation anyone could think of where lock bytes would want to be used… except two places. The first is the CC - page 03 - which, if programmed correctly for use as an NFC Type 2 tag, should never be changed. So, we set a bit in the static lock bytes in page 02 to forever lock page 03 and secure the CC from ever being changed. The second thing that could benefit from being locked, are the lock bytes themselves. Fortunately there are bits within both the static and dynamic lock bytes that can lock the lock bytes themselves… effectively locking the lock bytes. So, after locking page 03 and securing the CC, the dynamic and static lock bytes are then locked, blocking any further user memory pages from being locked.
-
The NTAG216 supports a 4 byte password feature. This password can not be removed, but it does have a factory default value of FF FF FF FF. The password feature works in concert with three other features; PACK (password ACK), AUTH0, and PROT. They are all contained within a “configuration section” of the NTAG216 which is made of of the last few memory pages; E2 through E6.
When a reader wants to authenticate, it issues a special PWD_AUTH command ADPU to the NTAG216 chip along with the password it wants to authenticate with to the NTAG216. If the password is correct, the NTAG216 can send back a custom 2 byte PACK or “password acknowledgement”. The default value is 00 00, and an error result is 90 00… but let’s say you want to play around with the PACK value… you could set it to 90 00 so the reader won’t know if the password is correct or not… or you can set the PACK to some other value so the reader can maybe detect an emulator in use that knows your UID but not the PACK, so the reader has a chance to try to detect fishy business going on and disable that UID entirely within the system.
AUTH0 is a byte value that is set to indicate the memory page at which password protection begins. The default value is FF which means none of the pages are protected by a password, including the password block itself. That would mean that even if you changed the password to something else, anyone could issue a write command to page E5 (the password block) and change the password without first authenticating, because AUTH0 is saying “only protect pages FF down”… and the last page of the NTAG216 is E6 (the PACK). Remember the “configuration section” mentioned earlier? It starts at page E2 and ends at E6, and Dangerous NFC sets AUTH0 to E2 to require password authentication for pages E2 onward (down to E6). If AUTH0 is set to 04, where user memory starts, then the entire writable contents of the tag would be password protected… but this is out of scope for Dangerous NFC so we set AUTH0 to E2 to protect just the configuration section, including the password block itself. That means to change the password (or set it back to default), one must first authenticate in order to write a new password value to block E5.
Another big reason AUTH0 is set to password protect the configuration section of memory pages is that, in page E4, there are two features called CFGLCK and AUTHLIM that are both capable of forever locking your configuration bytes and possibly making your entire tag either read only or not readable at all. If CFGLCK gets set to 1, then you cannot change any of your configuration bytes… can’t change AUTH0… can’t change your password… nothing. If AUTHLIM is set to any value greater than 00, like maybe 01 or 03 and someone passes the wrong password via PWD_AUTH command more times than the AUTHLIM is set to, then this is what the NTAG216 datasheet says: “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 PWDAUTH fails. Any successful password verification, before reaching the limit of negative password verification attempts, resets the internal counter to zero.”
So yeah, it’s pretty important to protect this specific configuration memory page. The reason we don’t lock it down like the CC in page 03 is that there are other bits in that page that would be good to be able to change, like the PROT bit.
Speaking of which, the PROT bit tells the NTAG216 what type of password protection to implement. The default setting of 0 means any memory page that is password protected under the AUTH0 setting can be read without authenticating, but a valid password must be sent in the PWD_AUTH command before those pages can be written to. In effect, PROT = 0 means any protected page is “write protected”. If PROT is set to 1 however, then any memory page protected under AUTH0 is read and write protected, meaning the reader cannot even read the value until a valid PWD_AUTH command is received. Once the session is over - the NTAG216 enters HALT state or is removed from the reader field, PWD_AUTH is lost and must be re-authenticated for the next session.
So the whole point of Dangerous NFC is to configure your xNT or flexNT in such a way that it is best protected against accidental catastrophe and/or malicious attack. The idea that someone could overwrite your data isn’t exactly considered a huge problem since they could not lock your tag after writing said data, or really affect any critical memory blocks without first knowing your password. If someone does write a rick-roll video URL to your tag, you can simply overwrite it.
That said, there are so many NFC applications and software packages out there that are written by extremely lazy people… including NXP’s TagWriter, NFC Tools, and the Windows based NFC application from GotoTags which all fail in some way or another to correctly process the NFC tags protected by Dangerous NFC. For example, GotoTags’ application considers a protected tag to be read only. It looks at the lock bytes and says “ok, they are not 00 00 so the tag must be locked”. A proper application would parse the lock bytes value and easily be able to tell the memory blocks that the user wants to write to are not actually locked and proceed to write. At this point, NFC TagWriter can’t seem to figure out how to accept a password given by the user, authenticate, and then write an updated password value.
At this time we are planning to update Dangerous NFC to add more password management features, but there is no ETA for this.
