d0k3 / decrypt9wip Goto Github PK

I noticed that you added colored output text when a task succeeds. GodMode9 looks really nice aesthetically, so I was wondering why Decrypt9WIP didn't get the same treatment. Also, could you consider adding colored text when an option is highlighted?

You can already create the xorpads. I don't see why there is a need for a pc program to do the cia building job when you can already decrypt and encrypt a 3ds/cia file on the 3ds itself.

Normmatt appears to have taken the liberty of adding TWL cart support to the NTR cart dumper you recently added:

https://gist.github.com/Normmatt/fe9c0308b6bec86443f9e94620b7aeff

It's in the form of a gist though. So I'll leave it to you to sort out the changes. :P

This should add support to allow dumping of DSi Enhanced games. I have not personally tested this however. My build environment is too out of date right now for me to compile this. :P

It seems "Inject files..." for emuNAND isn't properly updated since it still has the seed option (keep forgetting the name lol) and it lacks the option to inject friendsaves.bin to emuNAND, I used both .3dsx and .dat version to make sure it isn't specifically the built I used.
Dump list is fine, so kinda weird the inject list is slightly off haha

If launched via the GW Launcher.dat entrypoint and when accessing ITCM (f.e. for system info), Decrypt9WIP crashes. This has to be solved in gw-start.s:
https://github.com/d0k3/Decrypt9WIP/blob/master/source/abstraction/gw-start.s#L40-L46

I have an o3DS running A9LH (AuReiNand 4.2) with an updated SysNAND (10.7). When I try to run Decrypt9, it gets to "Initialization: success!" and then stalls. The screen prints out:

Counting 15 submenus and 111 features
Initializing, hold L+R to pause

Initializing SD card... success
0x03 KeyX & KeyY: automatically set up
0x25 KeyX: loaded, verified, set up
0x18 KeyX: already set up
0x1B KeyX: loaded, verified, set up
Finalizing Initialization...

Initialization: success!

Afterwards, that text just stays on the screen and nothing changes, and the only way to get out is by turning the 3ds off.

Add decryption of BOSS files. Will look into this later.

I am using Decrypt9WIP all-in-one 20160626 version of Decrypt9WIP.
I want to dump my gamecart, but I can not found the Gamecart Dumper Options?
I tried inserted the gamecard before enter Decrypt9WIP and inserted the gamecard after enter Decrypt9WIP, but Gamecart Dumper Options did not show once.
How can I make it work?
Thank you.

As referenced by this pull request:
#67

This needs a cleaner solution.

Simply rerunning the option "Build Key Database" more than once will cause the key to be written to the database more than once.

NCCH decryptor fails on romfs for Binding of Isaac rom. Result is a broken romfs partition.

BrahmaLoader needs updated to use the latest libkhax, otherwise you get compile errors with the latest ctrulib.

I mean ,by NCSD writter, the "Unbrick FW 2.1 EmuNAND" option in OTPHelper

So,you probably know that there is a dev update for old 3ds USA.
For other region,it is simple,we just need to follow the Region Change Guide....

But for New 3DS,I was thinking that this MAY work:

1. Change region (if you are in EUR/JPN)
2. Create an EmuNAND 3.Follow the downgrade to dev FW process
3. Your EmuNAND will be bricked,then we can rewrote NCSD,and other
4. Restore EmuNAND to SysNAND

Does it is possible? If yes,can you reimplement this on OTPHelper or D9WIP?

