Homebrew How to solve the AES key scrambler

[uyjulian]

I hope this information helps some people who have trouble figuring out the AES key scrambler.

k = normal key
x = keyX
y = keyY
C = constant

let's algebra !!!!

let's start with

k = (((x <<< 2) ^ y) + C) <<< 87

Solve for k

k = (((x <<< 2) ^ y) + C) <<< 87

Solve for x

k        = (((x <<< 2) ^ y) + C) <<< 87
  >>> 87                         >>> 87
(k >>> 87)     = ((x <<< 2) ^ y) + C
           - C                   - C
((k >>> 87) - C)     = (x <<< 2) ^ y
                 ^ y             ^ y
(((k >>> 87) - C) ^ y)      = x <<< 2
                      >>> 2     >>> 2
x = (((k >>> 87) - C) ^ y) >>> 2

Solve for y

k        = (((x <<< 2) ^ y) + C) <<< 87
  >>> 87                         >>> 87
(k >>> 87)     = ((x <<< 2) ^ y) + C
           - C                   - C
((k >>> 87) - C)              = (x <<< 2) ^ y
                 ^ (x <<< 2)  ^ (x <<< 2)
y = ((k >>> 87) - C) ^ (x <<< 2)

Solve for C

k        = (((x <<< 2) ^ y) + C) <<< 87
  >>> 87                         >>> 87
(k >>> 87)                   = ((x <<< 2) ^ y) + C
           - ((x <<< 2) ^ y) - ((x <<< 2) ^ y)
C = (k >>> 87) - ((x <<< 2) ^ y)

easy, right? You just need three variables to get one of them!

 

[Syphurith]

Well good if the implemented algorithm is that easy. But i've forgot the older one with function wrapper.
Now a implementation to just calculate the normal key with given KeyX or KeyY is needed, and I don't know how to do so.
There was a pair of KeyX/KeyY/CTR for N3DS 9.5 leaked but totally useless before, hope with its normal key we can use it to test out our recovery solution.
Wish the algorithm implemented in hardware is itself simple, or we may need to generate a lot of normal keys to get the curve of the function.
So steps: 1.calculate normalkey. 2.recover the algorithm, and constant C. 3.Use it to recover the KeyX/KeyY with anyslot that its counterpart is known.
Hope the solution is right.. wait we can check it using the keys leaked.

 

[Suiginou]

Well good if the implemented algorithm is that easy. But i've forgot the older one with function wrapper.
Now a implementation to just calculate the normal key with given KeyX or KeyY is needed, and I don't know how to do so.
There was a pair of KeyX/KeyY/CTR for N3DS 9.5 leaked but totally useless before, hope with its normal key we can use it to test out our recovery solution.
Wish the algorithm implemented in hardware is itself simple, or we may need to generate a lot of normal keys to get the curve of the function.
So steps: 1.calculate normalkey. 2.recover the algorithm, and constant C. 3.Use it to recover the KeyX/KeyY with anyslot that its counterpart is known.
Hope the solution is right.. wait we can check it using the keys leaked.

If you watch plutoo's presentation again, you need a normalkey and a keyY or keyX to actually make things happen, though. The 9.5 keyX/keyY is useless. Besides, we have a set of keyX/keyY already (7.x exefs/romfs crypto).

See also: The entirety of https://gbatemp.net/threads/aes-key-scrambler.406951/

The problem here is that normalkeys are very hard to come by. There was the example of the NFC normalkey in N3DS firmware 8.1/9.0 that got changed to a keyY in NATIVE_FIRM 9.3, but N3DSes seem to be fairly rare.

 

[Syphurith]

If you watch plutoo's presentation again, you need a normalkey and a keyY or keyX to actually make things happen, though. The 9.5 keyX/keyY is useless. Besides, we have a set of keyX/keyY already (7.x exefs/romfs crypto).
See also: The entirety of https://gbatemp.net/threads/aes-key-scrambler.406951/

I don't know if we can use the pair of keyX and keyY to calculate the normal one and get it out of the keyscrambler.
The 9.5 slot0x16 is useless before, and if it can not be used to check the recovery then that's useless afterwards (orz).
Still thanks for every effort made to the recovery..

UPDATE: Seen your post. So you can't read that out..

 

[Suiginou]

I don't know if we can use the pair of keyX and keyY to calculate the normal one and get it out of the keyscrambler.
The 9.5 slot0x16 is useless before, and if it can not be used to check the recovery then that's useless afterwards (orz).
Still thanks for every effort made to the recovery..

You can use keyX/keyY to calculate the normalkey once you have the constant C. The public doesn't have C yet, however. Figuring the key scrambler out has, at this point, nearly no practical applications. If you're here for usable hax, you're looking in the wrong place.

The current method presented by plutoo is to get a normalkey and a keyY and apply some bitwise logic to derive keyX and from there get C. The public, me included, is currently still stuck at the "find a normalkey" part.

 

[Syphurith]

You can use keyX/keyY to calculate the normalkey once you have the constant C. The public doesn't have C yet, however. Figuring the key scrambler out has, at this point, nearly no practical applications. If you're here for usable hax, you're looking in the wrong place.
The current method presented by plutoo is to get a normalkey and a keyY and apply some bitwise logic to derive keyX and from there get C. The public, me included, is currently still stuck at the "find a normalkey" part.

Not for the hax. I just want to know the progress on the calculations. Well I'm happy with my coldboot rx old 9.2.
So the normalkey is still blocking us. I'm quite sad but can not help with it then.

@Suiginou Eh.. Oh wait then why they said in the talk that bitflips the KeyY can be used to recover the KeyX (that sharing the same bit of produced normal key)? If their calculation is right but no way to get the normal one out? How do they figure this out.. That's weird.

 

[dark_samus3]

You can use keyX/keyY to calculate the normalkey once you have the constant C. The public doesn't have C yet, however. Figuring the key scrambler out has, at this point, nearly no practical applications. If you're here for usable hax, you're looking in the wrong place.

The current method presented by plutoo is to get a normalkey and a keyY and apply some bitwise logic to derive keyX and from there get C. The public, me included, is currently still stuck at the "find a normalkey" part.

I haven't gotten anything done with it, but I think the step most people missed is encrypt something on the 3ds, a file with all zeros... Then look at the result, flip a bit, repeat above process, look at what changed, record the change, rinse and repeat for all 128 bits of KeyY, then once KeyX is know (not sure but I think it is somehow derived in the results of the all zero file that was encrypted) all you need is C

 

[shinyquagsire23]

The problem though is that you can't find C itself without all three keys (keyX, keyY and normal), which is the tough part since you have to find keyX indirectly from a normal key and keyX without C. Doing it indirectly requires using the hardware keyscrambler for comparison so that's why it's actually difficult, you have to brute force finding the keyX somewhat.

 

[Psi-hate]

The problem though is that you can't find C itself without all three keys (keyX, keyY and normal), which is the tough part since you have to do it indirectly. Doing it indirectly requires using the hardware keyscrambler for comparison so that's why it's actually difficult, you have to brute force finding the keyX somewhat.

Rei says she has she just got the keyscrambler figured out and has it out of the way apparently.

 

[dankzegriefer]

Please, don't use maths in a text field. Use something made for maths.

 

[doctorgoat]

Please, don't use maths in a text field. Use something made for maths.

That's valid code in a text field.

 

[dankzegriefer]

That's valid code in a text field.

It's valid math in a code field. And hard to read.