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

[Shadowtrance]

It's possible to make multiple xorpad with drag&drop 2 or 3 .3ds on ctrkeygen.py ?

It should be possible, yes.
Should just be able to select however many .3ds files at the same time and drag n drop on the script.

 

[Asia81]

The new decrypt9 is very fast oO
Thanks a lot

 

[Shadowtrance]

The new decrypt9 is very fast oO
Thanks a lot

Indeed it is.
No problem.

@d0k3 or anyone else looking...

A couple of options for new icon... ignore the grey background, icon starts at the purple edges. Thoughts?

I also got Uncart added but sadly something goes horribly wrong after it finishes dumping and you press B to exit back to the menu, where you should have control of the menu again but you don't.
It doesn't load the top image after exiting and bottom images don't change if you move left/right, sd space is messed up too.

Spoiler: See pic here...

 

[d0k3]

It's possible to make multiple xorpad with drag&drop 2 or 3 .3ds on ctrkeygen.py ?

Yes, that should be possible. Just try it!

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

A couple of options for new icon... ignore the grey background, icon starts at the purple edges. Thoughts?

I think both are good options, but the left one fits better with the general theme.

I also got Uncart added but sadly something goes horribly wrong after it finishes dumping and you press B to exit back to the menu, where you should have control of the menu again but you don't.
It doesn't load the top image after exiting and bottom images don't change if you move left/right, sd space is messed up too.

That might be some of uncart's ASM not playing nice with Decrypt9's. Or maybe, it is not. I'm pretty sure you compared the source files in WinMerge (or similar). Are there differences in the .S files? If so, I doubt we can fix it. If not, we might be able to find the reason.

Another possibility would be that uncart does something 'temporarily irreversable', meaning something that can only be reversed by restarting the console, same as f.e. Brahma, which doesn't allow you to return once the payload is executed.

 

[Shadowtrance]

I think both are good options, but the left one fits better with the general theme.

That might be some of uncart's ASM not playing nice with Decrypt9's. Or maybe, it is not. I'm pretty sure you compared the source files in WinMerge (or similar). Are there differences in the .S files? If so, I doubt we can fix it. If not, we might be able to find the reason.

Another possibility would be that uncart does something 'temporarily irreversable', meaning something that can only be reversed by restarting the console, same as f.e. Brahma, which doesn't allow you to return once the payload is executed.

Yeah i was thinking the first one too.

Umm the start.s from uncart is identical to the bs-start.s in decrypt9, the gw-start.s in decrypt9 is of course different seeing as it's for running from spider i guess. So I'm not sure what it is.

 

[Asia81]

https://puu.sh/iNFdw/9a41c94e43.png

best icon

 

[atkfromabove]

@atkfromabove:
Thanks a ton for all the testing! Also for doing the risky stuff . So, the current state is, everything works, but there is some trouble with ncchinfo.bin XORpad generation, correct? To be honest, I never tested that, cause I haven't changed anything except the working dir.

As for that (the working directory) - well, I already suspected that would lead to confusion. I'd like to have the Decrypt9 stuff out of sight, and that is badly needed especially when it's about hundreds of dumped system titles. Or, for the (planned) CTR decryptor - that should not process roms across the SD (as rxTools does) or even in the root folder. I think I should only use the working directory for these two options. Should be less confusing that way.

No problem. I like the Decrypt9 directory instead of everything on root. It makes my filesystem cleaner. I was able to get the xropads working once I found out the correct folder.

 

[d0k3]

No problem. I like the Decrypt9 directory instead of everything on root. It makes my filesystem cleaner. I was able to get the xropads working once I found out the correct folder.

I'm thinking about making the work directory an option. I do prefer having all out of the way and so do you, but it's almost sure that this will lead to confusion. Plus, every other software out there wants the "slot..." file, "ncchinfo.bin" file and others in the root directory.

@Shadowtrance:
I still think that how the restore NAND option is accessed in the menu is too dangerous. If there is a chance something bad happens, it will happen, and just having to press an additional button is not a good layer of security. Picture an user accidentially triggering that option, who panics and force shutdowns their 3DS. Even Roxas75 gets criticism from time to time for including the NAND restore and inject options in a submenu. Also, the NAND restore option (in my opinion) should not be used by someone who doesn't have a hardmod at all. As of now, the restore NAND option is the only really dangerous option in Decrypt9, for all others basically nothing bad can happen, even with bad input files, force shutdowns and otehr stuff users might come up with.

