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

  • Thread starter Thread starter d0k3
  • Start date Start date
  • Views Views 935,203
  • Replies Replies 4,476
  • Likes Likes 71
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.
I have a hardmod that I installed right when I got the N3DS. I have a 9.6 dump but would the 10.1 dump be more beneficial in anyway?

Edit: I just re-read your post and realized that you were telling me the amount of effort involved! That's a lot of work just to get a seed to dump from emunand. @d0k3 if you think it would be good to test out I would be willing to do so.

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.

Sounds great! I am just happy to help with any testing for the work you put into this!
 
Last edited by atkfromabove,
I have a hardmod that I installed right when I got the N3DS. I have a 9.6 dump but would the 10.1 dump be more beneficial in anyway?

Edit: I just re-read your post and realized that you were telling me the amount of effort involved! That's a lot of work just to get a seed to dump from emunand. @d0k3 if you think it would be good to test out I would be willing to do so.

Sounds great! I am just happy to help with any testing for the work you put into this!
On O3DS it is pretty simple to test ;). No, don't waste that much time with that. @key1340 already tested, and I reused known working SEEDconv code, so nothing much will go wrong with that. There's more important stuff to test now. I'll do an updated version later today.

The ncchinfo.bin containing new KeyY generated by rxTool's ncchinfo_gen.py is also work in Decrypt9.
Yeah, but rxTools ncchinfo_gen.py works differently, in that it uses the seedinfo.bin right in the Python script to generate the correct decryption params (ie. with rxTools you don't need the seedinfo.bin in the SDcard root, correct?). Decrypt9's ncchinfo_gen.py just puts an entry into the ncchinfo.bin that says: "Hey, Decrypt9, there's a seed for that, that's your problem now!". Both ways are legitimate ways to do it, but I personally don't like the fact that rxTools ncchinfo_gen.py needs an additional binary file (seedinfo.bin). Anyways, I think I'll just leave thee seedsave dumper in. It is useful now for your seedinfo_gen.py and seeddb_gen scripts, and it may be useful for other stuff in the future as well.

@everyone:
Would it make sense to be able to directly dump more files from the NAND / EmuNAND? I've been thinking about those:
  • movable.sed
  • SecureInfo_A
  • LocalFriendCodeSeed_B
  • rand_seed
Except for the movable.sed, I have no idea what these are useful for. So, any opinions.
 
Last edited by d0k3,
@everyone:
Would it make sense to be able to directly dump more files from the NAND / EmuNAND? I've been thinking about those:
  • movable.sed
  • SecureInfo_A
  • LocalFriendCodeSeed_B
  • rand_seed
Except for the movable.sed, I have no idea what these are useful for. So, any opinions.

It would be good to be able to dump + inject them.

SecureInfo_A is needed to change the region of your 3ds nand or emunand.

LocalFriendCodeSeed_B i think that has your friend list in it.But i think maybe the friend list is also in movable.sed.

rand_seed i don't know what that is used for.
 
It would be good to be able to dump + inject them.

SecureInfo_A is needed to change the region of your 3ds nand or emunand.

LocalFriendCodeSeed_B i think that has your friend list in it.But i think maybe the friend list is also in movable.sed.

rand_seed i don't know what that is used for.
Injection will only be possible for files that have a fixed, never changing size. I don't know if that is guaranteed. Even so it would be more dangerous than partition injection and NAND restore, as if my makeshift FAT16 routines (can't use FATFS for that) fail, the whole filesystem may be broken, and this may only get obvious after further use. For files below 32kB the danger will be small to nonexistent, though. Moving over your friend list and changing region is a pretty rare task, though, correct?

Also, the movable.sed - it is used in decrypting SD installed titles, but it is normally not actually needed if you decrypt titles installed via the same system. I think the movable.sed, could - in theory - be used to move SD installed stuff from one system to another, but I'm unsure.
 
Injection will only be possible for files that have a fixed, never changing size. I don't know if that is guaranteed. Even so it would be more dangerous than partition injection and NAND restore, as if my makeshift FAT16 routines (can't use FATFS for that) fail, the whole filesystem may be broken, and this may only get obvious after further use. For files below 32kB the danger will be small to nonexistent, though. Moving over your friend list and changing region is a pretty rare task, though, correct?

Also, the movable.sed - it is used in decrypting SD installed titles, but it is normally not actually needed if you decrypt titles installed via the same system. I think the movable.sed, could - in theory - be used to move SD installed stuff from one system to another, but I'm unsure.

I don't think many would move the friend list.

Changing the region of the emunand is used a fair bit.Lots of people bought Japanese n3ds and wont euro or usa emunands.Or if you wont to play out of region DLC you need to change the region of the emunand.

Both of those could be done with emunandtool and fat16tool.But i have seen an option to do it in rxtools.

EDIT

Of the four options.

I don't know what rand_seed is used for probably not needed.

