It isn't even close to ready yet. I have the main reading and writing bits done, but there isn't really a UI to speak of, the permissions system is a complete mess, and there are a number of other features I would like to work on. At this point I have put that on hold as I'm not sure we'll ever even be able to actually do this.
It isn't even close to ready yet. I have the main reading and writing bits done, but there isn't really a UI to speak of, the permissions system is a complete mess, and there are a number of other features I would like to work on. At this point I have put that on hold as I'm not sure we'll ever even be able to actually do this.
We'll be patient, remember that people around here know quite a lot as well(not-me), you could always post your concerns/walls and I'm sure others will jump in to help
I built a tool which will allow you to decrypt your Amiibo data, edit the hex values of the data, then either download the modified data in a decrypted or encrypted bin.
http://amiibo.vgmoz.com/hex
Simply upload your Amiibo dump (540 byte bin file), edit the values, and download as a decrypted or encrypted bin. Also, the offset display can toggle between hex and decimal by clicking on it.
Let me know what you think and if you have any suggestions.
http://amiibo.vgmoz.com/hex
Simply upload your Amiibo dump (540 byte bin file), edit the values, and download as a decrypted or encrypted bin. Also, the offset display can toggle between hex and decimal by clicking on it.
Let me know what you think and if you have any suggestions.
Hey NFC Emulator friends!
today Kasper & Oswald GmbH started the "ChameleonMini - A Versatile NFC Card Emulator, and more..." project at https://www.kickstarter.com/projects/1980078555/chameleonmini-a-versatile-nfc-card-emulator-and-mo
"Cards that the ChameleonMini can emulate in principle include: NXP Mifare Classic, Plus, Ultralight, Ultralight C, ntag, ICODE, DESfire / DESfire EV1, TI Tag-it, HID iCLASS, LEGIC Prime and Advant, Infineon my-d, and many other NFC tags."
You can bake the new Rev.G board for $99. The old Rev.E.Light board is also available for $49 but will not support the new firmware.
Maybe the community can help to implement NTag21x :-)
today Kasper & Oswald GmbH started the "ChameleonMini - A Versatile NFC Card Emulator, and more..." project at https://www.kickstarter.com/projects/1980078555/chameleonmini-a-versatile-nfc-card-emulator-and-mo
"Cards that the ChameleonMini can emulate in principle include: NXP Mifare Classic, Plus, Ultralight, Ultralight C, ntag, ICODE, DESfire / DESfire EV1, TI Tag-it, HID iCLASS, LEGIC Prime and Advant, Infineon my-d, and many other NFC tags."
You can bake the new Rev.G board for $99. The old Rev.E.Light board is also available for $49 but will not support the new firmware.
Maybe the community can help to implement NTag21x :-)
Already working on it with my Rev E board. Good to know they finally launched their kickstarter though.
Ok, I finished up a python script that can scan, decrypt, encrypt, fix the signature at page 0x20, and restore the dump to either an unlocked NTag, or an existing Amiibo.
https://gist.github.com/anonymous/9523df91cb722e09d963
WARNING: YOU CAN TOTALLY FUBAR AN AMIIBO WITH THIS
WARNING: THIS DOESN'T ACTUALLY WORK WITH BLANK TAGS (yet), WE ARE STILL MISSING PART OF THE PROCESS
Right now, any clones created with this will fail, and have certain pages locked from future writes.
Notes:
Dependencies:
Usage:
python amiibo.py -k KEYFILE scan [-o OUTFILE]
python amiibo.py -k KEYFILE decrypt [-i INFILE] [-o OUTFILE]
python amiibo.py -k KEYFILE encrypt [-i INFILE] [-o OUTFILE]
python amiibo.py -k KEYFILE restore [-i INFILE]
Scan will always decrypt the dump and verify the checksum.
Restore expects a decrypted dump, fixes the checksum, and writes to the NFC tag.
All infile arguments default to stdin, and all outfile arguments default to stdout.
Tested on Windows and Linux; should work on Mac as well.
Edit: Small bug fix. When copying the locked section, all the data after the lock section was messed up as 20 pages were written instead of 19. Should be fixed now.
Edit: Another small update. Previously this was creating 524 byte dumps, now they are properly 520 bytes. I also changed how the memoryviews were being used to make things a bit safer.
https://gist.github.com/anonymous/9523df91cb722e09d963
WARNING: YOU CAN TOTALLY FUBAR AN AMIIBO WITH THIS
WARNING: THIS DOESN'T ACTUALLY WORK WITH BLANK TAGS (yet), WE ARE STILL MISSING PART OF THE PROCESS
Right now, any clones created with this will fail, and have certain pages locked from future writes.
Notes:
- The decrypted dump layout is different than amiitool; all sections are left in place, so the order is identical to that on the tag.
- The key file format is exactly the same as amiitool.
- This application works with 520 byte dumps, the config pages at the end are handled separately.
- This works with essentially any USB NFC reader. I used an ACR122U (even though they are crap). See the nfcpy device compatibility page for more info.
- I have tested simple modifications to real Amiibos such as changing the nickname, and those work fine.
Dependencies:
- Python 2.7: You will want to install the latest version of the 2.7 branch (currently 2.7.11). This is fairly straight forward.
- libusb: Getting this working on Windows is a bit of a pain, read this for help.
- pyusb: Download the latest zip from github, and then run the setup.py script to install.
- nfcpy: Download the tar.gz from Launchpad, open with 7zip, grab the "nfc" directory from inside, and put it either next to the script, or in your Python installation's site-packages directory. The tagtool.py script in the examples directory can be used to diagnose issues.
- PyCryptodome: Install from the command line with "python -m pip install pycryptodome".
Usage:
python amiibo.py -k KEYFILE scan [-o OUTFILE]
python amiibo.py -k KEYFILE decrypt [-i INFILE] [-o OUTFILE]
python amiibo.py -k KEYFILE encrypt [-i INFILE] [-o OUTFILE]
python amiibo.py -k KEYFILE restore [-i INFILE]
Scan will always decrypt the dump and verify the checksum.
Restore expects a decrypted dump, fixes the checksum, and writes to the NFC tag.
All infile arguments default to stdin, and all outfile arguments default to stdout.
Tested on Windows and Linux; should work on Mac as well.
Edit: Small bug fix. When copying the locked section, all the data after the lock section was messed up as 20 pages were written instead of 19. Should be fixed now.
Edit: Another small update. Previously this was creating 524 byte dumps, now they are properly 520 bytes. I also changed how the memoryviews were being used to make things a bit safer.
Last edited by Supercool330,
As requested by @rena2019 I set up a new tool to simply change the UID. So, just upload your bin dump enter the 14 hex chars and you'll get back the modified bin.
http://amiibo.vgmoz.com/uid
I don't have any way of testing this at the moment, but the hex appears to come back correct. So, if someone can verify that would be appreciated.
http://amiibo.vgmoz.com/uid
I don't have any way of testing this at the moment, but the hex appears to come back correct. So, if someone can verify that would be appreciated.
Md5 of my keyfile: 2551afc7c8813008819836e9b619f7edCan someone send me a hash of the amiibo keyfile? I think mine's not correct.
As an experiment, I scanned a link Amiibo, and restored it to a toad Amiibo (which writes everything except the locked pages from page 0x0D to 0x20), and it still scanned fine. This confirms that whatever the issue is, it is definitely somewhere in the locked area. There are three sections of memory in this locked region:
0x34 - 0x54: A hash according to the doc on 3dbrew. This section is used as the third segment when computing the hash at 0x80.
0x54 - 0x60: We know the first 8 bytes of this section are the Amiibo id that encodes the character. I'm not sure what the last 4 bytes are.
0x60 - 0x80: Probably another hash according to the doc on 3dbrew. This section is used when computing the per Amiibo keys. It is the second half of the base seed.
If these sections are in fact hashes, they must be of only immutable data such as the UID. Besides this section, every part of the user memory is writable, and apart from the UID, all CFG bytes are fixed (identical between Amiibo ). This means we only have a few options:
0x34 - 0x54 is a hash using the per Amiibo hmac key or the master hmac key of some data from 0x54 - 0x80 plus the UID, and potentially some other salt (unlikely; normally the key is the salt).
0x5C - 0x60 is actually the bit we are interested in somehow. I'm still trying to figure out exactly what this is.
0x60 - 0x80 is a hash using the master hmac key of some data from 0x34 - 0x60 plus the UID.
I tried all the obvious hash combinations (my best bet was 0x00-0x08 and then 0x54-0x80 since those are the last two segments used in the hash at 0x80), but couldn't find any matches. If we could figure out what 0x5C - 0x60 (page 23) is, it would be helpful.
Edit: 0x5C - 0x60 doesn't seem to be a good candidate, there is far too little entropy there. Note though that it definitely isn't part of the character ID as two different Amiibos of the same character have different values.
0x34 - 0x54: A hash according to the doc on 3dbrew. This section is used as the third segment when computing the hash at 0x80.
0x54 - 0x60: We know the first 8 bytes of this section are the Amiibo id that encodes the character. I'm not sure what the last 4 bytes are.
0x60 - 0x80: Probably another hash according to the doc on 3dbrew. This section is used when computing the per Amiibo keys. It is the second half of the base seed.
If these sections are in fact hashes, they must be of only immutable data such as the UID. Besides this section, every part of the user memory is writable, and apart from the UID, all CFG bytes are fixed (identical between Amiibo ). This means we only have a few options:
0x34 - 0x54 is a hash using the per Amiibo hmac key or the master hmac key of some data from 0x54 - 0x80 plus the UID, and potentially some other salt (unlikely; normally the key is the salt).
0x5C - 0x60 is actually the bit we are interested in somehow. I'm still trying to figure out exactly what this is.
0x60 - 0x80 is a hash using the master hmac key of some data from 0x34 - 0x60 plus the UID.
I tried all the obvious hash combinations (my best bet was 0x00-0x08 and then 0x54-0x80 since those are the last two segments used in the hash at 0x80), but couldn't find any matches. If we could figure out what 0x5C - 0x60 (page 23) is, it would be helpful.
Edit: 0x5C - 0x60 doesn't seem to be a good candidate, there is far too little entropy there. Note though that it definitely isn't part of the character ID as two different Amiibos of the same character have different values.
Last edited by Supercool330,
Then it's clear why decrypting by tool never works
From 2010 to 2011 Germany gave some NFC readers/writers with linux drivers away for free (intrtoduction of NFC-ID-Card), maybe those readers will work on @Supercool330 tool too. SCM SCL011.
It still isn't actually possible to create a clone yet, I just released the python script for people to play around with.A guide would be nice...
Not really, we are in essentially the same place we were a week ago.Moving forward
aww , well progress is progress. anyways, have you guys taken a look at the applications that were made by the Amiiqo company? their app and stuff? Could their app be taken apart and reviewed? Or is that not even relevant?
I just came to a realization. I was thinking about different sections of memory that could be hashed with the derived per amiibo hmac key, and I realized that you can't actually use that key since part of the seed is the write counter from the amiibo. However, the write counter isn't used with the "locked secret" keyset as the magic is 16 bytes long. This also totally explains why there are two sets of keys, the "unfixed infos" is used for the unfixed parts of the amiibo that can change, and the "locked secret" is used for the locked parts that can only be written once. This also explains why none of my hashing turned up any results; I was using the wrong keyset. I suspect we need to build a seed using the "locked secret" keyset, and then either hash it with the "locked secret" hmac key, take the first 32 bytes from the drbg, or generate a key with the drbg and decrypt/hash something. Regardless, the "locked secret" seed will still use the portion of the amiibo at 0x60, so almost certainly the target block of memory is 0x34-0x54. We just need to try various things until we get something that matches.
Last edited by Supercool330,
