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

[d0k3]

First some context:
I made a romhack of Pokemon Omega Ruby and before installing the cia I figured I would test it in Citra since installing the cia takes quite a lot of time, even on new3DS.

Reading through citra's guide I noticed the majority of getting the .cci from a .3ds is nigh similar to getting a .cia with Simple 3DS to CIA converter, the only difference being that Archshift's xorer also requires a romfs xorpad along with the exefs and exheader.

For the world of me I cannot figure out how I am to get the romfs xorpad. The way it is explained on Citra's website it should be right there along with the exefs and exheader xorpads when doing a NCCHPadgen with the NCCHInfo generated by ncchinfo_gen.py.

TLDR: Want to test a freshly (with 3ds builder) made .3ds in Citra before converting to and installing cia on 3DS but lacking the romfs xorpad to decrypt it.

So for my question:
Is the romfs xorpad generating a feature taken out of Decrypt9WIP and something I would have to use Archshift's Decrypt9 for it or am I missing something in the process?

---

p.s. a9lh new3ds 11.0 updated sysnand

p.p.s. I know Citra's website says it is not yet compatible with Pokemon but last I heard it is with the hardware render but even if it's not consider that irrelevant to the question and consider OR as just a "context example"

Nothing is taken out. If you really want to use the old, clunky, legacy XORpad way of decrypting roms, use ncchinfo_gen.py on PC to generate the ncchinfo.bin, then generate the XORpads from that. Or, you could just put the rom into /Decrypt9/ (or, /D9Game/, if that folder exists), and let the Decrypt9WIP NCCH decryptor handle the full decryption process for you.

 

[Favna]

Nothing is taken out. If you really want to use the old, clunky, legacy XORpad way of decrypting roms, use ncchinfo_gen.py on PC to generate the ncchinfo.bin, then generate the XORpads from that. Or, you could just put the rom into /Decrypt9/ (or, /D9Game/, if that folder exists), and let the Decrypt9WIP NCCH decryptor handle the full decryption process for you.

Ah noted. Didn't know I could just put the 3ds there and take out the ncchinfo part

 

[Indolan]

Hi, I'm trying to use Decrypt9 to rescue my saves after following this guide to the letter and installing arm9loaderhax. The link I inserted leads to the page describing the first time you backup your SysNAND, before any formatting occurs... which I, of course, did. After the whole process, my SysNAND is based on that original backup (with some modifications mandated by the guide, but), and I specifically "restored EmuNAND" using that exact original file, knowing that the right NAND is essential for accessing encrypted title/save data.

Something possibly strange is going on, though, and I don't understand how to overcome it.

Because the guide took me through a few formats, there were two extra /Nintendo 3DS/<id0>/ folders with just basic system settings from downgrades and such. That's normal, and I deleted them without a problem.

What's weird is that after the arm9loaderhax install, and after returning to normalcy using my original sysnand.bin backup, my system is installing to/recognizing the same /Nintendo 3DS/<id0>/ folder... but not the same /<id1>/ folder! It created a new one inside <id0>; now, there are two. If I install anything, it goes to the new one. When I used Decrypt9's recommended SD Decryptor (SysNAND or EmuNAND dir) function, it output decrypted files from the new <id1> folder to D9Game.

Here's what I tried after that initial discovery: I copied my original <id1> folder's contents to D9Game and used the less-recommended SD Decryptor/Encryptor function, figuring this would force Decrypt9 to acknowledge and decrypt its contents.

Once they were decrypted, I wasn't entirely sure what to do with them; SaveDataFiler didn't see them in D9Game, of course, so I tried copying a certain title's .sav and overwriting the same title's .sav in the new, in-use <id1> folder. SDF said it was broken, and so did the game ("Save data corruption detected, deleting save data").

So I figured I would run the SD Decryptor/Encryptor function again, with the vague thought that it would encrypt the old <id1> contents to be recognizeable by my current system. It's running right now. I plan to try the overwriting method again as soon as the encryption is done, but with 25 GB to process each time, a quick testing cycle is impossible. I'd like to know if I'm headed in the right direction, and if not, what direction that would be.

This is not a bug report; it's purely a selfish help request for my use case, but going through Decrypt9's readme, various internet-wide searches and thread/forum/answer board searches for the word "save" yielded no applicable answers, so I understand if the community and developers feel this is inappropriate, but appreciate any help you're willing to provide.

 

[d0k3]

Hi, I'm trying to use Decrypt9 to rescue my saves after following this guide to the letter and installing arm9loaderhax. The link I inserted leads to the page describing the first time you backup your SysNAND, before any formatting occurs... which I, of course, did. After the whole process, my SysNAND is based on that original backup (with some modifications mandated by the guide, but), and I specifically "restored EmuNAND" using that exact original file, knowing that the right NAND is essential for accessing encrypted title/save data.

Something possibly strange is going on, though, and I don't understand how to overcome it.

Because the guide took me through a few formats, there were two extra /Nintendo 3DS/<id0>/ folders with just basic system settings from downgrades and such. That's normal, and I deleted them without a problem.

