The AES key scrambler is annoying, I think we all agree on that. It's the reason we need a physical 3DS to decrypt titlekeys or do NCCH crypto. For other things, we need a physical 3DS not only because the key scrambler is unknown but also the keys are set by the bootroms, which we simply don't have, except maybe Yellows8.
Terminology: The scrambler function is used over keyX and keyY to yield a normalkey. The normalkey is then used to perform AES operations.
What we have
@Reisyukaku released a pastebin (username is the same on pastebin as on here) with a link to a Google Docs spreadsheet that contains the constant C and a list of known/unknown keyX/keyY.
Base formula: normalkey = (((keyX ROL 2) XOR keyY) + C) ROL 87
C is kept secret for whatever reason. You're on your own to find it. I have no idea why people are making a big deal about this, but whatever. I'll post it here when it lands on 3dbrew.
Some pointers:
In N3DS NATIVE_FIRMs 8.1 and 9.0, a normalkey for slot 0x39 can be found for NFC crypto. In N3DS and O3DS NATIVE_FIRMs, the key for 0x39 instead was changed to the corresponding keyY. This is embarrassing, Nintendo.
You have an easier time a physical N3DS to do the decryption of the arm9bins for 8.1/9.0/9.3+ on N3DS NATIVE_FIRM, however. However, the keys for 8.1-9.0 NATIVE_FIRM decryption have been leaked, so you can do it on an O3DS as well. Furthermore, there is a fully decrypted (arm9bin included) NATIVE_FIRM image floating around the Internet.
plutoo detailed in his part of the 32C3 talk (starts around 1h19min58s in) that (x <<< 2) ^ y0 < (x <<< 2) ^ y1, where y0 == y1 except for one bit and y0 shares that bit with keyX. This works because xor yields 0 for an identical bit.
@Myria elaborated on how their team found keyX and C.
@windwakr published a tool that aids in finding C as well.
For verification of your progress:
SHA-1(keyX_{0x39}) = cd40801bb34b8a9fe5bd58ad60471f6b88764c57
SHA-1(keyY_{0x39}) = 801fc53b2273939c6a193f3669e07ba990c6b57d
SHA-1(normalkey(keyX_{0x39}, keyY_{0x39})) = d659322804415d53ce0c7f6699e3e2d6c8777056
SHA-1(C) = 90ee1ff29fd7032176ad6d2222fa01c84ba6bf88
What can be done with it
0x16: arm9loader keyslot, used starting with 9.5. For firmware version 9.5, keyX and keyY are known. This is not yet the case for 9.6 and later (and as far as I know they use the OTP region somehow), however.
0x25: The 7.x keyslot. We have the keyX readily available on the Internet, the keyY is just taken from the signature of the NCCH to decrypt.
0x39: All keys known for Amiibo NFC key generation. For download play traffic, the keyX is the same, but the keyY differs. The DLP keyY is stored in NATIVE_FIRM somewhere.
Terminology: The scrambler function is used over keyX and keyY to yield a normalkey. The normalkey is then used to perform AES operations.
What we have
@Reisyukaku released a pastebin (username is the same on pastebin as on here) with a link to a Google Docs spreadsheet that contains the constant C and a list of known/unknown keyX/keyY.
Base formula: normalkey = (((keyX ROL 2) XOR keyY) + C) ROL 87
C is kept secret for whatever reason. You're on your own to find it. I have no idea why people are making a big deal about this, but whatever. I'll post it here when it lands on 3dbrew.
Some pointers:
In N3DS NATIVE_FIRMs 8.1 and 9.0, a normalkey for slot 0x39 can be found for NFC crypto. In N3DS and O3DS NATIVE_FIRMs, the key for 0x39 instead was changed to the corresponding keyY. This is embarrassing, Nintendo.
You have an easier time a physical N3DS to do the decryption of the arm9bins for 8.1/9.0/9.3+ on N3DS NATIVE_FIRM, however. However, the keys for 8.1-9.0 NATIVE_FIRM decryption have been leaked, so you can do it on an O3DS as well. Furthermore, there is a fully decrypted (arm9bin included) NATIVE_FIRM image floating around the Internet.
plutoo detailed in his part of the 32C3 talk (starts around 1h19min58s in) that (x <<< 2) ^ y0 < (x <<< 2) ^ y1, where y0 == y1 except for one bit and y0 shares that bit with keyX. This works because xor yields 0 for an identical bit.
@Myria elaborated on how their team found keyX and C.
@windwakr published a tool that aids in finding C as well.
For verification of your progress:
SHA-1(keyX_{0x39}) = cd40801bb34b8a9fe5bd58ad60471f6b88764c57
SHA-1(keyY_{0x39}) = 801fc53b2273939c6a193f3669e07ba990c6b57d
SHA-1(normalkey(keyX_{0x39}, keyY_{0x39})) = d659322804415d53ce0c7f6699e3e2d6c8777056
SHA-1(C) = 90ee1ff29fd7032176ad6d2222fa01c84ba6bf88
What can be done with it
0x16: arm9loader keyslot, used starting with 9.5. For firmware version 9.5, keyX and keyY are known. This is not yet the case for 9.6 and later (and as far as I know they use the OTP region somehow), however.
0x25: The 7.x keyslot. We have the keyX readily available on the Internet, the keyY is just taken from the signature of the NCCH to decrypt.
0x39: All keys known for Amiibo NFC key generation. For download play traffic, the keyX is the same, but the keyY differs. The DLP keyY is stored in NATIVE_FIRM somewhere.
Last edited by Suiginou,
, Reason: Game over. Reisyukaku wins.