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

[atkfromabove]

@atkfromabove & @key1340
Here's a new release for you and anyone else who is interested to test (not on GitHub yet).

For @atkfromabove: This has the 32bit fifo disabled, but still using the new SDMMC and FATFS routines. I think it is faster that way, but I'm entirely unsure. These speed results would be very helpful.

For @key1340: I'm almost sure the seedsave dumper will work as intended now. There's also a new seeddb.bin updater in there. It will work as SEEDconv does, but if seeddb.bin already exists it will update it (also doing duplicate checks). At this time I can only hope it works as intended. Backup your seeddb.bin file, just in case.

I tested the latest version. Here are my results:

 

[d0k3]

I tested the latest version. Here are my results:

View attachment 25725

So there's not much of a difference in any of the three versions.... There's one more thing we could try, increasing the buffer size. I'll make a new version later. Btw, you asked why the NAND backup is a little bigger now. According to basically everyone (CakesFW, rxTools, Gateway), the new NAND backup size is the correct one. Because we need that size for an offset in the EmuNAND now, it is important that the value we have is correct.

 

[Shadowtrance]

That is indeed the correct nand size (1888 MB, 2 GB emmc on n3ds), the one that was 1 MB smaller was wrong, dunno what was going on there.

 

[key1340]

@d0k3

I have test the new version on o3ds

Titlekey Decrypt + Ticket Dump still work fine

Seedsave Dump works fine

Update SeedDB works fine

The Seedsave Dump made a copy of the 00000000 file named seedsave.bin and Update SeedDB made a seeddb.bin.Are they supposed to make different file or the same file ?

 

[d0k3]

@d0k3

I have test the new version on o3ds

Titlekey Decrypt + Ticket Dump still work fine

Seedsave Dump works fine

Update SeedDB works fine

The Seedsave Dump made a copy of the 00000000 file named seedsave.bin and Update SeedDB made a seeddb.bin.Are they supposed to make different file or the same file ?

Well, the "Update SeedDB" feature creates a fully functional seeddb.bin, which can then be used (without further processing) by NCCH padgen or the title decryptor. If the seeddb.bin already exists, additional seeds from the EmuNAND are duplicate checked and (if not a duplicate) appended to the end of the file. I do hope there are no problems with it, as I have only very limited capabilities of testing myself on my N3DS.

EDIT: If you should have the time, could you try different use cases? F.e. creating the seeddb.bin anew, updating an existing seeddb.bin with more seeds, trying to update with some seeds from the 00000000 file already in seeddb.bin. All of this should work without trouble.

EDIT2: And, by the way, did you test on O3DS and N3DS?

The "Seedsave Dump" feature just dumps the 00000000 file, which has to be processed by SEEDconv then. I might remove that feature later if "Update SeedDB" works reliably enough.

 

[key1340]

Well, the "Update SeedDB" feature creates a fully functional seeddb.bin, which can then be used (without further processing) by NCCH padgen or the title decryptor. If the seeddb.bin already exists, additional seeds from the EmuNAND are duplicate checked and (if not a duplicate) appended to the end of the file. I do hope there are no problems with it, as I have only very limited capabilities of testing myself on my N3DS.

EDIT: If you should have the time, could you try different use cases? F.e. creating the seeddb.bin anew, updating an existing seeddb.bin with more seeds, trying to update with some seeds from the 00000000 file already in seeddb.bin. All of this should work without trouble.

EDIT2: And, by the way, did you test on O3DS and N3DS?

The "Seedsave Dump" feature just dumps the 00000000 file, which has to be processed by SEEDconv then. I might remove that feature later if "Update SeedDB" works reliably enough.

I have used the Update SeedDB to make new + update + try to update when there is no new seeds and it all worked fine. I can only test the seed stuff on o3ds I don't have a hard mod on my n3ds.

 

[d0k3]

I have used the Update SeedDB to make new + update + try to update when there is no new seeds and it all worked fine. I can only test the seed stuff on o3ds I don't have a hard mod on my n3ds.

Okay, great! I guess that means the SeedDB updater is release ready. Testing on different systems (at least in that case) is only important because of different NAND sizes. By the way: Do you think the seedsave dumper should be kept then (if seeddb updater is superior)?

 

[key1340]

