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

[ThisIsDaAccount]

@d0k3 If I wanted to prepare myself for the sudden failure of my 3DS, what files would I need to dump with Decrypt9 to make sure I can decrypt my SD card contents and re-encrypt it for a new 3DS? I see SD Padgen (SDinfo.bin) and (sysNAND Dir) but am I understanding correctly that this would make a separate XORpad for each and every single thing on the SD card? If my goal is to take SD files and decrypt them using a new console to then re-encrypt them so that the new console can see them, what would I need to do?

If you want to prepare yourself for sudden failure, you could dump a ctransfer and make a copy of the Nintendo 3DS folder on your SD card. That should be enough to transfer all your content.

 

[DocKlokMan]

If you want to prepare yourself for sudden failure, you could dump a ctransfer and make a copy of the Nintendo 3DS folder on your SD card. That should be enough to transfer all your content.

Really? My understanding from when I CTRNAND transferred down to 2.1 was that importing a CTRNAND transfer still kept the console's movable.sed and other DB files that you were importing it on. This is why I didn't lose any of my already downloaded eShop games. Would transferring a CTRNAND from a different console keep that consoles movable.sed and other files required to read the SD card's contents?

 

[d0k3]

Oh well, where do I start...

Hey guys I have two gba vc games so how to chose witch save I want to dump? Because it dumps only the save from the first game in line.
Ok I've figure it out it's like with "Agbsave9" you need to save the game you want to dump the save from first, push Home lunch Decrypt9WIP and dump the gba vc save (minus python injecting etc). It saves time, but I hope in the future you can choose the saves you want to dump, bye.

You can't choose which save to dump. AGBSAVE (that's the place where GBA save is stored) is a partition in NAND memory, and it always contains only the most recent GBA save.

Hey d0k3 ich hab ein old 3ds xl mit der FW 3.1.0 6E man sagte mir man könnte Decrypt 9 darauf Porten gibt es dafür ein tutorial ?

Any how to port Decrypt 9 to 3.1.0 6E , i can start the exploit but then it crashes on the browser

English is enough - don't write in german here. There is certain stuff in D9 that may not work on these early FWs. Depending on what you want to do, I'd try with GodMode9, which might have better compatibility.

Do you think you can add to your file dumper the ability to dump nand/data/00000000000000000000000000000000/sysdata/00010017/00000000/config needed for citra? The rest of the files can be obtained with 3dsutils. but the config file seems to be a pain in the butt to get.

That's already in there and has been for ages. It's called the configsave.bin. You may need to rename that file for Citra.

I realize it's very unlikely, but any chance of a build with sounds? Like a sound after loads, clicks navigating through the menu/selecting filenames, a sound after a success/failure.

I don't think anyone's figured out playing sound without the OS running (ie from a9lh).

Correct - no sound in ARM9.

@d0k3 If I wanted to prepare myself for the sudden failure of my 3DS, what files would I need to dump with Decrypt9 to make sure I can decrypt my SD card contents and re-encrypt it for a new 3DS? I see SD Padgen (SDinfo.bin) and (sysNAND Dir) but am I understanding correctly that this would make a separate XORpad for each and every single thing on the SD card? If my goal is to take SD files and decrypt them using a new console to then re-encrypt them so that the new console can see them, what would I need to do?

There are multiple ways of doing this. The absolute minimum requirement to save this data post console death is to have the movable.sed from the correct NAND dumped. I'd suggest you better have a complete NAND backup + the CTRNAND xorpad. It may be an even wiser choice to create CIAs from the stuff you want to keep at an earlier point, though.

Also, keep in mind, just reencrypting that stuff for a new console is not enough. You'd need the tickets, and tickets from the eshop will be unique (ie. not working on others) to the console they were created on. So, tl;dr, I'd really suggest you go the CIA route. You can create the CIAs on PC, even post console death, cause the movable.sed is enough to get that stuff decrypted (via the SD decryptor). As for saves, I am unsure. JKSM should be the answer. It is always a wiser choice to do backups early, though.

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

If you want to prepare yourself for sudden failure, you could dump a ctransfer and make a copy of the Nintendo 3DS folder on your SD card. That should be enough to transfer all your content.

That was a real good answer, one that I even forgot about .

Really? My understanding from when I CTRNAND transferred down to 2.1 was that importing a CTRNAND transfer still kept the console's movable.sed and other DB files that you were importing it on. This is why I didn't lose any of my already downloaded eShop games. Would transferring a CTRNAND from a different console keep that consoles movable.sed and other files required to read the SD card's contents?

CTRNAND transfer, then inject back the movable.sed and the ticket.db (from the old console) should work. You need to try though and keep backups.

 

[KazoWAR]

That's already in there and has been for ages. It's called the configsave.bin. You may need to rename that file for Citra.

