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

  • Thread starter Thread starter d0k3
  • Start date Start date
  • Views Views 935,203
  • Replies Replies 4,476
  • Likes Likes 71
@Shadowtrance @d0k3

I think one of you 2 have failed the latest release.
I downloaded the latest release in your github, but the binary file (3dsx and sdmh) files are from the 2015-06-26.
It's the older version with just the white text on black screen.

Could you reupload an updated binary ?
 
  • Like
Reactions: d0k3
@Shadowtrance @d0k3

I think one of you 2 have failed the latest release.
I downloaded the latest release in your github, but the binary file (3dsx and sdmh) files are from the 2015-06-26.
It's the older version with just the white text on black screen.

Could you reupload an updated binary ?
My releases with the menu and d0k3's releases are seperate.
But anyway, the link to my releases is here... https://github.com/Shadowtrance/Decrypt9/releases which is up to date with the latest changes.
 
Why not make only one release profile ?
That's a good question, that i don't really have an answer to. haha
Either way, mine is up to date with any changes made by d0k3 pretty much as soon they happen.
I guess just remember my link if you want to use the "pretty" menu version instead of the simple menu version. :)
 
Because if a people want download Decrypt9, he can ask the question:
Should I download on @Shadowtrance profile ? Or @d0k3 profile ? And why ?

I use the d0k3 github release because it's the first release link that I seen
 
Well like i said, basically the only difference is the menu look. So i guess people have a choice, some may not like the graphical menu version and like the simple menu version instead.
So for now at least there's a choice people can make.
 
  • Like
Reactions: klear
Why not make only one release profile ?
That's a good question, that i don't really have an answer to. haha
Either way, mine is up to date with any changes made by d0k3 pretty much as soon they happen.
I guess just remember my link if you want to use the "pretty" menu version instead of the simple menu version. :)
Because if a people want download Decrypt9, he can ask the question:
Should I download on @Shadowtrance profile ? Or @d0k3 profile ? And why ?

I use the d0k3 github release because it's the first release link that I seen

I guess I messed up that release :). I want to fix some stuff first, then I'll do a new release later today.

So, why not one release profile? Because of work in progress ;). I want to have one 'combined source code' later, but I also want to contribute my changes back to Archshifts repo, who is a bit picky about pull requests, especially the fancy stuff (I know that's his good right with his own project and that's not meant as criticism). For example, Archshift declined the PR with the Brahma loader, but everyone in here (including me) wants the Brahma loader. Even with contributing back to Archshift, our version may be different (design-wise, the features will be the same) from Archshifts in the end.

Also, Shadowtrance enables the dangerous stuff (NAND restore and NAND injection, but he has security measures in place against accidentially triggering them), while I do not.

I see that having two releases to choose from is not the best thing for users, though. We will work towards one version, but at the moment you will need to bear with how things are now.

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

By the way, two things...
  1. The AGBSAVE decryption seems to be correct. @Aurora Wright and profi200 (of 4dsdev.org fame) say so.
  2. Has anyone already tested injection? On TWLN or CTRNAND?
 
  • Like
Reactions: kactusss
By the way, two things...
  1. The AGBSAVE decryption seems to be correct. @Aurora Wright and profi200 (of 4dsdev.org fame) say so.
  2. Has anyone already tested injection? On TWLN or CTRNAND?
TWLN I've confirmed myself works, modified it after dumping (injected sudoku-hax into ds-dlp) and reinjected the partition again no problem. I'm sure others have done that as well.
One thing i think would be good (and i think others may have brought it up too), is an option to select which partition to dump and/or inject rather than doing all at once. Not sure how hard that'd be to implement though.
 
One thing i think would be good (and i think others may have brought it up too), is an option to select which partition to dump and/or inject rather than doing all at once. Not sure how hard that'd be to implement though.

That would be harder for you than it would be for me, as the best option to do that would be additional menu entries ;). I'm looking into it, but fixing the titlekey stuff is first.

As for that, I have a suggestion (for the internal coding of your menu system): why not use a struct as base (same as I do)? You wouldn't have to repeat the same code with minor changes over and over, and adding more stuff later / changing existing stuff would be a lot less work.
 
