ROM Hack [Release] 3DS Simple CIA Converter

[Riku]

After looking at how unnecessarily complicated current CIA converting methods are, I decided to write this tool. It's very simple and doesn't use Python or .NET Framework or any other programs and scripts, just my own code in a single exe file.

I decided to take slightly different approach to keep things simple and only use ExHeader XORpads. They are 1MB each in size and multiple ROM files supported during 'ncchinfo.bin' creation, so you can make xorpads for a bunch of games in one go. With version 4.0 I added ability to patch minimum required kernel version (FW Spoof) and 'RegionFree', which requires *.exefs_norm.xorpad's. 'FW Spoof' function checks FW version game requires to run and only applied if original value exceeds entered (2D02:FW8.0-8.1, 2E02:FW9.0-9.2, 3002:FW9.3, 3102:FW9.5, 3202:FW9.6-9.8).

1) Put your 3DS games into 'roms' folder and press 'Create ncchinfo.bin file' button to create 'ncchinfo.bin' from 3DS ROMs.

2) Use GodMode9 along with created 'ncchinfo.bin' to generate ExHeader XORpads, put it in root of SD card, launch GodMode9 and follow
'[0:] SDCARD --> nccginfo.bin --> NCCHinfo options... --> Build XORpads (SD output)'.

3) Put *.xorpad files you generated on 3DS from SD root into 'xorpads' folder, press 'Convert 3DS ROM to CIA' button, select folder with *.3ds files and wait for program to finish.

With version 5.0 of the program XORpads are no longer required if proper 'boot9.bin' file detected in the same folder.
To generate 'boot9.bin' file you need B9S hack installed on your 3DS. Just hold (Start) + (Select) + (X) on boot and it will be saved to the /boot9strap/ folder on your SD card.

UPDATE (2017-09-24)
Version 5.0 is out

Changelog:

• Added KeyX extraction from 'boot9.bin' file, no xorpad required if proper key provided.

Spoiler: Previous changelog

Version 4.3, 2015-07-03
----------------------------------
- Added zero-key encrypted ROM support, no xorpad required.
- Added error skip so program doesn't stop converting remain files.
- Added application Major version writing into TMD.

Version 4.0, 2015-06-28
----------------------------------
- Added Download Play support.
- Added input 3DS ROM folder selection dialog.
- Added searching for *.3ds|*.3dz files in subfolders.
- Improved partition type detection.
- Improved 'FW Spoof' function.
- Set RegionFree to default without ability to disable it.
- Code cleanup and minor optimizations.

 

[cearp]

thank you for this! not for myself, but for all the people who have trouble with the dirty cia conversion
rsf files are evil

 

[Phytophthora]

Is it possible to modify this to use it with rxTools xorpad generation on 9.2 system?
https://github.com/roxas75/rxTools/blob/master/tools/scripts/ncchinfo_gen.py
this script is normally used to create the ncchinfo.bin

 

[Riku]

Is it possible to modify this to use it with rxTools xorpad generation on 9.2 system?
https://github.com/roxas75/rxTools/blob/master/tools/scripts/ncchinfo_gen.py
this script is normally used to create the ncchinfo.bin

Possible, yes, but it will break compatibility with '3DS Multi Decryptor', since roxas75 decided to change 'ncchinfo.bin' format. Filenames inside ncchinfo.bin should be in Unicode. Maybe it's a better idea to ask him to fix this?

 

[Phytophthora]

I don't really understand how all this stuff works but I think Roxas75 is just using this:
https://github.com/archshift/Decrypt9
since the '3DS Multi Decryptor' is not working on 9.2 systems?
correct me if I'm wrong

 

[zoogie]

Possible, yes, but it will break compatibility with '3DS Multi Decryptor', since roxas75 decided to change 'ncchinfo.bin' format. Filenames inside ncchinfo.bin should be in Unicode. Maybe it's a better idea to ask him to fix this?

His program decrypts games 'in place' so you wouldn't even need an ncchinfo.bin -- it's all plaintext already.

 

[Riku]

I don't really understand how all this stuff works but I think Roxas75 is just using this:
https://github.com/archshift/Decrypt9
since the '3DS Multi Decryptor' is not working on 9.2 systems?
correct me if I'm wrong

I see. I'll change 'ncchinfo.bin' format as soon as he adds 4.5 MSET launching support then.

His program decrypts games 'in place' so you wouldn't even need an ncchinfo.bin -- it's all plaintext already.

And we don't want them decrypted. We need XORpads so we can re-encrypt patched ExHeader back.

 

[zoogie]

I see. I'll change 'ncchinfo.bin' format as soon as he adds 4.5 MSET launching support then.

And we don't want them decrypted. We need XORpads so we can re-encrypt patched ExHeader back.

I thought no part of the cia needs to be encrypted. Doesn't the 3ds handle reencryption as part of the import process?

 

[Riku]

I thought no part of the cia needs to be encrypted. Doesn't the 3ds handle reencryption as part of the import process?

That's how my program works. It's designed to make process simple and fast. Transferring ROMs to SD card (some of them ~4GB) and decrypt whole thing (double this size), then transferring it back to PC and basically rebuilding CIA from scratch are not considered simple/fast by me. And, yes, there's multiple layers of encryption involved, import process adds one on top.

 

[cearp]

And, yes, there's multiple layers of encryption involved, import process adds one on top.