What's weird is that after the arm9loaderhax install, and after returning to normalcy using my original sysnand.bin backup, my system is installing to/recognizing the same /Nintendo 3DS/<id0>/ folder... but not the same /<id1>/ folder! It created a new one inside <id0>; now, there are two. If I install anything, it goes to the new one. When I used Decrypt9's recommended SD Decryptor (SysNAND or EmuNAND dir) function, it output decrypted files from the new <id1> folder to D9Game.

Here's what I tried after that initial discovery: I copied my original <id1> folder's contents to D9Game and used the less-recommended SD Decryptor/Encryptor function, figuring this would force Decrypt9 to acknowledge and decrypt its contents.

Once they were decrypted, I wasn't entirely sure what to do with them; SaveDataFiler didn't see them in D9Game, of course, so I tried copying a certain title's .sav and overwriting the same title's .sav in the new, in-use <id1> folder. SDF said it was broken, and so did the game ("Save data corruption detected, deleting save data").

So I figured I would run the SD Decryptor/Encryptor function again, with the vague thought that it would encrypt the old <id1> contents to be recognizeable by my current system. It's running right now. I plan to try the overwriting method again as soon as the encryption is done, but with 25 GB to process each time, a quick testing cycle is impossible. I'd like to know if I'm headed in the right direction, and if not, what direction that would be.

This is not a bug report; it's purely a selfish help request for my use case, but going through Decrypt9's readme, various internet-wide searches and thread/forum/answer board searches for the word "save" yielded no applicable answers, so I understand if the community and developers feel this is inappropriate, but appreciate any help you're willing to provide.

I'd say, what you should have done, is deleting the new <id1> folder, or copy everything from the old one to the new one. This is based on the assumptions that nothing important is in the new one. You should have backups ready, of course.

 

[Indolan]

Dear lord, it worked perfectly. Software, saves, "saves to SD card," DLC: it's all back and functional as far as I can see. What a relief!

The lesson seems to be that, although <id0> folders are encrypted separately and not interchangeable simply through copy/paste, their inner <id1> folders (when they appear?) follow different rules. Hopefully, someone else who needs it can find your simple and effective solution someday.

I already had nothing but respect for the people who make this technical wizardry possible; this has certainly not hurt my opinion. Thank you very much!

 

[d0k3]

Dear lord, it worked perfectly. Software, saves, "saves to SD card," DLC: it's all back and functional as far as I can see. What a relief!

The lesson seems to be that, although <id0> folders are encrypted separately and not interchangeable simply through copy/paste, their inner <id1> folders (when they appear?) follow different rules. Hopefully, someone else who needs it can find your simple and effective solution someday.

I already had nothing but respect for the people who make this technical wizardry possible; this has certainly not hurt my opinion. Thank you very much!

Good to read this! A little bit explanation: the <id0> is generated from a file on your NAND (this file changes after a NAND format, thus <id0> changes), the <id1> is generated from your SD card CID (customer identifying data). While <id1> is not used in the crypto of these files at all, the file the <id0> is generated from (the movable.sed) is. The reason behind <id1> folders being interchangeable is that Nintendo wants you to be able to migrate to other / bigger SD cards.

By the way, is there any change that since you originally set up that SysNAND (where that backup is from) you migrated SD cards?

 

[Indolan]

Aha! I always love to read tidbits I can understand, thanks!

I changed SD cards for a larger one right after installing arm9loaderhax two days ago, but the old, smaller SD card also had the extra <id1> folder, so that's probably not what you meant.

Other than that, SOMETHING happened when I performed a system transfer from an O3DS XL as soon as I took the N3DS out of its box. I'm not 100% sure of the details anymore, but I think I gave the N3DS a bigger SD card that came from my O3DS. It was probably 1) System transfer: 32 GB O3DS -> 4 GB N3DS [since the 32 GB card was very underused at the time] 2) Folder copy/paste to give the 32 GB card to N3DS 3) Format 4 GB card, put it back in O3DS and go trade it for store credit. Basically, yeah! IIRC.

So you're saying that after being mistreated back and forth, the SysNAND simply remembered an old CID, or forgot the current CID and created a new/old folder because of that? Some kind of trauma-induced amnesia?

 

[Thunder Kai]

How I build from source?

 

[Khangaroo]

How I build from source?

I never built anything before, but I think build instructions are in the README.md on the repo.

 

[d0k3]

Aha! I always love to read tidbits I can understand, thanks!

I changed SD cards for a larger one right after installing arm9loaderhax two days ago, but the old, smaller SD card also had the extra <id1> folder, so that's probably not what you meant.

Other than that, SOMETHING happened when I performed a system transfer from an O3DS XL as soon as I took the N3DS out of its box. I'm not 100% sure of the details anymore, but I think I gave the N3DS a bigger SD card that came from my O3DS. It was probably 1) System transfer: 32 GB O3DS -> 4 GB N3DS [since the 32 GB card was very underused at the time] 2) Folder copy/paste to give the 32 GB card to N3DS 3) Format 4 GB card, put it back in O3DS and go trade it for store credit. Basically, yeah! IIRC.

