Where do you put the key?Basically we just compile socrams git with the encryption key,
Where do you put the key?Basically we just compile socrams git with the encryption key,
up the nose. you actually have to think here.Where do you put the key?
DAMN. Close.Just to be clear... I do not sell DIY amiibo cards so please do not PM me about it. Thanks.
I see the key. But I don't know how to use it. I made a key.bin file with it, and it tells me it's an invalid key.up the nose. you actually have to think here.
lol follow the stepsI see the key. But I don't know how to use it. I made a key.bin file with it, and it tells me it's an invalid key.
I already tried this, if one of the bits you mentioned is not set -> invalid amiibo.@_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 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.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.
lol follow the steps
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.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
_tim_ uses a modified version of amiitool... So... Think about that.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?
Amiiqo.Does anyone know how I could dump the amiibo as BIN files via Android?
AES CTR MODE. YES. I NEED THIS. I LOVE YOU.
all. It's not one key lmao.Which key in that set is for Amiibo?
(Wow I'm being a noob again.)