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

  • Thread starter Thread starter d0k3
  • Start date Start date
  • Views Views 935,437
  • Replies Replies 4,476
  • Likes Likes 71
By the, way GodMode9 development is progressing along nicely, take a look:
snap005.png
snap006.png
snap007.png
snap010.png


Won't be long until this has a proper release thread and you can finally use it.

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

Knows more about what? I don't pop in too often any more.
I meant, do you know about other cases where Decrypt9 CIA decryption failed?
 
Last edited by d0k3,
For legitimate tickets, there is already the print_ticket_keys.py script (included in Decrypt9). For CIAs, I guess make_cdn_cia doesn't lend itself to automation (ie, build a enctitlekeys.bin), but putting something together for the PC commandline is not too difficult. I agree that for single keys, putting it in directly might be a tad faster then moving around files.

As for CIAs from NUS, made by make_cdn_cia... I'd need an example, and you should better doublecheck it. I recently checked the FW 1.0.0 (US) package (created from a valid NAND backup). Seven files could not be decrypted, but doublechecking these with NUS content it turned out the non-decryptable CIAs had broken contents (100% sure, cause matching hashes and differing files). Maybe @MassExplosion213 knows more?
print_keys.py only prints the encrypted keys, which can already be found in the tickets or ticket.db easily.
 
print_keys.py only prints the encrypted keys, which can already be found in the tickets or ticket.db easily.
What are you trying to do?

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

To get ticket keys, use Decrypt9 to dump a decTitleKeys.bin and run print_ticket_keys.py on it.

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

Pipe that output into a file.
 
Alright, let me think about this some more. But, in the meantime, give me some information about those undecryptable CIAs ;).
Just build anything using make_cdn_cia. It will pack the CIA using encrypted CDN contents. Try downloading a game with FunkyCIA,py, for example.
Even though the ticket contains the proper encrypted title key (ctrtool can extract the original contents if you input the proper decrypted key), Decrypt9 won't be able to decrypt it.

I tried this weeks ago (with the Bravely Second demo). I didn't read about you changing anything in the CIA decryption lately so the problem might still be there.

What are you trying to do?

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

To get ticket keys, use Decrypt9 to dump a decTitleKeys.bin and run print_ticket_keys.py on it.

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

Pipe that output into a file.
You talk as if it wasn't a nuisance to always have to have the SD card inside the 3DS for decrypting anything.

If we wanted to decrypt a single title key it would be simpler to just type it out into the program and write down the resulting decrypted key instead of creating a binary file, copying it to the SD, decrypt it on the 3DS and getting it back to the PC so we can finally read the decrypted key.
 
Last edited by piratesephiroth,
Just build anything using make_cdn_cia. It will pack the CIA using encrypted CDN contents. Try downloading a game with FunkyCIA,py, for example.
Even though the ticket contains the proper encrypted title key (ctrtool can extract the original contents if you input the proper decrypted key), Decrypt9 won't be able to decrypt it.

I tried this weeks ago (with the Bravely Second demo). I didn't read about you changing anything in the CIA decryption lately so the problem might still be there.

The problem with the Bravely Second demo was with the seed. Nintendo did some shady stuff there. There is a workaround in Decrypt9 now that allows to properly extract that seed from the seeddb.

I did just yesterday (using 3DNUS + make_cdn_cia) download some FW 1.0.0 (US) contents and repack them as CIA. Decrypted without trouble.

I can't fully exclude there is some trouble with newer stuff, though. Maybe you can name a good test candidate? We can also continue this in PM.

As for the titlekey decryption thingy... One way to solve this is to add CSV support to Decrypt9. You could easily generate such a CSV file manually, then let Decrypt9 handle the titlekey decryption. I really don't like the manual input in Decrypt9 though.
 
Wow! I love it. Any chances of booting Brahma payloads from that ? Or updating things like some NAND sectors (like 0x5C000 for the stage2) ?
GodMode9 already runs on ARM9. While it would be technically possible to load other ARM9 payloads, I will deliberately keep this as simple as possible. With that kind of access (FAT access to the SysNAND), even a small bug can have very bad consequences. For that reason, no loading / viewing stuff, only base file operations with GodMode9 :).

This will also only access things with a file system Updating 0x5C00 for stage2 better belongs into OTPHelper, right?
 
Last edited by d0k3,
  • Like
Reactions: Mrrraou
GodMode9 already runs on ARM9. While it would be technically possible to load other ARM9 payloads, I will deliberately keep this as simple as possible. With that kind of access, even a small bug can have very bad consequences. For that reason, no loading / viewing stuff, only base file operations with GodMode9 :).

This will also only access things with a file system Updating 0x5C00 for stage2 better belongs into OTPHelper, right?
Well, I don't know, I just thought that an all-in-one payload would be awesome :P
But I agree with you on the fact that it could have disastrous consequences.
 
Well, I don't know, I just thought that an all-in-one payload would be awesome :P
I personally think a Brahma 2 based frontend for Decrypt9 / EmuNAND9 / GodMode9 / CFW / ..., maybe even with a unified theme / design would be the better solution. Or a ARM9 based frontend if you want to use it via another entrypoint.

@WhoAmI? also recently brought up the idea of adding CFW to Decrypt9 and we discussed the possibilities.
 
I personally think a Brahma 2 based frontend for Decrypt9 / EmuNAND9 / GodMode9 / CFW / ..., maybe even with a unified theme / design would be the better solution. Or a ARM9 based frontend if you want to use it via another entrypoint.

@WhoAmI? also recently brought up the idea of adding CFW to Decrypt9 and we discussed the possibilities.
rxTools rebirth ? :p
Having the possibility to firmlaunch from GodMode9 would be great, yeah. A all-in-one CFW would be awesome for sure.
 
rxTools rebirth ? :P
Please don't......

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

I personally think a Brahma 2 based frontend for Decrypt9 / EmuNAND9 / GodMode9 / CFW / ..., maybe even with a unified theme / design would be the better solution. Or a ARM9 based frontend if you want to use it via another entrypoint.
I like this idea though :)
 
  • Like
Reactions: WhoAmI? and Mrrraou
rxTools rebirth ? :P
Having the possibility to firmlaunch from GodMode9 would be great, yeah. A all-in-one CFW would be awesome for sure.
well, rxTools doesn't have the tools anymore.
It might be too much trouble to maintain a CFW and the tools so it's probalby best to keep them separated.
 
Would this work with a9hl loader?
You mean GodMode9 or Decrypt9? At the moment, you only have partial functionality for GodMode9 and Decrypt9, because some stuff has to be initialised by the bootloader for it to work. I might find a complete workaround for GodMode9 (I already have an idea...), but for Decrypt9 it is unlikely.
 
  • Like
Reactions: WhoAmI?
I haven't tried A9LH yet, but you might need to use the ARM9 payload directly (Decrypt9.bin or Decrypt9.dat). Get yourself informed! ;)
The current A9LH stage2 payloads are setting up the framebuffers with GW addresses, and setting up the framebuffer struct like CakeHax.
And you need to use the .bin, as arm9loaderhax is a Brahma-like.
 

Site & Scene News

Popular threads in this forum