Hacking [Release] rxTools - Roxas75 3DS Toolkit [fw 2.0 - 9.2]

[Cyan]

as nativ_firm can be updated by nintendo from NUS, it's probably generic data working on all consoles.
only N3DS are using a different one.
(2DS is using the same as 3DS, right?)
http://3dbrew.org/wiki/Title_list#00040138_-_System_Firmware
there are only 2 versions : NATIVE_FIRM and new3DS NATIVE_FIRM

 

[Riku]

That's it then. Also does NATIVE_FIRM contain any console unique data or is it the same for all consoles on the same region and version firmware. (obvously a 2DS or n3DS will have different native_firm data)

Yeah, it's the same. BTW, can you check if it's encrypted? If it's not encrypted it should look somewhat like this:

Spoiler

 

[Apache Thunder]

rxTools decrypts them. So yes that's what they look like. (definitely recall seeing "FIRM" in the beginning of the files). rxTools reencrypts them on import. They will then work fine so long as you don't modify them before hand as obviously they have to be signed correctly which they will be if you inject them without modifying/corrupting them.

I don't know about TWL, but in theory, we already have all we need to "region change" a 3DS (and n3DS once we gain access to it). If you have another "donar" 3DS to use, you can dump CTRNAND and firm0/firm1, then inject them into the other console and this will effectively region change them.

I don't know if TWL also needs to be transferred over or not. Someone more familiar with that could answer that question. But I think it's mainly NATIVE_FIRM (and the safe mode version of it) that holds the region locking and what not while the CTRNAND holds the console serial key needed for proper eShop access.

 

[Apache Thunder]

I've had confirmation from another user that he was able to update sysnand to 9.2 using CIAs, then replaced the firm0/firm1 files with the ones dumped from his 9.2 backup. (in this case his sysnand was already at 9.2. But he did this so he could "downgrade" TWL_FIRM to allow certain flashcarts to work as the DS Cart White list doesn't work on carts blocked by TWL)

So it's definite confirmation that Firm0/Firm1 is what causes CIA/Game rom updates to not work normally.

 

[Arisotura]

I tried using this to dump the system modules from my NAND. I used the obvious option for that, but it only located 10 titles, among which two system modules. According to 3dbrew there are many more titles.


My 3DS is on 4.5.0-10E. I don't use emuNAND. Do I still need the slot 0x25 key? Or is there another reason why this didn't go as expected?

 

[cearp]

I tried using this to dump the system modules from my NAND. I used the obvious option for that, but it only located 10 titles, among which two system modules. According to 3dbrew there are many more titles.


My 3DS is on 4.5.0-10E. I don't use emuNAND. Do I still need the slot 0x25 key? Or is there another reason why this didn't go as expected?

well, the system modules in nand are on CDN, anyone can download them and make a cia or whatever, so i would personally just do that

 

[Arisotura]

My plan isn't to install system modules, though. I want to decrypt some of them to study them.

Although I guess I could also grab them from the CDN and decrypt them, couldn't I?

 

[zoogie]

I tried using this to dump the system modules from my NAND. I used the obvious option for that, but it only located 10 titles, among which two system modules. According to 3dbrew there are many more titles.


My 3DS is on 4.5.0-10E. I don't use emuNAND. Do I still need the slot 0x25 key? Or is there another reason why this didn't go as expected?

You might try to run this
https://gist.github.com/archshift/4cb754c432ba7854212a#file-extract_ncchs-cpp
on the decrypted fat16 and maybe you'll get better luck (of course you could mount it too for finding everything else)

 

[Apache Thunder]

Yeah, it's the same. BTW, can you check if it's encrypted? If it's not encrypted it should look somewhat like this:

I got someone to get MD5 hashes for theirs and they don't match mine. Something is different among them despite both 3DSes being the same region and on the same version. The only difference with his is that he's using a 3DS and not a 3DS XL. Not sure if that matters or not? Perhaps difference in NAND chip type used? I recall the 3DS having two different brand NANDs and the two actually have different capacities.

 

[Zidapi]

I got someone to get MD5 hashes for theirs and they don't match mine. Something is different among them despite both 3DSes being the same region and on the same version. The only difference with his is that he's using a 3DS and not a 3DS XL. Not sure if that matters or not? Perhaps difference in NAND chip type used? I recall the 3DS having two different brand NANDs and the two actually have different capacities.

Yes, and they each produce differently sized NAND dumps.

Comparing yours to his might tell you if that's the reason for the differing MD5 hashes.

 

[Apache Thunder]

Any one willing to dump their 9.2 firm0/firm1 and get the MD5 hashes? You can post those so I can compare them to mine. The guy I got the initial MD5s to compare with mine didn't match and with Zidapi's idea, I then asked him what size his nand dump his. His is a little bit smaller then mine (His nand size is 943MB while mine is 954MB)

So there could be something to that. Different NAND capacities result in different NATIVE_FIRM installation so the resulting firm0/firm1 partitions will have different MD5. So if I can get the MD5 from another user with the same NAND capacity as my 3DS, then that would confirm that theory.

Here's the MD5s of the firm0/firm1 files I currently use:

firm0.bin - md5 is 642e5fc94ed1528b594cf62f1b828a64
firm1.bin - md5 is 245e31d95e74765d45d7401101b478c3

 

[Zidapi]

