Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The goal of this post for the author was created a modchip for the Wii U. It has a few known vulnerabilities, but not ever many good for homebrew. Additionally, the Wii's encrypted per-console OTP is known to corrupt and not be fixable.

The Wii U has individual cryptographic keys for each console, which means there are unique images per device. There are security fuses configured to disable encryption and sigchecks entirely. This separates the production from development devices. These are provisioned via JTAG, which is locked via eFuses as well.

eFuses are like fuses in a house. Sometimes, they are literal wires that are blown up; other times, they are EPROMS that can be reset via UV light. One way of turning on the developer functionality would be changing the fuses values (which is supposed to be impossible to do) or glitching the system to read these incorrectly.

The Wii U read the eFuses into registers as soon as the device turns on. There are 8 banks of 0x80 bytes. A counter decrements the fuse bit going all the way down to 0 prior to writing. Knowing on the data is read in and when this happens changes how to perform the attacks.

Initially on the Wii Mini (separate project), they tried glitching a very particular branch instruction for verification. While doing this, they found a path that made all of the OTP fuses zero. If the security level could be set to 0, that'd be perfect for turning off all of the security protections. The author wanted which boot stage they were at; this is outputted by LED GPIOs, which is nice for detecting when to glitch.

The first successful glitch was trying to do reset based attacks. By inserting one small pulse (less than a clock signal wide) into boot0, the signature verification succeeded! Sadly, no signs of life within boot1. After this, they tried undervolting to the same effect. Eventually, they bumped the wire connected to reset and got a success! But why?

From my understanding, they reverse engineered the firmware to find the true root cause. To support the eFuse JTAG lock, eFuse bits are buffered into a registry file right after NRST. When doing this registry file write, the write occurs from least significant to most significant on every rising clock edge.

Here's the kicker: when NRST is triggered, the eFuse registry file to reset to zero but the counter for the remaining bytes to write is NOT. On the subsequent boot after the glitch, 0x400-N (N is bytes written prior to reset) bytes will read into the file. This means we can force bytes to be 0x00 in a consistent fashion, including the JTAG lockout fuse and other security bits.

Overall, an awesome post going into the nitty-gritty details of glitching and the magic behind it. Amazing work!