So you're saying that after being mistreated back and forth, the SysNAND simply remembered an old CID, or forgot the current CID and created a new/old folder because of that? Some kind of trauma-induced amnesia?

Well, if an <id1> is already in folder, the 3DS OS takes that normally, even if it mismatches the current NAND CID. That's how a SD migrate should work normally. <id0> is a different story, but that can only change (1) if the SD card is put into a different console or (2) if you format the NAND (although formatting is a misleading term here, it's more like a reset).

How I build from source?

Instructions in readme (also do the basic stuff, like installing devkitArm), or just take the most recent nightly (link in my sig).

 

[Indolan]

Well, if an <id1> is already in folder, the 3DS OS takes that normally, even if it mismatches the current NAND CID. That's how a SD migrate should work normally. <id0> is a different story, but that can only change (1) if the SD card is put into a different console or (2) if you format the NAND (although formatting is a misleading term here, it's more like a reset).

In this weird case, it never lost access to the <id1> throughout the a9loader installation process but decided to create a new one anyway. Science!

 

[Thunder Kai]

how i do this?

 

[Conn0r]

View attachment 49807 how i do this?

If you have Windows, install Devkitarm and get Git.
Shift-Right click in a folder and click "open command window here"
Type 'git clone --recursive https://github.com/d0k3/Decrypt9WIP.git' (without quotes lol)
Go into /Decrypt9WIP folder and Shift-Right click and open the command window.
Type 'Make' into the command window and hit enter.

When you're done, tell all your friends you're an official hacker! You're in the Matrix! Epic HAX

 

[Thunder Kai]

If you have Windows, install Devkitarm and get Git.
Shift-Right click in a folder and click "open command window here"
Type 'git clone --recursive https://github.com/d0k3/Decrypt9WIP.git' (without quotes lol)
Go into /Decrypt9WIP folder and Shift-Right click and open the command window.
Type 'Make' into the command window and hit enter.

When you're done, tell all your friends you're an official hacker! You're in the Matrix! Epic HAX

thank you ^^ it worked!

 

[RocketRobz]

Is there a way to get an exefs_7x (only got exefs_norm) xorpad for use with xorer?

 

[d0k3]

Is there a way to get an exefs_7x (only got exefs_norm) xorpad for use with xorer?

Yes, just use the included Python scripts to generate the ncchinfo.bin (instead of any other solutions).

 

[RocketRobz]

Yes, just use the included Python scripts to generate the ncchinfo.bin (instead of any other solutions).

Using ncchinfo_gen didn't work, even if the ROM i'm using (Girls Mode 2 - Tokimeki Up) is a 7.x game. I didn't get a exefs_7x xorpad. Is there a file missing? I'm only getting a black screen on Citra. The US version works, though.

 

[d0k3]

Using ncchinfo_gen didn't work, even if the ROM i'm using (Girls Mode 2 - Tokimeki Up) is a 7.x game. I didn't get a exefs_7x xorpad. Is there a file missing? I'm only getting a black screen on Citra. The US version works, though.

Post your ncchinfo.bin file here. And, if you only want to decrypt the game, just put it in /Decrypt9/ and let the NCCH decryptor handle it.

 

[RocketRobz]

And, if you only want to decrypt the game, just put it in /Decrypt9/ and let the NCCH decryptor handle it.

Thanks, now I no longer need xorer!

 

[temp2000]

I hit a roadblock with Plailect's guide (Started with a stock 10.3.0-28U N3DS LL). Everything been going 100% until Part 4 Step 15. Health&Safety inject keeps failing.

Decrypt9 log file

Initializing SD card... success
0x03 KeyX & KeyY: already set up
0x05 KeyY: already set up
0x25 KeyX: already set up
0x18 KeyX: already set up
0x1B KeyX: not found
Finalizing Initialization...
Initialization: partially failed
Using RedNAND @ 000001/000001
Searching title "Health&Safety (N3DS)"...
Method 1: Search in title.db...
Found title 0004001020021300
TMD0 found at 1A4E8000, size 2916b
APP0 found at 1A4F8000, size 956kB
APP1 found at 1A5E8000, size 388kB
Use arrow keys and <A> to choose a name
hs.app
Dumping & decrypting APP0...
Creating hs.app ...
Code / Crypto: CTR-N-HACE / 7x
Decrypt ExHdr/ExeFS/RomFS (2kB/670kB/0MB)
Verify ExHdr/ExeFS/RomFS: OK/OK/OK
Health&Safety Dump: succeeded!
Press B to return, START to reboot.
Unmounting SD card...
You selected "Health&Safety Inject".
This feature writes to the EmuNAND.
Doing this is potentially dangerous!
If you wish to proceed, enter:
<Left>, <Right>, <Down>, <Up>, <A>
(B to return, START to reboot)
Using RedNAND @ 000001/000001
Searching title "Health&Safety (N3DS)"...
Method 1: Search in title.db...
Found title 0004001020021300
TMD0 found at 1A4E8000, size 2916b
APP0 found at 1A4F8000, size 956kB
APP1 found at 1A5E8000, size 388kB
No usable file found
Health&Safety Inject: failed!
Press B to return, START to reboot.