I'd suggest you make it 'more impossible' to trigger that option by accident. For example, by starting Decrypt9 in a 'safe mode', which the user has to actively switch to even get the NAND restore option in the menu. Or, put a disclaimer, with visual clues about danger (f.e. exclamation mark, red letters...) between the menu and the execution of the NAND restore option. Then require the user to input a key combination to continue. Or do two versions of Decrypt9, one with, one without the option.

I put some work into the ncchinfo_gen.py scripts. And, yup, ncchinfo v4 is not backwards compatible because the entries are 8 bit longer and include the titleId. It would be pretty easy to write a ncchinfo v3 -> v4 converter though. But, does that make sense? Do people really have old ncchinfo.bin files lying around that they still use to generate XORpads? Also, keep in mind that the CTRdecryptor option (once I finish that) will lead to people using the ncchinfo.bin format less anyways.

The seeddb mystery... I posted here hoping to get some people onboard for solving that (I don't think Archshift will reply on Github). I really think it should be possible to generate the seeddb.bin from nand:\data\<id>\sysdata\0001000f\00000000, but you'd have to be on a recent FW version (which I can't do) to even get that. Also, I'd like to know if that file is identical for every 3DS or if it is unique. Not a pressing issue, but knowing that you've got three 3DSs with hardmods lying around, you are one of the few persons who can find out on their own .

Last point - decryption (and encryption, of course) of TWL - I'm at it. Can't say much about yet, cause I'm still trying to figure out how to handle the different endianness of the TWL partitions. Check out the last few posts here if interested.

 

[Shadowtrance]

I'm thinking about making the work directory an option. I do prefer having all out of the way and so do you, but it's almost sure that this will lead to confusion. Plus, every other software out there wants the "slot..." file, "ncchinfo.bin" file and others in the root directory.

Yeah the work dir is a good idea, got enough crap on the root of my sd card as it is haha Just something people have to get used to it i guess.

I still think that how the restore NAND option is accessed in the menu is too dangerous. If there is a chance something bad happens, it will happen, and just having to press an additional button is not a good layer of security. Picture an user accidentially triggering that option, who panics and force shutdowns their 3DS. Even Roxas75 gets criticism from time to time for including the NAND restore and inject options in a submenu. Also, the NAND restore option (in my opinion) should not be used by someone who doesn't have a hardmod at all. As of now, the restore NAND option is the only really dangerous option in Decrypt9, for all others basically nothing bad can happen, even with bad input files, force shutdowns and otehr stuff users might come up with.

I'd suggest you make it 'more impossible' to trigger that option by accident. For example, by starting Decrypt9 in a 'safe mode', which the user has to actively switch to even get the NAND restore option in the menu. Or, put a disclaimer, with visual clues about danger (f.e. exclamation mark, red letters...) between the menu and the execution of the NAND restore option. Then require the user to input a key combination to continue. Or do two versions of Decrypt9, one with, one without the option.

Even though i personally think its just paranoia with everyone going on about nand restore options and the like, a bit of common sense goes a long way when messing with these sort of things, hard mod or no hard mod. Things like, plug it into the charger, make sure it has full charge, do you REALLY need to restore that nand backup, is it a valid backup you're trying to restore etc etc. i could go on...
But I'm sure some more checks can be put in place so even if someone IS holding UP when pressing A on nand dump option it won't accidentally restore instead of dump.

I put some work into the ncchinfo_gen.py scripts. And, yup, ncchinfo v4 is not backwards compatible because the entries are 8 bit longer and include the titleId. It would be pretty easy to write a ncchinfo v3 -> v4 converter though. But, does that make sense? Do people really have old ncchinfo.bin files lying around that they still use to generate XORpads? Also, keep in mind that the CTRdecryptor option (once I finish that) will lead to people using the ncchinfo.bin format less anyways.

Some people do yes I know i have a few from v3 ncchinfo_gen.py I've kept for certain things.

The seeddb mystery... I posted here hoping to get some people onboard for solving that (I don't think Archshift will reply on Github). I really think it should be possible to generate the seeddb.bin from nand:\data\<id>\sysdata\0001000f\00000000, but you'd have to be on a recent FW version (which I can't do) to even get that. Also, I'd like to know if that file is identical for every 3DS or if it is unique. Not a pressing issue, but knowing that you've got three 3DSs with hardmods lying around, you are one of the few persons who can find out on their own .

Yeah I've still got no idea about the seeddb thing, but I'll do some nand dumps/decryption from my 9.8 n3ds later and have a look.

Last point - decryption (and encryption, of course) of TWL - I'm at it. Can't say much about yet, cause I'm still trying to figure out how to handle the different endianness of the TWL partitions. Check out the last few posts here if interested.

Cool to see you're getting somewhere (sort of) with TWL stuff. Hopefully it can all be decrypted and we'll have full nand decryption (i think, not missing anything am i?)

 

[d0k3]

Cool to see you're getting somewhere (sort of) with TWL stuff. Hopefully it can all be decrypted and we'll have full nand decryption (i think, not missing anything am i?)

The AGBSAVE - that's the small partition between 0x0B100000 and 0x0B130000 (192kB). It contains the Gameboy Advance save and I'm unsure if it is encrypted at all. If AGB_FIRM was never started (that's the case for me), it is all 0x00 or 0xFF. Don't know if there's any use putting work in there, though.

 

[Shadowtrance]

Ah yeah, knew there was one i was missing, but yeah probably not much use adding it really. Could add it for completeness sake but that's about it i suppose.

edit: @d0k3 the nand backup / restore option is now safer. Check latest commit.

 

[key1340]

Here is some info on getting the seeddb.bin from another forum.

Where are you getting the external seed value? The game you've posted is successfully cryptofixed, yes, but it makes no sense that a "converter" would be able to remove encryption that requires sha256 + the 3ds's hardware aes engine to decrypt.

I can do the cryptofix dumping the seeddb.bin from the NAND.

Do you know where the seeddb.bin is located? I searched in my decrypted emunand backup and i can't find it

It's in NAND\data\(console exclusive)\sysdata\0001000f, the 00000000 file is the seeddb.bin

Yeah I found that file, I tried to rename it seeddb.bin and it doesn't seem to work with the last decrypt9 version. Did I miss something?

There aren't the steps. You need to use ctrKeyGen.py with the seeddb.bin renamed as 00000000.sav, after you will need to generate the xorpads via Multi Decryptor, after use xorer for decrypt the ROM and finally do cryptofix with mergerom. Despite this, I use a method envolving converting to cia.

 

[d0k3]

Ah yeah, knew there was one i was missing, but yeah probably not much use adding it really. Could add it for completeness sake but that's about it i suppose.

edit: @d0k3 the nand backup / restore option is now safer. Check latest commit.

I've seen it - much better that way! The additional input won't matter to those who actually want to use that option, and accidental triggerers will thank you for that. Do you want me to put a link into the first post to your release?

Here is some info on getting the seeddb.bin from another forum.

Where are you getting the external seed value? The game you've posted is successfully cryptofixed, yes, but it makes no sense that a "converter" would be able to remove encryption that requires sha256 + the 3ds's hardware aes engine to decrypt.

I can do the cryptofix dumping the seeddb.bin from the NAND.

Do you know where the seeddb.bin is located? I searched in my decrypted emunand backup and i can't find it

It's in NAND\data\(console exclusive)\sysdata\0001000f, the 00000000 file is the seeddb.bin

Yeah I found that file, I tried to rename it seeddb.bin and it doesn't seem to work with the last decrypt9 version. Did I miss something?

There aren't the steps. You need to use ctrKeyGen.py with the seeddb.bin renamed as 00000000.sav, after you will need to generate the xorpads via Multi Decryptor, after use xorer for decrypt the ROM and finally do cryptofix with mergerom. Despite this, I use a method envolving converting to cia.

That makes sense, somehow. Thank you! I can't test, but I'm pretty sure that puts us a step nearer to the solution.

 

[Shadowtrance]

I've seen it - much better that way! The additional input won't matter to those who actually want to use that option, and accidental triggerers will thank you for that. Do you want me to put a link into the first post to your release?
That makes sense, somehow. Thank you! I can't test, but I'm pretty sure that puts us a step nearer to the solution.

I haven't done a release yet with the latest changes, still got some UI stuff i want to make changes to. But i also got assignments to finish so that will have to wait for now.

 

[d0k3]

I haven't done a release yet with the latest changes, still got some UI stuff i want to make changes to. But i also got assignments to finish so that will have to wait for now.

No problem, that can still wait . Just let me know when to put up a link! Progress for me also has been a bit slow these last few days. Damn TWL decryption :/. I guess I'll make NCCH padgen routines backward compatible with NCCH v3, by the way. It is just a few lines of code, and perhaps a lot of people will be happier with that than with the current solution.

 

[Shadowtrance]

Yeah would be handy to have it backward compatible (if possible). Might not get used a lot but still handy.

How's the TWL stuff going anyway?

 

[d0k3]

Yeah would be handy to have it backward compatible (if possible). Might not get used a lot but still handy.

How's the TWL stuff going anyway?

I think that sums it up pretty good:
http://4dsdev.org/thread.php?pid=248#248

Decrypting the TWL NAND needs a different CTR and little endian / reversed order (everything in CTRNAND is big endian / normal order). I already have that and there's still something wrong. Either some stupid mistake I made along the way (by now, I doubt it), or I need something else, f.e. setting the KeyY manually. The proble with stuff like this is, an almost correct solution looks as bad as a completely wrong one, but that's by design for cryptography stuff :/.

 

[Aurora Wright]

I have a New 3DS (9.2), I tried to dump my title keys but with all the options, I always lack some of them for my legit DSiWare games. It just finds 8, but I have 17 or 18... I used the SDK Devmenu to check which games are missing (from their titleIDs), and it's completely random.

 

[d0k3]

I have a New 3DS (9.2), I tried to dump my title keys but with all the options, I always lack some of them for my legit DSiWare games. It just finds 8, but I have 17 or 18... I used the SDK Devmenu to check which games are missing (from their titleIDs), and it's completely random.

Thanks for the bug report! So... you tried all possible options, correct?

• Dump ticket.bin -> use FunkyCIA
• Decrypt Tiltlekeys from encTitlekeys.bin
• Decrypt Titlekeys from NAND
• (bonus option) Extract ticket.db from CTRNAND image, use FunkyCIA

And random means, different games are missing each time, even if you used the same method? Also - this only happens for DSIWare games?

I'll look into the issue. If you trust me that far (I don't know if there is any critical data in there, so no offense if you don't) you could also send me your ticket.bin or ticket.db (via PM), alongside a list with some expected but missing titles (must not be complete).

 

[d0k3]

Okay, new binary release with a ton of changes, check post #1.

Decrypt9 can now decrypt the TWLN and TWLP partitions. Alongside that there is a new 'secret' feature (not included in the binary). Also, there is a ton of various source code improvements.

Thanks go to profi200 of 4dsdev.org fame, who helped me a lot to finally figure the TWL decryption out (in fact, that means without him we wouldn't have that feature now).

@Shadowtrance and maybe @atkfromabove , I guess you know what to do with that so called 'secret feature' .

I know what you're probably itching to test right now, but alongside, this stuff would also be interesting:

• Can you try corrupting the TWLN and TWLP partitions (just fill them with random data or zeroes) and see if the 3DS still boots? (only possible via source code changes and only for people with hardmods!)
• Is the AGBSAVE correctly decrypted? If it is not, it may make sense to decrypt it as TWL (source code change in GetNandCTR() and PartitionInfo table). Cannot test myself because I don't have any data in there.
  
• The Titlekey Decrypt (NAND) option may need an additional test, checking if the titlekeys still are good. I changed a lot in there.
• Also, it would be a good thing to check if the the other partitions (firm0, firm1, ctrnand) still are correctly decrypted. That I did myself, but it is better more people test.
• Keep in mind I only have a N3DS for testing, so testing options different across the systems (like CTRNAND decryption) on O3DS makes sense.