Hacking DIY amiibo cards

izy

Advanced Tech Pleb
Member
Joined
Sep 17, 2010
Messages
2,311
Trophies
2
XP
4,025
Country
United Kingdom
Well either way how fixable this is by nintendo we will see.

I do like the idea of amiibo trading cards :D, easier to share with friends


https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https://www.reboot.ms/forum/threads/amiiqo.523/&edit-text=&act=url


The sx3 chip is running as the bank but essentially it is a rewritable tag with some modifications, im assuming because SX3 is the security in amiibos that the chip is writing a new the amibo dump and UID directly to the tag via keypress and thats why its limited to 200.


Either way if you get a RRW tag you could essentially just make an app to write dumps you jsut wouldnt get the switching etc

just need someone to acquire and test it <3
 
Last edited by izy,

Supercool330

Well-Known Member
Member
Joined
Sep 28, 2008
Messages
752
Trophies
1
XP
1,129
Country
United States
@_Tim_: could you try writing an amiibo with a couple pages different from normal? For page 0x02, make the last two bytes 0 (to disable static locking), leave the capability container (page 0x03) default (0xE1 0x10 0x3E 0x00) (the values on 3DSbrew don't really make sense given the spec), leave page 0x82 0 (to disable dynamic locking). Set page 0x83 to 0x00 0x00 0x00 0xFF to disable password checking, and page 0x84 to 0x10 0x00 0x00 0x00 to disable the config lock, count protection, and auth limit. I'm curious if the Wii U will read an Amiibo with all of the protection disabled (and a more standard capability container), or not (I suspect it checks at least some of these). I find it very interesting that the last byte of the capability container is 0xEE as 0xE is a proprietary value according to the spec (and the first byte being 0xF1 makes no sense as the spec says 0xE1 is a magic value).
 
Last edited by Supercool330,

_Tim_

Well-Known Member
OP
Newcomer
Joined
Dec 23, 2013
Messages
63
Trophies
0
Age
45
XP
230
Country
Belgium
@_Tim_: could you try writing an amiibo with a couple pages different from normal? For page 0x02, make the last two bytes 0 (to disable static locking), leave the capability container (page 0x03) default (0xE1 0x10 0x3E 0x00) (the values on 3DSbrew don't really make sense given the spec), leave page 0x82 0 (to disable dynamic locking). Set page 0x83 to 0x00 0x00 0x00 0xFF to disable password checking, and page 0x84 to 0x10 0x00 0x00 0x00 to disable the cfglck, count protection, and auth limit. I'm curious if the Wii U will read an Amiibo with all of the protection disabled (and a more standard capability container), or not (I suspect it checks at least some of these). I find it very interesting that the last byte of the capability container is 0xEE as 0xE is a proprietary value according to the spec (and the first byte being 0xF1 makes no sense as the spec says 0xE1 is a magic value).
I already tried this, if one of the bits you mentioned is not set -> invalid amiibo.
 
  • Like
Reactions: cearp

Supercool330

Well-Known Member
Member
Joined
Sep 28, 2008
Messages
752
Trophies
1
XP
1,129
Country
United States
Huh, even the capability container ones? That really confuses me as like every byte (except 0x1) doesn't really make sense. Byte 0x0 should be 0xE1 according to the spec, 0xFF in byte 0x2 would mean that the chip can store 2040 bytes (significantly more than it actually can), and 0xEE in byte 0x3 that the chip has proprietary read and write access conditions of some sort.
 

_Tim_

Well-Known Member
OP
Newcomer
Joined
Dec 23, 2013
Messages
63
Trophies
0
Age
45
XP
230
Country
Belgium
Huh, even the capability container ones? That really confuses me as like every byte (except 0x1) doesn't really make sense. Byte 0x0 should be 0xE1 according to the spec, 0xFF in byte 0x2 would mean that the chip can store 2040 bytes (significantly more than it actually can), and 0xEE in byte 0x3 that the chip has proprietary read and write access conditions of some sort.
I checked the 3DS code and it checks everything except CC, so those 4 bytes can be left untouched but they do not matter anyway. The lock bits needs to be set though.
 

fraret

A puffin
Member
Joined
Nov 22, 2015
Messages
100
Trophies
0
Location
Interblag
Website
localhost
XP
151
Country
lol follow the steps :P
Steps:
- decrypt amiibo dump
- use hex editor to change UID in amiibo dump to UID of blank NTAG215 tag
- encrypt amiibo dump
- write amiibo dump to blank NTAG215 tag
- print amiibo picture and cut it out
- put NTAG215 tag sticker on the back of amiibo picture
I can't decrypt, because I don't know how to compile amiitool with the key. And if I put the key as an HEX file, and I use amiitool with the -k parameter, passing it the file with the key, it says me it's an invalid key.
Also, why the key is 20 bytes long? Shoudn't it be 16bytes(128 bits) long?
 

OctopusRift

GBATemp's Local Octopus, Open 9am-2am. "Not Yet"
Member
Joined
Nov 19, 2014
Messages
1,460
Trophies
0
XP
947
Country
Saint Kitts and Nevis
I can't decrypt, because I don't know how to compile amiitool with the key. And if I put the key as an HEX file, and I use amiitool with the -k parameter, passing it the file with the key, it says me it's an invalid key.
Also, why the key is 20 bytes long? Shoudn't it be 16bytes(128 bits) long?
_tim_ uses a modified version of amiitool... So... Think about that.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    K3Nv2 @ K3Nv2: Pass