Oh ok, I didn't know. thanks for the awesome tool.

*edit*
That file doesn't seem to be working. =/

 

[d0k3]

Oh ok, I didn't know. thanks for the awesome tool.

*edit*
That file doesn't seem to be working. =/

It is the correct one. Just to be save, tyr dumping it with GodMode9, too.

 

[KazoWAR]

It is the correct one. Just to be save, tyr dumping it with GodMode9, too.

after looking at the file it looks like the correct file, but with extra stuff. i think citra only uses a portion of the file(dumped file was 256k and the one I have with from the chinese citra builds is only 32k, both files contrains thinkgs like locations settings and usernames bu in different locations.) I am trying to find the offset citra uses exactly.
*EDIT*
OK I think I understand, this is dumping the complete RAW file, but citra expects the file contained in it.

 

[DocKlokMan]

There are multiple ways of doing this. The absolute minimum requirement to save this data post console death is to have the movable.sed from the correct NAND dumped. I'd suggest you better have a complete NAND backup + the CTRNAND xorpad. It may be an even wiser choice to create CIAs from the stuff you want to keep at an earlier point, though.

Also, keep in mind, just reencrypting that stuff for a new console is not enough. You'd need the tickets, and tickets from the eshop will be unique (ie. not working on others) to the console they were created on. So, tl;dr, I'd really suggest you go the CIA route. You can create the CIAs on PC, even post console death, cause the movable.sed is enough to get that stuff decrypted (via the SD decryptor). As for saves, I am unsure. JKSM should be the answer. It is always a wiser choice to do backups early, though.

CTRNAND transfer, then inject back the movable.sed and the ticket.db (from the old console) should work. You need to try though and keep backups.

Thank you very much for the detailed answer! Is title.db important at all when trying the CTRNAND transfer method? Or Friend or config save? If I understand this, the CTRNAND will bring over the old NAND but leave out some files. I replace these files such as movable.sed and ticket.db with copies that belonged to the old NAND. After doing that do I still need to re-install tickets or anything? I may do a backup and try this out by moving an o3DS CTRNAND to my n3DS and see how it all works just so I'm prepared.

EDIT: Okay, so importing the CTRNAND transfer image and then re-importing the ticket.tb and movable.sed resulted in a black screen, non-bootable NAND. Working out the right combo of files that allow it to boot and read SD contents.

EDIT2: Scratch that, the CTRNAND transfer doesn't work period. Using Auto CTRNAND Transfer to import a dumped transferable CTRNAND from an o3DS to my n3DS results in a black screen boot without modifying anything else further. Guess I need to figure that out first.

 

[Tigrokai]

I'm actually trying to do something similar to AnalogMan. I have two n3DS's, both with a9lh installed. I want to completely clone 3DS 1 and the contents of the SD card to 3DS 2, so that they're essentially the same 3DS software-wise. I was unable to find much information on doing something like that, but there is some stuff in this thread. If I did a CTRNAND transfer from 3DS 1 to 3DS 2, then inject the movable.sed and ticket.db from 3DS 1 into 3DS 2, and then copy all of the SD card contents (without decrypting/re-encrypting) would that work out how I want it to? I know there's also some sort of thing with the FAT16 tool, but I feel like there's definitely easier methods with some of the stuff we have now. What would you recommend, @d0k3?

@AnalogMan, were you able to figure this out?

 

[d0k3]

Thank you very much for the detailed answer! Is title.db important at all when trying the CTRNAND transfer method? Or Friend or config save? If I understand this, the CTRNAND will bring over the old NAND but leave out some files. I replace these files such as movable.sed and ticket.db with copies that belonged to the old NAND. After doing that do I still need to re-install tickets or anything? I may do a backup and try this out by moving an o3DS CTRNAND to my n3DS and see how it all works just so I'm prepared.

EDIT: Okay, so importing the CTRNAND transfer image and then re-importing the ticket.tb and movable.sed resulted in a black screen, non-bootable NAND. Working out the right combo of files that allow it to boot and read SD contents.

EDIT2: Scratch that, the CTRNAND transfer doesn't work period. Using Auto CTRNAND Transfer to import a dumped transferable CTRNAND from an o3DS to my n3DS results in a black screen boot without modifying anything else further. Guess I need to figure that out first.

