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

[dark_samus3]

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.

Well we'd name it boot.3dsx ofc, and I really wish I could.... I've only heard if it I haven't seen any examples or anything like that, though I also would absolutely love to see how it worked

 

[d0k3]

Well we'd name it boot.3dsx ofc, and I really wish I could.... I've only heard if it I haven't seen any examples or anything like that, though I also would absolutely love to see how it worked

If we'd auto assume the name is boot.3dsx, we'd go from a very flexible tool (although somewhat diffcult to set up for some) to one with a very narrow use case spectrum (and still not for noobs). For example, the way it is now, you could also use this tool to send installation packages (f.e. for CFWs) to your 3DS by using 3DSLink (Button Y in HBL), which would be executed and installed right away. This would easily beat the crap out of any FTP client for ease of use.

EDIT: The above is not completely correct atm, because the extract root dir is the dir the ZIP3DSFX.3dsx resides in (at least for *hax 2.x). I can easily fix that, though.

BTW, the name of the application is the first start parameter, normally (this holds true on Linux and Windows). For 3DS, that holds true only when ran directly via HBL 2.5 or Mashers Grid launcher. It doesn't hold true for 3DSLink, CTR Boot Manager, older HBL versions and the state is unsure if ran directly from a *hax (boot.3dsx). For those other cases it can't even be safely determined IF there is a start parameter and it might crash (I already went through the touble of testing with the BrahmaLoader project). I don't know about the other methods, but I guess you see where this is going.

 

[Datalogger]

@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.

Riku isn't interested in fixing his way of creating .CIA, where every file created is icon.bin 0x2018 offset 0x7fffffff RegionFree ...<snip>

Also, the problem of not being able to "fix" the User Manual problem occurs on true RegionFree Games too (any Game Serial ending in "A", like CTR-N-JFJA)
They have the same issue with the Manuals as do RegionFixed games.

I know you have cooler things to take up your time than messing with lowly user Manual crashes, so no worries if you don't want to look into this now.


Edit: Oh yeah, one more little thing that does needs your expertise to look at.
If I create a decTitleKeys_emu.bin and a ticket_emu.db from Decrypt9WIP, the decTitleKeys_enu.bin is missing the last key in the set.

Example:
If I create a encTitleKeys.bin from the ticket_emu.db using dumpTicketKeys.py, then use decrypt9wip to create a new decTitleKeys.db, it is one key longer.

Also, since I'm being my usual pita today, is there any way to enable the clock for file timestamps while in ARM9, or was this already asked/answered and I missed it?

Any thoughts on this?

 

[Asia81]

Opening /D9Game ...
Processing CIA "2.cia"
Probably not a CIA file
Failed!
Processing CIA "1.cia"
Probably not a CIA file
Failed!
CIA Decryptor (shallow): failed!

Press B to return, START to reboot.

Opening /D9Game ...
Processing CIA "2.cia"
Probably not a CIA file
Failed!
Processing CIA "1.cia"
Probably not a CIA file
Failed!
CIA Decryptor (deep): failed!

Press B to return, START to reboot.

Wait, what ?

 

[Datalogger]

Wait, what ?

Does PackHack open these same .CIA, and what are they?

 

[Asia81]

It's 2 VC Games (NES). (made with 3DS Simple CIA converter)

 

[dark_samus3]

It's 2 VC Games (NES). (made with 3DS Simple CIA converter)

How are you using simple CIA converter (which converts only .3ds files into .CIA files) to make VC titles?

 

[zoogie]

@d0k3 , just want to throw this out there: do you think decrypting DSi TADs (sd exports) is possible with decrypt9?
It's a feature I've always wanted - thought I'd take a chance and ask. Don't mind me if it's any big trouble, you've accomplished a hell of a lot already. This would just be icing on the cake. : ) Thanks.

 

[d0k3]

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

Well, Decrypt9 tried to load the unmount GFX after the SD card was unmounted, and the debug background GFX was loaded before the screen was cleared. Now, why didn't this work? Anyways, I already fixed it in my Github, just take over my changes.

Riku isn't interested in fixing his way of creating .CIA, where every file created is icon.bin 0x2018 offset 0x7fffffff RegionFree and uses the same key.
If you have any .CIA created by Simple, create your ticket.db and decode it with printKeys.py.
You will see all of the files from Simple have the same key. ( seems like an easy target to detect. )

