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 Code: k = (((x <<< 2) ^ y) + C) <<< 87 Solve for k Code: k = (((x <<< 2) ^ y) + C) <<< 87 Solve for x Code: 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 Code: 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 Code: 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!

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.

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..

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.

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

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.