Okay, great! I guess that means the SeedDB updater is release ready. Testing on different systems (at least in that case) is only important because of different NAND sizes. By the way: Do you think the seedsave dumper should be kept then (if seeddb updater is superior)?

I can't see much use for the seedsave dumper unless some other app needs it.

 

[d0k3]

I can't see much use for the seedsave dumper unless some other app needs it.

Well the one app that would have a use for it is is the Seedinfo Generator Python script by @LITTOMA . This generates rxTools / 3DS Multi Tool compatible seedinfo.bin files. You don't need those if you already are a Decrypt9 user, though.

 

[d0k3]

@everyone:
I've been thinking about restructuring the menu in my Decrypt9 WIP version.

Including EmuNAND and DANGER_ZONE features, we now have 20 features in there (when I took up Decrypt9 development, there where four). If I were to enable the EmuNAND backup / restore / partition dump / partition injection features, there would be 28, and there is still some stuff planned.

As an overview, this is what is included now (directly from the source code)

MenuInfo menu[] =
{
    {
        "XORpad Options",
        {
            { "NCCH Padgen", &NcchPadgen, 0, 0 },
            { "SD Padgen", &SdPadgen, 0, 0 },
            { "CTRNAND Padgen", &CtrNandPadgen, 0, 0 },
            { "TWLNAND Padgen", &TwlNandPadgen, 0, 0 }
        }
    },
    {
        "NAND Options",
        {
            { "NAND Backup", &DumpNand, 0, 0 },
            { "All Partitions Dump", &DecryptAllNandPartitions, 0, 0 },
            { "TWLNAND Partition Dump", &DecryptTwlNandPartition, 0, 0 },
            { "CTRNAND Partition Dump", &DecryptCtrNandPartition, 0, 0 }
        }
    },
    {
        "Titles Options",
        {
            { "Titlekey Decrypt (file)", &DecryptTitlekeysFile, 0, 0 },
            { "Titlekey Decrypt (NAND)", &DecryptTitlekeysNand, 0, 0 },
            { "Ticket Dump", &DumpTicket, 0, 0 },
            { "Decrypt Titles", &DecryptTitles, 0, 0 }
        }
    },
    {
        "EmuNAND Options",
        {
            { "Titlekey Decrypt", &DecryptTitlekeysNand, 0, 1 },
            { "Ticket Dump", &DumpTicket, 0, 1 },
            { "Update SeedDB", &UpdateSeedDb, 0, 1 },
            { "Seedsave Dump", &DumpSeedsave, 0, 1 }
        }
    },
    #ifdef DANGER_ZONE
    {
        "!DANGER_ZONE!",
        {
            { "NAND Restore", &RestoreNand, 1, 0 },
            { "All Partitions Inject", &InjectAllNandPartitions, 1, 0 },
            { "TWLNAND Partition Inject", &InjectTwlNandPartition, 1, 0 },
            { "CTRNAND Partition Inject", &InjectCtrNandPartition, 1, 0 }
        }
    }
    #endif
};

In the current menu structure, 28 features would mean at least seven submenus - not all that great. Including more entries per submenu would be an option, but they should be grouped in a way that makes sense. Also, using a main menu to go to the submenus would be an option.

By the way, this is only for my WIP version, which needs a simple, flexible text based menu. @Shadowtrances version has a much more beautiful graphical menu, which also means more work to add more features.

So, any idea is welcome. Could you think of a different way to group the various features (with more entries per submenu)? Any other ideas on improving the menu?

 

[key1340]

@d0k3

I think the 20 features that are in there are enough for now.I don't see any need for the other 8.

As for menu design i don't mined the way it works now.

For other options you could have less menu's with more features per menu.Like all the dumping options on one page and all the decrypting options on another.

The only problem with that is new user's may get confused with too many options per page.

I like the idea of a main menu with XORpad Options,NAND Options,Titles Options and so on that goes to a submenu for that option.

 

[atkfromabove]

Okay, great! I guess that means the SeedDB updater is release ready. Testing on different systems (at least in that case) is only important because of different NAND sizes. By the way: Do you think the seedsave dumper should be kept then (if seeddb updater is superior)?

I can test on my n3ds but isn't the seed only after firmware 9.5? And n3ds emunand is stuck at 9.5 right? I have a dump of my 9.6 firmware or I can update to 10.1.0 and dump that then downgrade back.

 

[key1340]

