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

[Shadowtrance]

(I know, you're thinking "What do you want next, eggs in your beer?")

Screw the eggs, i want my beer, cake AND bacon all at once!
As to the rest, I've no idea. lol

 

[Datalogger]

I'd settle for a small FTP Server added to Decrypt9.
It'd save on re-booting when generating pads n things, and it could be used to upload the launcher of choice after a emu build.
(I know that there's no way to return to HB from Decrypt9, so I think of ways to get around it.)

But I gotta say, the ability to eject the SDCard mid-stream was a brilliant idea!

I just wish the little door that covers the SD on a O3DS-XL didn't seem like it's gonna break off every time I open it.

One of these days, I'm gonna have to play a game on these 3DS's I bought.
I hear they can be used for that too..

 

[d0k3]

Is there room in a buffer to store a payload to save to the root of the SDCard, maybe an optional parameter setup before compiling? (boot.3dsx, bootrx.3dsx, Launcher.dat or ??)

What would really be the icing on the cake would be a boot payload and a small FTP server.
Then you would never need to take the card out to the 3DS after making the emuNAND

(I know, you're thinking "What do you want next, eggs in your beer?")

Actually, we don't need a buffer for that cause several parts of the SD stay untouched. And this isn't a bad idea at all. I think it's best to let the user decide what to copy. Maybe use a file called start.3dsx for that, which gets renamed to boot.3dsx and copied to the SD root? You won't be able to avoid taking the SD out completely, though, as FTP is too slow for big files.

EDIT1: I just realized, there's a problem if we only allow taking over one file. We could, for example, use FTbrony, put that in the root and call it boot.3DSX. Upon starting *hax, it would get loaded. But for wifi access, the HBL has to be started first, ftBrony can't handle this on it's own. So... I wonder, is there any one file setup that would make sense? Maybe some special version of ftBrony that properly handles wifi? Using multiple files would be a lot more complicated than one, plus we would loose flexibility

EDIT2: You also suggested a FTP server in Decrypt9. Wouldn't work though. Because Decrypt9 runs on ARM9, we have no access to ctrulib, which would otherwise handle wifi access. Also, wifi in the 3DS doesn't even always work reliably under normal circumstances, and with the exploit things don't get better. So, I'd say, it is not possible.

 

[d0k3]

Thinking this through some more (and I hope you read my edited post above), I think one option would be a self extracting archive 3DSX, that would contain a base installation of HBL with at least ftBrony included. Size constraint would be around 1MB (I think that should be enough). And I'm unsure if we get compression working.

A self contained FTP server would be better, though. Maybe you've got some more ideas

 

[Jow Banks]

if i deep decrypt a cia file - make a couple of edits - what tool would be best to re-encrypt it back?
i remember a cia encrypter in a version a while ago, but i dont see it any more.

 

[d0k3]

if i deep decrypt a cia file - make a couple of edits - what tool would be best to re-encrypt it back?
i remember a cia encrypter in a version a while ago, but i dont see it any more.

Decrypt9 can reencrypt CIAs, but there is currently no menu entry for this feature because there is no known use for it. Why do you need this feature?

Edit: if this is about Gateway compatibility, you should simply use the CIA Decryptor (for GW) feature.

 

[TVL]

I'm using Decrypt9 UI, works great if I start it from sysNAND. Can't get it to work from emuNAND, it just gives me two red flashes and back to HBL. I have the latest version. Haven't read through the whole thread so maybe I've missed something?

 

[Shadowtrance]

I'm using Decrypt9 UI, works great if I start it from sysNAND. Can't get it to work from emuNAND, it just gives me two red flashes and back to HBL. I have the latest version. Haven't read through the whole thread so maybe I've missed something?

You haven't missed anything. If you try start it from HBL started from emunand it simply won't work and will do what you've described due to things it requires to run being patched above 9.2.

 

[TVL]

You haven't missed anything. If you try start it from HBL started from emunand it simply won't work and will do what you've described due to things it requires to run being patched above 9.2.

My emuNAND is the same version as my sysNAND. 9.0.0.20-EUR. Is there no way for me to start it from emuNAND then?

 

[Shadowtrance]

My emuNAND is the same version as my sysNAND. 9.0.0.20-EUR. Is there no way for me to start it from emuNAND then?

There is, you can use the new HBL loader cia that was released to load HBL from emunand and run it from there, but there's no need to run it from emunand really.
No idea if it will work or not even if your emunand is the same version as sysnand.
https://github.com/yellows8/hblauncher_loader

 

[TVL]

There is, you can use the new HBL loader cia that was released to load HBL from emunand and run it from there, but there's no need to run it from emunand really.
No idea if it will work or not even if your emunand is the same version as sysnand.
https://github.com/yellows8/hblauncher_loader

I've tried that, gives me the two red flashes. My only reason to run it from emuNAND is because I want to direct boot to emuNAND without any bootmanager, and the only time I use HBL is to run your program (pretty much), not a huge hassle to do it the way I already have it set up and running though. Thanks for the quick replies.

 

[d0k3]

Also, hate to be the bearer of more issues, but the "Gateway User Manual" fix does not work with other region .CIA files.

It has been reported and confirmed that newer Japan and Europe region .CIA files still will not load in Gateways even after being Decrypt9 "Deep" or "GW" fixed.

They still crash at 99% when trying to add the User Manual using a Gateway (using both FBI and dEVmEn)

The same exact .CIA files DO load just fine in any CFW....only Gateway has a problem loading them.

I still think the best fix for GATEWAY's SCREW-UP is to have a function that completely removes the User Manual for Gateway users.

Since CFW users can use the Manuals with no problems (SKY3DS, reiNAND, rxTools, Cakes, and all other properly working CFW), there is still a need for an easy way to either leave the User Manual or to completely strip it out of the ROM for the unfortunate ones using the flawed Gateway's that cannot read a properly decrypted User Manual.

Now, about the GW user manual fix - do you mean out of region CIAs? Meaning you tested it on a US 3DS console? If so, I'm pretty sure you also applied a region fix somewhere, and maybe even a FW spoof, correct? Well, that might have changed the manual as well, thus breaking the compatibility (cause emanual sigs are broken then). The function in Decrypt9 should actually be working well, but it can't fix what other tools have already broken . I think the best place for an actual 'removement' fix would be Riku's converter (I'm sure you used that). Riku's tool should also be the one responsible for any modifications on content 1, content 2, ..., so the GW fix should be right at home there, and also easy to add. I'm unsure if Riku would still be willing to put more work into that converter, though, but asking can't hurt. I myself am somewhat averse to the idea of actually irreversibly removing data in Decrypt9. I'm not averse to doing this in an external tool, though. Maybe there's also some way to just 'disarm' these contents, so they are still in there but not installed when installing via GW.

@Datalogger can you give me some more info about this? I might already have an idea for a 'minimal-invasive' fix. I still think that Riku should take care of of this.

So @d0k3 any idea why the debug_bg and unmount images aren't working yet? (I'm only using placeholders of the same size (one for top and one for bottom screen) at the moment, so doesn't really matter what you use to test).

Sorry, missed this earlier. Can you give me your work-in-progress version so that I can have a look? At the moment I am clueless.

I've tried that, gives me the two red flashes. My only reason to run it from emuNAND is because I want to direct boot to emuNAND without any bootmanager, and the only time I use HBL is to run your program (pretty much), not a huge hassle to do it the way I already have it set up and running though. Thanks for the quick replies.

Just use CTR Boot Manager with autoboot (delay = 0). That way CTR Boot Manager will only show up when pressing a button (you decide which), and otherwise you can boot directly to EmuNAND. Decrypt9 runs directly from CTR Boot Manager, so that should be the best option.

 

[TVL]

Just use CTR Boot Manager with autoboot (delay = 0). That way CTR Boot Manager will only show up when pressing a button (you decide which), and otherwise you can boot directly to EmuNAND. Decrypt9 runs directly from CTR Boot Manager, so that should be the best option.

I overlooked that one because I didn't want to be greeted by a choice every boot, and some other boot manager I tried lowered the successrate of boots, not by a lot but enough. Now though it's better than I figured it could be, thanks!

 

[d0k3]

I've got something new for you to play with:
https://github.com/d0k3/ZIP3DSFX

This is used to create self extracting, ZIP-based archives in .3DSX format. And yes, it can overwrite itself. Meaning: In theory, you could make an SFX archive from Smealums homebrew starter pack, call the file boot.3dsx and put that into the root of your SD card. Upon running the *hax exploit, all the contents of boot.3dsx would get extracted, boot.3dsx itself being overwritten with the boot.3dsx containing the homebrew launcher. Then, you push a button and get booted directly into homebrew launcher. Great, isn't it?

I say in theory, cause this is still untested with large files, and if we want to automate the process of setting up a new EmuNAND in Decrypt9, we would have a limit of ~1MB for the data we could take over to the formatted SD card (which is not enough for the whole homebrew pack).

With ZIP3DSFX we could now start putting together a specialized Decrypt9 starterpack. This is a list of software that I think would be nice to have in there, roughly in order of importance:

• Homebrew Launcher or CTR Boot Manager
• ftBrony or alternative / derivative
• BrahmaLoader & Decrypt9 (use Decrypt9.bin, load with BrahmaLoader to save memory)
• ThemeHax Manager
• HANS
• CTRXplorer
• eShop HANS shortcut
• OOT3DS sploit installer

Opinions might differ, of course .

 

[Deleted member 356526]

I've got something new for you to play with:
https://github.com/d0k3/ZIP3DSFX

This is used to create self extracting, ZIB-based archives in .3DSX format. And yes, it can overwrite itself. Meaning: In theory, you could make an SFX archive from Smealums homebrew starter pack, call the file boot.3dsx and put that into the root of your SD card. Upon running the *hax exploit, all the contents of boot.3dsx would get extracted, boot.3dsx itself being overwritten with the boot.3dsx containing the homebrew launcher. Then, you push a button and get booted directly into homebrew launcher. Great, isn't it?

I say in theory, cause this is still untested with large files, and if we want to automate the process of setting up a new EmuNAND in Decrypt9, we would have a limit of ~1MB for the data we could take over to the formatted SD card (which is not enough for the whole homebrew pack).

With ZIP3DSFX we could now start putting together a specialized Decrypt9 starterpack. This is a list of software that I think would be nice to have in there, roughly in order of importance:

• Homebrew Launcher or CTR Boot Manager
• ftBrony or alternative / derivative
• BrahmaLoader & Decrypt9 (use Decrypt9.bin, load with BrahmaLoader to save memory)
• ThemeHax Manager
• HANS
• CTRXplorer
• eShop HANS shortcut
• OOT3DS sploit installer

Opinions might differ, of course .

holy crap.

 

[dark_samus3]

I've got something new for you to play with:
https://github.com/d0k3/ZIP3DSFX

This is used to create self extracting, ZIP-based archives in .3DSX format. And yes, it can overwrite itself. Meaning: In theory, you could make an SFX archive from Smealums homebrew starter pack, call the file boot.3dsx and put that into the root of your SD card. Upon running the *hax exploit, all the contents of boot.3dsx would get extracted, boot.3dsx itself being overwritten with the boot.3dsx containing the homebrew launcher. Then, you push a button and get booted directly into homebrew launcher. Great, isn't it?

I say in theory, cause this is still untested with large files, and if we want to automate the process of setting up a new EmuNAND in Decrypt9, we would have a limit of ~1MB for the data we could take over to the formatted SD card (which is not enough for the whole homebrew pack).

With ZIP3DSFX we could now start putting together a specialized Decrypt9 starterpack. This is a list of software that I think would be nice to have in there, roughly in order of importance:

• Homebrew Launcher or CTR Boot Manager
• ftBrony or alternative / derivative
• BrahmaLoader & Decrypt9 (use Decrypt9.bin, load with BrahmaLoader to save memory)
• ThemeHax Manager
• HANS
• CTRXplorer
• eShop HANS shortcut
• OOT3DS sploit installer

Opinions might differ, of course .

Now THAT is awesome... Can it do something other than just .3dsx (for example a cakes.dat payload in the root along with everything in the cakes folder)?

Also will it just be a premade one or will the user be able to back up any files they'd want with a space limit based on how big their card is?

EDIT: OK so I reread this, and I see better what it is.... I still think users should be able to pick what they want, provided it fits ofc

 

[d0k3]

Now THAT is awesome... Can it do something other than just .3dsx (for example a cakes.dat payload in the root along with everything in the cakes folder)?

Also will it just be a premade one or will the user be able to back up any files they'd want with a space limit based on how big their card is?

EDIT: OK so I reread this, and I see better what it is.... I still think users should be able to pick what they want, provided it fits ofc

It is easy to make your own, but you have to be able to compile. Meaning: Of course you can also use this to setup a CFW. I could also change this to not require a recompile, but as this would be quite a lot of work I think it would not be worth it. The main idea behind this is to give the user basic access (FTP access, f.e.) right away. Realistically speaking, there is no way a full setup (CIAs etc) can't be fully automated anyways.

 

[dark_samus3]

It is easy to make your own, but you have to be able to compile. Meaning: Of course you can also use this to setup a CFW. I could also change this to not require a recompile, but as this would be quite a lot of work I think it would not be worth it. The main idea behind this is to give the user basic access (FTP access, f.e.) right away. Realistically speaking, there is no way a full setup (CIAs etc) can't be fully automated anyways.

I did see somewhere awhile ago that you could include files right in the .3dsx by just zipping up a zip file and melding the two files together... with the copy function on windows and cat on linux (copy /b file1.3dsx+file2.zip output.3dsx for windows (this may be incorrect) and cat file1.3dsx file2.zip > output.3dsx for linux) maybe you could do it that way? Basically have the unzip function in the file1.3dsx and whatever you want in file2.zip (size limited ofc) then the output.3dsx is on the card

 

[Shadowtrance]

Sorry, missed this earlier. Can you give me your work-in-progress version so that I can have a look? At the moment I am clueless.

Check PM. I have no idea why it isn't working for those 2 images either...

 

[d0k3]

I did see somewhere awhile ago that you could include files right in the .3dsx by just zipping up a zip file and melding the two files together... with the copy function on windows and cat on linux (copy /b file1.3dsx+file2.zip output.3dsx for windows (this may be incorrect) and cat file1.3dsx file2.zip > output.3dsx for linux) maybe you could do it that way? Basically have the unzip function in the file1.3dsx and whatever you want in file2.zip (size limited ofc) then the output.3dsx is on the card

Show me an example! And yes, the way you described it is the way a self extracting archive normally works, but it doesn't work that way with 3DSX. One of the problems with that is that there is no simple, always working way for an executable to find out it's own name with 3DSX.