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

[Deleted member 373223]

Because it is different formatting.

they aren't both FAT32?

 

[A_Random_Guy]

they aren't both FAT32?

@d0k3 means that Emunand and RedNand are formatted differently. The 3DS still need the sd card in FAT32

 

[Intronaut]

So... your NAND was somehow corrupted? Thats the only way you can get that error. Do you have any idea how that happened?

My emunand is fine, I tested all the partitions and they work very well. But anyway, my slot0x05keyY.bin was named Slot0x05keyY.bin. maybe that caused the error

 

[Hakujou]

they aren't both FAT32?

The data partition is in FAT32. The emuNAND is RAW (no file system in here, data is just stored as-is and therefore not understable by your computer).
It's just an analogy. Both are very close, but GW EmuNAND stores first 512 bytes at the end of file, where RedNAND is in the right order.

 

[d0k3]

My emunand is fine, I tested all the partitions and they work very well. But anyway, my slot0x05keyY.bin was named Slot0x05keyY.bin. maybe that caused the error

Nope, that is case insensitive, plus TWLP wouldn't have failed then (especially not with TWLN working, cause that uses the same crypto). You must have had some corruption in there (earlier, when you got the decryption errors). What did you use to test?

You can try the most recent testing version, use the NAND Dump Validator in NAND Backup & Restore to check any dumps you got:
http://workupload.com/file/7KTsqgjh

EDIT: Or, that decryption problem was in SysNAND somehow... Is there any chance you started from a 2.1 SysNAND on N3DS? That was not supported earlier (now it is, with the testing version).

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

they aren't both FAT32?

I think you may also wonder why there is no specific RedNAND restore option in D9, while there is one in E9. This is because D9 uses the formatting (RedNAND or GW EmuNAND) that was on there before, and defaults to GW type EmuNAND if nothing is detected. EmuNAND9 is the tool to go to for proper first time EmuNAND setup, not D9 .

 

[BDS]