I can test on my n3ds but isn't the seed only after firmware 9.5? And n3ds emunand is stuck at 9.5 right? I have a dump of my 9.6 firmware or I can update to 10.1.0 and dump that then downgrade back.

You would need a hard mod and update to firmware 10.1 then download a seed encrypted game. Then back up the firmware downgrade to 9.2. Then use emunandtool to inject the nand dump. Then use decrypt9 to dump the seeddb.

 

[d0k3]

@d0k3

I think the 20 features that are in there are enough for now.I don't see any need for the other 8.

As for menu design i don't mined the way it works now.

For other options you could have less menu's with more features per menu.Like all the dumping options on one page and all the decrypting options on another.

The only problem with that is new user's may get confused with too many options per page.

I like the idea of a main menu with XORpad Options,NAND Options,Titles Options and so on that goes to a submenu for that option.

You think I should leave the other eight out? I'm not sure yet. For example with these included, you could copy your SysNAND to your EmuNAND and vice versa, without even using a computer (sure, the total time needed woudl be bigger. And then theres the SudokuHax exploit, which needs TWLNAND injection (don't know if that's possible on EmuNAND, though). Maybe other use cases. Still thinking.

And yes, a main menu might in fact be a good idea. Or at least some faster way to get to a specific submenu. Maybe I'll implement up / down / left / right button navigation for the menus.

I can test on my n3ds but isn't the seed only after firmware 9.5? And n3ds emunand is stuck at 9.5 right? I have a dump of my 9.6 firmware or I can update to 10.1.0 and dump that then downgrade back.

You would need a hard mod and update to firmware 10.1 then download a seed encrypted game. Then back up the firmware downgrade to 9.2. Then use emunandtool to inject the nand dump. Then use decrypt9 to dump the seeddb.

Yeah, what @key1340 said. Too complicated. The seedDB updater is a at the present time only useful on O3DS, cause you need to have SysNAND on an exploitable FW and EmuNAND > 9.6. Plus, you have to have seed encrypted games installed in EmuNAND. I guess the users of that won't be too many for now, but others will profit from the seedDB updater, because it enables us to decrypt these seed crypto titles.

 

[Madridi]

@d0k3 .. My vote would be for the 28. Mainly because, why not?

Anything that would allow more features is welcome, especially those that would eliminate the need to use a computer.

Whatever you decide though

 

[Shadowtrance]

@d0k3 .. My vote would be for the 28. Mainly because, why not?

Anything that would allow more features is welcome, especially those that would eliminate the need to use a computer.

Whatever you decide though

Make my life harder why don't you. haha
Yep I'm gonna have fun updating my version... if anyone needs me I'll be over here ------------------------------------->>>>> glued to photoshop. haha

 

[key1340]

@d0k3

It's up to you what you do with the other 8 options.

I just give an example of some time difference.

Backup ctrnand emu partition 5-10 min back that up to PC 1-2 min then put back on sdcard 1-2 min then inject back to emunand 5-10 min. It will take at least 12 min.

Or back up with emunandtool 1 min decrypt with fat16tool 1-2 min the re encrypt 1-2 min inject back with emunand tool 1 min. Total time 5 min or less.

Plus I had to dump partitions 3 times to get a good dump.

 

[Madridi]

Make my life harder why don't you. haha
Yep I'm gonna have fun updating my version... if anyone needs me I'll be over here ------------------------------------->>>>> glued to photoshop. haha

Haha it's for the greater good

Plus I had to dump partitions 3 times to get a good dump.

What do you mean by this?

 

[key1340]

What do you mean by this?

When I was testing the emunand partition dumper I had to dump them 3 times to get a good dump of all of them.

One time it corrupt ctrnand and the other time it corrupt twln.

 

[d0k3]

When I was testing the emunand partition dumper I had to dump them 3 times to get a good dump of all of them.

One time it corrupt ctrnand and the other time it corrupt twln.

That's a very good reason not to do it, and I almost forgot that... Don't know what happens there. If it is random, no wonder CTRNAND and TWLN were affected, these are the two biggest ones. It may be different now, because I'm using an updated version of the sdmmc.c routines now (these are responsible for SD and NAND access).

@atkfromabove : I may have another idea how to speed up things, increasing the buffers. Will have an updated version later, I may want to enable (experimentally!) the EmuNAND backup / restore / dump / inject routines first.