Throwback: K9Lhax by Bruteforce
Given the recent topic of OTPless k9lhax installation on N3DS, I felt it would be interesting to mention the original hardware method of executing non-enhanced k9lhax on an N3DS. For the sake of documentation, this exploit was conducted in May 2015 cooperatively between myself, WulfyStylez and Dazzozo. I ended up being the one to conduct the actual hardware exploit and bruteforce while the 3DS software process was almost entirely done by WulfyStylez and Dazzozo.
The original k9lhax method was documented on 3dbrew on March 29, 2015 as “Missing verification-block for the 9.6 keys” (the dubbed name “arm9loaderhax” only came after 32c3 at the end of the year). The idea was fairly simple: By corrupting the second keystore key, FIRM would decrypt to garbage and that garbage has the potential to execute RAM. While RAM is completely cleared on boot, a reboot via MCU i2c will not clear RAM, setting up a vector for bruteforcing.
It is also important to note the reasons to even execute a one-time k9lhax at all: For one, the 7.x and 6.x encryption keys, used for games and saves respectively, are able to be gained at this point. The 7.x key was (presumably) sold to Gateway and then eventually leaked through reverse engineering their payloads. However, the 6.x save key was not known at all and was not used by Gateway, and the only way to utilize it was by booting a firmware version over 6.x, which was not a problem since most people stuck on 9.2 anyhow by this point. Needless to say, it’s still be nice to have this key. The real reason for performing the exploit, however, was a detrimental flaw which happens to Just Work in the particular spot of execution which k9lhax yields:
All of the new keys used on the New 3DS are derived from an encrypted keystore on NAND. This includes the game and save encryption keys for New 3DS games, encryption keys for FIRMs, etc. The encryption key used to decrypt this keystore is based on the hash of each console’s OTP, and as such the encrypted keystore is unique to each console, while the actual decrypted keystore is not. While the decrypted keystore and all intermediate keys are wiped after being set into the AES hardware, the SHA registers used to calculate the OTP hash were not, which meant that k9lhax = OTP hash = decrypted keystore. This meant completely breaking all added encryption measures on the New 3DS, and in practicality, decryption of newer games and emuNAND on 9.6 and above.
To conduct this exploit, I chose to use a Raspberry Pi B, simply because it was a device which could talk eMMC and i2c from the same device. For actually writing to the New 3DS NAND I used my trusty Anker card reader, which was able to remain plugged into the USB port while not restricting read access on the N3DS. Rather, it would only cause issues with N3DS reads when the Raspberry Pi itself went to read and write, which works perfectly in this case.
To determine when to stop brute forcing, and to increase the chance of success, the payload used was a small payload designed to shut off the New 3DS and nothing more. When the N3DS was off, the NAND writes and i2c probing would no longer work, and the key which remained would work for consistent k9lhax bootstrapping.
Finding the pads for i2c on the same bus as the MCU ended up being somewhat tricky, however looking for the NFC chip on the same bus yielded two pads which ended up being the ones needed:
From there, getting i2c to work with the Raspberry Pi took just a bit of effort due to the devices I was looking for not quite correlating to the IDs on 3dbrew, however I did eventually get success:
After hooking everything up and validating i2c, I ended up with this setup:
The bruteforce itself is somewhat boring, basically just watching things increment for a while:
Eventually, the N3DS would shut off with the correct key. At about one iteration every 7-10 seconds, a successful bruteforce would happen after about 30 minutes to an hour. Once the key was gained, it was possible to consistently bootstrap into post-K9L code execution:
From this point, the OTP hash and 7.x/6.x keys could be written to SD and then the entirety of New 3DS keys could be calculated and used on other consoles. As a bonus, the OTP hash could also be used for permanent k9lhax installation via enhanced-k9lhax, no downgrade required.