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

[d0k3]

Tested some more and it looks like everything is fine with the NAND dumping function. It may even be better than GWs alternative, cause that dumped garbage after the actual NAND dump. I still want to test some more and add additional features before the release.

In the meantime, if you want to help me, I don't exactly understand what these functions of rxTools do:

• Decrypt CTR Titles
• Decrypt Title Keys
• Dump Tickets (it does not do what I assumed at first, namely copying a file from the FAT16 partition)
• Scan System Titles

If you could, explain these to me, that would help a lot.

I understand what these do:

• Create NAND dump
• Decrypt partitions
• Generate fat16 Xorpad
• Generate Xorpads

Did I forget about any rxTools fucntionality?

Also, @Shadowtrance, are you interested in testing the NAND dumper? I could provide the code to you.

 

[Asia81]

@d0k3 : Decrypt CTR Titles is... decrypt a .3DS rom
It means that your xorpads are useless.

ctrtool -p --exheader=DecryptedExHeader.bin %Nom%.3ds
ctrtool -p --exefs=DecryptedExeFS.bin %Nom%.3ds
ctrtool -p --romfs=DecryptedRomFS.bin %Nom%.3ds
ctrtool.exe -t romfs --romfsdir=./romfs DecryptedRomFS.bin

You can extract a partition from the game and extract datas immediately

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

He decrypt the partiton inside the rom herself, instead of using xor, padxorer... for decrypt romfs, exefs...

 

[DJPlayer]

@d0k3 : Decrypt CTR Titles is... decrypt a .3DS rom
It means that your xorpads are useless.

ctrtool -p --exheader=DecryptedExHeader.bin %Nom%.3ds
ctrtool -p --exefs=DecryptedExeFS.bin %Nom%.3ds
ctrtool -p --romfs=DecryptedRomFS.bin %Nom%.3ds
ctrtool.exe -t romfs --romfsdir=./romfs DecryptedRomFS.bin

You can extract a partition from the game and extract datas immediately

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

He decrypt the partiton inside the rom herself, instead of using xor, padxorer... for decrypt romfs, exefs...

Would love to see a feature like this!

 

[d0k3]

@d0k3 : Decrypt CTR Titles is... decrypt a .3DS rom
It means that your xorpads are useless.

ctrtool -p --exheader=DecryptedExHeader.bin %Nom%.3ds
ctrtool -p --exefs=DecryptedExeFS.bin %Nom%.3ds
ctrtool -p --romfs=DecryptedRomFS.bin %Nom%.3ds
ctrtool.exe -t romfs --romfsdir=./romfs DecryptedRomFS.bin

You can extract a partition from the game and extract datas immediately

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

He decrypt the partiton inside the rom herself, instead of using xor, padxorer... for decrypt romfs, exefs...

Useless is a a pretty strong word . Xorpads are also used for NAND decryption (yeah, I know, we can do that from rxTools, too) and to extract theme packs.

From what I saw, rxTools processes the rom files directly, meaning the encrypted versions get overwritten with the unencrypted versions. And it searches across the whole SD card... guess it is better to limit this to one folder.

Also, what can we do with decrypted roms and what about the other options I listed?

 

[DJPlayer]

Useless is a a pretty strong word . Xorpads are also used for NAND decryption (yeah, I know, we can do that from rxTools, too) and to extract theme packs.

From what I saw, rxTools processes the rom files directly, meaning the encrypted versions get overwritten with the unencrypted versions. And it searches across the whole SD card... guess it is better to limit this to one folder.

Also, what can we do with decrypted roms and what about the other options I listed?

We can convert them to cia without need the xorpads for it.
We can extract the decrypted files from romfs and exefs, too without xorpads.

 

[Shadowtrance]

Tested some more and it looks like everything is fine with the NAND dumping function. It may even be better than GWs alternative, cause that dumped garbage after the actual NAND dump. I still want to test some more and add additional features before the release.

Also, @Shadowtrance, are you interested in testing the NAND dumper? I could provide the code to you.

Yeah I'll do some testing with the nand dumper (and any other stuff you add), been keeping an eye on your git page
Edit: Added nand dumper to my local test copy, and testing at the moment on my n3ds and o3ds XL.