I think LocalFriendCodeSeed_B is just a back up of the friend list.And i think the friend list is already in the movable.sed.

I don't think rand_seed or LocalFriendCodeSeed_B would need to be backed up.

Movable.sed can be used to transfer all your sd content from one 3ds to another.

Usefull if your 3ds broke or you got a new one.

SecureInfo_A is needed to change the region of your 3ds nand or emunand.

Usefull if you bought Japanese n3ds and wont euro or usa emunand.Or if you wont to play out of region DLC you need to change the region of the emunand.

I don't know if a lot of poeple would use the Movable.sed or SecureInfo_A dump + inject.You could always do it with fat16tool if you didn't put it in Decrypt9.
 
Last edited by key1340,
  • Like
Reactions: d0k3
I don't think many would move the friend list.

Changing the region of the emunand is used a fair bit.Lots of people bought Japanese n3ds and wont euro or usa emunands.Or if you wont to play out of region DLC you need to change the region of the emunand.

Both of those could be done with emunandtool and fat16tool.But i have seen an option to do it in rxtools.

EDIT

Of the four options.

I don't know what rand_seed is used for probably not needed.

I think LocalFriendCodeSeed_B is just a back up of the friend list.And i think the friend list is already in the movable.sed.

I don't think rand_seed or LocalFriendCodeSeed_B would need to be backed up.

Movable.sed can be used to transfer all your sd content from one 3ds to another.

Usefull if your 3ds broke or you got a new one.

SecureInfo_A is needed to change the region of your 3ds nand or emunand.

Usefull if you bought Japanese n3ds and wont euro or usa emunand.Or if you wont to play out of region DLC you need to change the region of the emunand.

I don't know if a lot of poeple would use the Movable.sed or SecureInfo_A dump + inject.You could always do it with fat16tool if you didn't put it in Decrypt9.
Okay, thank you! I will think about it. It's just that the current menu structure is already completely overloaded as it is now, and doing this (especially for EmuNAND & SysNAND) would basically force me to think of something better. Also, do you have an idea if the size of these files is fixed? I think (but don't know) that it is for SecureInfo_A & movable.sed, and both should be far smaller than 32kB.
 
Okay, thank you! I will think about it. It's just that the current menu structure is already completely overloaded as it is now, and doing this (especially for EmuNAND & SysNAND) would basically force me to think of something better. Also, do you have an idea if the size of these files is fixed? I think (but don't know) that it is for SecureInfo_A & movable.sed, and both should be far smaller than 32kB.

How Decrypt9 is now I don't any more options it does everything I need.

It does everything Decrypt9 + 3dsmultidecrypter can do and more. The only thing rxtools can do extra is the movable.sed + secureinfo_a stuff. And that can be done with fat16tool.
 
  • Like
Reactions: d0k3
How Decrypt9 is now I don't any more options it does everything I need.

It does everything Decrypt9 + 3dsmultidecrypter can do and more. The only thing rxtools can do extra is the movable.sed + secureinfo_a stuff. And that can be done with fat16tool.
And, injecting ticket.db - would that make sense? Just thinking aloud now. I just noticed for each file I add, we'd have four(!) (dump/NAND, inject/NAND, dump/(EmuNAND), inject/EmuNAND) new menu entries.
 
On O3DS it is pretty simple to test ;). No, don't waste that much time with that. @key1340 already tested, and I reused known working SEEDconv code, so nothing much will go wrong with that. There's more important stuff to test now. I'll do an updated version later today.