That would be harder for you than it would be for me, as the best option to do that would be additional menu entries ;). I'm looking into it, but fixing the titlekey stuff is first.

As for that, I have a suggestion (for the internal coding of your menu system): why not use a struct as base (same as I do)? You wouldn't have to repeat the same code with minor changes over and over, and adding more stuff later / changing existing stuff would be a lot less work.
Well to be honest i just started with an example i had that worked and went from there. :) But yeah you've got a point, a lot of repeating stuff in there.
 
It's possible to add the SD Padgen for EmuNand ?
I have a question about that, as I still have not fully understood it... What stuff does this actually generate xorpads for and what is the use? Do we need to extract the movable.sed from out own CTRNAND (ie. is it console-unique)? And is movable.sed even needed? And how to get the SDinfo.bin?

I'm thinking about automating this as well (so you won't need to use your PC for that decryption). The python script sdinfo_gen.py seems simple enough to port it into Decrypt9.

Also, about the EmuNAND stuff - I guess that would be quite simple to add, and I mean not only for the SDinfo option. I'll consider that later.
 
I have a question about that, as I still have not fully understood it... What stuff does this actually generate xorpads for and what is the use? Do we need to extract the movable.sed from out own CTRNAND (ie. is it console-unique)? And is movable.sed even needed? And how to get the SDinfo.bin?

I'm thinking about automating this as well (so you won't need to use your PC for that decryption). The python script sdinfo_gen.py seems simple enough to port it into Decrypt9.

Also, about the EmuNAND stuff - I guess that would be quite simple to add, and I mean not only for the SDinfo option. I'll consider that later.
SDInfo generates xorpads for stuff already installed. moveable.sed, I've never had to use it for the sdinfo option, not sure why it's there.
And to get the SDinfo.bin, you run the SDinfo_gen.py, for eg like this.... sdinfo_gen.py "X:/Nintendo 3DS/xxxxxxxx/xxxxxxxx/" which weill generate the SDinfo.bin from the folders on your sd card.... replace xxxxxxxx/xxxxxxxx/ with the "long random id number of folders" inside the nintendo 3ds folder.
Hope that makes sense? haha
 
SDInfo generates xorpads for stuff already installed. moveable.sed, I've never had to use it for the sdinfo option, not sure why it's there.
And to get the SDinfo.bin, you run the SDinfo_gen.py, for eg like this.... sdinfo_gen.py "X:/Nintendo 3DS/xxxxxxxx/xxxxxxxx/" which weill generate the SDinfo.bin from the folders on your sd card.... replace xxxxxxxx/xxxxxxxx/ with the "long random id number of folders" inside the nintendo 3ds folder.
Hope that makes sense? haha
Yup, I think I got it. But I don't know if it makes sense to do anything for that stuff. These are CTR titles, correct? In that case the coming up CTR decryptor will handle it. By the way, check the first post, I added links to your fork.

@everyone:
I made new binary release. This now dumps the full ticket.db and with that, the NAND Titlekey Decryptor should also be fixed for those of you that had problems earlier. The launcher.dat is also possibly fixed, but I can't test. Also, for those of you that use the dangerous stuff, the #define is now in common.h.
 
If rxTools got the ability to inject Sudokuhax over the DS Internet DSi app (the app launched from system settings that normally configures DS mode internet), one could use that to launch MSET ROP installer. In theory when you exit it, it will return right back to System Settings. ;)
 
d0k3 you should help add the TWL stuff to rxTools. :D

Is the FS and crypto libs compatible with rxTools?
I only had to make a few changes to the crypto lib, but these might require a lot of changes in the rxTools source code. If you compare those in WinMerge, porting shouldn't be all that complicated. For the FS lib, roxas75 did a lot of changes there, but that should not matter that much. The real knowledge, though, lies in decryptor.c, in the PartitionInfo table and, of course, in the NAND partition dumper functions. Just copy and paste will not work, but it should be possible to port it over relatively painless.

I'm pretty sure @Roxas75 has already seen this btw, and might port it himself. He even left a comment in his own source code (it's in there since 2.4) that he intends to properly decrypt the TWL partitions.
 

Site & Scene News

Popular threads in this forum