Seems to be working good, nand size appears to be detected right, 943 MB for the old xl (which matches the size i get from gateway and hard mod dumps), n3ds detects at 1240 MB (my other n3ds dumps are 1.8gb) which i assume is correct (pretty sure only 1.2gb is used on n3ds regardless of nand type (toshiba 1.8gb / samsung 1.2gb).
Will see if all is good once dumping is finished and i decrypt them, it's pretty fast.
Edit2: @d0k3 it works a treat. and without the extra 600 MB of garbage that gateway/hard mod dumps (on my n3ds)

 

[d0k3]

Yeah I'll do some testing with the nand dumper (and any other stuff you add), been keeping an eye on your git page
Edit: Added nand dumper to my local test copy, and testing at the moment on my n3ds and o3ds XL.

Seems to be working good, nand size appears to be detected right, 943 MB for the old xl (which matches the size i get from gateway and hard mod dumps), n3ds detects at 1240 MB (my other n3ds dumps are 1.8gb) which i assume is correct (pretty sure only 1.2gb is used on n3ds regardless of nand type (toshiba 1.8gb / samsung 1.2gb).
Will see if all is good once dumping is finished and i decrypt them, it's pretty fast.
Edit2: @d0k3 it works a treat. and without the extra 600 MB of garbage that gateway/hard mod dumps (on my n3ds)

You may incorporate the NAND dumper into the bootstrap-mod if you want to. Or just wait for a bit, because I think new features will come pretty fast now. It should also not be to complicated to pair this with your design, as all my changes affect only the internal stuff.

 

[Shadowtrance]

Already added it earlier
Was thinking of doing a UI redesign anyway so that's no problem with new stuff being added, not sure what I'll do or when but I've thought about it. haha

 

[d0k3]

Already added it earlier
Was thinking of doing a UI redesign anyway so that's no problem with new stuff being added, not sure what I'll do or when but I've thought about it. haha

I know, the output right now is ugly as hell, but I'd wait with skinning that. From four main features we will now go to eight (if everything works as planned) and I'm unsure about where to fit these now. I also plan to improve the on screen messages and make that more consistent. I may start using the bottom screen for that, so that we can display stuff even before the user has made a selection.

 

[Shadowtrance]

I wouldn't say it's ugly as hell, could look a lot nicer though.
What other things were you looking to add?

 

[d0k3]

I wouldn't say it's ugly as hell, could look a lot nicer though.
What other things were you looking to add?

Basically everything that rxTools has (but not EmuNAND, cause I don't have the knowledge to port that). If you took a look at my current source code, next is on-the-fly dumping & decryption of NAND partitions, and there is already a stub for that in there. I'm also improving the coding as I go, cause just copy and paste will not work. I still need to understand what some of the rxTools features do. And, I'm unsure wether I forgot some rxTools features - I never tried rxTools myself, all my knowledge I have about that is from the source code.

I'm also open for feature requests beyound rxTools functionality, if you have an idea. rxTools features go first, though. I thought about adding a cart dumper (to make the GW launcher completely useless, ), but I'm missing code examples for that.

 

[hippy dave]

I thought about adding a cart dumper (to make the GW launcher completely useless, ), but I'm missing code examples for that.

uncart is open source isn't it?

 

[d0k3]

uncart is open source isn't it?

Yeah,I'll look into that. First things first.

 

[neobrain]

uncart is open source isn't it?

It very much is indeed: https://github.com/citra-emu/uncart

 

[d0k3]

... And, more progress! We can now dump decrypted NAND partitions. For the FAT CTRNAND partition the results look good and work in osfmount. For FIRM0 and FIRM1, it looks good in a hex editor, but I don't know how to properly verify them. They are not completely identical with each other (shouldn't they be?).

For everyone who wants to test, here's my GitHub repo:
https://github.com/d0k3/CTRXtools
No compiled executables for the masses yet, so no need to look.

Now, we're out of legitimate buttons (I don't want to include arrows), so I have to think about how to continue with the interface. Dumping decrypted partitions opens up a ton of possibilities, so we need room.

 

[neobrain]

Fyi, it would be great if you tried to submit your changes as PRs to decrypt9 instead of forking the project under a different name. The latter is not what we intend to achieve by releasing our work along with the source code, and it's not particularly helpful to have 20 forks of the same thing, all of which have slightly different features, either.

 

[d0k3]

Fyi, it would be great if you tried to submit your changes as PRs to decrypt9 instead of forking the project under a different name. The latter is not what we intend to achieve by releasing our work along with the source code, and it's not particularly helpful to have 20 forks of the same thing, all of which have slightly different features, either.

Yes, that's what I thought, too, and I'd very much prefer to work on that together. But my changes are pretty extensive. For example, Archshift already declined the pull request with the Brahma Loader included. Now, I had to move all the feature functions into one C file, and I'm not sure if Archshift would be too happy to accept such a change from one rather unknown developer.

I can't properly maintain two forks (one with, one without the loader), so I have to go on for myself for now. Archshift mentioned the Brahma Loader would be acceptable if it was included as submodule, but that I'm not capable of. I'll try to feed my changes and additional features back to the project once I got somewhere, though.

About the name. Well, that's difficult. It is a fork of Decrypt9, but roxas75 could be as unhappy that it is not called rxTools, with all of his work getting ported in there. I'd never claim the code to be my own, though. And also, note that it is not yet released under that name.

The go on for myself part is up for discussion, of course. In fact, I'd be more than happy if you found a solution that enabled us to work together on Decrypt9.

 

[d0k3]

Oh well, I just noticed @Roxas75 just updated rxTools to v2.5 and included (still unstable) Ninjhax support via Brahma. I guess we really need to think about how to proceed now. My goals are mainly to give Ninjhax users access to rxTools and Decrypt9 functions and to beautify the Decrypt9 UI and improve the existing code along the way.

If I proceed on my own now, several people will work on the same stuff with similar results, and we make much less progress than would be possible. Care to discuss, @neobrain and (maybe) @Archshift ?

 

[Asia81]

Oh well, I just noticed @Roxas75 just updated rxTools to v2.5 and included (still unstable) Ninjhax support via Brahma. I guess we really need to think about how to proceed now. My goals are mainly to give Ninjhax users access to rxTools and Decrypt9 functions and to beautify the Decrypt9 UI and improve the existing code along the way.

If I proceed on my own now, several people will work on the same stuff with similar results, and we make much less progress than would be possible. Care to discuss, @neobrain and (maybe) @Archshift ?

now decrypt9 is only useful for n3ds users, like me

 

[d0k3]

now decrypt9 is only useful for n3ds users, like me

Well, in fact rewriting code such as Decrypt9 or rxTools doesn't require many changes to include N3DS support (EmuNAND is a special case, though, that's different). Also rxTools is still unstable on Ninjhax. The problem is more or less, several people working on the same stuff because some details are difficult to agree upon (such as the Brahma Loader). Archshifts stance on that is correct for what he tries to achieve, and so is mine for what I'm trying to achieve.