Yeah, but rxTools ncchinfo_gen.py works differently, in that it uses the seedinfo.bin right in the Python script to generate the correct decryption params (ie. with rxTools you don't need the seedinfo.bin in the SDcard root, correct?). Decrypt9's ncchinfo_gen.py just puts an entry into the ncchinfo.bin that says: "Hey, Decrypt9, there's a seed for that, that's your problem now!". Both ways are legitimate ways to do it, but I personally don't like the fact that rxTools ncchinfo_gen.py needs an additional binary file (seedinfo.bin). Anyways, I think I'll just leave thee seedsave dumper in. It is useful now for your seedinfo_gen.py and seeddb_gen scripts, and it may be useful for other stuff in the future as well.

@everyone:
Would it make sense to be able to directly dump more files from the NAND / EmuNAND? I've been thinking about those:
  • movable.sed
  • SecureInfo_A
  • LocalFriendCodeSeed_B
  • rand_seed
Except for the movable.sed, I have no idea what these are useful for. So, any opinions.
I think movable.sed would be a great option!
 
And, injecting ticket.db - would that make sense? Just thinking aloud now. I just noticed for each file I add, we'd have four(!) (dump/NAND, inject/NAND, dump/(EmuNAND), inject/EmuNAND) new menu entries.

Injecting ticket.db doesn't have a lot of uses.One would be if you bought something on the eshop on your emunand you could dump the ticket.db from emunand and inject the ticket.db to system nand and play the game from system nand.But if you dumped a bad ticket.db then injected it to system nand it would brick the 3ds.

The only way to get around having lots of menu's would be to have all the dumping options,all the decrypting options and all the injecting options under the three menu's.Then you would just have to add the new stuff under it's menu.But you would have like ten options per menu.

Also remember if you do go through all the work to add movable.sed + secureinfo_a injecting,most people wouldn't be able to even use the option with out building Decrypt9 from source and enabling danger zone.
 
Last edited by key1340,
Also remember if you do go through all the work to add movable.sed + secureinfo_a injecting,most people wouldn't be able to even use the option with out building Decrypt9 from source and enabling danger zone.
Or they could just wait for mine to be updated which doesn't have "danger zone", but other checks in place instead. :) But still a valid point.
 
I think movable.sed would be a great option!
Also remember if you do go through all the work to add movable.sed + secureinfo_a injecting,most people wouldn't be able to even use the option with out building Decrypt9 from source and enabling danger zone.
It's actually pretty simple to write injection functions for movable.sed, SecureInfo_A and others, especially for files below 32kB such as these two. Also, useful injection functions will make it to the main release in the future. There's a new unlock sequence for the dangerous stuff, that will make sure that it is absolutely impossible (even if you let your cat/dog/toddler handle Decrypt9) to accidentially trigger it. You can try it, see below.

Injecting ticket.db doesn't have a lot of uses.One would be if you bought something on the eshop on your emunand you could dump the ticket.db from emunand and inject the ticket.db to system nand and play the game from system nand.But if you dumped a bad ticket.db then injected it to system nand it would brick the 3ds.
Good point. The only case in which that would be useful is if you want to keep one NAND updated with the purchases from another, and that should actually be pretty rare. You could also do that via CTRNAND backup and injection, of course. Or via EmuNAND tool. I think I'll leave that out.

The only way to get around having lots of menu's would be to have all the dumping options,all the decrypting options and all the injecting options under the three menu's.Then you would just have to add the new stuff under it's menu.But you would have like ten options per menu.
That would be an option, but ten entries per menu would be too much. I thought about 6 or 8 at maximum.


I've attached a new testing version to this post. This one has everything enabled (SysNAND writing, EmuNAND reading, EmuNAND writing, too). To be honest, I'm not sure if the additional EmuNAND stuff will be kept. It also uses a bigger buffer size and might be faster. EmuNAND dumping might be fixed by the newer sdmmc.c routines. Therefore, for this one, two things are interesting:
  • Is it faster now due to the bigger buffer size?
  • Are there still errors when backing up the EmuNAND or dumping partitions from it? Meaning, is each dump valid (can be found out by comparing with earlier dumps)?
  • Bonus: Does EmuNAND restore and injection work properly?
If you want to test the new unlock sequence for dangerous stuff, it is also enabled for the EmuNAND Writing functions. Have backups ready, just in case something happens.
 

Attachments

Last edited by d0k3,
Loving the progress on here. Still wishing that it worked with Ninjhax 2.X with firmwares 9.3-10.X. Is there really no way to make it work without Brahma?
Nope not really (sadly). It runs on arm9 which is one reason you can't return to the homebrew menu when exiting Decrypt9. And Brahma gives us that arm9 access we need that ninjhax doesn't by itself.
 
Sorry for noob question but will this homebrew work on a 9.9 3ds with ninjhax 2.1? It will be cool to be able to decrypt game carts and dump my nand on it. I think not without arm9 kernel access, but will reading it at least work?

EDIT SORRY, i just read it wont without brahma, but will nand reading work, does ninjhax 2.1 have access to arm9 at all or just arm11?
 
Last edited by ironmaster49,
Sorry for noob question but will this homebrew work on a 9.9 3ds with ninjhax 2.1? It will be cool to be able to decrypt game carts and dump my nand on it. I think not without arm9 kernel access, but will reading it at least work?
EDIT SORRY, i just read it wont without brahma, but will nand reading work, does ninjhax 2.1 have access to arm9 at all or just arm11?
Decrypt9 (or any homebrew that uses brahma/needs arm9) won't even boot on ninjhax 2 let alone 9.9. Decrypt9 just exits back to homebrew menu and trying to load a payload through normal brahma menu fails the arm11 exploit (just tried it on my 9.9 n3ds :) )
Only way you're getting a nand backup on 9.9 is installing a hardmod and dumping it that way.
 
Decrypt9 (or any homebrew that uses brahma/needs arm9) won't even boot on ninjhax 2 let alone 9.9. Decrypt9 just exits back to homebrew menu and trying to load a payload through normal brahma menu fails the arm11 exploit (just tried it on my 9.9 n3ds :) )
Only way you're getting a nand backup on 9.9 is installing a hardmod and dumping it that way.
So there's also no way to dump NAND using Ninjhax 2.X/Ironhax/Tubehax...
 

Site & Scene News

Popular threads in this forum