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

[Shadowtrance]

@d0k3 is the seedsave functionality only usable to recover seeds from N3DS emunand? Or is there a way to get a seedsave (and later a seeddb) from an O3DS 10.3 emunand?

Also, great work!

Should work on both n3ds and o3ds now that we have 10.3 emunand on n3ds. Previously you could only get seeds from o3ds because of being stuck on 9.5 emunand on n3ds.

 

[ootnes2]

Should work on both n3ds and o3ds now that we have 10.3 emunand on n3ds. Previously you could only get seeds from o3ds because of being stuck on 9.5 emunand on n3ds.

Could the issue be that it doesn't grab the right seed if emunand and sysnand are linked, or should that not make a difference if the dump is done via emunand option?

Also, massexplosian's link appears to have all the seeds...

 

[Shadowtrance]

Could the issue be that it doesn't grab the right seed if emunand and sysnand are linked, or should that not make a difference if the dump is done via emunand option?

Also, massexplosian's link appears to have all the seeds...

What was the issue? You didn't post an issue, you asked a question...

And yeah i know about that link, think everyone does by now. Quite handy.

As to THIS question, I don't think it matters if the nands are linked or not as the seedsave is actually IN the emunand and won't exist in sysnand unless it is 9.6+ anyway. The seedsave function doesn't even look at sysnand as it is coded to only look at emunand. It is under the emunand menu for a reason.

 

[d0k3]

I did find a probjem with file injection, though, specifically movable.sed.
I'm trying to inject a movable.sed that's smaller than the one currently in NAND, and Decrypt9 won't recognize the smaller file on my SD card.

The one in my NAND is 0x140 bytes, the one i want to inject is missing the last 0x20 bytes from the file that get written during a system transfer / format. See http://3dbrew.org/wiki/Nand/private/movable.sed

More injection size problems:

I dumped my EmuNAND (formatted with GW back then) via EmuNAND9 to EmuNAND.bin, 1888MB.
I then broke my emunand and wanted to restore the backup with Decrypt9. The EmuNAND Restore option recognized the EmuNAND.bin on my SD, but it complained about an invalid size and aborted.

That's a bit of a controversial issue... As it is now, the size of a file is one of the things that is used to determine if the file to inject is alright. I could allow injecting smaller / bigger files, but then that safety would be gone. Add to that, however, that Decrypt9 doesn not use FAT routines fo NAND, thus injecting bigger files is somewhat not possible. For basically all dumpable / injectable files but movable.sed, the size does never change anyways. Now, is there a specific reason why you wanted to inject that uninitialized movable.sed back when you could have reached the same goal by just reseting the 3DS from system settings?

Second one... the NAND injection problem. The dumps from EmuNAND9 and Decrypt9 should be identical in size, as long as they come from the same console. Can you try using Decrypt9 to dump the EmuNAND backup and tell me what size it is?

Could the issue be that it doesn't grab the right seed if emunand and sysnand are linked, or should that not make a difference if the dump is done via emunand option?

Also, massexplosian's link appears to have all the seeds...

Nope, EmuNAND / SysNAND linking has nothing to do with it. Can you give me some more details about the issue? What doesn't work the way you think it should?

 

[Krude]

Removing the last 0x20 bytes from movable.sed to reset it to "uninitialized" state is neccessary to do a manual system transfer (to keep all your save games), for example. I'm currently playing around with that. Considering that, the size for that file should never increase, only decrease, i guess. Maybe you can code in an exception for that file, the only sizes it can be is 0x120 and 0x140, anyways.

I'll try a D9 dump later.

 

[Krude]

Another suggestion: When dumping a file and choosing a file name, the selector shows a little (!) when that file already exists on the SD, which is good. But make it also request another overwrite confirmation, just in case you miss that little notification. Better be safe!

 

[d0k3]

Removing the last 0x20 bytes from movable.sed to reset it to "uninitialized" state is neccessary to do a manual system transfer (to keep all your save games), for example. I'm currently playing around with that. Considering that, the size for that file should never increase, only decrease, i guess. Maybe you can code in an exception for that file, the only sizes it can be is 0x120 and 0x140, anyways.

I'll try a D9 dump later.

Good idea! However, actually changing the size of the movable sed will require some deeper code changes, and it might be easier to just add a "truncate movable.sed" feature in, but then the question is how often will that actually get used... Will have to think about it. Is there some tutorial on how to do that manual system transfer available somewhere?

