Homebrew AES key scrambler

[Earth97]

The two unknown are...?

 

[dark_samus3]

The two unknown are...?

KeyY and the constant C

 

[Dazzozo]

The point was calculating a keyX with only keyY. Without the normal key this is not possible. The hardware does not (yet) leak normal keys.

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

KeyY and the constant C

C is not unknown in this context.

 

[Earth97]

Wait, wasn't normal key retrievable from WiiU?

 

[Dazzozo]

Wait, wasn't normal key retrievable from WiiU?

Some are. The NCCH keyslot is not (and the keyY and by extension the normal key is different for every NCCH).

The NCCH keyslot apparently shares a keyX with the UDS keyslot (and UDS normal key is apparently available on Wii U), however we don't know the UDS keyY since it is set by bootrom also, so there are still two unknowns.

 

[Earth97]

http://prntscr.com/9jynju
"Anyone who can decrypt 3DS firmware binaries can perform this attack to get the constant C(flipping the bits)"
What's the point in getting the constant he talks about? is it of any use?

 

[Dazzozo]

http://prntscr.com/9jynju
"Anyone who can decrypt 3DS firmware binaries can perform this attack to get the constant C(flipping the bits)"
What's the point in getting the constant he talks about? is it of any use?

If you have any two of: keyY, keyX, normal key.

You can calculate the one that you are missing.

Having the normal key allows you to do the crypto on any machine, without relying on the 3DS AES hardware.

 

[motezazer]

@Dazzozo Is the hash of the KeyY in this thread right? It doesn't match here (but it's perhaps my testing program's fault).
Link: http://gbatemp.net/threads/aes-key-scrambler.406951/page-4#post-5893342

 

[Earth97]

So, you've already calculated the keyX (having keyY and normal key), haven't you?
And, to get 9.6+ emuNAND, we need the key stored in the NCCH keyslot, which cannot be dumped even gaining access to 9.3+ sysNAND (ARM11 kernel or ARM9 kernel). Therefore, we need a bootrom dump, am I right?

 

[FR0ZN]

Wasn't the keyscrambler segment in the talk about actually BREAKING it ? Like figuring out the algorithm?
My understanding of it was, that the talk wasn't about gaining keys ... but knowing how to calculate the normal key ONCE you have keyY and keyX (which is a whole different story).

 

[Dazzozo]

Wasn't the keyscrambler segment in the talk about actually BREAKING it ? Like figuring out the algorithm?
My understanding of it was, that the talk wasn't about gaining keys ... but knowing how to calculate the normal key ONCE you have keyY and keyX (which is a whole different story).

Yes, as has been established many times over the last few pages. This is just considering future consequences/possibilities of knowing it, it's a key generation algorithm, so generating (unknown) keys with it has been discussed.

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

@Dazzozo Is the hash of the KeyY in this thread right? It doesn't match here (but it's perhaps my testing program's fault).
Link: http://gbatemp.net/threads/aes-key-scrambler.406951/page-4#post-5893342

$ sha1sum 0x39-NFC-keyY.bin
801fc53b2273939c6a193f3669e07ba990c6b57d *0x39-NFC-keyY.bin

seems legit.

 

[motezazer]

$ sha1sum 0x39-NFC-keyY.bin
801fc53b2273939c6a193f3669e07ba990c6b57d *0x39-NFC-keyY.bin

seems legit.

