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

[Mrrraou]

[+] HS APP ORIGINAL SIZE  : 823296 bytes
[+] HS APP INJECT (N) SIZE: 786432 bytes
[+] HS APP INJECT (B) SIZE: 827392 bytes
/!\ INJECT APP IS BIGGER THAN HS APP

N3DS or O3DS ? Region?

 

[d0k3]

Oh well, you go for a night of drinking, come back here, and - boom - three new pages of posts. Where do I start...

also, here is a suggestion, @d0k3 , could you add a check when restoring sysnand, to check if a A9LH setup is present (check for something in sector 0x5C000 ?) and if so, ask the user if he wants to keep A9LH, if he chooses to keep it, skip the relevant sectors (secret sector, firm0/1, sectors 0x5C000-0x5C980 (beginning of ctrnand)) when restoring the backup, otherwise restore as usual ? how feasable would that be ?

If they'd like to keep it they shouldn't be using a whole NAND backup, they should be using a CTRNAND backup only....

Only restoring the CTRNAND will work if you stayed on the same FW version, but if not idk... System updates sometimes also change stuff in TWLN, maybe even in firm. I can look into the possibility of a A9LH saving system restore, but for now you're better off just only injecting the CTRNAND or doing new backups with A9LH included.

BOSS encryption is used for SpotPass data.
I don't know if BOSS decryptor would be useful for many people, but I sure
would like to have it myself. Maybe you will look into it when you have time.

I'll look into it, maybe it is easy.

I'm trying to inject a cia into the sysnand H&S app but no matter what I try, it doesn't change into the injected cia.
I'm using AuReiNand-A9LH (9.2 SYS/10.6 EMU) and have tried using Decrypt9 through the FIRM90 patched HomebrewLoader and through the A9LH BootCR9 bin file. Both print a success message but when booting H&S it's unchanged. I've tried different cias, and injects with and without banner.

What could be the problem? Thanks in advance.

If you're using the current release version, that can't work on A9LH - the success message must be a false positive. The exact output would help. Other than that, you did select the correct file (you see that you can select it, right?) for injection?

The reason it most likely fails is because BOI was never a cartridge game - an eshop game with seeddb. If a 3DS version exists, it's most likely been crypto-fixed at some point and then either standard/zero-key encrypted.

No, that's not the problem. D9 can handle zerokey encryption, and the decryption must still work for anything. I'll look into this issue later.

So I was trying to use Decrypt9 from A9LH on my N3DSXL and apparently I couldn't dump sys/emuNAND partitions, see here for context.
(though it was considered fixed so worth reminding it's not, sorry for that )

So i have a9hl installed and i want to dump my ticket.db but it fails to dump? I updated to the newest one soooo idk what I did wrong

That goes not to you specifically, but for anyone complaining about stuff not working when running D9 from A9LH directly: Be patient, goddammit! If you two don't want to be patient, compile from the most recent D9 source code and get the slot0x05keyY.bin file from somewhere (I trust you find it). I won't make another rushed release version.

Decrypt9WIP.nds in Gateway Blue, I installed Rop Installer "4.x..." first choice but i have an error occured and restarting with ds profile, again.

Can't help with that much... almost no one is using that entry point anymore. Anyone have an idea about that?

[+] REBUILD HS INJECT APP
[+] HS APP ORIGINAL SIZE  : 823296 bytes
[+] HS APP INJECT (N) SIZE: 786432 bytes
[+] HS APP INJECT (B) SIZE: 827392 bytes
/!\ INJECT APP IS BIGGER THAN HS APP

Which FBI version is compatible?

Actually, you can inject anything, not just FBI, but the question was which one to inject, right? D9 won't inject the bigger one, even if you tell it too, so nothing will go wrong. By the way, while you're here ... I've seen rxTools now uses the TMIO driver instead of old SDMMC... Is it recommended to switch? Would be pretty much a swap in replacement with the new FATFS version as far as I see it.

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

Hi, I'm trying to dump my CTRNAND partition with the 3/5 release but it's taking a very long time, about 1% a minute. Dumping was much faster on an older build from my experience. Would it be safe for me to shutdown the 3DS mid-dump and try the older version? Thanks.

Okay so it's safe to shut down mid-dump. How come the 2/15 build dumps much quicker than the latest build?

That sounds like a weird system hiccup more than anything else. Nothing has changed in dumping these partitions. Just to be safe, though, can anyone reproduce this? And, if you can, try to confirm you really had much faster speeds on the earlier build.

 

[Lumince]

That goes not to you specifically, but for anyone complaining about stuff not working when running D9 from A9LH directly: Be patient, goddammit! If you two don't want to be patient, compile from the most recent D9 source code and get the slot0x05keyY.bin file from somewhere (I trust you find it). I won't make another rushed release version.

Im sorry. Im not being impatient. I was merely told that it worked and it failed mulitple times. I didnt know it wasnt supported fully. And I have been searching for that key but with no avail.

 

[Geren]

If you're using the current release version, that can't work on A9LH - the success message must be a false positive. The exact output would help. Other than that, you did select the correct file (you see that you can select it, right?) for injection?

I tried different versions: the official release, shadowtrance's mini version and the one posted on a reddit thread that claimed it worked in A9LH. I also tried different entrypoints: OoTHax/Browserhax HBL over firm90-launched sysnand (if I tried without firm90, decrypt9 wouldn't even boot) and Bootcr9 autobooting to one of the mentioned versions. I did see that you could choose the hs.app, but even if I tried banner or bannerless versions of the injected app, it wouldn't work. It must be a false positive.

