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

[Apache Thunder]

Ok. I deep decrypted the original CIA and saved that. Then I encrypted it and decrypted it using deep option. Saved that with _deepdecrypted ammended to name. Then encrypted it again, then deep decrypted it a second time. Saved that file with _deepdecryptedpass2.

The two deep decrypted files MD5 match. However the original CIA which I decrypted doesn't have a matching MD5 with the two other CIAs that were passed through multiple times.

The changed offsets appear to be the same in regards to the original file that I decrypted the first time. Perhaps because this CIA was packed in a way that would just result in it always being different from the new files after passing through Decrypt9.

But the CIAs that went through the deep decryptor and CIA encryptor are the same, so the result is consistent.

I haven't had a chance to actually try installing the CIA. The app in question is BossLotcheckTool. I'm going to unpack the CXI and edit the exheader so it installs to NAND like I've been able to do with some of the other devapps. Then I'll repack the CXI like I normally do. Now this time instead of encrypting the CXI before building the CIA, I will immediately build the CIA, then use Decrypt9WIP to encrypt the CIA using the NCCH option.

Once I get around to this I'll report if this made any difference. BossLotcheckTool was one of the apps that was giving me trouble and not wanting to work from NAND so it's a good start to see if it made any difference packing the CIA with the unencrypted CXI first.

EDIT:

