Hey guys,
I've decided that we have need a separate thread to discuss the usage of NTAG216.
There has been rumors about the existence of the possibility to use 216 in place of 215,but certain users refuse to actually give any information about how.
We know a few things about how 216 works in comparison to 215. Mostly the difference is the size of the cards and the location of the locking bits. Most notably, the difference that may potentially lock us out of using 216 is if Ninty checks for 215 to be used.
What I have personally tried:
Straight copying of the .bin's using tagmo.
-Does not work, the data differs from 215 when scanning the raw data written to the card.
Editing the .bin and filling with 0's
-Does not work, scanning the tags reveals the same result written to the card. So, basically tagmo does this already.
Here's a link to the datasheet of the 215 and 216's (its basically what we are using)
http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf
Let's work together on this. Certain users that claim they know how to do it should just be ignored.
If you're looking for info on Ntag215, there is already a tutorial and a thread on that.
I've decided that we have need a separate thread to discuss the usage of NTAG216.
There has been rumors about the existence of the possibility to use 216 in place of 215,but certain users refuse to actually give any information about how.
We know a few things about how 216 works in comparison to 215. Mostly the difference is the size of the cards and the location of the locking bits. Most notably, the difference that may potentially lock us out of using 216 is if Ninty checks for 215 to be used.
What I have personally tried:
Straight copying of the .bin's using tagmo.
-Does not work, the data differs from 215 when scanning the raw data written to the card.
Editing the .bin and filling with 0's
-Does not work, scanning the tags reveals the same result written to the card. So, basically tagmo does this already.
I tried to look into this issue. However I am new to making android apk's, the apk always generate errors ('Unfortunately app has stopped') when I trigger the NFC functions in my custom tagmo app (signed with self-generated key). The error exists even with compling the original code. I do not know what's wrong with my android studio :\
I hypothesized earlier on the NTAG215 thread for replacing with NTAG216:
Took a brief look at the datasheet. The difference between the 2 chips are the location of 'dynamic lock bytes' and 'configuration pages' as well as the value in CC. [Also, the response in GET_VERSION will be different too] So in order to use NTAG216 in place of NTAG215, the data for 'dynamic lock bytes' and 'configuration pages' need to be written to the correct location. CC bits could be set to FF (refer to Amiibo article on 3dbrew) so the difference in default value does not matter. [Those data may need to be written into both NTAG215 and '216 locations. However, for the PASS and PACK they are write-only, so the NTAG215 location needs to be 0's]
The problem is with GET_VERSION which is fixed. Byte 6 (storage size) is different between NTAG215 and '216. If ninty really checks the response, I do not think there is a way to get around it. However I could not get my working android compiler to play with it
Here's a link to the datasheet of the 215 and 216's (its basically what we are using)
http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf
Let's work together on this. Certain users that claim they know how to do it should just be ignored.
If you're looking for info on Ntag215, there is already a tutorial and a thread on that.
Last edited by KingOfTaurus,