[Segmentation Fault]

Background - Why Wii U?

The Wii U has had a fairly small homebrew scene, I believe in part because it currently has no commercial nor open-source modchips for facilitating early-boot code execution. While there exists a coldboot boot1 vulnerability, isfshax, it leaves a lot to be desired, and it is unfortunately not useful for recovering consoles from an unknown state, since NAND is encrypted per-console based on an OTP key. Additionally, certain SEEPROM corruptions can cause consoles to never reach boot1, resulting in unrecoverable bricks (at least without drilling through the SoC substrate).

With the news that a handful of Hynix Wii U eMMCs were starting to rapidly degrade, I decided to revisit a recurring project idea of mine: an open-source Wii U modchip. I had originally started this endeavor by glitching the Wii mini, which at the time had not been hacked, however my efforts were quickly sniped by FullMetal5’s bluebomb (which later precipitated to Wii U by GaryOderNichts as bluubomb, however it is a different vulnerability). I did, however, manage to get boot1 execution on my Wii mini in a novel way: by inserting a voltage glitch shortly after reset, before the console started executing code, OTP had been cleared to zero. More on this in a bit.

boot0 and chip provisioning, on Wii

The Wii was extremely basic in how it handled booting: ROM was somewhat expensive (for die space, but also more likely, for chip revisions), so the Wii’s boot0 simply loaded boot1 from NAND, decrypted it with a key stored in ROM, and checked that its hash matched fused values in OTP. If it matched, it booted. However, there is one special case for factory-fresh console (and apparently dev units): If the OTP hash is entirely 00s, it will run anything that is loaded from NAND. More details are available on its WiiBrew page.

boot0 and chip provisioning, on Wii U

The Wii U is significantly more sophisticated in how it boots: the boot1 Ancast image can be loaded from either NAND or the SD card, images are specific to the hardware they are signed for (NAND vs SD card), signature pubkeys are specific to dev vs retail hardware configs, and security fuses can be configured to disable encryption and sigchecks entirely:

(Tumblr probably murdered the image resolution; An SVG is available here.)

Fuses on both the Wii and Wii U are provisioned via JTAG, and JTAG is locked out via its own eFuse, which is readable via OTP registers. I haven’t figured out if fuse cutting is done before or after the chip is soldered to the motherboard.

How do eFuses work?

‘eFuses’ technically encompass a large variety of different types of PROMs. On some devices, eFuses are just EPROMs which can be reset via UV light and decapping, on other devices they are more like the name implies: literal fuses which, when enough current is pushed through them, will physically disconnect and burn in a 1 bit.

eFuse sensing typically relies on a combination of current-sensing FETs, and a multiplexed array of resistive fuses. A sense voltage is applied across the fuse, and if the current passing through the fuse meets a blown threshold it is detected as a 1, otherwise a 0. This has three implications:

In order to allow the usage of eFuses for security lockouts (JTAG), there must be an initialization sequence in which the multiplexer iterates through each fuse and stores it to registers.
If eFuses are used for security lockouts, eFuses must be read immediately after reset, before any code executes.
Current sensing requires a fixed, stable voltage. An increased voltage will increase current, because the resistance of the eFuses are fixed. This might also mean that sensing is dependent on temperature, since semiconductors’ resistance decreases with temperature.

eFuse burning has even more logistics, and typically has its own dedicated voltage rail and incantations to verify the fuse cut correctly. There’s also some eFuse patents which indicate that some eFuse designs have error correction and redundancy.

Aside: A lot of the specifics on sensing are purely speculation, because like most things in silicon, IP component details aren’t even given to the chip designers, and designers especially aren’t given silicon-level details for partner IP without a lot of red tape. At best I can guess based on patents, but it’s almost certain that Nintendo did not design their eFuse sensing.

How do the Wii and Wii U read eFuses?

Both the Wii and Wii U read all fuses sequentially into registers as soon as reset is deasserted. On the Wii, OTP is only one bank of 0x80 bytes, whereas on Wii U this was upgraded to 8 banks of 0x80 bytes. A counter decrements from the highest eFuse bit (0x400 on Wii, 0x2000 on Wii U) down to 0. After the counter reaches 0, the internal reset is presumably released, and the rest of the hardware begins to boot.

On Wii U, fuse bits are latched at a rate of 4 bits per 27MHz cycle following reset deassertion, and bytes are shifted into the OTP registers every other cycle.

(It’s possible that it’s not actually 4 bits per cycle, but is instead 8 bits on one cycle and 0 bits on the next while it shifts the result to the register file; it’s impossible to know which it is without a really expensive microscope.)

