This tutorial is now over 4 years old and out of date! You can now simply use a 3DS and Godmode9 to convert any CSUs on the SD card to CIAs, so long as the CSU contains a banner and icon, otherwise those specific CSUs won't convert.

Spoiler: Old post content

When I got my hands on the 3DS SDK tools, I thought I could just simply install the pre-built CIAs onto my 2DS with no hassle. Turns out I was wrong! The CIAs were apparently for the Dev Kits, and therefore, would not install. That's when I turned my attention to the .CSU files in the same directories as the CIAs. Nearly every Devkit tool has its own CSU file.

You will need

• A 2DS/O3DS/N3DS on 9.2 or under with Emunand or RxTools' DevMode
  
• The 3DS SDK Devkit Tools (find 'em yourself, I'm afraid...)
• 3DS to CIA Converter v4.1 (https://mega.nz/#!SY1U2ADI!pJuZ8oVxT4cn0swADYLXKsJI9I640rjCd-ruZxXQdSc)

1.Extract the 3DS to CIA converter RAR file to somewhere convenient. Then, if necessary, extract the SDK Tools to the same place. It should look something like this:

2. Enter the SDK Tools Directory and search for '.csu' (without quotation marks)

3. Grab all of the .csu files you find in the search, making sure that you don't pick up any duplicates. After that, copy and paste the files into the 3DS to CIA converter folder.

Final Result:

4. Open '3DS to CIA Converter.bat'. When it opens, type and enter 3 to go to the Converter menu, then type and enter 4 to convert CSU to CIA. It'll prompt for a CSU name. Looking at the list of CSUs above, I'll use BossLotcheckTool as the main example. Anyway, enter the name of the CSU, adding the extension on at the end.

It'll work it's magic. Be sure to remove region lock, as well! Soon, it appears with this screen:

5. WARNING! THE FOLLOWING STEP IS VITAL! READ IT CAREFULLY, OR YOU MAY FIND YOUR BUILT CIAS WILL NOT INSTALL PROPERLY!
Open RSF2.rsf in Notepad. Don't worry about anything else other than the Unique Id! Whatever CSU you convert first is recommended to have the Unique Id 0x00000001. NO CIAS SHOULD HAVE THE SAME UNIQUE ID! That's why this step is so important. Personally, I would note down the Unique Id's I have already used.
Also make sure to change the ExtSaveDataId value to be the same as the Unique Id.

6. Save the edited rsf file, then return to the converter. Press enter to let it finish off converting it to CIA. When done, choose 'yes' to clean up the files, then check to see if your built CIA is present.

7. Repeat steps 4 to 6 for the rest of the CSU files, making sure you use a different Unique Id every time, then copy the new CIA files onto an SD card.

8. On your 3DS, insert your SD card, then boot your Emunand or whatever you folk use nowadays. I use RxTools' DevMode. When you're in Emunand, go to the homebrew launcher, and open FBI, assuming you have already prepared these.

9. Enter the directory with the CIAs, then press X to install all CIAs in the current directory. If this method fails, then try to see if DevMenu will install by itself. If THAT fails, then you can find BigBlueMenu.cia, which is out there somewhere.

9a. Only undergo this step if you have had to install DevMenu/BigBlueMenu. Boot Emunand/Dev Mode again, then open either Dev Menu or Title Manager. Do the same procedure as step 9, but instead of pressing X to install all CIAs, use the L + R + A combination.

10. If you have done everything correct, you should see that the SDK Tools have installed onto your Home Menu, ready to be used somehow.

My Screenshots:

 

[Asia81]

Thanks, I searched something like that for a while now xD

 

[Deleted User]

Thanks, I searched something like that for a while now xD

You're welcome!

 

[piratesephiroth]

The CIAs aren't corrupt. They just use a different encryption so only development units can decrypt them.

 

[Deleted User]

The CIAs aren't corrupt. They just use a different encryption so only development units can decrypt them.

Sorry. I didn't phrase that correctly!

 

[zoogie]

Sorry. I didn't phrase that correctly!

And those dev cia's can be decrypted with these instructions:
https://gbatemp.net/threads/dumping...mario-3d-land-beta.389806/page-3#post-5529628

 

[Deleted User]

And those dev cia's can be decrypted with these instructions:
https://gbatemp.net/threads/dumping...mario-3d-land-beta.389806/page-3#post-5529628

Soooo, basically this thread isn't needed, then?

 

[zoogie]

Soooo, basically this thread isn't needed, then?

I don't know if a thread was ever made on this subject so maybe it's a good idea.
You might revise your OP to reflect the new info however. (and try it yourself so you can teach it)

 

[Deleted User]

I don't know if a thread was ever made on this subject so maybe it's a good idea.
You might revise your OP to reflect the new info however. (and try it yourself so you can teach it)

Just remind me what OP means, again?

 

[piratesephiroth]

And those dev cia's can be decrypted with these instructions:
https://gbatemp.net/threads/dumping...mario-3d-land-beta.389806/page-3#post-5529628

That's how we dump them. You still need a dev unit to run (or decrypt) the CXIs.

 

[Deleted User]

That's how we dump them. You still need a dev unit to run (or decrypt) the CXIs.

That’s why I thought this was a more reliable method. Perhaps this is the only way to do it?

 

[piratesephiroth]

That’s why I thought this was a more reliable method. Perhaps this is the only way to do it?

yeah, remember how we need an exploited retail 3DS to generate the xorpads to decrypt retail games? This is just the same. We need an exploited dev unit.

 

[Apache Thunder]

Decrypting the CIAs is only half the battle. Some of the dev app CXIs don't use zero key encryption and instead use the system fixed key slot like their retail counterparts. It's not a key that's been leaked last I checked, so it's impossible to decrypt them with anything other then a dev unit.

Many of the dev apps are originally intended to be installed to NAND much like standard retail system apps. So if you convert them to CIA so they can run from SD, you may find issues with them causing games to not boot anymore after you had recently used one of them. You would then have to reboot the console to avoid a game hanging at the 3DS boot logo. That's assuming you go the proper route and convert them to CIA without using RSF files. I don't know what exactly has to be altered in the exheader to fix this issue though.

I've noticed the BigBlueBox releases like DevMenu 6.2 don't have this problem yet the versions I convert myself does. It's not a problem with how I'm building them. There's something different being done to the exheaders because they are not the same as the ones I end up using (which in most cases are nearly identical to the original besides a few offsets being altered in a hexeditor. One example being that I change them from a system app to a SD app by changing their title ID. One of the requirements of getting them to install to SD properly if built without using rsf files) I just need to find out what else needs to be changed in the exheader before a system app will work properly as a SD app. Meddling with RSF files is messy and I don't get good results. Just about all the games I've converted to CIA with my new method have gone off without a hitch. It's only the system apps that have problems.

If there was a way to encrypt new apps using the system fixed keyslot with a CTR Encrypter (basically the reverse version of CTR Decrypter that rxTools/Decrypt9 has), then simply having them install to NAND would solve this issue entirely and little if any work would have to be done to them prior to building the CIA.


And no you can't use zero key encryption because that works only on dev units and in Gateway mode on retail units. CFWs that are currently out do not enable that and a previous firmware version (somewhere in the 6.x-7.x range, I don't know when) started enforcing proper encryption for system apps. So if you don't encrypt them or encrypt them with the wrong keyslot/key, they won't show up on the homemenu or boot if you try to build them as system apps that install to NAND. So getting them encrypted to the right key and keyslot is a must.

 

