- Joined
- Jun 1, 2014
- Messages
- 144
- Trophies
- 0
- Location
- RnVja1lvdU15RHVkZQ
- Website
- www.goombi.fr
- XP
- 178
- Country
Okay, here we go, I found a fix for the QRcode export thing. That still has an online dependency (on PHP on my server tho, someone who wants to rehost it can PM me if you want the PHP files).
Since some Mii research were freshly published, this thread will keep track of it.
We still don't know what does many bytes of a decrypted Mii.
The goal of this thread is understanding which bit define what on a Mii.
- Ressources -
3dbrew
Those pages are full of useful information:
Mii
Mii Maker
Mii formats
In decrypted state they are 0x60 bytes long or 0x5c bytes long in CFL_DB.dat.
The 4 bytes of difference are 2 null bytes and a 2 bytes of CRC16.
Let's call those 0x60 bytes long, ".mii" files.
In encrypted state they are 0x70 bytes long. Simply the 0x60 decrypted bytes passed through APT:Wrap (AES-CMM adds 16 bytes of integrity checks).
As those are encrypted, let's call them ".bin" files.
Finally, the only stuff you could get without homebrew, QR codes. It's simply a .bin encoded in QR code format.
Tools
QR <-> .bin
Webapp: editMii.
You can open .bin or images and exports them to .bin or image.
You can also open .mii and re-export it in .mii right away, that will fix the CRC before downloading.
.bin <-> .mii
Homebrew: cipherMii Calls APT:Wrap on input.mii and APT:Unwrap on input.bin (input and output should be placed in the .3dsx folder)
Extract CFL_DB.dat
Homebrew: extdata_dump will do. config.txt is already set to dump CFL_DB.dat
Real time edition
CFW: NTR (with NTR debugger or RAM explorer). Sorry for non CFW users, but the RAM viewing is one of the best tools we have.
Research
- I'm now sure that putting a wrong CRC 16 at the end of a .mii doesn't do anything when scanned back in Mii Maker.
- Also, editing the special Mii (gold pants) then ciphering the Mii produces an invalid Mii (CRC fixed or not). This probably means there are more about how the Mii datas are moved when put inside a QR code.
- The "CFOG" section of CFL_DB.dat is loaded in RAM at 0x14895a20. It is only written when saving. You can watch a Mii with RAM explorer, do a change+save, reopen an see if you can spot what changed.
- If you edit the special bit in RAM with NTR then load the Mii for editing, it crashes the editor and reboots the console.
What's to be done
- Understand better the Mii <-> QR code done by Mii Maker. That will probably need some REing.
- Map each Mii variable to the bits in a .mii. The Mii page on 3D brew contains all my findings about those values order in RAM and possible values range.
- Port the 3DS APT:Wrap and APT:Unwrap to PC. More testing than anything (and we have to get the 0x31 key. With Miitomo that has to have it, we have 2 ways to get our hands on the key). That would greatly speed things up.
Feel free to post any offset you found or tool you made that could help, I'll keep the OP up to date
(but since I don't know anything about true REing, I'll need some help, if someone could tell me about an ARM dissassembler that a noob in RE can use AND that does not cost two legs would be really nice).
Since some Mii research were freshly published, this thread will keep track of it.
We still don't know what does many bytes of a decrypted Mii.
The goal of this thread is understanding which bit define what on a Mii.
- Ressources -
3dbrew
Those pages are full of useful information:
Mii
Mii Maker
Mii formats
In decrypted state they are 0x60 bytes long or 0x5c bytes long in CFL_DB.dat.
The 4 bytes of difference are 2 null bytes and a 2 bytes of CRC16.
Let's call those 0x60 bytes long, ".mii" files.
In encrypted state they are 0x70 bytes long. Simply the 0x60 decrypted bytes passed through APT:Wrap (AES-CMM adds 16 bytes of integrity checks).
As those are encrypted, let's call them ".bin" files.
Finally, the only stuff you could get without homebrew, QR codes. It's simply a .bin encoded in QR code format.
Tools
QR <-> .bin
Webapp: editMii.
You can open .bin or images and exports them to .bin or image.
You can also open .mii and re-export it in .mii right away, that will fix the CRC before downloading.
.bin <-> .mii
Homebrew: cipherMii Calls APT:Wrap on input.mii and APT:Unwrap on input.bin (input and output should be placed in the .3dsx folder)
Extract CFL_DB.dat
Homebrew: extdata_dump will do. config.txt is already set to dump CFL_DB.dat
Real time edition
CFW: NTR (with NTR debugger or RAM explorer). Sorry for non CFW users, but the RAM viewing is one of the best tools we have.
Research
- I'm now sure that putting a wrong CRC 16 at the end of a .mii doesn't do anything when scanned back in Mii Maker.
- Also, editing the special Mii (gold pants) then ciphering the Mii produces an invalid Mii (CRC fixed or not). This probably means there are more about how the Mii datas are moved when put inside a QR code.
- The "CFOG" section of CFL_DB.dat is loaded in RAM at 0x14895a20. It is only written when saving. You can watch a Mii with RAM explorer, do a change+save, reopen an see if you can spot what changed.
- If you edit the special bit in RAM with NTR then load the Mii for editing, it crashes the editor and reboots the console.
What's to be done
- Understand better the Mii <-> QR code done by Mii Maker. That will probably need some REing.
- Map each Mii variable to the bits in a .mii. The Mii page on 3D brew contains all my findings about those values order in RAM and possible values range.
- Port the 3DS APT:Wrap and APT:Unwrap to PC. More testing than anything (and we have to get the 0x31 key. With Miitomo that has to have it, we have 2 ways to get our hands on the key). That would greatly speed things up.
Feel free to post any offset you found or tool you made that could help, I'll keep the OP up to date
(but since I don't know anything about true REing, I'll need some help, if someone could tell me about an ARM dissassembler that a noob in RE can use AND that does not cost two legs would be really nice).
Last edited by Goombi,
;)
