Homebrew Official [Download] Decrypt9 - Open Source Decryption Tools (WIP)

[Yuuyuun]

It should work. Keep in mind that saves coming from emulators can have a a differing format and may not work (I can't check this). If you dump, edit and reinject, there should be no problems. Also, keep in mind you have to reboot (not poweroff) the console after the injection.

I tried with a .sav from the VBA emulator, which I renamed to .bin. I'll try what you just said.

Update:
Didn't work. Here's what I did: I played a game for a bit, saved, checked if the game was saving correctly, then I dumped it with decrypt9, booted the game and deleted the data from the in-game menu, booted decrypt9 and injected the file I dumped before deleting the save in-game (which should have my records) and then hit start to reboot. But in-game all save slots are blank.
Btw, when I try to dump the save there's a message saying "Warning: Current CMAC does not match" is this normal?

 

[d0k3]

I tried with a .sav from the VBA emulator, which I renamed to .bin. I'll try what you just said.

Update:
Didn't work. Here's what I did: I played a game for a bit, saved, checked if the game was saving correctly, then I dumped it with decrypt9, booted the game and deleted the data from the in-game menu, booted decrypt9 and injected the file I dumped before deleting the save in-game (which should have my records) and then hit start to reboot. But in-game all save slots are blank.
Btw, when I try to dump the save there's a message saying "Warning: Current CMAC does not match" is this normal?

No, that's not normal. I messed up. I'll fix it and will let you know once it is ready.

 

[d0k3]

I tried with a .sav from the VBA emulator, which I renamed to .bin. I'll try what you just said.

Update:
Didn't work. Here's what I did: I played a game for a bit, saved, checked if the game was saving correctly, then I dumped it with decrypt9, booted the game and deleted the data from the in-game menu, booted decrypt9 and injected the file I dumped before deleting the save in-game (which should have my records) and then hit start to reboot. But in-game all save slots are blank.
Btw, when I try to dump the save there's a message saying "Warning: Current CMAC does not match" is this normal?

Okay... Maybe you can help me test / confirm something? Do the same as you just described, but also dump the AGBSAVE partition before and after (2 files). Provide me with these files, if you want to via PM.

 

[GilgameshArcher]

The sav was FLASH 128k?

 

[Yuuyuun]

Okay... Maybe you can help me test / confirm something? Do the same as you just described, but also dump the AGBSAVE partition before and after (2 files). Provide me with these files, if you want to via PM.

Sure! I PM'ed you.

The sav was FLASH 128k?

The save from the emulator was FLASH 64k.

 

[d0k3]

Sure! I PM'ed you.


The save from the emulator was FLASH 64k.

Alright, got it, checked it. I made a mistake. Could you recompile from this branch and try again?
https://github.com/d0k3/Decrypt9WIP/tree/conv_cia

EDIT: Okay, that did required another fix... derp. It should work now, though. You can also get the compiled build from here:
https://transfer.sh/hFt6M/decrypt9wip-20160801-003945.zip

 

[Yuuyuun]

Alright, got it, checked it. I made a mistake. Could you recompile from this branch and try again?
https://github.com/d0k3/Decrypt9WIP/tree/conv_cia

EDIT: Okay, that did required another fix... derp. It should work now, though. You can also get the compiled build from here:
https://transfer.sh/hFt6M/decrypt9wip-20160801-003945.zip

It works! I tested with both its own save and a save from the VBA emulator, and it worked just fine. Thank you very much for this!

 

[d0k3]

re: my bug report a few posts above, I forgot to add that if the exefs file size is already
a multiple of the sector size (512 bytes) then it doesn't get rounded up. example:
16383 bytes gets rounded up to 16384. (1 byte difference)
16384 bytes stays as 16384. (0 byte difference)
16385 bytes gets rounded up to 16896. (511 byte difference)

see: "Kirby - Planet Robobot (USA) (Demo) (Kiosk)" (you'll need to decrypt it first)
the banner is at offset 0x234A00, the filesize is 524288 bytes (which is a multiple of the sector size)
the icon is at offset 0x2B4A00 which is exactly 524288 bytes (0x80000) after the start of the banner.

Okay, coming back to this - are you 100% sure that files inside ExeFS are always aligned to media units (aka 0x200 byte)?

 

[N7Kopper]

EDIT: Okay, that did required another fix... derp. It should work now, though. You can also get the compiled build from here:
https://transfer.sh/hFt6M/decrypt9wip-20160801-003945.zip

It seems that the compiled version seems to still have the "Warning: Current CMAC does not match" bug from those old sources you posted. I decided to test the precompile because it seemed that the source code version was already tested (and because compiling things is annoying, so I take precompiles when they're available ) and - unless it's Luma's fault somehow for not letting me run a payload from an AGB_FIRM reboot - not only did it fail to inject my Mother 3 save from my flashcart, it also didn't even delete my dummy save.

 

[Yuuyuun]

It seems that the compiled version seems to still have the "Warning: Current CMAC does not match" bug from those old sources you posted. I decided to test the precompile because it seemed that the source code version was already tested (and because compiling things is annoying, so I take precompiles when they're available ) and - unless it's Luma's fault somehow for not letting me run a payload from an AGB_FIRM reboot - not only did it fail to inject my Mother 3 save from my flashcart, it also didn't even delete my dummy save.

Strange, I had no problems with it.

 

[c4388354]

Okay, coming back to this - are you 100% sure that files inside ExeFS are always aligned to media units (aka 0x200 byte)?

Looks like that last commit has fixed the 'icon' and 'banner' files, there is no more encrypted data after those files.

The '.code' file still has encrypted data after it, which has me thinking,
is that leftover data just 00's that are encrypted with KeySlot0x2C instead?
Maybe Nintendo encrypts the entire ExeFS partition with KeySlot0x2C and then
decrypts and re-encrypts all ExeFS files (excluding icon and banner) with the new keyslot instead?

If so, then the method to Encrypt an Decrypted ExeFS with Crypto-type 0x01 and 0x0A is:
1. Encrypt entire ExeFS partition (except the first 512 bytes header) with Keyslot 0x2C.
2. Look at each file in the ExeFS, if its icon or banner then skip processing the file,
else: Decrypt the file (Aligned to 16 bytes?) using KeySlot0x2C and re-encrypt it using either
KeySlot0x25 if Crypto-Type 0x01
-or-
KeySlot0x18 if Crypto-Type 0x0A.
3. Encrypt the ExeFS header using Keyslot 0x2C.

and the method to Decrypt an Encrypted ExeFS with Crypto-type 0x01 and 0x0A is:
1. Decrypt the ExeFS header using Keyslot 0x2C.
2. Look at each file in the ExeFS, if its icon or banner, skip processing the file.
else: Decrypt the file (Aligned to 16 bytes?) using:
- KeySlot0x25 if Crypto-Type 0x01 -or- KeySlot0x18 if Crypto-Type 0x0A.
Re-encrypt the file using KeySlot0x2C.
3. Decrypt the entire ExeFS Partition (except first 512 bytes header) using KeySlot 0x2C.

 

[d0k3]

Looks like that last commit has fixed the 'icon' and 'banner' files, there is no more encrypted data after those files.

The '.code' file still has encrypted data after it, which has me thinking,
is that leftover data just 00's that are encrypted with KeySlot0x2C instead?
Maybe Nintendo encrypts the entire ExeFS partition with KeySlot0x2C and then
decrypts and re-encrypts all ExeFS files (excluding icon and banner) with the new keyslot instead?

If so, then the method to Encrypt an Decrypted ExeFS with Crypto-type 0x01 and 0x0A is:
1. Encrypt entire ExeFS partition (except the first 512 bytes header) with Keyslot 0x2C.
2. Look at each file in the ExeFS, if its icon or banner then skip processing the file,
else: Decrypt the file (Aligned to 16 bytes?) using KeySlot0x2C and re-encrypt it using either
KeySlot0x25 if Crypto-Type 0x01
-or-
KeySlot0x18 if Crypto-Type 0x0A.
3. Encrypt the ExeFS header using Keyslot 0x2C.

and the method to Decrypt an Encrypted ExeFS with Crypto-type 0x01 and 0x0A is:
1. Decrypt the ExeFS header using Keyslot 0x2C.
2. Look at each file in the ExeFS, if its icon or banner, skip processing the file.
else: Decrypt the file (Aligned to 16 bytes?) using:
- KeySlot0x25 if Crypto-Type 0x01 -or- KeySlot0x18 if Crypto-Type 0x0A.
Re-encrypt the file using KeySlot0x2C.
3. Decrypt the entire ExeFS Partition (except first 512 bytes header) using KeySlot 0x2C.

You can check this yourself... use the ExeFS header (the one containing the offsets to the files) and check if each file starts at the next media unit. If not, well, then there is encrypted data between it. You may be right with the description above, too, but I'd rather not implement this just for aesthetics (that no one ever sees, adding to that).

 

[liljohn360]

Just a quick warning, don't click GBA VC Save Dump if you haven't loaded a GBA game! It corrupted my SD card.

 

[d0k3]

Just a quick warning, don't click GBA VC Save Dump if you haven't loaded a GBA game! It corrupted my SD card.

Not possible actually. That function checks if there is a save on there, checks if the size in there is sane, and only then starts dumping. Can I see the log? It is more likely something else corrupted your SD card.

 

[liljohn360]

That's very strange then. Unfortunately I don't have access to the log because the entire SD was corrupted. Only thing I could get was this screenshot, seems like the onscreen instructions somehow got dumped into a few large files.

EDIT: Decrypt9 threw a warning about the AGB save being empty or corrupt, and then my 3DS wouldn't boot, threw the SD in my PC and saw these files, I don't think anythings broken though, all seems to work after a format.

 

[d0k3]

That's very strange then. Unfortunately I don't have access to the log because the entire SD was corrupted. Only thing I could get was this screenshot, seems like the onscreen instructions somehow got dumped into a few large files.

EDIT: Decrypt9 threw a warning about the AGB save being empty or corrupt, and then my 3DS wouldn't boot, threw the SD in my PC and saw these files, I don't think anythings broken though, all seems to work after a format.

Okay, thanks for this. I'll look into the source code, but it is more likely the corruption happened before you actually run D9 (with the text from the inapp text strangely being files now).

 

[liljohn360]

That is very likely, I've since used the GBA dump feature and it's been fine, so I suspect another app too.

 

[hippy dave]

Would having the movable.sed from a broken console be enough to be able to decrypt the AGBSAVE partition from a backup of that console? (The description on decrypt9's github just refers to SD card files.) If not, would there be any other way to decrypt it? I have the xorpad for the fat16 partition but apparently not for the entire nand.

 

[d0k3]

Would having the movable.sed from a broken console be enough to be able to decrypt the AGBSAVE partition from a backup of that console? (The description on decrypt9's github just refers to SD card files.) If not, would there be any other way to decrypt it? I have the xorpad for the fat16 partition but apparently not for the entire nand.

Movable.sed won't help, you actually need the consoles NAND CID and unique keys (or at least ARM9 access on it). Since it is broken, I guess you are out of luck.

 

[hippy dave]

Movable.sed won't help, you actually need the consoles NAND CID and unique keys (or at least ARM9 access on it). Since it is broken, I guess you are out of luck.

Hm ok thanks.

--------------------- MERGED ---------------------------

...would they be readable from the nand chip with a hardmod?