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

Skip to content

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<br>They also referenced:

eco_process.rpx<br>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<br>Game area: 0x2<br>Those values matched a USA console. Later, the MLC rebuild tool confirmed the same result:

Region already matches (P:2, G:2, C:2).<br>I also attempted coldboot-related recovery and ECO-related cleanup. Those steps did not ultimately repair the console, but they were...