Thank you for taking the time to read and answer my question. In the end I managed to use NASA to do what I intended. Nonetheless, I'll wait the next releases just to see if I'm able to debug any issues for you.

 

[Nikolay]

That sounds like a weird system hiccup more than anything else. Nothing has changed in dumping these partitions. Just to be safe, though, can anyone reproduce this? And, if you can, try to confirm you really had much faster speeds on the earlier build.

I tried the 3/5 build on my O3DS and it seemed to be dumping pretty fast, so it's probably something on my end.. but I don't understand why one build dumps properly while another takes hours
Some info: O3DS 16 GB Kingston Class 4 SD (fast dump) ; N3DS XL 64 GB G.Skill UHS-I / Class 10 (slow dump)
Okay, after trying it again, it's working perfectly on the N3DSXL with the most recent build. Guess it was a one time thing. Sorry for the inconvenience.

 

[Hakujou]

@d0k3 : Thanks for your amazing work, I'm really excited about new features for A9LH.
Few questions, though : Will the H&S dump/injection will work from A9LH or it will still require EmuNand boot ?
Also, the key seems to be really hard to find this time. Google it and you'll only fine this topic... Any "hint" on where I can find it ? I didn't on "that iso site" neither...

 

[Svaethier]

@d0k3 : Thanks for your amazing work, I'm really excited about new features for A9LH.
Few questions, though : Will the H&S dump/injection will work from A9LH or it will still require EmuNand boot ?
Also, the key seems to be really hard to find this time. Google it and you'll only fine this topic... Any "hint" on where I can find it ? I didn't on "that iso site" neither...

Pretty sure it's on a pastebin

 

[Hakujou]

Pretty sure it's on a pastebin

Really ? I found some keys (required by Cakes, mainly) but not this one...

 

[Mrrraou]

Really ? I found some keys (required by Cakes, mainly) but not this one...

I think it's on a spreadsheet?

 

[Lumince]

Of coursse as i refresh the page its there

 

[Shadowtrance]

google sheets 3DS AES Keys
You're welcome.

 

[3xkrazy]

Hi @d0k3
Can you give me a hint where the file path for "slot0x05keyY.bin" is defined or read? I can't search for it in your fork...because we can't do searches in forks

 

[Shadowtrance]

Look at the post above... i basically gave you the key right there.

 

[3xkrazy]

Look at the post above... i basically gave you the key right there.

Yea, I have the key. I just wanna see where it's defined in Decrypt9 and looks for the .bin file on the SD card in the code.

 

[Shadowtrance]

Yea, I have the key. I just wanna see where it's defined in Decrypt9 and looks for the .bin file on the SD card in the code.

Where it looks for everything else, on sd root and if it isn't there then in the "Decrypt9" folder on sd root.

 

[Madridi]

Where it looks for everything else, on sd root and if it isn't there then in the "Decrypt9" folder on sd root.

I think he is asking where that is coded in the source

 

[3xkrazy]

Ok, I think I found it...