Another suggestion: When dumping a file and choosing a file name, the selector shows a little (!) when that file already exists on the SD, which is good. But make it also request another overwrite confirmation, just in case you miss that little notification. Better be safe!

I actually want to minimize user interaction inside these feature functions. The file selection (and SD folder selection for SD Decryptor) is the first exepction to that rule. I will think about it, though, you've got a point there.

 

[Krude]

So i made another dump of emunand via D9, and it seems the E9 and D9 dumps are exactly the same size, down to the byte.

I then tried to restore the E9 dump with D9 again:
"ERROR, file is too small!
EmuNAND Restore: failed!"

Then i tried to restore the D9 dump i JUST MADE with D9, and it gave the same error!

Just for reference, when i earlier found out that D9 couldn't restore my E9 dump, i went back into E9 and it restored the dump without complaint. I haven't tried restoring the D9 dump with E9 yet, but i probably don't need to, it seems clear something is borked in D9 at the moment.
I'm using the 20160112 release, btw.

edit: since i don't have a hard mod, i'm not gonna test the sysNand restore in case something goes horribly wrong, but man, i hope it works, since E9 can't restore sysNand at the moment.

 

[d0k3]

So i made another dump of emunand via D9, and it seems the E9 and D9 dumps are exactly the same size, down to the byte.

I then tried to restore the E9 dump with D9 again:
"ERROR, file is too small!
EmuNAND Restore: failed!"

Then i tried to restore the D9 dump i JUST MADE with D9, and it gave the same error!

Just for reference, when i earlier found out that D9 couldn't restore my E9 dump, i went back into E9 and it restored the dump without complaint. I haven't tried restoring the D9 dump with E9 yet, but i probably don't need to, it seems clear something is borked in D9 at the moment.
I'm using the 20160112 release, btw.

edit: since i don't have a hard mod, i'm not gonna test the sysNand restore in case something goes horribly wrong, but man, i hope it works, since E9 can't restore sysNand at the moment.

I'll look after it. I'm pretty sure this is a simple one. Will look after it, thank you for pointing it out!

Also, if there is trouble with restoring EmuNAND backups atm, there will also be trouble with SysNAND backups.

UPDATE: ... and fixed. You'd need to compile fresh from source, no new release yet.

 

[dark_samus3]

Removing the last 0x20 bytes from movable.sed to reset it to "uninitialized" state is neccessary to do a manual system transfer (to keep all your save games), for example. I'm currently playing around with that. Considering that, the size for that file should never increase, only decrease, i guess. Maybe you can code in an exception for that file, the only sizes it can be is 0x120 and 0x140, anyways.

I'll try a D9 dump later.

Why not just pad the last 0x20 with 0's?

 

[Krude]

I'm wondering, can Decrypt9 also decrypt the NAND data files? So, the "saves" for system apps and other things installed to NAND. These files lack the SD Encryption layer, but they still use the movable.sed seed for the AES MAC savegame encryption.

I've been trying to decrypt and backup NAND saves all day now, and haven't found a method yet. The usual Homebrew save exporters don't work, for obvious reasons, and even Savedatafiler only accesses the SD card for saves.
Being able to decrypt and maybe re-encrypt system saves would mean you don't have to set up your entire system again after a system transfer or a format (after unlinking NANDs for example).
In the future, it would also help for EmuNAND browsers if we want to stay on 10.3 for menuhax, but the browser is blocked for updates by Nintendo again: the block is written to the browser save, and we could just update that to keep it functional past 10.3.

 

[d0k3]

I'm wondering, can Decrypt9 also decrypt the NAND data files? So, the "saves" for system apps and other things installed to NAND. These files lack the SD Encryption layer, but they still use the movable.sed seed for the AES MAC savegame encryption.

I've been trying to decrypt and backup NAND saves all day now, and haven't found a method yet. The usual Homebrew save exporters don't work, for obvious reasons, and even Savedatafiler only accesses the SD card for saves.
Being able to decrypt and maybe re-encrypt system saves would mean you don't have to set up your entire system again after a system transfer or a format (after unlinking NANDs for example).
In the future, it would also help for EmuNAND browsers if we want to stay on 10.3 for menuhax, but the browser is blocked for updates by Nintendo again: the block is written to the browser save, and we could just update that to keep it functional past 10.3.