I know panda units arent your main concern, but there might be a minor edit that could make the checks more flexible. All features work on panda, but recently one of the checks denies 7.x stuff. I assume thats this:
https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/keys.c#L273
So if you could, would you be able to add a second entry for
{0x25,{....
(i assume those are xorpads, so with a dev xorpad)
and have the function check any and all entries with the respective keyslot, and maybe set a flag if one of them passed, and return that result. Idk, i'm just spit-balling ideas.

Some work has already been done in this repo but it seems like it has stalled.

If you open System Info, it shows the number of installed emuNANDs as 5 on my console, however, I only have 2. If I look one line down at the list of installed emuNANDs, I have 2, emuNAND #0, a GW emuNAND, and emuNAND #1, a redNAND.

Hello.

Can you add ability to run this homebrew software in emuNAND, if I already have access to Homebrew menu https://github.com/smealum/3ds_hb_menu from emuNAND?

Thanks.

This wouldn't be considered an issue on it's own, but the "update seeddb" option checks if it's a 0 byte file and errors due to a "file too small" error.

To have a programatically shut down is just the line: i2cWriteRegister(I2C_DEV_MCU, 0x20, 1 << 0);
Quite useful sometimes. However due to the current design i felt confused of where to put this line.
Also you would have to bind it with a KEY, and i suggest you to enable this when SD is unmounted.

Also, i don't know if you can let the decryptor wrote a log, so i won't miss those that failed decryption.

Can someone explain why it's not possible? I kind of screwed myself. I have a emunand and sysnand both with 11.0 but a 9.1 nand backup that cant be restored because it thinks its from another 3DS. Also how can I force the nand backup while keepong A9LH installed? I don't feel like going through a9lh again ;-;

Hello. I've a SysNAND 9.2 and a RedNAND 10.7. I am following Plailect's guide. I'm currently trying to get the OTP, and I need to dump the Health & Safety using Decrypt9. It gives me an error that says my SD is not formatted for EmuNAND. Reference image. I am using the 20160404 version.

I'm using the latest pre-compiled release. I'm aware that DSi is not supported without a newer build from the dev branch. While it's not strictly related, I'd like to point out that issue #74 is marked closed but has apparently not been 100% fixed yet. Moving on to the nitty gritty...

NTR dev cart output:

Selected: Dump NTR Cart (full)
Cartridge ID: 0000FFC2
Cartridge Type: NTR
Product name:
Product ID:
Cartridge data size: 0MB
Cartridge used size: 4095MB
Cartridge dump size: 0MB
DSi Cartridge is not supported
Dump NTR Cart (full): failed!

TWL dev cart output:

Selected: Dump NTR Cart (full)
Cartridge ID: C000FFC2
Cartridge Type: NTR
Product name:
Product ID:
Cartridge data size: 0MB
Cartridge used size: 4095MB
Cartridge dump size: 0MB
DSi Cartridge is not supported
Dump NTR Cart (full): failed!

For what it's worth, dumping CTR dev cards does appear to work, but will not allow you to dump a blank cart. Being able to dump blanks (raw) would be a nice feature, but I suppose I should submit that in a separate request.

I know not everyone has access to the requisite hardware to test this, so please let me know if there is any experimentation/etc I can assist with. Thanks contributors! Decrypt9 is great; here's hoping we can make it a little better!

Mind me please, but sometimes your submodule commit version is removed aggressively that git could not check it out. This may due to force-update/upload-unknown that wiped the commit. I could use the release zip as always, but this may cause some issues when building it. That's all. Have a good time.

fatal: reference is not a tree: 6b2c7e48c895e37634a9da0a7087da15c2528255
Unable to checkout '6b2c7e48c895e37634a9da0a7087da15c2528255' in submodule path 'BrahmaLoader'

3072e0a broke multi EmuNAND detection on O3DS.
The error is in line 17 of source/decryptor/nand.c:
#define EMUNAND_MULTI_SECTORS ((getMMCDevice(0)->total_size >= 0x200000) ? 0x200000 : 0x400000)
It sets EMUNAND_MULTI_SECTORS to 0x400000 instead of 0x200000.

I'm pretty sure it should look like this:
#define EMUNAND_MULTI_SECTORS ((getMMCDevice(0)->total_size > 0x200000) ? 0x400000 : 0x200000)

I would like it if you could decrypt split 3DS rom files.

For the moment I will work on this, but if someone beats me to it I will be OK.

Hi d0k3, thanks for your hard work.

Exact same problem as #39 :

I've a SysNAND 9.2 and a RedNAND 10.7. I am following Plailect's guide. I'm currently trying to get the OTP, and I need to dump the Health & Safety using Decrypt9. It gives me an error that says my SD is not formatted for EmuNAND.

Using latest version as well.

Im using a NN3DSXL EU, created RedNAND using EmuNAND9. I do have the files that were missing to previous OP in the root of my SD card.

Here are the first 1024 bytes of my SD card attached.

EMUNAND9SD (G).zip

Please let me know if you need any other info.

Thanks !

Hi, please, if you can, can you add the ability to Dump the Game Cartridges and let Decrypt9 convert the dump .3ds directly to .cia ???
This can be more easy for who want to dump his own cart and install as cia.

Without the need to dump it with one tool to .3ds, then go to pc and create ncch, then transfer the ncch to 3ds, generate xorpads, then go back to pc and create cia.

This can be a cool idea, but only if this can be done. :)

Both of them actually work correctly on both a9lh and hblauncher (which is known to work)

Hello。
When use D9 to De/Encrypt a 3ds game (CDNto3DS, SDto3DS) with seed encryption, the game manual will cannot be access,or be missing（show the message game card is ejected.） but the game can be played normally.

Or maybe it's the SD Decryption function's bug? I use SD Decryption and Sdto3DS to build the game.

And a game without seed encryption won't have this bug.

So when I try to dump Health & Safety it tells me that the dump failed! It still creates a hs.app on my SD , but I'm skeptical of it. I think the reason it fails is because I have FBI already injected and the verification fails therefore the whole process just fails. I just want to update FBI. I never had issues with previous versions. Log is attached if it's any help. Thanks!
Decrypt9.txt

What I mean is that when dumping,it will ask for a name to the user with a "virtual keyboard" where user tap the name

Hello,
After the initial setup/read it ends with Success.. but it doesn't do anything after that, its stuck_frozen_ there.
Emu9 does boot up without issues, but not Dec9 :/.
I just updated my console to O3DS 11.0 (a9lh) US
-- Gave your Nightly a test run 2016/05/17 version and still nothing :(.

From: https://gbatemp.net/threads/download-decrypt9-open-source-decryption-tools-wip.388831/page-185#post-6561529

When decrypting an NCSD file, and it has an ExeFS that uses the 7x encryption method (type 0x01 or 0x0A) the size of the file in the exefs doesn't get rounded up to the next 0x200 byte block boundary.
(it gets aligned to a 16 byte boundary by the AES engine as it works with multiples of 16 bytes). This just leaves a small amount of still encrypted data after the end of the file (which is harmless) which continues until the end of the 0x200 byte sector. it probably should all be 00's like it is when decrypting exeFS that use the 'standard' crypto-type 0x00.

In the file: /source/decryptor/game.c @ line #379 and line #1082.
https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/game.c#L379
https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/game.c#L1082

On these lines above - the value needs to get rounded up to the next 0x200 bytes to fill the sector.
Code:
u32 size_exefs_file = getle32(buffer + (i*0x10) + 0xC);

When comparing the contents of an encTitleKeys.bin that was extracted directly from a 3ds vs one that was re-encrypted from a decTitleKeys.bin (also from the same 3ds) the contents do not match. The former version actually aligns with the ticket.db file for encrypted title keys where as the latter seems to result in gibberish giving the wrong keys even for titles purchased from the eshop.

Keys were dumped using the print_ticket_keys.py/dump_ticket_keys.py using the encTitleKeys.bin and ticket.db respectively to check this and all files were dumped using the latest repository code.

How to reproduce:

Simply unmount SD and plug it into a Windows PC,it will say you that you have to format it...

(not on linux, don't know for mac...)

Is there a way to pick a 2nd/3rd/4th emuNAND from Decrypt9?
If so, how?
If not, could you implement it?

Thanks.

hey m8 whenever when i try to dump gba vc save its always telling me
GBA VC save dump : failed
slot0x24key y not set up

I try to launch the latest build as of 3/31/16 and get a Blue Screen with random numbers And Bootrom error im on N3DS, A9LH, A9Select, and sysnand 10.7

Downloaded latest build (2016/04/01), and launching the Gateway entrypoint on a old 3DS XL 9.2 sysNAND, cant get the program to proceed past Initializing SD card ... success. Have tried it 3 times, with no change.

All that prints out is
Decrypt9WIP (2016/04/01)
Counting 15 submenus and 111 new features
Initializing, hold L+R to pause

Initializing SD card ... success

I see the usual flash of black/red like when loading EmuNAND9 (which works), but then all I see is an empty black screen with the backlight on. Launching from sysNAND ver. 9.2 with menuhax (themehax) and Homebrew Launcher

Partition dumping doesn't seem to be working on old 3ds via browser (launcher.dat) version. Just sits there at 0%.
Works fine via ninjhax though on both n3ds and o3ds.
Updated my bootstrap branch too. :)
gbatemp not working atm. noooooooo!

Some dump/decrypt function took a lot of time (backup nands, generate nand pad etc), would be great if Decrypt9 can make a noise (or an audio file) when is done.

Thanks.

Is this normal for having a9lh installed? i just dumped the firms, basically just testing out the new features you implemented. i like to feel useful

Hi,

My 3DS has the select button always pressed, so I cant make the key combination to inject an app into H&S app.

Any chances to compile an uber-unsecure version for these cases? I know its a hassle.

Thanks in advance

How to reproduce:
Start D9 fresh, start a feature that will produce truncated Debug output (f.e. the NCCH decryptor is a good candidate). After it finished, push up to reverse scroll. Output will be incomplete.

The same can't be reproduced if another feature with non truncated output was run before.

I've had a small idea;
Add an option to generate xorpads that could save a 3DS from being bricked, and then upload them to a server, which could then store them under a certain serial, aswell as a NAND backup, so if anything is to occur to the users' computer they could get a copy back.

They'd be kept in a manner which nobody could touch them (plus nobody would be able to use them anyways except for the orig. console)

every time padgen will regenerate all xorpad files.
it is possible generate the specified xorpad file?

How to reproduce:
Start D9 fresh, run NAND restore, select a file, start. You will be greeted with a ERROR: file too small message, even if the file is fine, and has previously been checked for the correct size.

Run the feature again, and the error message will be gone. This is most likely a problem in the filesystem routines.

Why is this happening? it takes just as long to reach the "failed!" error message as it does to do a good decryption. Seems to happen randomly, it's happening now on .cia files i know for a fact ive decrypted before.

I was having some trouble restoring a proper NAND backup due to the file extension. The file name was NAND.BIN and wasn't deemed usable by Decrypt9. However, once I renamed it to NAND.bin, it worked perfectly fine. It should be case insensitive.