When Internal Memory Fails: A No-Solder Wii U Recovery

It was just another hot Sunday at smol HQ. My wife and I were playing games with the family during our biweekly FaceTime game night, and as we were getting ready to end the call, my brother-in-law chimed in.

“Oh yeah, before we get off the call, I’m gonna throw away the Wii U. Anyone have any protests before I throw it out? Five… four…”

My sister-in-law immediately responded, “What? No! What’s wrong with it?”

“I don’t know. It just doesn’t play games anymore. It gives me some kind of error.”

“Aw man, I have sentimental value tied to it. But if it doesn’t work, I guess throw it away.”

I don’t know what came over me. The last time I had seriously dabbled with exploits and low-level recovery was when I spent months trying to revive a bricked M1 Max MacBook Pro. Several companies and repair shops had told me that getting through the problem was impossible, but after months of working at it, I finally got the machine running again on New Year’s Day 2024. I am still using it today, and it continues to run strong.

Imposter syndrome still pokes at me almost every week, but my love for computers, technology, and machine learning keeps me at my computer with absolute glee, wondering what new thing I might discover next. Since recovering the M1, however, I had not felt particularly called toward that kind of project again. Maybe it was the heat from not having air conditioning in the house. Maybe it was my ego. Or maybe it was just the particular kind of cheekiness I felt that weekend, the urge to fuck around and find out.

After a minute, I spoke up.

“Don’t throw it away. I’ll get it up and running.”

They were stunned and immediately asked how. I told them I had absolutely no idea, but I would try. The youngest of the bunch said it sounded like I was making empty promises. I assured them I was not, although by that point I was mostly just more determined to get the Wii U running for this ungrateful bunch.

The Starting Point

When the Wii U was finally in my hands, I powered it on and found it in a familiar but frustrating state. It would power on, display the Wii U logo, and remain there indefinitely. At this stage, it was not safe to assume one specific cause because a logo hang is only a symptom, not a diagnosis.

I already had a Raspberry Pi Pico configured for UDPIH, the USB Host Stack exploit used to load recovery tools on a Wii U that cannot boot normally. Before attempting to repair anything, I needed to confirm that the recovery path itself was functioning. The official Pico payload produced the expected behavior, and when required recovery files were missing, the console responded in a way that suggested the exploit was still reaching it. Once recovery_menu was placed on the SD card, the Wii U power LED turned purple, confirming that the recovery payload was running.

That was the first meaningful breakthrough. The console was not completely unreachable, and UDPIH gave me a way to interact with it even though the normal operating system could not finish booting.

The Recovery Menu Worked, but the Display Did Not

The next obstacle was video output. The standard recovery_menu build appeared to run, as confirmed by the purple LED, but the television continued displaying the stale Wii U logo. The recovery code was executing, yet the display was not updating. I also tested a display-initializing build called recovery_menu_dc_init, which produced output, but the image was badly distorted on the displays available to me.

This created the possibility that some recovery operations would need to be performed blindly. That was not something I wanted to approach casually. A single incorrect menu selection could make an already damaged console worse, so I avoided broad or destructive recovery-menu operations and used only narrow, known sequences when necessary. The display problem shaped the rest of the recovery strategy because I needed an approach that did not depend upon being able to see every menu clearly.

Coldboot, ECO Mode, and Region Settings

At first, the failure did not look like a straightforward storage problem. Earlier logs contained references to the ECO Process title:

0005001010066000

They also referenced:

eco_process.rpx

This mattered because a Wii U can fail to boot if the wrong title is configured as the coldboot title, or if the system attempts to launch a special process instead of the normal Wii U Menu. Region settings were another possible cause because a mismatch between the console’s product area, game area, and installed system titles can also create serious boot problems.

The region information showed:

Product area: 0x2
Game area:    0x2

Those values matched a USA console. Later, the MLC rebuild tool confirmed the same result:

Region already matches (P:2, G:2, C:2).

I also attempted coldboot-related recovery and ECO-related cleanup. Those steps did not ultimately repair the console, but they were not wasted effort. They allowed me to rule out several plausible causes without making broad or destructive changes. Much of troubleshooting is not immediately finding the answer, but narrowing the problem while avoiding the creation of new ones.

The Breakthrough: MLC Media Errors

The decisive evidence came from a fresh system log. After the coldboot and ECO work, the console was attempting to launch the correct USA Wii U Menu:

MCP: Master title 0005001010040100 os 000500101000400a from mlc01 flags 0004

The title:

0005001010040100

is the USA Wii U Menu. This was important because it showed that the console was no longer primarily failing because it was trying to boot the wrong title. It had reached the correct menu, but something was preventing that menu from loading successfully.

Immediately afterward, the log showed serious read failures from the MLC:

FSA: ### MEDIA ERROR ###, dev:mlc01, err:-2228230, cmd:11, path:(null)

It also showed failed reads of required shared font files:

failed to read file /vol/storage_mlc01/sys/title/0005001b/10042400/content/CafeCn.ttf, err -196673

and:

failed to read file /vol/storage_mlc01/sys/title/0005001b/10042400/content/CafeTw.ttf, err -196673

The most revealing line identified the storage manufacturer and showed a low-level read error:

mdblk: err=-131099, mid=0x90, prv=0x5c, pnm=[HYNIX ]

This changed the diagnosis. The problem was not simply one missing font or one damaged system title. The console was reporting media errors from mlc01, the Wii U’s internal MLC storage, and the device involved was a Hynix eMMC chip.

At that point, continuing to replace individual files would have been the wrong strategy. If the internal storage could no longer read data reliably, repairing one file might only move the failure somewhere else. The console could fail on a font during one boot, another system title during the next, and a save directory after that. The real problem was that the system could no longer depend on its internal MLC.

Choosing ISFShax and redNAND

The symptoms matched the Wii U community’s no-solder recovery method closely. The console was stuck at the Wii U logo, the logs showed Hynix eMMC read errors, UDPIH remained functional, and the system was damaged without being completely unreachable.

Hardware-based repair methods also exist, including NAND-AID and MLC2SD-style replacements. Those approaches can produce a more stock-like result because they physically replace or redirect the failing eMMC path. For this recovery, however, the no-solder ISFShax redNAND method was suitable because I still had working access through UDPIH and could install an early boot environment.

ISFShax allows the console to load minute before the normal Wii U operating system fully starts. minute can then patch IOSU and redirect storage access. In this case, the goal was to redirect only the MLC to a dedicated partition on the SD card while leaving the SLC and SLCCMPT on the console.

The underlying idea is fairly simple even though the implementation is technical: instead of continuing to ask the failing Hynix eMMC for the…