So my program seems wrong (excepted if the normal-key isn't "as-is" in N3DS Process9).
Thanks!

 

[FR0ZN]

Yes, as has been established many times over the last few pages. This is just considering future consequences/possibilities of knowing it, it's a key generation algorithm, so generating (unknown) keys with it has been discussed.

So no Nintendo Ultra 64 emulatorZ for me? (((((((((((((((((((((((((((((((((((

 

[Dazzozo]

So, you've already calculated the keyX (having keyY and normal key), haven't you?
And, to get 9.6+ emuNAND, we need the key stored in the NCCH keyslot, which cannot be dumped even gaining access to 9.3+ sysNAND (ARM11 kernel or ARM9 kernel). Therefore, we need a bootrom dump, am I right?

keyX of what?

For 9.6 New3DS you need a bunch of K9L keyXs initialized. The data used to generate those is locked off immediately after they're used for this key generation. This attack doesn't help you obtain those either, as you can't obtain a normal key from a system with them initialized.

 

[dark_samus3]

So, considering that there's only 128 bits for each key, could we, say, guess a KeyY (for the UDP, which we don't know)? If so (I'm guessing it's possible) how would we tell it what KeyX keyslot to use (guessing that something like Decrypt9 already has that sort of thing figured out)? Also how would we feed it the guessed KeyY? I'm really not sure how the keys are stored (are they always decrypted from NAND each time they're used? Or are they stored in the ARM9's RAM at runtime?)

 

[zecoxao]

aparently ryanrocks leaked keyY lol. hash matches

 

[Dazzozo]

aparently ryanrocks leaked keyY lol. hash matches

The keyY is really not important and takes seconds to find if you know where to look.

 

[motezazer]

aparently ryanrocks leaked keyY lol. hash matches

But even without his "help" we could just bruteforce any potential key of the FIRM until the hash matched...
Plus the key was easy to find, just look in the .rodata

 

[Dazzozo]

So, considering that there's only 128 bits for each key, could we, say, guess a KeyY (for the UDP, which we don't know)? If so (I'm guessing it's possible) how would we tell it what KeyX keyslot to use (guessing that something like Decrypt9 already has that sort of thing figured out)? Also how would we feed it the guessed KeyY? I'm really not sure how the keys are stored (are they always decrypted from NAND each time they're used? Or are they stored in the ARM9's RAM at runtime?)

There are 0x40 keyslots. They're this abstract isolated memory that the ARM9 cannot read, and can only be written to by interfacing with the AES hardware. Each keyslot has space to store its own keyY, keyX and normal key (so three keys). When the last machine word of a keyY is written to the keyY setting register, the key generator is automatically invoked, which processes the keyX and keyY according to the selected algorithm (at that time) and stores the resulting normal key in the normal key memory for that keyslot. You can also write a normal key directly and bypass the key generator entirely (and be able to reproduce AES crypto done on the 3DS on any PC without being concerned with the key generator this way).

When you select a keyslot, the key stored in the normal key memory is used for whatever AES operation you do next (this part is just standard AES)

To set a key, essentially: you select the keyslot and write the key to whichever register is relevant (keyY, keyX, normal key) and after 4 machine words are written (0x10 bytes) the key in the internal memory is updated. No other keyslots are affected by that, other than the one that was selected.

For specific examples of keys, you would need to provide some context, they're set and generated in different ways depending on their purpose. A lot of them are set by bootrom and as we don't have the bootrom, we don't know what they are.

 

[dark_samus3]

There are 0x40 keyslots. They're this abstract isolated memory that the ARM9 cannot read, and can only be written to by interfacing with the AES hardware. Each keyslot has space to store its own keyY, keyX and normal key (so three keys). When the last machine word of a keyY is written to the keyY setting register, the key generator is automatically invoked, which processes the keyX and keyY according to the selected algorithm (at that time) and stores the resulting normal key in the normal key memory for that keyslot. You can also write a normal key directly and bypass the key generator entirely (and be able to reproduce AES crypto done on the 3DS on any PC without being concerned with the key generator this way).

When you select a keyslot, the key stored in the normal key memory is used for whatever AES operation you do next (this part is just standard AES)

To set a key, essentially: you select the keyslot and write the key to whichever register is relevant (keyY, keyX, normal key) and after 4 machine words are written (0x10 bytes) the key in the internal memory is updated. No other keyslots are affected by that, other than the one that was selected.

For specific examples of keys, you would need to provide some context, they're set and generated in different ways depending on their purpose. A lot of them are set by bootrom and as we don't have the bootrom, we don't know what they are.

Ok so say we set a bunch of KeyY's to try and decrypt something (set each time we want to try ofc) can we basically brute force it? I don't think there's too ridiculous an amount of permutations (2^128 for each key right?)