Tested this with my new attempt with the encrypt CIA options available. No change. BossLotCheckTool still crashes immediately after starting it. (boot logo never has a chance to show). I made the correct changes to the exheader. (set content type bit to 02 to make it install to NAND and set offset at 0x0d to 01 to disable the run from SD flag. Code was still compressed so used 01 in it's place)

This one may need a different method of CXI rebuild process so the new CIA encryption stuff made no difference. I may switch over to 3dstool to see if that does something different in terms of rebuilding the CXI. Wish I could just edit the exheader while it's still in the CXI. But the CXI header has it's own program id and partition id in the header and if one or both of those aren't updated, the resulting CIA will still want to install to SD. I tried ediing one or both of those lines, but the resulting CIA will crash at 100% during install. (DevMenu crashes forcing me to reboot) This crash isn't related at all to your CIA encrypted stuff. That's just things I had attempted with the CXI long before the CIA encryption stuff was used.

I'm guessing I don't know enough about the CXI header to do it correctly. So rebuilding CXI seems the only method for me right now. I'll just find alternate means of building the CXI. Before I used 3DS Builder No crypt version to build the CXI. So instead I'll move over to giving 3dstool a try.

Since it appears to behave identical to my previous attempt, it looks like the CIA encryption options don't make things any worse. So they appear to work and produce a valid CIA that installs correctly. It would be safe to assume that for most other normal circumstances that it would produce valid CIAs for games and such.

It's up to you if you want to keep these in the menu. It's fine if they end up not staying. The experienced users can add them back to the menu themselves if they need CIA encryption for some special reason.

 

[d0k3]

Ok. I deep decrypted the original CIA and saved that. Then I encrypted it and decrypted it using deep option. Saved that with _deepdecrypted ammended to name. Then encrypted it again, then deep decrypted it a second time. Saved that file with _deepdecryptedpass2.

The two deep decrypted files MD5 match. However the original CIA which I decrypted doesn't have a matching MD5 with the two other CIAs that were passed through multiple times.

The changed offsets appear to be the same in regards to the original file that I decrypted the first time. Perhaps because this CIA was packed in a way that would just result in it always being different from the new files after passing through Decrypt9.

But the CIAs that went through the deep decryptor and CIA encryptor are the same, so the result is consistent.

I haven't had a chance to actually try installing the CIA. The app in question is BossLotcheckTool. I'm going to unpack the CXI and edit the exheader so it installs to NAND like I've been able to do with some of the other devapps. Then I'll repack the CXI like I normally do. Now this time instead of encrypting the CXI before building the CIA, I will immediately build the CIA, then use Decrypt9WIP to encrypt the CIA using the NCCH option.

Once I get around to this I'll report if this made any difference. BossLotcheckTool was one of the apps that was giving me trouble and not wanting to work from NAND so it's a good start to see if it made any difference packing the CIA with the unencrypted CXI first.

--------------------- MERGED ---------------------------

Tested this with my new attempt with the encrypt CIA options available. No change. BossLotCheckTool still crashes immediately after starting it. (boot logo never has a chance to show). I made the correct changes to the exheader. (set content type bit to 02 to make it install to NAND and set offset at 0x0d to 01 to disable the run from SD flag. Code was still compressed so used 01 in it's place)

This one may need a different method of CXI rebuild but the new CIA encryption stuff made no difference.

Since it appears to behave indentical to my previous attempt, it looks like the CIA encryption options don't make things any worse. So they appear to work and produce a valid CIA that installs correctly. It would be safe to assume that for most other normal circumstances that it would produce valid CIAs for games and such.

It's up to you if you want to keep these in the menu. It's fine if they end up not saying. The experienced users can add them back to the menu themselves if they need CIA encryption for some special reason.

Well, I'll need to think about it. My best bet is, that tool crashes because of not matching signatures and CFWs not patching sigs for system content. Don't know though. You could try other types of encryption (7x, seed, .... anything you can think of), but I doubt it would make any difference. Does that tool work from the SD?

 

[Apache Thunder]

It's known to work from SD just fine I believe. If the crash was sig related, my attempts to have DevMenu run from NAND would not have succeeded, so it's not sig related.

I was even able to get FBI to work from NAND. (though that was a radically different rebuild process. I edited the rsf it used to build the CXI/CIA during compiling from source code, so unlike retail stuff, it was a proper rebuild)

 

[Ninoh-FOX]

A stupid question... Can I converter game.cia to game.3ds with Decript9? I try this in my pc (old old pc) but brutal crash appeared!!

 

[d0k3]

A stupid question... Can I converter game.cia to game.3ds with Decript9? I try this in my pc (old old pc) but brutal crash appeared!!

Nope, not possible, and I'll never add that in. Doing that requires a multitude of advanced tools, and even then there are ways you can mess up. You'll need to try differently.

 

[Ninoh-FOX]

Nope, not possible, and I'll never add that in. Doing that requires a multitude of advanced tools, and even then there are ways you can mess up. You'll need to try differently.

Well, thanks, I finally can fix the bug from the bat script for converte cia to 3ds in os x86 XD. Now I can converter 3ds to cia in my computer. Yeah!!

 

[runetoonxx2]

CIA version?

 

[dark_samus3]

CIA version?

Read the OP

 

[Hyura]

Just wanted to say thanks for your work. Worked perfectly on my 9.2 O3DS.
Used H&S Dump and Inject and NAND backup/restore.

Thanks again @d0k3 !


edit


@d0k3 , sorry to bother you, but is there a way to Decrypt9 to restore a sysnand backup made by the Gateway Launcher?

When I tried to restore the backup Decrypt9 can't find an usable file.

And as I'm already asking, would I be able to restore a NAND backup done with Emunand9?

 

[Chuu]

Similar question as @Hyura
I made a sys-nand backup using emunand9, and i was wondering if restoring my sysnand using that would restore nnid functionality (after having used emunand for a while)
great program by the way. fbi injection works flawlessly

 

[Hyura]

Similar question as @Hyura
I made a sys-nand backup using emunand9, and i was wondering if restoring my sysnand using that would restore nnid functionality (after having used emunand for a while)
great program by the way. fbi injection works flawlessly

Do you wanna give up on CFW? Or keep using the emunand but get eShop back?

 

[d0k3]

@d0k3 , sorry to bother you, but is there a way to Decrypt9 to restore a sysnand backup made by the Gateway Launcher?

When I tried to restore the backup Decrypt9 can't find an usable file.

And as I'm already asking, would I be able to restore a NAND backup done with Emunand9?

Well, the backup is not recognized because GW dumps a wrong size backup, that is. I could enable Decrypt9 to process this backup as well, but for something as sensible as a SysNAND restore I'd rather not. Just use a hex editor to truncate your GW backup to the same size as a Decrypt9 backup and you're good to go.

Similar question as @Hyura
I made a sys-nand backup using emunand9, and i was wondering if restoring my sysnand using that would restore nnid functionality (after having used emunand for a while)
great program by the way. fbi injection works flawlessly

Do you wanna give up on CFW? Or keep using the emunand but get eShop back?

Can't help with that, I hope @Hyura can. If you made the SysNAND backup in EmuNAND9, you can restore it in Decrypt9 without trouble.

 

[Hyura]

Well, the backup is not recognized because GW dumps a wrong size backup, that is. I could enable Decrypt9 to process this backup as well, but for something as sensible as a SysNAND restore I'd rather not. Just use a hex editor to truncate your GW backup to the same size as a Decrypt9 backup and you're good to go.


Can't help with that, I hope @Hyura can. If you made the SysNAND backup in EmuNAND9, you can restore it in Decrypt9 without trouble.

At the time I did that backup the tutorial I followed suggested the Gateway Launcher as a tool for the sysnand backup. I restored it and did a new backup using Decrypt9.

I'm not sure how I'd truncate the backup, so I won't try this. As you said, it is sensible.

Thanks again.

 

[Shadowtrance]

Well, the backup is not recognized because GW dumps a wrong size backup, that is. I could enable Decrypt9 to process this backup as well, but for something as sensible as a SysNAND restore I'd rather not. Just use a hex editor to truncate your GW backup to the same size as a Decrypt9 backup and you're good to go.
Can't help with that, I hope @Hyura can. If you made the SysNAND backup in EmuNAND9, you can restore it in Decrypt9 without trouble.

FWIW there isn't any issue restoring a GW backup to sysnand, I've done it on multiple consoles multiple times before (same with emunand dump > sysnand restore). So kinda a little misinformation somewhere. GW dumps aren't technically "bad", they just dump the whole damn chip regardless of actual used space on said chip, so there's just a bunch of useless empty space at the end...

 

[d0k3]

FWIW there isn't any issue restoring a GW backup to sysnand, I've done it on multiple consoles multiple times before (same with emunand dump > sysnand restore). So kinda a little misinformation somewhere. GW dumps aren't technically "bad", they just dump the whole damn chip regardless of actual used space on said chip, so there's just a bunch of useless empty space at the end...

No, GW dumps more than the whole chip, that's the problem here. If I knew 100% for sure (for every possible console / NAND chip) the size of a GW NAND dump, I could implement this check into Decrypt9 and just process these backups. The way it is now I could only allow Decrypt9 to restore any SysNAND backup, and I'd like to keep teh file size check as a safety clamp.

And yes, you're correct, these dumps are not bad, they just contain garbage at the end. As I wrote, the problem is that bad filesize is a red flag.

 

[dark_samus3]

No, GW dumps more than the whole chip, that's the problem here. If I knew 100% for sure (for every possible console / NAND chip) the size of a GW NAND dump, I could implement this check into Decrypt9 and just process these backups. The way it is now I could only allow Decrypt9 to restore any SysNAND backup, and I'd like to keep teh file size check as a safety clamp.

And yes, you're correct, these dumps are not bad, they just contain garbage at the end. As I wrote, the problem is that bad filesize is a red flag.

Yeah, I can confirm this... I've bricked my 3ds before (it's hardmodded) and back in the early days GW launcher was one of the only ways to backup NAND, when I used dd to put it back onto the 3ds it actually ran out of space on my NAND chip, scared me a bit but the 3ds still booted fine and I couldn't find anything out of place afterwards

 

[d0k3]

Yeah there's a way to remove the nnid from the nand, i have it here somewhere in my notepad. Will have a look for it.
That nnid will be rendered useless though (not really a problem going by your post there) because they're not only linked on the console but also server side.
I've done it before on emunand and it was basically like it never existed.

--------------------- MERGED ---------------------------

Found it!
Old notes i found on here a fair while ago in some thread...

My 9.4.0 emuNAND already has NNID and you need internet/actual
fw to remove it, so i thought about a way to remove it without internet.

NNID is listed in: \data\<your unique id>\sysdata\00010038 > 00000000

It was pretty simple to do it and here it is how i did it:

1. I extracted my fat16 xorpad using launcher.dat from 3DS_Multi_Decryptor
2. Dumped emuNAND.bin using emuNANDTool
3. Extracted emunand.fat16.bin
4. xor'ed emunand.fat16.bin
5. Mounted emunand.fat16.bin.out with WinImage
6. Browsed to \data\<your unique id>\sysdata\00010038
7. Replaced 00000000 with another one i've extracted the same way that never had nnid
8. Renamed emunand.fat16.bin.out to test.bin
9. xor'ed test.bin
10. Injected test.bin.out into emunand.fat16.bin with HxD
11. Injected emunand.fat16.bin @ offset B930000 with HxD
12. Injected my new emunand.fat16.bin into my SD Card using emuNANDTool

Eh, voila, after booting into emuNAND NNID was gone :)

