AES key scrambler

Discussion in '3DS - Homebrew Development and Emulators' started by Suiginou, Dec 27, 2015.

  1. Suiginou
    OP

    Suiginou (null)

    Member
    565
    588
    Jun 26, 2012
    Gambia, The
    pc + 8
    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.
     
    Last edited by Suiginou, Jan 1, 2016 - Reason: Game over. Reisyukaku wins.
  2. Duo8

    Duo8 I don't like video games

    Member
    3,444
    1,144
    Jul 16, 2013
    If the normal key is the result of keyx and keyy is it not possible to just run them through the scrambler then get the result?
    Is it known whether dev units have the same keyscrambler or not?
    What if the keyscrambler was built to prevent exactly this?

    One of those times one'd wish the decapping wasn't a scam
     
  3. Suiginou
    OP

    Suiginou (null)

    Member
    565
    588
    Jun 26, 2012
    Gambia, The
    pc + 8
    See OP:
    You can only write, but not read normalkeys. There's a slight weakness regarding that but only for the DSi keyslots (section "DSi / 3DS-TWL key-generator" on 3dbrew/3DS_System_Flaws#Hardware), so it's useless in this scenario.

    As far as I know, that's unknown. If retail NCCHs/CIAs run without modification, it's likely they have the same key scrambler.
     
    Syphurith likes this.
  4. Duo8

    Duo8 I don't like video games

    Member
    3,444
    1,144
    Jul 16, 2013
    But dev units don't run retail content. Either the keys or the scrambler or both.
    Also, again, is it possible that it was built to prevent guessing?
     
  5. Suiginou
    OP

    Suiginou (null)

    Member
    565
    588
    Jun 26, 2012
    Gambia, The
    pc + 8
    And pretty much no way of finding that out unless we have a way to dump bootroms.

    Probably. Maybe. Who knows, not like it makes much of a difference.
     
  6. windwakr

    windwakr GBAtemp Fan

    Member
    483
    112
    Sep 13, 2009
    United States
    It has been revealed today by plutoo, during their talk at 32c3 that the 3DS' AES keyscrambler is:
    Code:
    (((keyX ROL 2) XOR keyY) + SECRET) ROL 87
    
    He revealed that there are 3DS AES normalkeys embedded somewhere in the Wii U for some of the keyslots in the 0x31-0x39 range. One of those is also embedded in the 8.1 3DS firmware(N3DS only?).

    Using the normalkey and some messing around with different keyYs, you can work out the secret value.
     
    Last edited by windwakr, Dec 28, 2015
    Suiginou and nanika like this.
  7. OctopusRift

    OctopusRift GBATemp's Local Octopus, Open 9am-2am. "Not Yet"

    Member
    1,460
    832
    Nov 19, 2014
    Saint Kitts and Nevis
    That's really cool guys. Actual progress... NOW GET ME A 9.6+ N3DS OTP DUMP.
     
  8. Bug_Checker_

    Bug_Checker_ GBAtemp Advanced Fan

    Member
    950
    444
    Jun 10, 2006
    United States
    Warning: Spoilers inside!

    It may be easier for people searching to look for :

    FFFEFB4E295902582A680F5F1A4F3E79h

    http://ngemu.com/threads/dsi-aes-unit-fully-reversed.169857/
     
  9. KazoWAR

    KazoWAR GBAtemp Advanced Maniac

    Member
    1,818
    694
    Aug 12, 2008
    United States
    Winter Haven
    I am a little confused. He gave us the formula for the key scrambler and tells us how to brute force it to solve for KeyX and C, but only tells us where to find one NKey and KeyY pair, in the 2 3ds firmwares. but his example showed using 2 pairs of keys to bruteforce it. he also said normal keys are in the wiiu but said since the one pair is in the 2 N3DS fimwares, the wii u is no longer needed.
     
    OctopusRift likes this.
  10. windwakr

    windwakr GBAtemp Fan

    Member
    483
    112
    Sep 13, 2009
    United States
    Like he said in the presentation, a small change in keyY is a small change in the normalkey. So, you can change one bit in the keyY and bruteforce the new normalkey from the old one, by flipping a bit or two.
     
    Last edited by windwakr, Dec 28, 2015
  11. KazoWAR

    KazoWAR GBAtemp Advanced Maniac

    Member
    1,818
    694
    Aug 12, 2008
    United States
    Winter Haven
    but how do we see this second normal key? the whole point of the keyscrabmler and hardware AES was to hide the normal keys.

    keyY goes in, XORPAD comes out
     
  12. windwakr

    windwakr GBAtemp Fan

    Member
    483
    112
    Sep 13, 2009
    United States
    After changing a bit in the keyY, encrypt something(like all 00s) and save the output. The randomly flip a bit or two in the normalkey you have until encrypting using that with the same input gives the same output as the 3DS.
     
    Last edited by windwakr, Dec 28, 2015
    Syphurith likes this.
  13. KazoWAR

    KazoWAR GBAtemp Advanced Maniac

    Member
    1,818
    694
    Aug 12, 2008
    United States
    Winter Haven
    Oh! I get it now.
     
  14. Suiginou
    OP

    Suiginou (null)

    Member
    565
    588
    Jun 26, 2012
    Gambia, The
    pc + 8
    Clearly, plutooo made some progress. To solve the equataion normalkey = (((keyX <<< 2) ^ keyY) + C) <<< 87, we still need a triplet, but he gave us pretty much a good framework.

    The problem is now finding a normalkey with a keyX or a keyY.
     
    Last edited by Suiginou, Dec 28, 2015
  15. KazoWAR

    KazoWAR GBAtemp Advanced Maniac

    Member
    1,818
    694
    Aug 12, 2008
    United States
    Winter Haven
    He said in the talk, nintendo in a rush to support amiibo, used a normal key in the NFC crypto for Firmware 8.1, but later fixed it by changing it to a keyY in 9.3. so you can get the key pair from those 2 firmwares.

    also its (((keyX <<< 2) ^ keyY) + C) <<< 87

    I have a pretty good understanding of what to do math wise. I just dont have the key pair and the means to generate the 128 xorpads.
     
  16. Suiginou
    OP

    Suiginou (null)

    Member
    565
    588
    Jun 26, 2012
    Gambia, The
    pc + 8
    You're aware the ARM9 NATIVE_FIRM part is like 558 kByte of code mixed with data and finding the key in there is a needle in a haystack.
     
  17. Duo8

    Duo8 I don't like video games

    Member
    3,444
    1,144
    Jul 16, 2013
    Unless they obfuscated it a disassembly should show.
     
    KazoWAR likes this.
  18. Suiginou
    OP

    Suiginou (null)

    Member
    565
    588
    Jun 26, 2012
    Gambia, The
    pc + 8
    Code:
    $ arm-none-eabi-objdump -b binary -m arm -D arm90.bin|wc -l
    142684
    I'm not sure how fast you can read disassemblies, but one hundred and forty-two thousand instructions mixed with data (plus a few redumps because objdump isn't clever enough to detect switches to Thumb mode) seems like a lot to sift through.

    When I have time, I'll instead try:

    1. Encrypt all-0 with keyslot 0x39 as-is. Save that result.
    2. Read ARM9 binary for firmware 9.3. For each offset, read 16 bytes, set those as keyY and see if encrypting all-0 matches the result from before.
    3. Read ARM9 binary for firmware 9.0. For each offset, read 16 bytes, set those as normalkey and see if encrypting all-0 matches the result from before.

    EDIT: That plan seems to have failed with the step for the 9.3 keyY already.
     
    Last edited by Suiginou, Dec 28, 2015
  19. Xenon Hacks

    Xenon Hacks GBAtemp Guru

    Member
    7,125
    3,424
    Nov 13, 2014
    United States
    I still don't understand the whole 87 rotation equation bit :unsure: or how the Wii U came into play
     
  20. Suiginou
    OP

    Suiginou (null)

    Member
    565
    588
    Jun 26, 2012
    Gambia, The
    pc + 8
    The 87 rotation was derived just by observing output when flipping bits in the keyY.

    The Wii U didn't come into play at all in the end. Originally, the plan was to use the Wii U to obtain normalkeys to then derive a keyX from a keyY and normalkey to find the constant. Because the Wii U and the 3DS can communicate with each other and/or have to support the same features, such as decrypting Mii QR codes, but the Wii U doesn't use a key scrambler, the Wii U must hold the corresponding normalkey, whereas the 3DS may just derive the key from a set of keyX/keyY.
     
    Xenon Hacks likes this.