I actually didn't know/realize they could have separate partitions. That explanation completely makes sense though now knowing that. Thanks for sharing!
Glad I don't have to start referring to you as dbag_5678
Hacking NTAG216 Amiibo collaboration thread
- Thread starter KingOfTaurus
- Start date
- Views 48,667
- Replies 73
- Likes 2
Glad I don't have to start referring to you as dbag_5678
I assumed it was possible to just create dummy data to fill the extra space, but didn't know you could also set it to it's own partition. Really, the most logical, possibly, only way to use the 216's. Thx for the hints dpad_5678.
After reading up on the technical part of the document, locking certain pages go like this:
BD = always there
XX = variable
Blank Page 2 of NTAG215:
XX XX 00 00
Blank Page 130 of NTAG215:
00 00 00 BD
An "amiibo":
Page 2:
XX XX 0F E0
Page 130:
01 00 0F BD
Blank Page 2 of NTAG216:
XX XX 00 00
Blank Page 226 of NTAG216:
00 00 00 BD
A "tagmo'd incorrectly amiibo"
Page 2
XX XX 0F E0
Page 226
00 00 00 BD
So, what does that mean?
For the incorrectly written 216, that means pages 04-12 are blocked and pages 12-15 are locked and blocked. All of which are "user data"
For an amiibo on 215, pages 04-12 are blocked and write only and pages 13-31 are locked and blocked and read only, and pages 32-129 are blocked and read only
What does blocked mean?
What does locked and blocked mean?
If a tag is read only, how is data being saved to it ingame? It probably has something to do with locked vs blocked.
So, I guess, in order to use a 216 as a 215, we need to do something with pages 130 to 225, make tagmo do its thing, then manually lock it afterwards. All talking out of my seat though. The manual is slightly confusing:
I'm having a hard time understanding the "lock bytes". If you look at the data on the tag, you see a page. A page has 8 bits arranged in pairs of two, four times. 00 00 00 00. A byte is 8 bits, so each page is 1 byte.
The "locking bits" required for example, on page 226 of ntag216, require 32 bits on the single page. How do you get 32 bits from 1 byte? It describes it like this (loosely):
00 00 00 BD
00 = 7 6 5 4 3 2 1 0 | 00 = 7 6 5 4 3 2 1 0 | 00 = 7 6 5 4 3 2 1 0 | BD
Look at page 15 of the datasheet.
What am I missing here?
Edit: I think I get it now. 0 in HEX = 0000 in DECIMAL sooooo:
0F E0 = 00001111 11100000 which means , 4-15 are blocked and 13-15 are read only and these mean something about the "capability container" which I am guessing is something significant.
BD = always there
XX = variable
Blank Page 2 of NTAG215:
XX XX 00 00
Blank Page 130 of NTAG215:
00 00 00 BD
An "amiibo":
Page 2:
XX XX 0F E0
Page 130:
01 00 0F BD
Blank Page 2 of NTAG216:
XX XX 00 00
Blank Page 226 of NTAG216:
00 00 00 BD
A "tagmo'd incorrectly amiibo"
Page 2
XX XX 0F E0
Page 226
00 00 00 BD
So, what does that mean?
For the incorrectly written 216, that means pages 04-12 are blocked and pages 12-15 are locked and blocked. All of which are "user data"
For an amiibo on 215, pages 04-12 are blocked and write only and pages 13-31 are locked and blocked and read only, and pages 32-129 are blocked and read only
What does blocked mean?
What does locked and blocked mean?
If a tag is read only, how is data being saved to it ingame? It probably has something to do with locked vs blocked.
So, I guess, in order to use a 216 as a 215, we need to do something with pages 130 to 225, make tagmo do its thing, then manually lock it afterwards. All talking out of my seat though. The manual is slightly confusing:
I'm having a hard time understanding the "lock bytes". If you look at the data on the tag, you see a page. A page has 8 bits arranged in pairs of two, four times. 00 00 00 00. A byte is 8 bits, so each page is 1 byte.
The "locking bits" required for example, on page 226 of ntag216, require 32 bits on the single page. How do you get 32 bits from 1 byte? It describes it like this (loosely):
00 00 00 BD
00 = 7 6 5 4 3 2 1 0 | 00 = 7 6 5 4 3 2 1 0 | 00 = 7 6 5 4 3 2 1 0 | BD
Look at page 15 of the datasheet.
What am I missing here?
Edit: I think I get it now. 0 in HEX = 0000 in DECIMAL sooooo:
0F E0 = 00001111 11100000 which means , 4-15 are blocked and 13-15 are read only and these mean something about the "capability container" which I am guessing is something significant.
Last edited by KingOfTaurus,
@KingOfTaurus, so you're trying to actually lock different bits and stuff to use the higher capacity? Have you tried what dpad_5678 said and just create a dummy partition for the last 348 bytes? Then the remaining partition may act exactly like a NTAG215 as far as which bytes to lock.
i've been digging around the internet trying to find info on NFC partitioning, is this part of a specific spec?
To be honest, just get the 100 pack for 35$ of ntag215s, or go spend 70$for that same pack on amazon if you want to get them faster... either way,just buy the correct ntags... this is really not needed.
Just go buy every Wii U game that you want to play, and learn Japanese so you can read the uncensored versions of the game. Hacking the Wii U is really un needed.
I'm doing this because I WANT to, and I'm sure I'm not the only one.
The problem is, I don't exactly know how to create a partition yet. I'm studying the lock bits first, and I'm sure it has something to do with creating partitions.
Last edited by KingOfTaurus,
ditto. i already have NTAG215 tags, but i also have NTAG216 tags and getting NTAG216 to work is an academic exercise.
Hm, good point lol. @dpad_5678 made it sound like it was common knowledge, but I can't find anything about it either. Maybe his newfound helpfulness will enable him to teach us how to make a second one.
My comment was towards people asking other to get this done... if you are doing it for an academic exercise or because you like a challange, or its fun, go ahead and do it. It does not take away the fact that it is not needed.
I'm going to try just writing to and locking the last 348 bytes of the card and see what happens. I'll also use a 215 card and clone to a 216 byte by byte and recreate the "locks" to be compatible with that byte by byte section and see what happens.
Stay tuned.
I've had small amounts of progress. Not enough time lately. I'll definitely get back onto it soon.
After a lot of research I have an idea how this is done, but I do not have any ntag216's to test this on right now. I may buy some just to test out my theory unless someone wants to "donate" some to me.
--------------------- MERGED ---------------------------
Isn't it 384 bytes and not 348?
--------------------- MERGED ---------------------------
Isn't it 384 bytes and not 348?
NTAG216 Total bytes (888) -- Amiibo Dump (540) == How many bytes should be scrapped (348)
NTAG216 has a total of 924 bytes of data and only has 888 bytes of user read/write data and an NTAG215 a total of 540 bytes of data with only 504 user read/write bytes.
Either way you do the math 924-540=384 or 888-504=384
Last edited by Phantisy,
Amiibo dumps are a total of 540 bytes. I've created the app to lock 348 bytes. If that was wrong then it wouldn't work properly. But it does.
A little more squeezing and ill have it. So, we lock them. The first 348 or the last 348?
Still could not get my compiled app to run correctly. Familiar with Java/C++/Embedded C but new to Android. I guess NDK is needed for amiitool, anyone got a brief instructions on how to generate the apk?
@KingOfTaurus: Have you tried:
1. writePages(mifare, 3, 129, pages); as normal
2. write the config data to data pages 130, 131 & 132
3. writePassword(mifare); to pages 230 & 229
4. writeLockInfo(mifare); to pages 2, 226, 227 & 228
Judging from the read procedure on 3DBrew, the read results should be identical with '215 except GET_VERSION. However the second step "READ, startpage=0x03." looks strange, this reads 4 bytes from 0x03 to 0x06 which does not contain the UID required by the next step.
@KingOfTaurus: Have you tried:
1. writePages(mifare, 3, 129, pages); as normal
2. write the config data to data pages 130, 131 & 132
3. writePassword(mifare); to pages 230 & 229
4. writeLockInfo(mifare); to pages 2, 226, 227 & 228
Judging from the read procedure on 3DBrew, the read results should be identical with '215 except GET_VERSION. However the second step "READ, startpage=0x03." looks strange, this reads 4 bytes from 0x03 to 0x06 which does not contain the UID required by the next step.
- Read procedure
- GET_VERSION
- READ, startpage=0x03.
- PWD_AUTH. Key is based on UID.
- FAST_READ: startpage=0x00, endpage=0x3B
- FAST_READ: startpage=0x3C, endpage=0x77
- FAST_READ: startpage=0x78, endpage=0x86
Last edited by gualala,
Okay. Not saying you're wrong. Just trying to understand because you can only write to 504 bytes on the ntag215 even if the data is 540 bytes in the bin file of the amiibo backup, because you cannot change the data that contains the manufacture data. My guess is that your writing the 540 bytes to the free 888 bytes on the ntag216 giving it an actual 1:1 copy plus the bytes your locking and the original manufacturer data.
Last edited by Phantisy,
-
-
-
-
-
@
RedColoredStars:
Never even seen a tiger crust pizza in any stores around here. Walmart, Cub, or otherwise. -
-
-
@
RedColoredStars:
Last thing I told her is how much I love her, and that Im not leaving her there forever and I promise to come back and take her back home with me.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
