de_Fuse, the Wii U open source modchip, updated to v.0.3
The open source Wii U modchip is getting closer, with update 0.3 this week. De_Fuse, a groundbreaking update on the Wii/Wii U scene, was disclosed by hacker Shiny Quagsire almost a month ago. The only reason I haven’t talked about it has been honestly, that other scene websites are much more accurate than me when it comes to Nintendo, in particular the older consoles.
Nonetheless, the achievement is important enough, I’ll use this new release of Shiny Quagsire’s code as an opportunity to talk about the project.
What is de_Fuse for Wii U?
de_Fuse is a hardware vulnerability on the Wii U, a flaw in its OTP* eFuse readout state machine. Long story short, the flaw allows, with about $30 worth of off-the-shelf electronics, to fully hack the Wii U. Shiny Quagsire’s work on this (both the software and hardware) is Work in Progress, but 100% open source.
* The One Time Programmable memory is programmed sometime during the factory process and can never be changed afterwards. The Wii U’s OTP is much larger than the Wii’s (1KB split across 8 banks of 128 bytes each) and contains an assortment of read-only data, including the console’s encryption/decryption keys.
from the project’s readme:
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.
For more details, check the dev’s full writeup here. Possibly the most interesting part to me is how the flaw was found by initially looking into Wii vulnerabilities, and guessing that similar exploits might exist in the Wii U’s boot process. Also, how much luck got involved, according to the hacker himself.
What’s new in de_Fuse 0.3
boot1.img
now verifies the BoardConfig CRC32, and if it is not valid, DRAM is initialized using fallback defaults.- Added PRSHhax-based OTP dumping support for all boot1 versions available on CDN (prod and dev)
- Added
BOOT1_SLC.RAW
dumping and restoring - Added support for restoring seeprom.bin
- This option can result in an inability to dump OTP via PRSH hax if you do something stupid!
- I added as many verification/safety measures as I could to make sure that PRSH hax wouldn’t get locked out, but at the end of the day it’s the user’s responsibility to keep
otp.bin
andseeprom.bin
backed up and safe. - A incomplete list of things that can stop working irrecoverably if you lose your
seeprom.bin
backup and flash something incorrect includes:- The disk drive
- Saves stored on USB drives
- Added support for syncing SEEPROM boot1 versions with NAND after flashing
BOOT1_SLC.RAW
- This option requires a copy of
otp.bin
from the same console (and this is verified).
- This option requires a copy of
- Adjusted redNAND partitioning to place 1MiB of free space at the start of the SD card for Ancast images.
- Misc reliability improvements
So, how do I hack my Wii U with de_Fuse?
Important: At the current step of the project, this is a very early release, and all the software/hardware does is letting you know if everything’s wired correctly. This does not technically hack the Wii U yet, although there’s every reason to believe a full-fledged open source modchip is right around the corner thanks to this project.
Download links for the software, instructions on required hardware, and operating instructions can all be found on the project’s release page here.
Hardware-wise, you will at the very least need a Raspberry Pi Pico, and some wire. Wiring details for the Pico board can be found here.
Source: Shiny Quagsire
Ok, very cool but is there any point at all? Does it bring any more funcionality that a simple softmod?
Why should I use a modchip in the WiiU? It’s possible to mod the console using Software only. What am I missing?
Ι suppose the bricking problem still exists. Every day I read about bricked Wii u’s.