Okay, I missed that bit... Transfering from O3DS to N3DS makes things more complicated. I suggest you try just injecting the O3DS movable.sed, nothing else, into the N3DS. You may also need to manually transfer tickets, which is a pita (ticket dumper in D9, ticket installer in FBI. Also use the SD card from the O3DS, or copy over the stuff from /Nintendo 3DS/.

I'm actually trying to do something similar to AnalogMan. I have two n3DS's, both with a9lh installed. I want to completely clone 3DS 1 and the contents of the SD card to 3DS 2, so that they're essentially the same 3DS software-wise. I was unable to find much information on doing something like that, but there is some stuff in this thread. If I did a CTRNAND transfer from 3DS 1 to 3DS 2, then inject the movable.sed and ticket.db from 3DS 1 into 3DS 2, and then copy all of the SD card contents (without decrypting/re-encrypting) would that work out how I want it to? I know there's also some sort of thing with the FAT16 tool, but I feel like there's definitely easier methods with some of the stuff we have now. What would you recommend, @d0k3?

@AnalogMan, were you able to figure this out?

Try with the CTRNAND transfer. You actually only need to move over the movable.sed manually (from 3DS 1 to 3DS 2). Tell me if it works.

 

[DocKlokMan]

Okay, I missed that bit... Transfering from O3DS to N3DS makes things more complicated. I suggest you try just injecting the O3DS movable.sed, nothing else, into the N3DS. You may also need to manually transfer tickets, which is a pita (ticket dumper in D9, ticket installer in FBI. Also use the SD card from the O3DS, or copy over the stuff from /Nintendo 3DS/.

No need to apologize, you missed nothing. I never mentioned going from o3DS to n3DS because that was just for the test. I figured if we could CTRNAND Transfer 2.1.0 that it wouldn't be an issue but now I realize that newer firmwares may not work that well. So I have devised a new test. I'll backup my n3DS NAND, movable.sed, ticket.db and title.db, friendsave and other important files, then TinyFormat my n3DS. Then I'll see if I can get it reading my SD card via CTRNAND Transfer and movable.sed import.

EDIT: Alright, experiment over. I managed to restore my system to practically the same as it had been by restoring the following things:

1. CTRNAND Transfer
2. movable.sed
3. seedsave.bin
4. LocalFriendCodeSeed_B
5. friendsave.bin

My games all appeared on menu and opened, my theme loaded, my friend code, and friend list was intact. The only things that did not restore were my notifications, icon layout (though stored layouts did so getting my icons back to place was easy), Mii's and Mii Plaza Mii's.

I didn't care about the notifications or my icon layout, but the loss of Mii's and Mii Plaza meetings did cause concern, though I believe a save backup from JK's Save Manager will resolve that.

So my backup routine is to dump movable.sed (only needs to be done once), make a CTRNAND Transfer image, dump seedsave.bin, LocalFriendCodeSeed_B (maybe this only needs to be dumped once?), friendsave.bin, and a decrypted save for Mii Plaza and Mii Maker.

 

[Vaamo]

Is it possible to do a batch SD -> CXI job for the entire title folder but start from a specific folder within that.

I'd already done half before my SD card filled up.

 

[Tigrokai]

I finally had time so I attempted to try what I wanted to do. CTRNAND transfer and movable.sed dump from 3DS 1 then injected into 3DS 2 worked just fine, only thing that I noticed didn't transfer was the layout, which is what the other person had mentioned. I don't use the streetpass games ever so I'm unsure if that transferred, but as far as I can see, everything worked just fine. Thanks!

 

[d0k3]

No need to apologize, you missed nothing. I never mentioned going from o3DS to n3DS because that was just for the test. I figured if we could CTRNAND Transfer 2.1.0 that it wouldn't be an issue but now I realize that newer firmwares may not work that well. So I have devised a new test. I'll backup my n3DS NAND, movable.sed, ticket.db and title.db, friendsave and other important files, then TinyFormat my n3DS. Then I'll see if I can get it reading my SD card via CTRNAND Transfer and movable.sed import.

EDIT: Alright, experiment over. I managed to restore my system to practically the same as it had been by restoring the following things:

1. CTRNAND Transfer
2. movable.sed
3. seedsave.bin
4. LocalFriendCodeSeed_B
5. friendsave.bin

My games all appeared on menu and opened, my theme loaded, my friend code, and friend list was intact. The only things that did not restore were my notifications, icon layout (though stored layouts did so getting my icons back to place was easy), Mii's and Mii Plaza Mii's.

I didn't care about the notifications or my icon layout, but the loss of Mii's and Mii Plaza meetings did cause concern, though I believe a save backup from JK's Save Manager will resolve that.

So my backup routine is to dump movable.sed (only needs to be done once), make a CTRNAND Transfer image, dump seedsave.bin, LocalFriendCodeSeed_B (maybe this only needs to be dumped once?), friendsave.bin, and a decrypted save for Mii Plaza and Mii Maker.

Nice! I have no idea what happened with Mii Plaza there, but it's good to know it worked so far. Maybe I'll refine the CTRNAND transfer stuff a bit to allow it to be used more easily for actual system transfers. Still needs more experimentation, though. Let me know once you tried taking over those files from your O3DS to you N3DS (as described in my last post).

Is it possible to do a batch SD -> CXI job for the entire title folder but start from a specific folder within that.

I'd already done half before my SD card filled up.

Oh well. From the D9 readme:

There are some features (NAND backup and restore, f.e.), that require the user to choose a file or a directory. In these cases, use the arrow keys (that includes LFET/RIGHT) to select and A / B to confirm and cancel.

Question answered?

I finally had time so I attempted to try what I wanted to do. CTRNAND transfer and movable.sed dump from 3DS 1 then injected into 3DS 2 worked just fine, only thing that I noticed didn't transfer was the layout, which is what the other person had mentioned. I don't use the streetpass games ever so I'm unsure if that transferred, but as far as I can see, everything worked just fine. Thanks!

Thank you, too! Normally, everything should work as expected. If anything comes up in daily usage of the transferred console (3DS 2), let me know about that, too.

 

[Vaamo]

Oh well. From the D9 readme:

Question answered?

That's what I'd done initially but I ended up only getting half way before my SD card was filled. I was wondering if it were possible to start the batch job from a specific folder within the overall folder.

It doesn't look like it's possible. So I'll just do each sub folder individually. Thanks anyway.

 

[d0k3]

That's what I'd done initially but I ended up only getting half way before my SD card was filled. I was wondering if it were possible to start the batch job from a specific folder within the overall folder.

It doesn't look like it's possible. So I'll just do each sub folder individually. Thanks anyway.

Oh, okay, got it now. Well, no, that is not possible. You will have to do it individually.

 

[Zan']

Since A9LH & Luma3DS allow to run payloads from CTRNand it might be nice to have Decrypt9 / GodMode9 work without the need to initialize the SD Card.
EmuNAND9 doesn't do this and starts even thought that really does need the SD.

At least GodMode9 should be able to work without that.

 

[d0k3]

Since A9LH & Luma3DS allow to run payloads from CTRNand it might be nice to have Decrypt9 / GodMode9 work without the need to initialize the SD Card.
EmuNAND9 doesn't do this and starts even thought that really does need the SD.

At least GodMode9 should be able to work without that.

For Decrypt9, making it work without the SD card makes no sense at all. Where should the output / input files go to then? EmuNAND9 is designed to work with borked SD cards (cards that can't be initialized properly), so that's that.

For GodMode9: thinking about it. I have my doubts, though, as it will be a lot of work and of limited use. GM9 is a file manager, designed to move files around, and if you only have SysNAND / virtual stuff / a zero initialized RAMdrive, what stuff do you want to move around? I'm open for suggestions, though. Give me a usecase or two, and I will consider it further. But, please do so in the GM9 thread!

 

[Zan']

For Decrypt9, making it work without the SD card makes no sense at all. Where should the output / input files go to then? EmuNAND9 is designed to work with borked SD cards (cards that can't be initialized properly), so that's that.

For GodMode9: thinking about it. I have my doubts, though, as it will be a lot of work and of limited use. GM9 is a file manager, designed to move files around, and if you only have SysNAND / virtual stuff / a zero initialized RAMdrive, what stuff do you want to move around? I'm open for suggestions, though. Give me a usecase or two, and I will consider it further. But, please do so in the GM9 thread!

Yeah I figured it wouldn't make a lot of sense for Decrypt9 without having a way to store output files.
For GodMode9 it would be nice though.

 

[d0k3]

New Decrypt9WIP release, check it out here. This is new:

• Added a config file dumper (this is required for the Citra emulator)
• CTRNAND transfer now working on devkits (enables A9LH installation)
• Overall better support for devkit crypto keys
• Cancellation of various operations is now possible (just hold B)
• Enabled continuous scroll (hold arrow buttons)
• Fixed shallow decrypted CIAs not being installable
• SD -> CIA converter now also wipes the (possibly identifying) ticket id
• Improved error handling in SD -> CIA / SD -> CXI features

So, one new feature, better support for devkits, and other than that improvements to existing stuff. As always, have fun testing and be sure to report bugs!

 

[d0k3]

No comments to the last release? This can only be a good sign . Here's a new release for you, concentrating on improvements to the popular CIA builder features. This is new:

• Reorganized menu, take note that several features are renamed now (basically all CIA building features)
• New features that allow building of fully decrypted CIAs from SD content
• Improved SD content selector, now sorted by title ID
• Faster CIA builder in certain cases
• SEEDs for NCCH crypto can now be extracted on-the-fly from NAND
• Updated readme file (yeah, I forgot last time)

If you wrote a tutorial on this earlier (or using one), keep the reorganized menu in mind.

Btw, for statistics: This is the 66th release of Decrypt9WIP. It now contains 29 submenus and 159 features. When I started working on the project roughly one and a half years ago, it had four features and no menu system at all. This has gone a long way .