what titlekey do you use to encrypt with? a friend who told me this method a while ago used hex converted from ascii of Reggie Fils-Aime

 

[sailor_moon]

Just wanted to say Thanks for this Tool~ so Thank you very much for making this tool.

 

[Apache Thunder]

Makerom should support re-encrypting using zero keys as is the standard practice for building custom 3DS files and CIAs. Why not implement this in your scripts? Being able to use rxTools direct decryption method instead of messing with xorpads would make your "simple" cia converter even more simple to use and rxTools pretty much works on all firmware ranges.

 

[NicEXE]

doesn't use Python or .NET Framework

Ok .NET Framework is an unnecessary requirement since people can produce GUI applications on windows without it but no python takes out OS X and *nix users in general.
Scripts are more desirable (at least for me) since you can launch them practically on every OS and also you can open them and fiddle with them before you launch them.
When you give out binaries the only way to mess with it is to decompile or disassemble them first.

 

[Riku]

what titlekey do you use to encrypt with? a friend who told me this method a while ago used hex converted from ascii of Reggie Fils-Aime

Random one, I guess.

Makerom should support re-encrypting using zero keys as is the standard practice for building custom 3DS files and CIAs. Why not implement this in your scripts? Being able to use rxTools direct decryption method instead of messing with xorpads would make your "simple" cia converter even more simple to use and rxTools pretty much works on all firmware ranges.

This way you'll need fully decrypt every game on 3DS first, which means transferring it to SD card (up to 4GB each, again), wait for 3DS to finish decryption (takes a while) and transfer it back to pc. IT. IS. SLOW. My 'ncchinfo.bin' only produce 1MB ExHeader XORpads, other partitions just skipped + it can store info for multiple games. And I can make it support rxTools XORpad maker, but I don't want to loose '3DS Multi Decryptor' compatibility just yet.

 

[Apache Thunder]

I think the 1mb xorpads named "s" that it creates is perhaps an issue with the particular ncchinfo.py script you are using to gen the ncchinfo file. I recently read that rxTools and perhaps Decrypt9 stores the filenames as unicode in the bin file which the original from the multitool doesn't (or it could be the other way around. I'm not that sure). So if you used the python script form void multitool thing to make the file instead of the one that came with rxTools you would get the bugged xorpad generation with only a 1mb file called "s". That file happens to be whatever the last xorpad it generated was. (since each new one it makes would overwrite the last one due to the bugged filenames)

EDIT: Yep it's how it stores the file names. I genned the ncchinfo for a game rom with both the old ctrkeygen python script then used the one for rxTools. In a hex editor I can easily tell the difference. Looks like the old script generates the filenames in unicode while the new one doesn't. I would assume Decrypt9 (which rxTool's xorpad generator is based off of) also expects the new format. So just use the ncchinfo generator script that came with rxTools/Decrypt9 instead.

 

[Riku]

I think the 1mb xorpads named "s" that it creates is perhaps an issue with the particular ncchinfo.py script you are using to gen the ncchinfo file. I recently read that rxTools and perhaps Decrypt9 stores the filenames as unicode in the bin file which the original from the multitool doesn't (or it could be the other way around. I'm not that sure). So if you used the python script form void multitool thing to make the file instead of the one that came with rxTools you would get the bugged xorpad generation with only a 1mb file called "s". That file happens to be whatever the last xorpad it generated was. (since each new one it makes would overwrite the last one due to the bugged filenames)

EDIT: Yep it's how it stores the file names. I genned the ncchinfo for a game rom with both the old ctrkeygen python script then used the one for rxTools. In a hex editor I can easily tell the difference. Looks like the old script generates the filenames in unicode while the new one doesn't. I would assume Decrypt9 (which rxTool's xorpad generator is based off of) also expects the new format. So just use the ncchinfo generator script that came with rxTools/Decrypt9 instead.

Yeah, I'm already aware of this. I'm not using any scripts though, it's my own code. Switching from old unicode name format to rxTools-compatible one is simple. It's just rxTools can't fully replace '3DS Multi Decryptor' now, since you can't launch it via DS Profile and without WiFi connection.

 

[Apache Thunder]

He plans on implementing Cubic Ninja support (and perhaps DS Profile version later) so that might not be true for very long.

For me it doesn't matter. I use my 3DS near my computer all the time, so the internet requirement doesn't bother me. I even went through the trouble of manually updating to 9.2 via CIAs and such to get off the old 4.5 fw. I have no plans on going back.

 

[Asia81]

Excuse me, but :
What the utility of your tool if no Region-Free or firm version patches are supported. ?

 

[Phytophthora]

Yeah, I'm already aware of this. I'm not using any scripts though, it's my own code. Switching from old unicode name format to rxTools-compatible one is simple. It's just rxTools can't fully replace '3DS Multi Decryptor' now, since you can't launch it via DS Profile and without WiFi connection.

So could you just make a second version just for rxTools/Decrypt9 usage besides the '3DS Multi Decryptor' version until rxTools supports DS Profile loading?

 

[Riku]

Excuse me, but :
What the utility of your tool if no Region-Free or firm version patches are supported. ?

Generated CIAs are not 4.5CFW-friendly. For now it's more for Gateway users and maybe future CFWs.

So could you just make a second version just for rxTools/Decrypt9 usage besides the '3DS Multi Decryptor' version until rxTools supports DS Profile loading?

I'm considering this.