You wouldn't believe but I actually wondered which key Riku uses. I was just too lazy to try and find out. And yup, easy target. I'm pretty sure Nintendo could easily wipe out all of Riku's stuff (with user savegames and all) with the next FW update. Make this timed with a random timer, and no one (but N3DS users, cause we can't update the EmuNAND anyways ) will be safe.

Also, the problem of not being able to "fix" the User Manual problem occurs on true RegionFree Games too (any Game Serial ending in "A", like CTR-N-JFJA). They have the same issue with the Manuals as do RegionFixed games.

That can only mean that these manuals have in a way or another been tampered with (ie. that the signature doesn't match). I'll see about an easy fix, but this truely is an annoying issue. I really don't want to throw away perfectly good data. What I could offer pretty fast would be a small command line utility that you'd have to use on the .3DS before converting it with Riku's tool. You could also do this manually - actually it would be a good thing if you tried. Just zero out offsets 0x128 till 0x160 (including 0x128 but excluding 0x160, to make that clear) in the 3DS rom, then process it with Riku's tool.

Edit: Oh yeah, one more little thing that does needs your expertise to look at.
If I create a decTitleKeys_emu.bin and a ticket_emu.db from Decrypt9WIP, the decTitleKeys_enu.bin is missing the last key in the set.

Example:
If I create a encTitleKeys.bin from the ticket_emu.db using dumpTicketKeys.py, then use decrypt9wip to create a new decTitleKeys.db, it is one key longer.

Okay, one moment. Not sure if I got that right. You mean if you decrypt titlekeys directly from EmuNAND, one key is missing, vs the old manual method of using dumpTicketKeys.py, correct? Good catch, btw. Is that title key a special one? And can you make absolutely sure it is not a duplicate? The NAND ticketkey decryptor has duplicate checking, but dumpTicketKeys.py most likely does not.

Also, since I'm being my usual pita today, is there any way to enable the clock for file timestamps while in ARM9, or was this already asked/answered and I missed it?

Sorry, but no, I don't know of any way. It may as well not be possible. By the way, since you first brought up that idea - what do you think about ZIP3DSFX - is that what you had in mind? The EmuNAND format feature in Decrypt9 needs some work so that it could actually take a file over, and I hope you will help me testing again once that is finished .

It's 2 VC Games (NES). (made with 3DS Simple CIA converter)

How are you using simple CIA converter (which converts only .3ds files into .CIA files) to make VC titles?

Yeah, that's what I like to know, too . I need more information! Normally, the shallow CIA decryptor is not required for Riku's converted CIAs (they don't even have shallow encryption). VC NES games can't be deep decrypted (cause they are not in NCCH format). Still, the error message is weird. As I said, I need more info.

@d0k3 , just want to throw this out there: do you think decrypting DSi TADs (sd exports) is possible with decrypt9?
It's a feature I've always wanted - thought I'd take a chance and ask. Don't mind me if it's any big trouble, you've accomplished a hell of a lot already. This would just be icing on the cake. : ) Thanks.

I'd need more info on these files, more specifically on the keyslots and / or keys used. The TAD files themselves seem to have a pretty simple file structure but the info on DSibrew is not enough to be able to actually decrypt them. Also, you'd only be able to decrypt these files on the 3DS they were first installed on. No way to do anything with old TAD files.

 

[dark_samus3]

@d0k3 I don't think you realize the scope of how big ZIP3DSFX could get... Let me put it this way, for Smea it means no more starter pack zip, just one .3dsx executable to download, for mashers it could make his over the web update easier (since certain files don't get updated) icon pack makers would just need to distribute one smdh and 3dsx and you'd get all of the icons when the app is opened, CFW guide makers could set up one that a user can just pop onto the SD card and make the process MUCH smoother... Anyways, I really hope you make it a bit easier to include files (I'd say add something that opens the executed file at a certain offset (which is where the zip file begins) and extracts the contents from there (the offset could even be calculated with some Makefile trickery ) this could be a pretty neat little homebrew

 

[d0k3]

@d0k3 I don't think you realize the scope of how big ZIP3DSFX could get... Let me put it this way, for Smea it means no more starter pack zip, just one .3dsx executable to download, for mashers it could make his over the web update easier (since certain files don't get updated) icon pack makers would just need to distribute one smdh and 3dsx and you'd get all of the icons when the app is opened, CFW guide makers could set up one that a user can just pop onto the SD card and make the process MUCH smoother... Anyways, I really hope you make it a bit easier to include files (I'd say add something that opens the executed file at a certain offset (which is where the zip file begins) and extracts the contents from there (the offset could even be calculated with some Makefile trickery ) this could be a pretty little homebrew