[Deleted User]

Decrypting the CIAs is only half the battle. Some of the dev app CXIs don't use zero key encryption and instead use the system fixed key slot like their retail counterparts. It's not a key that's been leaked last I checked, so it's impossible to decrypt them with anything other then a dev unit.

Many of the dev apps are originally intended to be installed to NAND much like standard retail system apps. So if you convert them to CIA so they can run from SD, you may find issues with them causing games to not boot anymore after you had recently used one of them. You would then have to reboot the console to avoid a game hanging at the 3DS boot logo. That's assuming you go the proper route and convert them to CIA without using RSF files. I don't know what exactly has to be altered in the exheader to fix this issue though.

I've noticed the BigBlueBox releases like DevMenu 6.2 don't have this problem yet the versions I convert myself does. It's not a problem with how I'm building them. There's something different being done to the exheaders because they are not the same as the ones I end up using (which in most cases are nearly identical to the original besides a few offsets being altered in a hexeditor. One example being that I change them from a system app to a SD app by changing their title ID. One of the requirements of getting them to install to SD properly if built without using rsf files) I just need to find out what else needs to be changed in the exheader before a system app will work properly as a SD app. Meddling with RSF files is messy and I don't get good results. Just about all the games I've converted to CIA with my new method have gone off without a hitch. It's only the system apps that have problems.