source/decryptor/nand.c
// part #3: CTRNAND N3DS KEY
- if (GetUnitPlatform() == PLATFORM_N3DS) {
+ while (GetUnitPlatform() == PLATFORM_N3DS) {
u8 CtrNandKeyY[16];

if (!FileOpen("slot0x05KeyY.bin")) {
- Debug("0x05 KeyY: not set, file not found");
- return1;
+ Debug("0x05 KeyY: not set, slot0x05KeyY.bin not found");
+ break;
}
if (FileRead(CtrNandKeyY, 16, 0) != 16) {
Debug("0x05 KeyY: not set, bad file");
FileClose();
- return1;
+ break;
}
FileClose();

 

[d0k3]

Im sorry. Im not being impatient. I was merely told that it worked and it failed mulitple times. I didnt know it wasnt supported fully. And I have been searching for that key but with no avail.

@d0k3 : Thanks for your amazing work, I'm really excited about new features for A9LH.
Few questions, though : Will the H&S dump/injection will work from A9LH or it will still require EmuNand boot ?

If you compile from source now, eevrything should work even on A9LH. Will require some more testing, but the next release evrsion is also around the corner.

I tried different versions: the official release, shadowtrance's mini version and the one posted on a reddit thread that claimed it worked in A9LH. I also tried different entrypoints: OoTHax/Browserhax HBL over firm90-launched sysnand (if I tried without firm90, decrypt9 wouldn't even boot) and Bootcr9 autobooting to one of the mentioned versions. I did see that you could choose the hs.app, but even if I tried banner or bannerless versions of the injected app, it wouldn't work. It must be a false positive.

Thank you for taking the time to read and answer my question. In the end I managed to use NASA to do what I intended. Nonetheless, I'll wait the next releases just to see if I'm able to debug any issues for you.

I double checked the code - it is absolutely impossible for this to say it succeeded when it actually did nothing at all. Did you inject into the wrong NAND? Also, the exact output would help.

Ok, I think I found it...

source/decryptor/nand.c
// part #3: CTRNAND N3DS KEY
- if (GetUnitPlatform() == PLATFORM_N3DS) {
+ while (GetUnitPlatform() == PLATFORM_N3DS) {
u8 CtrNandKeyY[16];

if (!FileOpen("slot0x05KeyY.bin")) {
- Debug("0x05 KeyY: not set, file not found");
- return1;
+ Debug("0x05 KeyY: not set, slot0x05KeyY.bin not found");
+ break;
}
if (FileRead(CtrNandKeyY, 16, 0) != 16) {
Debug("0x05 KeyY: not set, bad file");
FileClose();
- return1;
+ break;
}
FileClose();

Yup, just read the commits properly to find stuff such as this .

 

[Lumince]

If you compile from source now, eevrything should work even on A9LH. Will require some more testing, but the next release evrsion is also around the corner.

Yea i just figured out how to compile it! It seemed complicated at first but just ended up being very simple to compile it Thank you for your hard work!

 

[3xkrazy]

If you compile from source now, eevrything should work even on A9LH. Will require some more testing, but the next release evrsion is also around the corner.


I double checked the code - it is absolutely impossible for this to say it succeeded when it actually did nothing at all. Did you inject into the wrong NAND? Also, the exact output would help.


Yup, just read the commits properly to find stuff such as this .

Yea, reading the commits is the way to go. It seems like you hard coded all the paths in your code. Would you consider doing something similar to what CakesFW does?

CakesForeveryWan/source/paths.h

#pragma once

// A file to keep track of all the file paths used throughout cakes.

// The "topdir"
#define PATH_CAKES "/cakes"

#define PATH_FIRMWARE PATH_CAKES "/firmware.bin"
#define PATH_PATCHED_FIRMWARE PATH_CAKES "/firmware_patched.bin"
#define PATH_FIRMKEY PATH_CAKES "/firmkey.bin"
#define PATH_CETK PATH_CAKES "/cetk"

#define PATH_AGB_FIRMWARE PATH_CAKES "/agb_firmware.bin"
#define PATH_PATCHED_AGB_FIRMWARE PATH_CAKES "/agb_firmware_patched.bin"
#define PATH_AGB_FIRMKEY PATH_CAKES "/agb_firmkey.bin"
#define PATH_AGB_CETK PATH_CAKES "/agb_cetk"

#define PATH_UNSUPPORTED_FIRMWARE PATH_CAKES "/firmware_unsupported.bin"
#define PATH_SLOT0X25KEYX "/slot0x25keyX.bin"
#define PATH_SLOT0X11KEY96 "/slot0x11key96.bin"
#define PATH_PATCHES PATH_CAKES "/patches"
#define PATH_CONFIG PATH_CAKES "/config.dat"