ROM Hack 3DS ROM Tool: rom_tool

[umdking]

Do not do that, you're breaking the NCSD signature, no current device has 3DS Sig checks patched.

Is that means a rom still can not work yet on the gateway card if its signature is broken? but,why don't GW to disable signature checks? Are these useful to run roms?

 

[3DSGuy]

but,why don't GW to disable signature checks? Are these useful to run roms?

That's something you'd have to ask gateway.

 

[umdking]

That's something you'd have to ask gateway.

lol you're right.
And one more question please,can we use your tool extract some resources like musics,pics,models in the future versions?

 

[3DSGuy]

lol you're right.
And one more question please,can we use your tool extract some resources like musics,pics,models in the future versions?

That's something only time can tell.

 

[GameBarHome]

WHAT IS "rom_tool" ?
"rom_tool" is a tool I wrote in light of the recently announced Gateway 3DS. It has three main features:

1. Read 3DS ROMs, and print information about them, including actual ROM file size, and minimum required 3DS FW etc.
2. Accurately trim 3DS ROMs, and be able to restore them again.
3. Extract the partitions from 3DS ROMs (and other NCSD Images, such as NAND Dumps)

ROM trimming and un-trimming is tested(to trim and un-trim correctly), and works with all 3DS ROM sizes, large(4GB) and small(128MB).


NOTE: In release v2.6 and onwards, there exists a feature called "Super Trim". This works by removing the update partition(in addition to unused bytes) from the ROM. This has been tested by Devin, and works with Gateway-3DS. However as this is removing used data from the ROM, the removed update partition CANNOT be restored, and the ROM is PERMANENTLY altered. As update partitions are approximately 30MB in size, Super Trimming offers little advantage over regular trimming when dealing with large ROMs. So Super Trimming a ROM should only be done when space is scarce.

NOTE: Super Trimmed ROMs are only compatible with Gateway Version 1.1 and above.

HOW TO USE
This is a command line tool, so you have to use cmd .

View ROM/NAND Dump Info:
rom_tool -i Test.3ds

Extract ROM Partitions:
rom_tool -x <prefix for extracted files> Test.3ds

Trim ROM:
rom_tool -t Test.3ds

Super Trim ROM (Permanently remove update partition):
rom_tool -s Test.3ds

Restore ROM (Untrim):
rom_tool -r Test.3ds

DOWNLOAD(WINDOWS) : FileTrip (v2.6 Released: 20/8/13)

SOURCE CODE : GITHUB
Note the source code was written to be compatible with both Windows and Linux. When compiling on Windows, use MinGW, success not guaranteed with any other Windows developing environment.

Found a BUG！

English is not good, sorry!
ROM name, named as *.**.3Ds (* is an arbitrary symbols, such as the name of the picture)
Extract ROM Partitions (absolute path specified ROM)
rom_tool stored in the x:\9898 folder (required)
WIN + R
CMD
command line:
x:\9898\rom_tool -x x:\9898\*.**.3ds

An error message

 

[justinkb]

Is that means a rom still can not work yet on the gateway card if its signature is broken? but,why don't GW to disable signature checks? Are these useful to run roms?

The processor probably simply refuses to execute the code. Not much gateway team can do about it.

 

[umdking]

The processor probably simply refuses to execute the code. Not much gateway team can do about it.

Oh
But I thought that If they(Gateway) indeed have kernel access,they could be able to patch the signature checks,so that allow unsigned codes to execute,and CPU can't stop these operations from kernal.
I don't know whether I misunderstood about this.Please correct if I'm wrong.

 

[3DSGuy]

Found a BUG!

Thank you for drawing to my attention, that my program didn't catch some bad input from the user.

 

[3DSGuy]

Oh
But I thought that If they(Gateway) indeed have kernel access,they could be able to patch the signature checks,so that allow unsigned codes to execute,and CPU can't stop these operations from kernal.
I don't know whether I misunderstood about this.Please correct if I'm wrong.

Gateway *can* remove signature checks in GW mode. But they'll only do it, if it is in their best interests as a flash cart maker.

 

[Devin]

Gateway *can* remove signature checks in GW mode. But they'll only do it in their best interests as a flash cart maker.

So we could actually see them create some kind of homebrew launcher? I'm sure they'd incorporate it with the red card somehow, due to not needing the red/blue card to get into GW3DS mode.

 

[3DSGuy]

So we could actually see them create some kind of homebrew launcher? I'm sure they'd incorporate it with the red card somehow, due to not needing the red/blue card to get into GW3DS mode.

That's the thing. If they remove signature checks, eventually someone will find a way to install a HB launcher to the SD card via the red card. Once installed, the user would only have to enter GW mode to use the installed HB launcher, and could re-sell the card.

 

[umdking]

Gateway *can* remove signature checks in GW mode. But they'll only do it in their best interests as a flash cart maker.

So,technically,they can,and the CPU cannot stop them.
I think there will be a way that Gateway can allow somebody else's unsigned codes to run in GW mode,with the red card of course.And they should be willing to do that.Because people who need homebrews are potential buyers of the red card.Considering that we don't have any homebrew running in the 3DS mode yet ATM.

 

[MrAnalysis]

Its not as simple as taking away the requirement of firmware from the rom if you did that most games will still work but some wont.

Firmware can add new features and these features might be needed so just bypassing the need for firmware on the rom would just cause some games to spaz out and crash/not load/play correctly.

A rather shitty of extreme example of this would be Nintendo could make some new games use a different cartridge type (different hardware inside extra ram added or something maybe) if you put a cart like that into a 3ds without firmware update the 3ds would be unable to read it. But carry a firmware update on the card and update the 3ds to be able to read this new type and old type.. and hey presto works..