If there was a way to encrypt new apps using the system fixed keyslot with a CTR Encrypter (basically the reverse version of CTR Decrypter that rxTools/Decrypt9 has), then simply having them install to NAND would solve this issue entirely and little if any work would have to be done to them prior to building the CIA.


And no you can't use zero key encryption because that works only on dev units and in Gateway mode on retail units. CFWs that are currently out do not enable that and a previous firmware version (somewhere in the 6.x-7.x range, I don't know when) started enforcing proper encryption for system apps. So if you don't encrypt them or encrypt them with the wrong keyslot/key, they won't show up on the homemenu or boot if you try to build them as system apps that install to NAND. So getting them encrypted to the right key and keyslot is a must.

......To complicated for me!

Anyway, I'm pretty sure this is an easier way. Looking at this massive chunk of text and unimaginable jargon, I'd stick with this method!

 

[gudenau]

Decrypting the CIAs is only half the battle. Some of the dev app CXIs don't use zero key encryption and instead use the system fixed key slot like their retail counterparts. It's not a key that's been leaked last I checked, so it's impossible to decrypt them with anything other then a dev unit.

Many of the dev apps are originally intended to be installed to NAND much like standard retail system apps. So if you convert them to CIA so they can run from SD, you may find issues with them causing games to not boot anymore after you had recently used one of them. You would then have to reboot the console to avoid a game hanging at the 3DS boot logo. That's assuming you go the proper route and convert them to CIA without using RSF files. I don't know what exactly has to be altered in the exheader to fix this issue though.

I've noticed the BigBlueBox releases like DevMenu 6.2 don't have this problem yet the versions I convert myself does. It's not a problem with how I'm building them. There's something different being done to the exheaders because they are not the same as the ones I end up using (which in most cases are nearly identical to the original besides a few offsets being altered in a hexeditor. One example being that I change them from a system app to a SD app by changing their title ID. One of the requirements of getting them to install to SD properly if built without using rsf files) I just need to find out what else needs to be changed in the exheader before a system app will work properly as a SD app. Meddling with RSF files is messy and I don't get good results. Just about all the games I've converted to CIA with my new method have gone off without a hitch. It's only the system apps that have problems.

If there was a way to encrypt new apps using the system fixed keyslot with a CTR Encrypter (basically the reverse version of CTR Decrypter that rxTools/Decrypt9 has), then simply having them install to NAND would solve this issue entirely and little if any work would have to be done to them prior to building the CIA.


And no you can't use zero key encryption because that works only on dev units and in Gateway mode on retail units. CFWs that are currently out do not enable that and a previous firmware version (somewhere in the 6.x-7.x range, I don't know when) started enforcing proper encryption for system apps. So if you don't encrypt them or encrypt them with the wrong keyslot/key, they won't show up on the homemenu or boot if you try to build them as system apps that install to NAND. So getting them encrypted to the right key and keyslot is a must.

Is the memory set to be system? That could be the problem.

 

[Deleted User]

Is the memory set to be system? That could be the problem.

No, the memory isn't set to be system when installing them through DevMenu. Although you can choose to install them to either NAND or SD in FBI. However, I don't use FBI; it doesn't work for me 50% of the time.

 

[gudenau]

GameCoinSetter and MenuSelector do not have banners. This causes it to fail.

 

[Deleted User]

GameCoinSetter and MenuSelector do not have banners. This causes it to fail.

No, they actually do work. On my 6.1.0 2DS, the banners are just put in place with a placeholder.

Edit: Just realized that you have to convert 'PlayCoinSetter.csu', not 'GameCoinSetter.csu'. They are exactly the same, except there is a banner and an icon in PlayCoinSetter.

 

[DinohScene]

No asking for warez.

 

[Deleted User]

-snip-

absolutely not. They are apps built with Nintendo's official SDK, therefore warez, as stated by DinohScene.

And I didn't think that command line app was 64-bit only... o.O