I said it is a flexible little tool . The problem with including files, though... the offset is not the problem, the problem is for the extractor to know it's own name (and thus be able to access it's own data). We don't want to hardcode that name either, because less flexibility (what if a user renames it and is stumped by why it doesn't work anymore?). And finding out the name the usual way (argument 0) will only safely work on HBL 2.5+ and Mashers Grid Launcher, again meaning less flexibility. I think we'll need to think about this some more.

By the way, I've got something for you to try. Take a ZIP file, in fact, any ZIP file. Now open it in a hex editor and add some garbage bytes at the beginning (in fact, any number you want, Megabytes, Gigabytes)). Now, save it and try to open it again in your ZIP archiver of choice. Notice something? . (what you've just seen means that there is no need at all to store an offset).

 

[dark_samus3]

I said it is a flexible little tool . The problem with including files, though... the offset is not the problem, the problem is for the extractor to know it's own name (and thus be able to access it's own data). We don't want to hardcode that name either, because less flexibility (what if a user renames it and is stumped by why it doesn't work anymore?). And finding out the name the usual way (argument 0) will only safely work on HBL 2.5+ and Mashers Grid Launcher, again meaning less flexibility. I think we'll need to think about this some more.

By the way, I've got something for you to try. Take a ZIP file, in fact, any ZIP file. Now open it in a hex editor and add some garbage bytes at the beginning (in fact, any number you want, Megabytes, Gigabytes)). Now, save it and try to open it again in your ZIP archiver of choice. Notice something? . (what you've just seen means that there is no need at all to store an offset).