Any one willing to dump their 9.2 firm0/firm1 and get the MD5 hashes? You can post those so I can compare them to mine. The guy I got the initial MD5s to compare with mine didn't match and with Zidapi's idea, I then asked him what size his nand dump his. His is a little bit smaller then mine (His nand size is 943MB while mine is 954MB)

So there could be something to that. Different NAND capacities result in different NATIVE_FIRM installation so the resulting firm0/firm1 partitions will have different MD5. So if I can get the MD5 from another user with the same NAND capacity as my 3DS, then that would confirm that theory.

Here's the MD5s of the firm0/firm1 files I currently use:

firm0.bin - md5 is 642e5fc94ed1528b594cf62f1b828a64
firm1.bin - md5 is 245e31d95e74765d45d7401101b478c3

Sorry to keep you waiting, here you go.

EU 3DSXL with 9.2 sysNAND (954MB NAND dump)

firm0.bin - md5 is 181f6c82fc0b201ae00f9a668a66fc60
firm1.bin - md5 is d636907048a4dc1f59d2d65b4857afa2

Not very helpful it seems. Same system software, same NAND dump size. Only difference is the region.

 

[Hashtastrophe]

I was going to give the MD5s for my firm*.bin however, I'm too lazy to turn off OoT and launch rx to dump these, copy to computer, get hashes, post.

Also my Dream Team XL has the 943MB nand so not helpful either.

Edit: Actually, I should probably do it anyway. Can never have too many backups.

 

[Cindakil]

I've had confirmation from another user that he was able to update sysnand to 9.2 using CIAs, then replaced the firm0/firm1 files with the ones dumped from his 9.2 backup. (in this case his sysnand was already at 9.2. But he did this so he could "downgrade" TWL_FIRM to allow certain flashcarts to work as the DS Cart White list doesn't work on carts blocked by TWL)

So it's definite confirmation that Firm0/Firm1 is what causes CIA/Game rom updates to not work normally.

Ey! You think that it will be possible to use a 9.5 sysnand to install a 9.0 System using this exploit?

 

[Roxas75]

Ok sorry for being late.
The download is a bit outaded, i forced it to dump 10 titles to test, but the sources are complete, just re-compile with build.bat to get a rxTools.dat that dumps all the titles.

And, do not worry for the md5.
I'll explain... The firm0 partition contains NATIVE_FIRM, and much dummy data, since if far bigger than the firmware size.
The md5 will not match even on the same firmware.

Also, i was thinking on this sort of downgrade : since the 9.2 NATIVE_FIRM should be able to boot 9.5 nand (i made some tests), an hard-modded 9.5 can in theory inject an old firm0 in the nand and use the kernel exploit to launch Gateway and downgrade to 4.2. This should be possible in theory.

 

[GamingAori]

how i can decrypt games with this?

 

[daxtsu]

If you're taking feature requests, how about a cartridge dumper as well? Then RxTools would be an all in one solution for both dumping and decrypting 3DS games.

 

[Apache Thunder]

Ok sorry for being late.
The download is a bit outaded, i forced it to dump 10 titles to test, but the sources are complete, just re-compile with build.bat to get a rxTools.dat that dumps all the titles.

And, do not worry for the md5.
I'll explain... The firm0 partition contains NATIVE_FIRM, and much dummy data, since if far bigger than the firmware size.
The md5 will not match even on the same firmware.

Also, i was thinking on this sort of downgrade : since the 9.2 NATIVE_FIRM should be able to boot 9.5 nand (i made some tests), an hard-modded 9.5 can in theory inject an old firm0 in the nand and use the kernel exploit to launch Gateway and downgrade to 4.2. This should be possible in theory.

Wouldn't one have to encrypt the firm0 to the unique nand encryption of the target console? I don't think you can just inject any firm0.bin into encrypted NAND on a 9.3+ console that you don't have full access to like with 9.2 and below consoles....


Also to expand upon the cartridge dumper idea. Perhaps a cartridge save decryptor? Then people can dump their cartridge games they made saves on with 6.x save keys to be used in Gateway/MT-Card mode. rxTools will have the ability that Gateway's save dumper can't do right now. (obviously this means you have to boot rxTools on a firmware that uses the new keys)

There's many people with legit copies of games that would want their saves transferred into rom form in Gateway mode. but the save encryption issue is the road block. Gateway's classic mode uses the new save keys if you are on a sysnand that supports it. But for whatever reason Gateway mode still uses the old save keys no matter what sysnand version you are on. So many users are stuck with retail games saved on newer save encryption that they can't dump and use in gateway mode.

 

[Roxas75]

Yep, the firm0 needs to be encrypted. But we can easyly have a xorpad for that by downloading the console target firm from the CDN.

Also, yes, the save and card dumping / restoring is one of my next goals. Save decryption is too.
But i need time for this, since some things are not documented.

 

[Codename]

There's many people with legit copies of games that would want their saves transferred into rom form in Gateway mode. but the save encryption issue is the road block. Gateway's classic mode uses the new save keys if you are on a sysnand that supports it. But for whatever reason Gateway mode still uses the old save keys no matter what sysnand version you are on. So many users are stuck with retail games saved on newer save encryption that they can't dump and use in gateway mode.

But doesn't Gateway load the save encryption keys on boot, from the SysNAND? If the SysNAND is 6.x+ (uses newer save encryption), then wouldn't Gateway mode and Classic mode load the 6.x+ save encryption keys? If not, where does Gateway mode load the save encryption keys from?