Sighax.md

This is being hosted here, until the reddit post I made gets approved.

I saw, in the recent reddit thread about sighax, a lot of information being posted that's factually incorrect. I'd like to go ahead and clarify how sighax works, and how it's different from arm9loaderhax, while also clearing up some misconceptions I'm seeing (I really dislike misinformation).

What is sighax?

Sighax is an exploit taking advantage of a flaw in the arm9 bootrom, causing the signatures (which those of you less technically oriented may think of as "proofs of authenticity" that normally only Nintendo can generate) for arbitrary firmwares to be read as valid. On a normal boot, if one modifies the header for the firmware partition stored in NAND, the signature's proof of authenticity will fail to validate, and the firmware will be rejected. Sighax allows us to make every modified firmware header read as valid, and thus allows for loading custom code from the NAND's firmware partitions.

Why isn't sighax released?

Sighax will require the community to perform a large brute-force effort in order to find a "perfect" signature valid for every firmware. However, in order to know what constitutes a perfect signature, we will need to review the code used to parse signatures in the protected arm9 bootrom. The arm9 bootrom hasn't been dumped publically, which is why sighax has not been released.

Derrek, the person who posted the tweet about sighax earlier today has dumped the arm9 bootrom privately, and performed the brute force to find the "perfect" signature for sighax. However, he did not release sighax when he revealed the exploit at 33c3, and there's no reason in particular to expect him to do so any time soon.

What does sighax allow us to do?

To understand what sighax lets us do, first we've got to understand what happens when the 3DS turns on, and what arm9loaderhax does. When a 3DS turns on, the bootrom reads firmware into memory, validates it, and, if it's valid, locks itself out and launches the firmware.

In arm9loaderhax, a quirk in a particular firmware revision is taken advantage of. In particular, the New 3DS has an intermediary bit of code referred to as the "arm9loader" or "kernel9loader" that runs before the actual firmware does. arm9loader is responsible for decrypting the new 3DS firmware using keys stored in NAND (using the OTP to do so before locking it out), and then launching it. Arm9loaderhax takes advantage of poor validation of this key in a particular revision of arm9loader in order to gain control before firmware is launched.

Sighax, on the other hand, replaces the firmware partition directly - the bootrom loads our firmware, instead of arm9loader.

We thus have the following control flow charts:

• Normal boot: Bootrom -> [Bootrom lockout] -> Arm9loader -> [OTP lockout] -> Firmware
• arm9loaderhax boot: Bootrom -> [Bootrom lockout] -> Arm9loader -> [OTP lockout] -> [Our hax].
• Sighax boot: Bootrom -> [Bootrom lockout] -> [Our hax]

When viewed as such, it's much easier to understand how sighax is different from arm9loaderhax. Very importantly, in both arm9loaderhax/sighax boots, original nintendo firmware is not loaded - our hax runs instead. In arm9loaderhax, we gain execution after Arm9loader and OTP lockout, but before firmware. Under sighax, we gain execution when arm9loader does - before OTP lockout.

Further, sighax is an exploit earlier on in the boot chain - and thus it has fewer prerequisites. Arm9loaderhax requires us to dump the OTP in order to perform the calculations required to create the malicious, exploitive keys (unless you use risky OTPless installation methodologies). Sighax has no such requirement.

In addition, because sighax's exploit happens before the bootrom is locked out (though we don't gain control until afterwards), we can actually use it to dump the ARM11 protected bootrom.

A public sighax release will likely do exactly what arm9loaderhax does -- load a payload off of the SD card, and then launch it.

Thus, we can create the following lists:

Things sighax allows that arm9loaderhax doesn't:

• Execution without the OTP region being locked out.
• Unfixable installation for anyone with a hardmod or an arm9 exploit.
• Dumping of the ARM11 protected bootrom.
• There could potentially be further vulnerabilities that, combined with sighax, could allow for dumping of the ARM9 protected bootrom. This is kind of moot, though, since sighax will require a dump of the ARM9 protected bootrom to release.
• A cleaner execution environment for developers.

Things sighax does not allow, but people seem to think it does:

• "True CFW" instead of "patches to existing firmware". This is just silly. Arm9loaderhax runs before firmware is loaded, as you can see in the above control flow chart. "True CFW" is fully possible with arm9loaderhax, but nobody has implemented one.
• Pretty much anything not listed under the list above this one.

I hope this is informative, and clears up some of the misconceptions I've seen going around.

The whole idea of "True CFW" sounds funny.

I wouldn't really see the purpose. We need to update the OFW regularly to access online and such, so just merging it with Luma would probably mess some stuff up.

Arm9loaderhax requires us to dump the OTP in order to perform the calculations required to create the malicious, exploitive keys (unless you use risky OTPless installation methodologies).

How is it malicious? Other than from Nintendo's point of view, I mean.

good. true cfw
i m writing by boot9strapped 3ds here because i ve readed on lumaupdater sighax