4dsdev
Views: 1,609,240 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-21-24 11:45 AM
Guest:

0 users reading What is special about homebrew zero key encryption? | 1 bot

Main - Homebrew discussion - What is special about homebrew zero key encryption? Hide post layouts | New reply


d0k3
Posted on 11-10-15 10:43 AM (rev. 2 of 11-10-15 10:45 AM) Link | #700
As some of you might already know, my own fork of Decrypt9 has options to decrypt NCCH/NCSD and CIAs. The NCCH/NCSD decryptor works fine with commercial CCIs and system apps, however I noticed just yesterday, that this isn't the case for homebrew .3DS files. If I try to decrypt them the same way, I just get broken output. So, what is different about the encryption in those (this is zero key encryption, right?), and how can I detect it? CTRtool and Makerom seem to handle that encryption just fine, but I haven't found the correct place in their source codes yet.

On another, slightly related note... I can decrypt homebrew CIAs just fine, but the content hashes in there seem to be all wrong. Again, there never was any trouble with verifying the hashes for commercial stuff (legit CIAs / custom CIAs from Riku's converter / CIAs built from CDN). Any ideas about that?

If you need an example, btw, just check my own CTRXplorer or FBI.

Dazzozo
Posted on 11-10-15 10:55 AM Link | #701
Posted by d0k3
(this is zero key encryption, right?), and how can I detect it?


Yes. The FixedCryptoKey bit is set. See http://3dbrew.org/wiki/NCCH#NCCH_Flags

The key used (fixed / zero) depends on whether its a system title. This is all explained at http://3dbrew.org/wiki/NCCH#Encryption

d0k3
Posted on 11-10-15 11:09 AM Link | #703
Posted by Dazzozo
Yes. The FixedCryptoKey bit is set. See http://3dbrew.org/wiki/NCCH#NCCH_Flags

The key used (fixed / zero) depends on whether its a system title. This is all explained at http://3dbrew.org/wiki/NCCH#Encryption

Alright, so with that flag set, a fixed key is used as AES NormalKey for encryption and everything else works as normal? I assume the zero key is all zeroes, and the systemkey is unknown. Because of the all-zeroes key, no actual hardware is needed for de-/encryption, but actual hardware would be required for decrypting with the fixed systemkey. Also, does this work with 7x / seed crypto? (might only make sense in theory)

Plus, the thing about the hashes in homebrew CIAs... any ideas?


Dazzozo
Posted on 11-10-15 11:57 AM Link | #705
Posted by d0k3
Alright, so with that flag set, a fixed key is used as AES NormalKey for encryption and everything else works as normal?


Yep.

Posted by d0k3
I assume the zero key is all zeroes


Yep.

Posted by d0k3
and the systemkey is unknown.


It's known, but I don't think it has been posted anywhere yet.

Posted by d0k3
Because of the all-zeroes key, no actual hardware is needed for de-/encryption, but actual hardware would be required for decrypting with the fixed systemkey.


They're both normal keys, intended for debug.

Posted by d0k3
Also, does this work with 7x / seed crypto? (might only make sense in theory)


Neither, it doesn't make sense. A normal key is set when FixedCryptoKey is set, and the production NCCH keyXs and title keyY (regardless of generation method) aren't used. Process9 basically prioritises the different flags based on common sense.

Posted by d0k3
Plus, the thing about the hashes in homebrew CIAs... any ideas?


I can verify the hashes on your CTRXplorer CIA. So it just sounds like something's broken, haha.

d0k3
Posted on 11-10-15 04:40 PM Link | #706
Posted by Dazzozo
-- Snip --

Got it, and both of it. For the CIAs the problem was that I did not recognize that Metadata comes at the end of the file structure. Thanks a ton!


Main - Homebrew discussion - What is special about homebrew zero key encryption? Hide post layouts | New reply

Page rendered in 0.013 seconds. (2048KB of memory used)
MySQL - queries: 28, rows: 73/73, time: 0.006 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.