Developing de_Fuse and Gaining Code Execution

In 2019, I experimented with attempting to glitch boot0 on the Wii mini, a console which at the time had not been hacked. The consoles were cheap, and the Wii is extremely well documented thanks to WiiBrew and the portablizing scene. While I had intended to glitch a branch instruction, I accidentally stumbled onto a more interesting vulnerability: One which left the OTP eFuses entirely zeroed, reliably, by glitching a few cycles after reset. The ChipWhisperer Python and reproduction docs can be found here.

I was curious if the same exploit would work on Wii U, and after looking at boot0 more carefully, it indeed had the same exact (potential) flaw if OTP happened to read all zeroes.

The plan for gaining code execution was as follows:

Make the security level u32 read as 0xxxxxxx.
Write a decrypted payload to NAND, or alternatively, trigger SD booting by setting the UNSTBL_PWR bit on the EXI bus.

This has several benefits (and a few downsides) over glitching branches in boot0:

Corrupted SEEPROM Wii Us are now recoverable, since CRC32 fails are ignored in factory provisioning.
Both NAND and SD card payloads are loaded decrypted, and without Ancast signature+header verification (boot1 payloads can coincide with an MBR, for instance).

The downsides:

OTP cannot be dumped, because it’s 00s now. Irrecoverably bricked consoles would require an OTP donor.
The boot0 SD card driver does not support SDHC (and especially doesn’t support SDXC) :(

First order of business was getting boot stage visibility: Each stage in boot0 is indicated by the value written to the NDEV_LED GPIOs. To make things easier on myself, I used an iCEBreaker with one PMOD handling the NDEV_LEDs and another handling reset, glitch triggering, and EXI overrides. While I’d wanted to have a proper EXI module, I settled for counting EXI clocks and using a p-channel MOSFET to force the line high when the UNSTBL_PWR bit is being read. For GPIO monitoring, I queued values into a UART FIFO when I detected any changes. I also made sure to run the FPGA at 27MHz to allow for cycle-precise timing, matching the Wii U.

Overall, I’m quite pleased with my setup. The PMODs and standoffs made it easy to flip the console over to access testpoints.

(via https://twitter.com/ShinyQuagsire/status/1638026420931936256)

Aside: The open-source ice40 toolchains are SO nice for quick iteration, so much better than Xilinx ISE and Vivado.

Because ~~I have commitment issues~~ the MOSFETs I ordered would take a week to arrive (and also to make sure my reset trigger works fine) I spent some time attempting to do reset-based attacks. By holding reset and then inserting one small (<=1 clock wide) reset pulse at a swept offset, I had hoped to find any weird partial reset behavior that may exist. Success was mixed: I discovered one range early into boot which would result in a successful signature check, meaning it verified the signature and jumped to boot1, but no signs of life from boot1 itself. This will be important later.

While waiting for MOSFETs, still, I decided to experiment with reset glitches combined with undervolting. I desoldered the two inductors from the 1V line to bring in my bench power supply, and I tied the 1V PGOOD snitch signal to GND by tying the solitary leg of Q1064 to GND, so that the SMC chip would stop shutting off the regulators and blinking the power LED red.

(via https://twitter.com/ShinyQuagsire/status/1641629325614272512)

Results were mostly the same, however I also got extremely lucky: in preparation, I had already flashed my SD card with a fork of minute, which is a fork of fail0verflow’s mini (I helped work on minute in 2017 and was fairly confident it would be a good base for a boot1 replacement). To be sure my payload would work correctly, I verified it with a zeroed OTP in Wii-U-Firmware-Emulator, an LLE Wii U emulator.

By some weird stroke of luck (what I assumed at the time was just me bumping the power wire), I pressed the button I wired to reset and was greeted with my success trigger: 0x88 flashing on the debug LED GPIOs. Despite not being able to recreate the glitch, this confirmed that my theory of the Wii U being vulnerable to the same 00’d OTP vulnerability, and I figured that surely the vulnerability would be 100x more reliable with a proper MOSFET-driven brownout, since this is how I achieved 00’d eFuses on Wii mini (and the Wii mini glitch was extremely consistent).

However, once my MOSFETs had arrived and I connected them up, voltage glitching also yielded no results, at least not via sweeping offsets: To experiment with pulse widths, I had wired one of my buttons to act as a manual trigger for a reset followed by a delayed MOSFET pulse. By some act of God, I had managed to find a consistent way to trigger 00’d OTP, which exclusively worked using my pushbutton. To my horror, it even worked when I disconnected my MOSFETs entirely, and it even worked when I stopped undervolting the 1.0V line.

Attempting to Clear the Fog of War

Why did I gain code execution only via my pushbutton? Button bouncing. My pushbutton just happened to bounce with the exact timing required to trigger de_Fuse. By counting the cycles between pushbutton bounces, I found the exact reset timing which characterized my pushbutton on a successful glitch. In fact, the automated timing was so consistent that I desoldered my MOSFET trigger wire and began work on making a boot1 replacement. This is where I began the post-mortem of understanding wtf was even going on.

My initial hypothesis was waves hands vaguely harmonics and current draw. The Wii U has an extremely sudden current draw when reset is released going from ~900mA to 1.5A, so maybe jumping from a high current draw to an extremely low one would glitch the fuse sensing to read 00s, especially since my provided power was significantly lower wattage (intentionally). There’s also some debate about whether capacitors help or hurt voltage glitching by dumping large amounts of current very suddenly following a glitch pulse, which then rings on the voltage line.

(It was not anything voltage-related, though.)

To facilitate faster development on my boot1 replacement, I developed a bitbanged serial driver so that I could dump data faster. At this point I hadn’t even dumped my OTP, because I figured it must be 00s, and was therefore not super interesting.

But it wasn’t 00s, there were ~0x40 bytes of valid OTP. Everything following the valid OTP readout was 00s. This did not fit my model at all, because there were no bitflips that you’d expect in a voltage glitch; what was loaded was pristine and exact.

I began to experiment with reset timings again, to understand what could possibly cause this. What I found was even weirder: As I increased the delay of my glitch reset, less data was loaded into OTP, instead of more. I could even see exactly how much was loaded with per-cycle granularity, and with some more notes I was able to control exactly how much OTP was read from the eFuses. The duration that I held down the glitch NRST did not matter either, meaning that this was not a brownout glitch. It was too consistent to be that.

de_Fuse, the One True Pwn

(aka, the section I’m copy-pasting into the Hardware Flaws page on WiiUBrew)

In order to accommodate eFuse-based JTAG lockout (and due to other considerations), eFuse bits must be buffered into a register file immediately following NRST, before the internal reset can be released. The eFuse sense state machine latches at a rate of 4 bits per cycle, directly off the 27MHz XTALCLK. Every other rising edge, a byte is written into the register file, starting from the least significant byte of the current u32.

An internal counter is used to keep track of the remaining bytes to be read into the register file. While the eFuse register file is reset to zero with NRST, the internal counter is not: By asserting NRST after N bytes have been read, only 0x400-N bytes will be read on the subsequent boot.

By asserting NRST just before the final byte has been read (1830 cycles), all eFuses will read entirely zero, including the JTAG lockout fuse. This allows trivial, unsigned and unencrypted boot1 execution, with no SEEPROM anti-rollback.

One More Thing,

Additionally, because SRAM is not cleared on reboot, and because boot1 verifies over the encrypted payload, the boot1 key can be extracted: By asserting NRST after 176 cycles and walking the delay width down cycle-by-cycle, code execution can be used to gather 16 failed decryptions of boot1: A zerokey-decrypted boot1, and 15 others with one more byte present in its boot1 key than the last. This allows a straightforward bruteforce of the boot1 key.

For those who wish to follow along at home, I’ve provided the following worksheet:
https://gist.github.com/shinyquagsire23/d42c57782ec31f9c3e74177b1e34e6d2

The bomb has been de_Fused, Counter-Terrorists Win

What Next?

All of my modchip development is open-source on Github, however it is in the early stages: It requires an FPGA, I haven’t standardized any components or schematics, frankly I haven’t even tested it on any other consoles. For booting custom firmware and de-bricking tools, a fair amount of work still has to be done, but it hopefully won’t take too long. At some point I will try and attempt to get de_Fuse working with an RP2040–my target price is $25~$35 in parts, if not lower. Collaboration is greatly welcomed.

Additional Reading

I couldn’t find a good place to mention this, but I found out I was beat to the punch on OTP eFuse readout glitching in 2019, by some other researchers looking into the Espressif ESP32: https://raelize.com/blog/espressif-systems-esp32-glitching-otp-transfer/

WiiUBrew pages which go into more detail on boot processes, what’s in OTP, etc:

Special Thanks

YvetalGriffin, for lending me their Wii U board scans so that I could follow the internal PCB traces for PGOOD.
Relys, for donating their old Wii U to me for glitching.
derrek, for answering a few questions I had about his Wii U glitching setup.
GaryOderNichts, quarky, for keeping me in the loop CFW deets, random Wii U musings
kinnay, https://github.com/kinnay/Wii-U-Firmware-Emulator
SALT peeps, gang