I don't know many people who don't use *hax 2.x... Also very very cool about the zip thing (I'm guessing the unzip tools automatically search the whole file for the zip strings)

EDIT: wait... So *hax 2.5 is the only one that can get the filename? Interesting...

 

[Shadowtrance]

debug text background! Woo! lol With transparent text background, the show progress counter doesn't like it though.
And why can't i take screenshots while stuff is running goddammit! haha

 

[d0k3]

I don't know many people who don't use *hax 2.x... Also very very cool about the zip thing (I'm guessing the unzip tools automatically search the whole file for the zip strings)

EDIT: wait... So *hax 2.5 is the only one that can get the filename? Interesting...

No, in fact all the data needed for the correct offset is stored right at the ending of the ZIP. And the filename... Anything that correctly handles start parameters can do it. But (and that's the big catch) if ZIP3DSFX uses these start parameters and runs on something that doesn't support it, the results are unpredictable and range from crashes to corrupted data (crashes are much more likely, though).

debug text background! Woo! lol With transparent text background, the show progress counter doesn't like it though.
And why can't i take screenshots while stuff is running goddammit! haha

I don't need a screenshot, I know what you mean. That problem is by design, as the debug console is designed to completely overwrite the previous output line by line which in turn leads to liquid output (vs reloading the background completely, which would lead to slow output and flickering). Not much that can be done about that other than not using transparent for debug atm, I fear.

 

[dark_samus3]

No, in fact all the data needed for the correct offset is stored right at the ending of the ZIP. And the filename... Anything that correctly handles start parameters can do it. But (and that's the big catch) if ZIP3DSFX uses these start parameters and runs on something that doesn't support it, the results are unpredictable and range from crashes to corrupted data (crashes are much more likely, though).

Ahh... That would explain why I've never been able to figure out how zips work lol, footer instead of a header, hadn't considered that one also its really cool that, with the way they're designed (zip files), the self extracting archive app can be so flexible... As always I look forward to what you come up with next

 

[Datalogger]

You wouldn't believe but I actually wondered which key Riku uses. I was just too lazy to try and find out. And yup, easy target. I'm pretty sure Nintendo could easily wipe out all of Riku's stuff (with user savegames and all) with the next FW update. Make this timed with a random timer, and no one (but N3DS users, cause we can't update the EmuNAND anyways ) will be safe.


That can only mean that these manuals have in a way or another been tampered with (ie. that the signature doesn't match). I'll see about an easy fix, but this truely is an annoying issue. I really don't want to throw away perfectly good data. What I could offer pretty fast would be a small command line utility that you'd have to use on the .3DS before converting it with Riku's tool. You could also do this manually - actually it would be a good thing if you tried. Just zero out offsets 0x128 till 0x160 (including 0x128 but excluding 0x160, to make that clear) in the 3DS rom, then process it with Riku's tool.


Okay, one moment. Not sure if I got that right. You mean if you decrypt titlekeys directly from EmuNAND, one key is missing, vs the old manual method of using dumpTicketKeys.py, correct? Good catch, btw. Is that title key a special one? And can you make absolutely sure it is not a duplicate? The NAND ticketkey decryptor has duplicate checking, but dumpTicketKeys.py most likely does not.


Sorry, but no, I don't know of any way. It may as well not be possible. By the way, since you first brought up that idea - what do you think about ZIP3DSFX - is that what you had in mind? The EmuNAND format feature in Decrypt9 needs some work so that it could actually take a file over, and I hope you will help me testing again once that is finished .

I'm in the process of re-creating all of my SimpleCIA created CIA the proper way using Multi+Decrypt9 to fix this problem

On the missing key, there is a new key showing up ever since the User Manual issue started occurring, 0x0004000000b00000
It may be involved in the reason why there's a problem, but I've not collected enough data just yet.
It could be just a coincidence that it's showing up now...

This key does have duplicates with different key data, but I'm unsure why
Example:
0004000000b00000 1fe6751669213574e9b1aba59945c30
0004000000b00000 616d85a6a531bca22eddb5203c4b7ef

No worries on the no way to set the clock and timestamp the files, it's understandable
Thanks for the answer.

I'd be more then happy to help test the cool new ZIP3DSFX!!

Edit1:

ZIP3DSFX works fantastic!

• I made a compile with an FTP Server zipped up as /3DS/3DS-FTP/FTP-3DS.3dsx & FTP-3DS.3dsx
• put ZIP3DSFX.3dsx on the root
• Launched MenuHax2.5
• File Browsed to it
• Ran ZIP3DSFX.3dsx
• It un-zipped the two files in the correct directories and re-started MenuHax Menu
• Tested the FTP and it runs fine.

I would think this can be copied to a blank FAT32 before it is made into a emuNAND then executed after?
Only one file to track moving around while creating the emuNAND partition...
(edit: OK 2 files, it would need CtrBootManager's boot.3dsx also)

If so, this IS the answer to all of my questions!
Next test is, can I setup every-little-thing I would want on a new emuNAND and see if it can do all of them.
Decrypt9, CTRXplorer, FTP, FBI, Pasta, Cakes, rXTools...

Edit2: YES! It worked.

• I created a new 16GB emuNAND with Decrypt9WIP
• Copied only the ZIP3DSFX.3dsx and boot.3dsx from CtrBootManager to the new card.
  ↑↑↑ (Simulating what I'm hoping it will do by itself later on) ↑↑↑
• Rebooted - it created a new user on the SD.
• I set the Menu to Black (for MenuHax)
• Launched NinjHax2.5
• Let CtrBootManager make a fresh CFG file then ran FileBrowser
• Launched my "AIO" ZIP3DSFX.3dsx file
• It looked like nothing was gonna happen for a minute or so then it started unzipping everything
• When it was done it restarted CtrBootManager, this time it had all of my saved Menu Options
• Selected MenuHax and installed it.
• Selected Pasta and it launched my emuNAND!

FYI: My AIO file is 20.6 MB and has:

Spoiler

CtrBootManager
HomeBrewMenu for 2.5
HomeBrewMenu for 1.1
PastaCFW
CakesCFW
rxTools (Code.bin Launch)
rxTools (bootrx.3dsx Launch)
CHMM2
CTRXplorer
Decrypt9WIP (My hacked up version)
Decrypt9WIP (Almost stock, with only the "DPAD Left + Start" menu change and the Locks turned ON)
FBI
FTP-3DS
HANS
MenuHax Manager
mGBA
Screenshot Tool

Plus a few directories and files:
Launcher.dat (for my Gateway)
/Decrypt9/seedb.bin
/Decrypt9/slot0x25KeyX.bin
/D9games/ (empty)
/dbs/title.db (empty file)
/dbs/import.db (empty file)

 

[Myria]

How do I run this on a New 3DS?

 

[zoogie]

How do I run this on a New 3DS?

Just put the decrypt9WIP folder in the 3ds folder and run it like any other 3dsx homebrew. <= 9.2 of course.
don't forget to put the D9decrypt folder in the sd root. that's your work folder.

 

[Shadow#1]

@d0k3 have the latest .git compiled so I can get a copy?

 

[d0k3]

How do I run this on a New 3DS?

Just put the decrypt9WIP folder in the 3ds folder and run it like any other 3dsx homebrew. <= 9.2 of course.
don't forget to put the D9decrypt folder in the sd root. that's your work folder.

That folder is actually called D9Game now (to fit better with the names in the menu), and using Decrypt9 works as well.

@d0k3 have the latest .git compiled so I can get a copy?

Well, the latest .git right now needs cleaning up and a few safety clamps enabled, so there is no compiled release for now. Just use the previous one - you'll only miss out on the EmuNAND setup / format stuff.

I'm in the process of re-creating all of my SimpleCIA created CIA the proper way using Multi+Decrypt9 to fix this problem

Can you also take care of the manual problem this way?

On the missing key, there is a new key showing up ever since the User Manual issue started occurring, 0x0004000000b00000
It may be involved in the reason why there's a problem, but I've not collected enough data just yet.
It could be just a coincidence that it's showing up now...

This key does have duplicates with different key data, but I'm unsure why
Example:
0004000000b00000 1fe6751669213574e9b1aba59945c30
0004000000b00000 616d85a6a531bca22eddb5203c4b7ef

One title ID, multiple keys - strange! And this also sounds like the duplicate checking in the NAND titlekey decryptor doesn't work properly (or does it?). Still wondering about that missing key!

I'd be more then happy to help test the cool new ZIP3DSFX!!

Edit1:

ZIP3DSFX works fantastic!

• I made a compile with an FTP Server zipped up as /3DS/3DS-FTP/FTP-3DS.3dsx & FTP-3DS.3dsx
• put ZIP3DSFX.3dsx on the root
• Launched MenuHax2.5
• File Browsed to it
• Ran ZIP3DSFX.3dsx
• It un-zipped the two files in the correct directories and re-started MenuHax Menu
• Tested the FTP and it runs fine.

I would think this can be copied to a blank FAT32 before it is made into a emuNAND then executed after?
Only one file to track moving around while creating the emuNAND partition...
(edit: OK 2 files, it would need CtrBootManager's boot.3dsx also)

If so, this IS the answer to all of my questions!
Next test is, can I setup every-little-thing I would want on a new emuNAND and see if it can do all of them.
Decrypt9, CTRXplorer, FTP, FBI, Pasta, Cakes, rXTools...

Edit2: YES! It worked.

• I created a new 16GB emuNAND with Decrypt9WIP
• Copied only the ZIP3DSFX.3dsx and boot.3dsx from CtrBootManager to the new card.
  ↑↑↑ (Simulating what I'm hoping it will do by itself later on) ↑↑↑
• Rebooted - it created a new user on the SD.
• I set the Menu to Black (for MenuHax)
• Launched NinjHax2.5
• Let CtrBootManager make a fresh CFG file then ran FileBrowser
• Launched my "AIO" ZIP3DSFX.3dsx file
• It looked like nothing was gonna happen for a minute or so then it started unzipping everything
• When it was done it restarted CtrBootManager, this time it had all of my saved Menu Options
• Selected MenuHax and installed it.
• Selected Pasta and it launched my emuNAND!

FYI: My AIO file is 20.6 MB and has:

Spoiler

CtrBootManager
HomeBrewMenu for 2.5
HomeBrewMenu for 1.1
PastaCFW
CakesCFW
rxTools (Code.bin Launch)
rxTools (bootrx.3dsx Launch)
CHMM2
CTRXplorer
Decrypt9WIP (My hacked up version)
Decrypt9WIP (Almost stock, with only the "DPAD Left + Start" menu change and the Locks turned ON)
FBI
FTP-3DS
HANS
MenuHax Manager
mGBA
Screenshot Tool

Plus a few directories and files:
Launcher.dat (for my Gateway)
/Decrypt9/seedb.bin
/Decrypt9/slot0x25KeyX.bin
/D9games/ (empty)
/dbs/title.db (empty file)
/dbs/import.db (empty file)

Again, thanks a ton! To be honest, I wouldn't have thought that it works with an archive that big . You missed something, though, you need only one file because ZIP3DSFX can overwrite itself. Meaning, just call it boot.3dsx and include a file called boot.3dsx, and you have a complete, one file setup. Moving it to blank FAT32 space is out of the question, as there is just too much that can go wrong with manually linking that file in the FAT table and the root directory. We either have to create a recovery partition (meaning we'll lose that memory for the main partition) or use the RAM to take that file over (this meaning that we'll have to live with the narrow size constraints of memory).