Full Report
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!
Analysis Summary
# Vulnerability: Wii U eFuse Reset Persistence Glitch (JTAG/Security Lockout Bypass)
## CVE Details
- **CVE ID:** N/A (Consoles often do not receive formal CVEs for hardware glitches discovered post-lifecycle)
- **CVSS Score:** 6.8 (Medium/High - Physical access required)
- **CWE:** CWE-1274: Improper Restoration of Register Values After Reset
## Affected Systems
- **Products:** Nintendo Wii U Console
- **Versions:** All retail hardware revisions (Production units)
- **Configurations:** Systems where eFuses are blown to production mode (disabling JTAG and enforcing signature checks).
## Vulnerability Description
The vulnerability lies in the hardware's transition from NRST (Negative Reset) to the initialization of security registers from eFuses. Upon powering on/resetting, the system reads 8 banks of 0x80 bytes (total 0x400 bytes) from eFuses into a register file. This process is controlled by a counter that decrements on every rising clock edge.
A critical state-machine flaw exists: when a hardware reset (NRST) is triggered, the **eFuse register file** is cleared to zero, but the **read counter** is not reset. By pulsing the reset line at a precise time during the boot sequence, an attacker can interrupt the write process. On the subsequent boot cycle, the system only writes the remaining `0x400-N` bytes. This leaves the first `N` bytes of the security register file as `0x00`, effectively nullifying security protections such as JTAG lockouts, signature checks, and encryption requirements which are typically enabled by non-zero fuse values.
## Exploitation
- **Status:** PoC demonstrated; modchip implementation successful.
- **Complexity:** High (Requires precise timing, hardware modification, and voltage/pulse glitching equipment).
- **Attack Vector:** Physical (Requires internal access to the motherboard and GPIO/Reset lines).
## Impact
- **Confidentiality:** High (Allows extraction of per-console cryptographic keys and OTP data).
- **Integrity:** High (Disables signature checks, allowing custom firmware and homebrew execution).
- **Availability:** Low (Risk of permanent hardware corruption if glitching is performed incorrectly).
## Remediation
### Patches
- **Hardware Revision:** No software patch can fix this flaw as it is rooted in the silicon logic of the eFuse controller and reset state machine. Only a hardware revision (SOC stepping) would mitigate this.
### Workarounds
- **User Side:** There are no practical workarounds for users to prevent this, though the physical nature of the attack means a console is only at risk if the attacker has hands-on access.
## Detection
- **Indicators of Compromise:** Physical evidence of tampering (soldering on the motherboard, presence of a modchip).
- **Detection Methods:** Monitoring the boot timing or GPIO LED patterns; however, this is not feasible for standard retail operation.
## References
- **Original Post:** hxxps[://]fail0verflow[.]com/blog/2013/espresso/ (Historical context for Wii U security)
- **Glitching Research:** hxxps[://]github[.]com/shinyquagsire23/ (Related research into Wii U/Wii Mini glitching vectors)