They could change a number of things in new games like how it loads, where it gets some data from or saves to etc etc, the 3ds would need to know the changes and how to react to them, this is why new firmware would be needed to allow them to do so. So when you get a game that says "you need XX firmware" you might actually really need it, bypassing the need for it could cause no end of trouble.

Unless they can spoof the new features of upgraded firmware somehow also i really dont think its a good idea removing the requirement for it down the line there will be issues.

 

[justinkb]

Gateway *can* remove signature checks in GW mode.

Sorry but technically I think this is wrong. They can feed data through exploits and get certain stuff executed via ROP, but the hardware fundamentally won't allow "plain" execution of unsigned stuff.

 

[3DSGuy]

Sorry but technically I think this is wrong. They can feed data through exploits and get certain stuff executed via ROP, but the hardware fundamentally won't allow "plain" execution of unsigned stuff.

Sorry, but this actually made me laugh. Though I suppose it was my fault for not being very clear. The difference between signed content and unsigned content to a 3DS is the '0' or a '1' returned from what ever function does the signature check. Which is something after a bit of research Gateway-3DS could force to always return 0. In much the same way Gateway-3DS has already patched NS to return 0 when it checks to see if a Game Card Update is required, and similar patch for the Home Menu so checking the app's region data has the correct bit-flag for the home menu's region.

With at least the NCSD and NCCH signature checks patched, you could run an un-signed ROM via the gateway card. There's nothing at a fundamental level which can stop loading that unsigned ROM at that point when the 3DS believes it's signed as the NCSD and NCCH signature checks returned 'Good'.

 

[umdking]

Sorry, but this actually made me laugh. Though I suppose it was my fault for not being very clear. The difference between signed content and unsigned content to a 3DS is the '0' or a '1' returned from what ever function does the signature check. Which is something after a bit of research Gateway-3DS could force to always return 0. In much the same way Gateway-3DS has already patched NS to return 0 when it checks to see if a Game Card Update is required, and similar patch for the Home Menu so checking the app's region data has the correct bit-flag for the home menu's region.

With at least the NCSD and NCCH signature checks patched, you could run an un-signed ROM via the gateway card. There's nothing at a fundamental level which can stop loading that unsigned ROM at that point when the 3DS believes it's signed as the NCSD and NCCH signature checks returned 'Good'.

Thanks for your detailed explanation.

May i ask a few questions about the rom?
What's actually in the NCSD header?some sorts of file system data?just like MFT in the NTFS ?
Is the original decryption key is required to decrypt the actual contents in the NCCH partitions? Any possible alternative way to do the decryption?
Is it technically possible that someone can aquire the decryption key of the rom from a 3DS console with the kernal access?

Sorry if i disturbed you.

 

[3DSGuy]

What's actually in the NCSD header?

http://3dbrew.org/wiki/NCSD

Is the original decryption key is required to decrypt the actual contents in the NCCH partitions? Any possible alternative way to do the decryption?

The only way the decrypt the NCCH partitions is with the AES key the NCCH was encrypted with.

Is it technically possible that someone can aquire the decryption key of the rom from a 3DS console with the kernal access?

No, the keys are stored in two parts(scrambled), one part is known by the 3DS, the other part is calculated from the NCCH header of the NCCH file. Then the two parts are descrambled by a hardware AES engine, and the actual key is written by the AES engine to a register to which only the AES engine can read. So even with kernel level control you won't ever get the final key which is used to decrypt the NCCH.

 

[BORODA]

Its not as simple as taking away the requirement of firmware from the rom if you did that most games will still work but some wont.

Firmware can add new features and these features might be needed so just bypassing the need for firmware on the rom would just cause some games to spaz out and crash/not load/play correctly.

A rather shitty of extreme example of this would be Nintendo could make some new games use a different cartridge type (different hardware inside extra ram added or something maybe) if you put a cart like that into a 3ds without firmware update the 3ds would be unable to read it. But carry a firmware update on the card and update the 3ds to be able to read this new type and old type.. and hey presto works..

They could change a number of things in new games like how it loads, where it gets some data from or saves to etc etc, the 3ds would need to know the changes and how to react to them, this is why new firmware would be needed to allow them to do so. So when you get a game that says "you need XX firmware" you might actually really need it, bypassing the need for it could cause no end of trouble.

Unless they can spoof the new features of upgraded firmware somehow also i really dont think its a good idea removing the requirement for it down the line there will be issues.

Kernel access can give a possibility to deploy updated parts of the system without touching the DS mode or system settings that has the exploit. Just like on Wii, where you could deploy vulnerable IOSes and have the exploit working even with the latest system version.

 

[umdking]

No, the keys are stored in two parts(scrambled), one part is known by the 3DS, the other part is calculated from the NCCH header of the NCCH file. Then the two parts are descrambled by a hardware AES engine, and the actual key is written by the AES engine to a register to which only the AES engine can read. So even with kernel level control you won't ever get the final key which is used to decrypt the NCCH.

Thanks for answering .So it's nearly impossible to get the final key from a 3DS console.
But can people do something like what they previously did to the psp? that using the functions in the system itself to read out what was encrypted in the rom.In that way,maybe it's possible to work around the key itself,and get the actual contents in the rom.

 

[3DSGuy]

Using the functions in the system itself to read out what was encrypted in the rom.In that way,maybe it's possible to work around the key itself,and get the actual contents in the rom.

That's what people with kernel exploits are doing to get decrypted NCCH files (or decrypted anything). While you personally won't know the key, you can always get the 3DS to decrypt it for you.