I could have switched out or deleted any other files i wanted,
maybe this will help your research

--------------------- MERGED ---------------------------

Don't remember if i did it on n3ds or not, pretty sure i did it on o3ds but it may still be helpful.

This has been a while, but I only just got around to trying it (with backups and all). Worked like a charm! I think I'll add dump / inject options for that file into Decrypt9, as this might be a common problem.

 

[Shadowtrance]

This has been a while, but I only just got around to trying it (with backups and all). Worked like a charm! I think I'll add dump / inject options for that file into Decrypt9, as this might be a common problem.

Cool.
Did you replace the file with another or just zero out the current one or just totally remove it? I honestly don't remember which i did way back when.

 

[d0k3]

Cool.
Did you replace the file with another or just zero out the current one or just totally remove it? I honestly don't remember which i did way back when.

I used the one from my no NNID SysNAND.

 

[d0k3]

Ok I encrypted using the NCCH option as you suggested. Then decrypted it afterwords using the deep option? Not sure if that's the decyption option you wanted me to use. The files aren't identical afterwords. However they very nearly are. I did file compare with HxD. These are the offset ranges that change afterwords:

2FA4-2FE7
38D1-38F3

Perhaps hashes or something. But the rest of the CIA are identical with each other so there's no reason for them to be different I think.

I'm not familiar with what those areas are used for in CIAs. But I'm sure you might know more about that.

Alright, I finally checked this difference, and you are right. There is actually only one byte different though, and that is the one denoting the crypto type inside the NCCH flags (all other different bytes are just hashes). Don't know if that is useful information to you, but the original version of Bosslotcheck is completely unencrypted, but the header / NCCH flags still say it uses a FixedCryptoKey (which doesn't make much sense, but I guess it has been tampered with). Hope that helps, maybe it also explains why things didn't work previously.