I just did a data transfer between two (new, but I guess it shouldn't matter) 3DSs (from 3DS1 to 3DS2), and anything installed with FBI is "gone".
Yet, I did make a NAND backup before the data transfer and all my apps and games appear as "new software" in the restored 3DS1.
So I tried to dump title.db from 3DS1 to 3DS2 and it didn't boot. Tried adding ticket.db with not much more hope, still no boot. Which file(s) should I import from 3DS1 to 3DS2?

 

[Qwertyqwerty]

Hi. I have a question.

I have two nand.bin files. One made with the gateway launcher when I bought the console, and another made with Decrypt9 when I got the OTP.

My question is that does not match the MD5, although the two files have the exact same size. Have corrupted any of the two files or something?

 

[d0k3]

I just did a data transfer between two (new, but I guess it shouldn't matter) 3DSs (from 3DS1 to 3DS2), and anything installed with FBI is "gone".
Yet, I did make a NAND backup before the data transfer and all my apps and games appear as "new software" in the restored 3DS1.
So I tried to dump title.db from 3DS1 to 3DS2 and it didn't boot. Tried adding ticket.db with not much more hope, still no boot. Which file(s) should I import from 3DS1 to 3DS2?

I don't know if what you intend to do can work at all, but maybe someone knows.

Hi. I have a question.

I have two nand.bin files. One made with the gateway launcher when I bought the console, and another made with Decrypt9 when I got the OTP.

My question is that does not match the MD5, although the two files have the exact same size. Have corrupted any of the two files or something?

Hmmm... did you use your 3DS between the first and the second backup? If so, yes, changes in the SysNAND are normal.


Everyone, this is the last testing version before the next release:
http://workupload.com/file/Y9KNCIV3

If you want to help, this is what needs testing (roughly in order of importance). I marked anything that is completely risk free with [RISK FREE], for everything else I suggest having backups of your SD and EmuNAND (or a spare SD card):

• [N3DS/1.8GB NAND] [RISK FREE] Backing up minimum size RedNANDs (created by newest EmuNAND9) - what size do you get?
• [N3DS/1.8GB] Same as above, but try restoring. What size is restored?
• [RISK FREE] The new keydb feature - build your aeskeydb.bin (option in Maintenance), remove your slot0x??key?.bin, try if everything works. Everything includes decrypting 7x / Secure3 / Secure4 NCCHs/.3DS files.
• [RISK FREE] Hold L+R upon starting (might take a while), report anything that looks not right.
• [RISK FREE] Try the new System Info feature - does the output look correct?
• [RISK FREE] [N3DS] Validating FW 2.1 NAND backups, dumping CTRNAND from FW 2.1 NANDs (can be on EmuNAND)
• A9LH preserving NAND restore - try if this leaves your A9LH installation untouched

Hoping to get some feedback, and thanks in advance.

 

[ihaveahax]

I don't know if what you intend to do can work at all, but maybe someone knows.


Hmmm... did you use your 3DS between the first and the second backup? If so, yes, changes in the SysNAND are normal.


Everyone, this is the last testing version before the next release:
http://workupload.com/file/Y9KNCIV3

If you want to help, this is what needs testing (roughly in order of importance). I marked anything that is completely risk free with [RISK FREE]:

• [N3DS/1.8GB NAND] [RISK FREE] Backing upminimum size RedNANDs (created by newest EmuNAND9)- what size do you get?
• [N3DS/1.8GB] Same as above, but try restoring. What size is restored?
• [RISK FREE] The new keydb feature - build your aeskeydb.bin (option in Maintenance), remove your slot0x??key?.bin, try if everything works. Everything includes decrypting 7x / Secure3 / Secure4 NCCHs/.3DS files.
• [RISK FREE] Hold L+R upon starting (might take a while), report anything that looks not right.
• [RISK FREE] Try the new System Info feature - does the output look correct?
• [RISK FREE] [N3DS] Validating FW 2.1 NAND backups, dumping CTRNAND from FW 2.1 NANDs (can be on EmuNAND)
• A9LH preserving NAND restore - try if this leaves your A9LH installation untouched

Hoping to get some feedback, and thanks in advance.

I built the latest commit from source (shouldn't be different but I felt I should mention it). I tried decrypting "Super Mario World" SNES VC on Old3DS, through arm9loaderhax, with only "aeskeydb.bin" and "seeddb.bin", and it worked just fine. I was able to extract it on a computer as well.

Spoiler

Opening /D9Game ...
Processing CIA "Super Mario World (000400000F700E00).cia"
Pass #1: CIA decryption...
Decrypting Content 1 of 2 (3MB)...
Verifying decrypted content...
Verified OK!
Decrypting Content 2 of 2 (1MB)...
Verifying decrypted content...
Verified OK!
Pass #2: NCCH decryption...
Processing Content 1 of 2 (3MB)...
Code / Crypto: KTR-N-UAAE / Secure4 Seed
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (2kB/1311kB/2MB)
Verify ExHdr/ExeFS/RomFS: OK/OK/OK
Recalculating hash...
Processing Content 2 of 2 (1MB)...
Code / Crypto: CTR-P-CTAP / Seed
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (0kB/0kB/1MB)
Verify ExHdr/ExeFS/RomFS: -/-/OK
Recalculating hash...
Recalculating TMD hashes...
Success!

1x processed / 0x failed
CIA Decryptor (deep): succeeded!

Press B to return, START to reboot.

Unmounting SD card...

I also tried Pokémon Yellow under the same environment and it worked as well.

Spoiler

Opening /D9Game ...
Processing CIA "Pokemon Yellow (USA).cia"
Pass #1: CIA decryption...
Decrypting Content 1 of 2 (6MB)...
Verifying decrypted content...
Verified OK!
Decrypting Content 2 of 2 (2MB)...
Verifying decrypted content...
Verified OK!
Pass #2: NCCH decryption...
Processing Content 1 of 2 (6MB)...
Code / Crypto: CTR-P-QBFA / 7x Seed 
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (2kB/987kB/5MB)
Verify ExHdr/ExeFS/RomFS: OK/OK/OK
Recalculating hash...
Processing Content 2 of 2 (2MB)...
Code / Crypto: CTR-P-CTAP / Seed 
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (0kB/0kB/2MB)
Verify ExHdr/ExeFS/RomFS: -/-/OK
Recalculating hash...
Recalculating TMD hashes...
Success!

1x processed / 0x failed 
CIA Decryptor (deep): succeeded!

Press B to return, START to reboot.

the only Secure3 game I know of is Xenoblade Chronicles and that's huge, so I wanted to mention this for now while I test it out.

 

[3xkrazy]

@d0k3

I noticed that you revamped AES key management. Can you shed some light on "aeskeydb.bin" in Decrypt9WIP/source/decryptor/key.c? This file is not listed in the readme. Is this file generated by Decrypt9WIP at the root of the card using the user provided slot*.bin files, or is it something that the user has to create and provide?

Also, I noticed that you removed:

if (FileGetData("slot0x05KeyY.bin", CtrNandKeyY, 16, 0) != 16) - from nand.c
snprintf(filename, 31, "slot0x%02XKeyX.bin", (unsigned int) keyslot); - from game.c

and added multiple entries of "slot0x%02X%s.bin" into key.c

In past versions, I modified the files above if I wanted to change the *bin path detection to some place other than the root of the SD. If i wanted to do the same in the current version (aeskeydb and slot files), I would only need to modify key.c, or is there something else i'm missing?

 

[Madridi]

@d0k3

I noticed that you revamped AES key management. Can you shed some light on "aeskeydb.bin" in Decrypt9WIP/source/decryptor/key.c? This file is not listed in the readme. Is this file generated by Decrypt9WIP at the root of the card using the user provided slot*.bin files, or is it something that the user has to create and provide?

Also, I noticed that you removed:

if (FileGetData("slot0x05KeyY.bin", CtrNandKeyY, 16, 0) != 16) - from nand.c
snprintf(filename, 31, "slot0x%02XKeyX.bin", (unsigned int) keyslot); - from game.c

and added multiple entries of "slot0x%02X%s.bin" into key.c

In past versions, I modified the files above if I wanted to change the *bin path detection to some place other than the root of the SD. If i wanted to do the same in the current version (aeskeydb and slot files), I would only need to modify key.c, or is there something else i'm missing?

While not directly the same, I second this. Is it possible to change where the keys are loaded from instead of sticking everything in the root? Maybe from a folder called Keys instead on the root or inside the decrypt9 folder. It would really make the SD cleaner

 

[3xkrazy]

While not directly the same, I second this. Is it possible to change where the keys are loaded from instead of sticking everything in the root? Maybe from a folder called Keys instead on the root or inside the decrypt9 folder. It would really make the SD cleaner

I think you can also place them into SD:/Decrypt9/. I currently have CakesFW, GodMode9, Decrypt9WIP, and a9lh from delebile all pointing to the same directory (SD:/3ds/bin/) for *.bin files. I'm gonna messing around with Decrypt9 right now to see if it works using the selftest function.

 

[3xkrazy]

@d0k3

I noticed that you revamped AES key management. Can you shed some light on "aeskeydb.bin" in Decrypt9WIP/source/decryptor/key.c? This file is not listed in the readme. Is this file generated by Decrypt9WIP at the root of the card using the user provided slot*.bin files, or is it something that the user has to create and provide?

Also, I noticed that you removed:

if (FileGetData("slot0x05KeyY.bin", CtrNandKeyY, 16, 0) != 16) - from nand.c
snprintf(filename, 31, "slot0x%02XKeyX.bin", (unsigned int) keyslot); - from game.c

and added multiple entries of "slot0x%02X%s.bin" into key.c

In past versions, I modified the files above if I wanted to change the *bin path detection to some place other than the root of the SD. If i wanted to do the same in the current version (aeskeydb and slot files), I would only need to modify key.c, or is there something else i'm missing?

Ok, So I dove in not knowing anything about the new "Maintenance Options."

I change the *bin path by modifying Decrypt9WIP/source/decryptor/key.c:

Original:

#define KEYDB_NAME "aeskeydb.bin"
snprintf(filename, 31, "slot0x%02X%s.bin", (unsigned int) keyslot, keyname);
snprintf(filename, 31, "slot0x%02X%s.bin", (unsigned int) keyslot, keyname);

My changes:

#define KEYDB_NAME "/3ds/sys/bin/aeskeydb.bin"
snprintf(filename, 31, "/3ds/sys/bin/slot0x%02X%s.bin", (unsigned int) keyslot, keyname);
snprintf(filename, 31, "/3ds/sys/bin/slot0x%02X%s.bin", (unsigned int) keyslot, keyname);

Dumped all my slot*.bin files into SD:/3ds/sys/bin/ and ran Maintenance options --> Build Key Database.
Decrypt9WIP then builds aeskeydb.bin into SD:/3ds/sys/bin/ using the .bin files provided. The Selftest passed all 20 test, so I guess I did something right.

@d0k3
When Re-building Key Database with 0 new keys found, did you intend it to fail?

Searching for unknown keys...
Found 0 new keys
Build Key Database: failed!

 

[d0k3]

I built the latest commit from source (shouldn't be different but I felt I should mention it). I tried decrypting "Super Mario World" SNES VC on Old3DS, through arm9loaderhax, with only "aeskeydb.bin" and "seeddb.bin", and it worked just fine. I was able to extract it on a computer as well.

Spoiler

Opening /D9Game ...
Processing CIA "Super Mario World (000400000F700E00).cia"
Pass #1: CIA decryption...
Decrypting Content 1 of 2 (3MB)...
Verifying decrypted content...
Verified OK!
Decrypting Content 2 of 2 (1MB)...
Verifying decrypted content...
Verified OK!
Pass #2: NCCH decryption...
Processing Content 1 of 2 (3MB)...
Code / Crypto: KTR-N-UAAE / Secure4 Seed
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (2kB/1311kB/2MB)
Verify ExHdr/ExeFS/RomFS: OK/OK/OK
Recalculating hash...
Processing Content 2 of 2 (1MB)...
Code / Crypto: CTR-P-CTAP / Seed
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (0kB/0kB/1MB)
Verify ExHdr/ExeFS/RomFS: -/-/OK
Recalculating hash...
Recalculating TMD hashes...
Success!

1x processed / 0x failed
CIA Decryptor (deep): succeeded!

Press B to return, START to reboot.

Unmounting SD card...

I also tried Pokémon Yellow under the same environment and it worked as well.

Spoiler

Opening /D9Game ...
Processing CIA "Pokemon Yellow (USA).cia"
Pass #1: CIA decryption...
Decrypting Content 1 of 2 (6MB)...
Verifying decrypted content...
Verified OK!
Decrypting Content 2 of 2 (2MB)...
Verifying decrypted content...
Verified OK!
Pass #2: NCCH decryption...
Processing Content 1 of 2 (6MB)...
Code / Crypto: CTR-P-QBFA / 7x Seed
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (2kB/987kB/5MB)
Verify ExHdr/ExeFS/RomFS: OK/OK/OK
Recalculating hash...
Processing Content 2 of 2 (2MB)...
Code / Crypto: CTR-P-CTAP / Seed
Loading seed from seeddb.bin: ok
Decrypt ExHdr/ExeFS/RomFS (0kB/0kB/2MB)
Verify ExHdr/ExeFS/RomFS: -/-/OK
Recalculating hash...
Recalculating TMD hashes...
Success!

1x processed / 0x failed
CIA Decryptor (deep): succeeded!

Press B to return, START to reboot.

the only Secure3 game I know of is Xenoblade Chronicles and that's huge, so I wanted to mention this for now while I test it out.

Thanks a ton for this!

@d0k3
When Re-building Key Database with 0 new keys found, did you intend it to fail?

Searching for unknown keys...
Found 0 new keys
Build Key Database: failed!

Yup, the fail is intended, but thinking about it again, I guess it should say success in that case. I'll change that.

While not directly the same, I second this. Is it possible to change where the keys are loaded from instead of sticking everything in the root? Maybe from a folder called Keys instead on the root or inside the decrypt9 folder. It would really make the SD cleaner

You mean you don't like the /Decrypt9/ folder for keys either? I will enable GodMode9 to load from the D9 folder als alternative path (also, enable compatibility with aeskeydb.bin), none of my other tools use keys. By the way, @3xkrazy & @Madridi - the better option for you may be changing the work folder in common.h instead of all those small changes. Anything can be loaded from and written to the work folder. Works for D9, E9 and OTPHelper (although I do not recommend anyone use OTPHelper for anything else but it's intended purpose).

 

[Hakujou]

You mean you don't like the /Decrypt9/ folder for keys either? I will enable GodMode9 to load from the D9 folder als alternative path (also, enable compatibility with aeskeydb.bin), none of my other tools use keys. By the way, @3xkrazy & @Madridi - the better option for you may be changing the work folder in common.h instead of all those small changes. Anything can be loaded from and written to the work folder. Works for D9, E9 and OTPHelper (although I do not recommend anyone use OTPHelper for anything else but it's intended purpose).

To be honest, I think it would be nice to have all the files needed by your homebrews (keys, NAND dumps, etc) in one place instead of one folder per homebrew. For example, it would be better to have NANDs dumps in one folder available with EmuNAND9 and Decrypt9... Same for AES keys

 

[d0k3]

To be honest, I think it would be nice to have all the files needed by your homebrews (keys, NAND dumps, etc) in one place instead of one folder per homebrew. For example, it would be better to have NANDs dumps in one folder available with EmuNAND9 and Decrypt9... Same for AES keys

I agree about NAND dumps, for keyfiles you've got the problem that these are not only used by my own software, and the one folder everyone can agree on is the SD card root. I'll see what I can do about this.

 

[Hakujou]

I agree about NAND dumps, for keyfiles you've got the problem that these are not only used by my own software, and the one folder everyone can agree on is the SD card root. I'll see what I can do about this.

If everyone was using your new AES keys DB that would be awesome. Just one file with all keys at the root of SDCard. We could even have an homebrew to manage these keys (add/delete them if needed).

 

[Sniffynose]

I like the key database idea, that would clean up a ton of stuff and could be a good place for various homebrews to store different keys.

 

[d0k3]

If everyone was using your new AES keys DB that would be awesome. Just one file with all keys at the root of SDCard. We could even have an homebrew to manage these keys (add/delete them if needed).

I like the key database idea, that would clean up a ton of stuff and could be a good place for various homebrews to store different keys.

Decrypt9 adds them ('Build Key Database'), and deleting should not be required, but you can do so manually, with a hex editor. The keys file is also encrypted, it does not contain the keys in clear text. Sharing it (just in case someone asks) is still not allowed in here.

 

[Hakujou]

Decrypt9 adds them ('Build Key Database'), and deleting should not be required, but you can do so manually, with a hex editor. The keys file is also encrypted, it does not contain the keys in clear text. Sharing it (just in case someone asks) is still not allowed in here.

I was saying that because some people doesn't use Decrypt9 while using other homebrews that requires keys (Cakes, for example), so a separate homebrew would make sense, since the AES database could be an "open" format ^^.
But I really like the idea, it's just great !