That's a good idea. I could implement that for specific files (same as only specific files can be dumped / injected now). I need some more info, though. I don't fully understand that encryption yet. Can you give me the full path to one of these files?

BTW, the seedsave file should fall into this category, too. And I don't see any encryption in that...

 

[ootnes2]

Nope, EmuNAND / SysNAND linking has nothing to do with it. Can you give me some more details about the issue? What doesn't work the way you think it should?

When I try to convert seedsave.bin from O3DS 10.3 emunand using your seedconv program the program says "No SEEDs found!" Ther are definitely apps from the eshop with 9.6 crypto in the emunand, so there should be seeds in the seedsave. Any thoughts?

(If it is helpful, here is the text in Decrypt9 when I dump the seedsave.bin:

"Using EmuNAND @ 1DD000/000000
Searching for seedsave.bin...
System version 9.x
Found at 0EBB000, size 688kB"

After pressing a to create the seedsave it says "Dump seedsave.bin: succeeded!")

 

[Asia81]

Would it be possible to add a cia encryptor, like you do for ncch?
With that, we could encrypt cia, like custom themes and install to gw.

 

[redunka]

Would it be possible to add a cia encryptor, like you do for ncch?
With that, we could encrypt cia, like custom themes and install to gw.

Gateway doesn't patch sig checks for CFA. It's the same problem as for cryptofixed manuals/dlp.
Even if we encrypt it, we still can't sign it.

 

[d0k3]

When I try to convert seedsave.bin from O3DS 10.3 emunand using your seedconv program the program says "No SEEDs found!" Ther are definitely apps from the eshop with 9.6 crypto in the emunand, so there should be seeds in the seedsave. Any thoughts?

(If it is helpful, here is the text in Decrypt9 when I dump the seedsave.bin:

"Using EmuNAND @ 1DD000/000000
Searching for seedsave.bin...
System version 9.x
Found at 0EBB000, size 688kB"

After pressing a to create the seedsave it says "Dump seedsave.bin: succeeded!")

Use the newest SEEDconv version. And also, try the Update SeedDB feature in Decrypt9.

Would it be possible to add a cia encryptor, like you do for ncch?
With that, we could encrypt cia, like custom themes and install to gw.

Gateway doesn't patch sig checks for CFA. It's the same problem as for cryptofixed manuals/dlp.
Even if we encrypt it, we still can't sign it.

Exactly. You can encrypt it all you like, Gateway will not allow you to install custom themepack CIAs. In fact, GW will patch signatures only for the first content of a CIA (which the TOC in a theme pack CIA, duh...), but not for anything else. This leads to you being unable to install such a CIA. It is beyound my logic why they are doing this the way they do, and they seem to have zero interest in fixing this issue (I'm pretty sure it wouldn't take one of their devs more than an hour to do this). All they concentrate on nowadays is fancy new features that sound good on paper.

 

[redunka]

Exactly. You can encrypt it all you like, Gateway will not allow you to install custom themepack CIAs. In fact, GW will patch signatures only for the first content of a CIA (which the TOC in a theme pack CIA, duh...), but not for anything else. This leads to you being unable to install such a CIA. It is beyound my logic why they are doing this the way they do, and they seem to have zero interest in fixing this issue (I'm pretty sure it wouldn't take one of their devs more than an hour to do this). All they concentrate on nowadays is fancy new features that sound good on paper.

Actually, IIRC, GW will not patch control content (TOC) of themes either, because it's not a CXI.
It has an ExeFS partition, but it's just an icon, there is no actual code, so that content is also a CFA.
It's a shame that GW ignores problem which can be easily fixed.

 

[d0k3]

Actually, IIRC, GW will not patch control content (TOC) of themes either, because it's not a CXI.
It has an ExeFS partition, but it's just an icon, there is no actual code, so that content is also a CFA.
It's a shame that GW ignores problem which can be easily fixed.

Bunch of lazy b... they are... :/ Anyways, @Asia81, if there is any good reason to have the CIA encryptor, I will put it back in there. I just don't want a feature in there that no one uses and no one will test.

 

[Asia81]

If we can't use it for install theme.cia, don't worry, I don't need it :3

 

[ootnes2]

Use the newest SEEDconv version. And also, try the Update SeedDB feature in Decrypt9.

After redownloading one of the titles and repairing the other, Decrypt9 now was able to get the seeds (I had already been using the most recent SEEDconv). Is it possible that this happened because I had downloaded the games before I had installed the emunand (and my nands are still linked)?