CXI decryption bug

[Reisyukaku]

Theres an issue with the NCCH decryption when i try to decrypt stuff from CDN. It's a pain to make a cia just to decrypt the CXI/NCCH, so I use openssl on PC to decrypt the cbc layer and use this for NCCH crypto. I use the -nopad flag in openssl so that the padding isnt truncated, causing the filesize to be different than the ncch header says, so I'm not sure why this fails. Also seems D9 sets the ncch header to show as nocrypto regardless of pass or fail. CXI decryption is fine in CIA though.

Heres what the command looks like incase its something i can fix on my end: openssl enc -aes-128-cbc -d -K %key% -iv 00000000000000000000000000000000 -nosalt -nopad -in %~nx1 -out %~nx1.bin

i have it in a batch file, hence the weird variables.

[d0k3]

Four things to try:

• Show me the log of a failed decrypt
• Actually make sure the file size matches or exceeds the size in the NCCH header (offset 0x104, multiplied by 0x200)
• Extract the (encrypted) CXI from the CIA and hex compare
• Try to decrypt the CXI in GodMode9 (!)

Other than that, I may be able to provide something to automate this. What tool are you using for CDN downloads, and how would a typical output (folder content) from that tool look like (screenshot maybe)? Where do you get the %key% from?

[Reisyukaku]

Initializing SD card... success
Build: Decrypt9WIP (2017/01/29)
Work directory: /
Game directory: /D9Game
sector0x96 Key: loaded, stored
0x03 KeyX & KeyY: automatically set up
0x05 KeyY: automatically set up
0x25 KeyX: loaded, verified, set up
0x18 KeyX: already set up
0x1B KeyX: loaded, verified, set up
0x24 KeyY: automatically set up
Finalizing Initialization...

Initialization: success!

Selected: [NCCH/NCSD Decryptor]
Opening /D9Game ...

Processing NCCH "00000009.bin"
Code / Crypto: CTR-M-HMEE-00 / Standard
Decrypt ExHdr/ExeFS/RomFS (0kB/0kB/46MB)
Verify ExHdr/ExeFS/RomFS: -/-/Fail
Failed!

NCCH/NCSD Decryptor: failed!

Press B to return, START to reboot.

And yes, like i said, i did make sure the size was the same, thats why i started using the -nopad flag because before it wasn't. I could try the other two suggestions in the meantime and report back. Also i'm not using tools for CDN, i have the url in my history and i ping it directly. Also %key% is a batch variable for input string. I input the decrypted title key and the crypto obviously seems to be working since the NCCH is plaintext.

Edit: GM9 yields same result

[d0k3]

Okay. Make sure you use the most recent GM9 nightly from here (if it works, otherwise build yourself): https://d0k3.secretalgorithm.com/

You can still shallow decrypt the CIA in D9, extract it in ctrtool, and compare what you have with the CXI you decrypted via openssl.

Btw, I rather meant where you got the titlekey from. CDN doesn't allow ticket downloads, right?

Can you contact me in a PM? GBAtemp or IRC (#Cakey or #3dsdev) works.

[Reisyukaku]

I'll leave my notes here for future reference i suppose. Comparing content which CBC layer was decrypted via D9 (via cia shallow mode) vs openssl cbc mode yields a difference of usually 1 byte, sometimes a few more.. in all my tests they have been in the RSA sig, and the rest of the file is identical. I have no idea why this should still fail since you dont need the RSA to decrypt. Changing those bad RSA bytes in my openssl decrypted ncch to the ones in the D9 decrypted ncch, it then succeeds, thus proving to me, the RSA sig has some weird effect on the ncch decryption process. Edit: Seems you need to set IV where first u16 is the content index and then trailing 0s, so 16 digits in total. So its both an openssl issue on my end, and a weird issue with D9 and the RSA.

[d0k3]

Well, let me guess, the difference of 1 byte is actually in the first 16 byte of the signature, right? These 16 bytes are used in the decryption process, as a keyY. Thus, if you change only one byte in there, decryption must fail.

[Reisyukaku]

Ohhh, thats right, how could i forget! Welp problem solved then. Just need to use the proper IV, etc It only worked for me in some cases since i was already using a 00 iv when decrypting 00 contents.