当内部存储器失效时：无需焊接的Wii U恢复方法

那天，我们小分部的办公室又是一个炎热的星期天。我和妻子正和家人一起玩着每周一次的FaceTime游戏之夜。正当我们准备结束通话时，我的姐夫突然插话道：

“哦，对了！在我们挂断电话之前，我得把Wii U扔掉。有没有人要提出抗议，等我把它扔出去？五……四……”

我的嫂子立刻回应道：“什么？不！它有什么问题？”

“我也不懂。它就是再也玩不了游戏了，还老是报错。”

“哎呀，这台机对我来说可是有特殊意义的啊！不过要是它不行，那我也只好把它扔掉了。”

我也不知道自己怎么了。上一次认真尝试利用漏洞、进行低级恢复，还是在我花了好几个月时间，试图让一台坏掉的M1 Max MacBook Pro重新启动的时候。

当时，多家公司和维修店都告诉我，要彻底解决这个问题根本不可能，可经过数月的努力，我终于在2024年新年那天，让这台机器重新运转了起来。

直到今天，我依然在用它，而且它运行得依旧非常稳定。

尽管冒名顶替综合症几乎每星期都会找上我，但对电脑、科技以及机器学习的热爱，总能让我满怀期待地坐在电脑前，心怀好奇地思索：接下来我又会发现些什么新奇的东西呢？

不过自从把M1修好之后，我再也没那么强烈地想要去从事这类项目了。也许是因为家里没有空调，热得让人喘不过气来；也许是因为我的自尊心作祟；又或者只是因为那周末那种特别的顽皮劲儿——想胡闹一番，好好探个究竟。

过了一会儿，我开口说道：

“别扔掉它！我来把它重新启动起来。”

他们愣住了，立刻问我是怎么做到的。我告诉他们，自己完全不知道原因，但我愿意试一试。队里年纪最小的那位说，这听起来像是我在空口许诺。

我向他保证，绝不是在空口许诺，不过到那时，我更多地只是下定决心，一定要让这台Wii U重新启动，好回报这群不知感恩的人。

起点

当Wii U终于到我手中时，我给它通电，却发现它处于一种既熟悉又令人沮丧的状态：它能正常开机，显示Wii U的标志，却一动不动地停留在那里，一待就是很久。

在这个阶段，我们不能轻易就认定问题的根源，因为“标志卡顿”只是一种症状，而非诊断结果。

我早已为Raspberry Pi Pico配置好了UDPIH——一种用于在无法正常启动的Wii U上加载恢复工具的USB主机堆栈漏洞利用程序。在尝试修复任何问题之前，我必须先确认恢复路径本身是否正常运作。

官方的Pico载荷能够正常运行，而当所需的恢复文件缺失时，控制台的反应也表明，漏洞利用程序仍在顺利抵达目标。一旦将recovery_menu放置在SD卡中，Wii U的电源指示灯便变成了紫色，这证实了恢复载荷正在运行。

这是第一次真正取得突破。控制台并未完全无法访问，UDPIH也给了我一种与之互动的方式——尽管正常的操作系统始终未能完成启动。

恢复菜单奏效了，但屏幕却没反应

接下来的障碍是视频输出。标准的recovery_menu构建似乎已经成功运行，紫色指示灯也印证了这一点，然而电视屏幕上却依旧显示着陈旧的Wii U标志。

恢复代码正在执行，但屏幕却始终没有更新。我还测试了一种名为recovery_menu_dc_init的屏幕初始化版本，该版本确实产生了预期的输出，但在我手头可用的显示器上，画面却严重失真。

这也让我们意识到，有些恢复操作可能需要盲目的进行。而我可不想轻率地面对这样的情况。只要一个菜单选择失误，原本就已经受损的控制台可能会变得更加糟糕。

因此，我避免进行大规模或破坏性的恢复菜单操作，仅在必要时使用那些狭窄而已知的序列。屏幕问题也塑造了后续的恢复策略，因为我需要一种不必依赖于能否清晰看到每一个菜单的方案。

冷启动、ECO模式与区域设置

起初，这次故障看起来并不像单纯的存储问题。早些时候的日志中曾提到过ECO进程的标题：

0005001010066000

日志中还提到了：

eco_process.rpx

这一点很重要，因为如果将错误的标题配置为冷启动标题，或者系统尝试启动一个特殊的进程而非正常的Wii U菜单，Wii U就可能无法正常启动。

区域设置也是另一种可能的原因，因为当控制台的产品区域、游戏区域与已安装的系统标题不一致时，同样可能导致严重的启动问题。

区域信息显示：

产品区域：0x2
游戏区域：    0x2

这些数值与美国地区的控制台相符。后来，MLC重建工具也证实了同样的结果：

区域已匹配（P:2, G:2, C:2）。

我也尝试了与冷启动相关的恢复操作，以及与ECO相关的清理工作。虽然这些步骤最终并没有修复控制台，但它们并非徒劳无功。它们让我得以在不进行大规模或破坏性改动的情况下，排除了多种可能的故障原因。

很多时候，故障排查并不是一蹴而就的，而是通过逐步缩小问题范围，同时避免制造新的问题。

突破：MLC媒体错误

决定性的证据来自一条全新的系统日志。在完成冷启动和ECO操作后，控制台正尝试启动正确的美国Wii U菜单：

MCP：主标题 0005001010040100，OS 000500101000400a，由mlc01提供，标志 0004

标题：

0005001010040100

正是美国Wii U菜单。这一点非常重要，因为它表明，控制台的问题不再单纯在于尝试启动错误的标题。它已经进入了正确的菜单，但某种因素却阻碍了该菜单的成功加载。

紧接着，日志中出现了MLC的严重读取失败：

FSA：### 媒体错误 ###，设备：mlc01，错误码：-2228230，命令：11，路径：(空)

日志中还记录了对所需共享字体文件的读取失败：

未能读取文件 /vol/storage_mlc01/sys/title/0005001b/10042400/content/CafeCn.ttf，错误码 -196673

还有：

未能读取文件 /vol/storage_mlc01/sys/title/0005001b/10042400/content/CafeTw.ttf，错误码 -196673

最引人注目的是一行记录了存储制造商，并揭示出一次低级别的读取错误：

mdblk：错误码=-131099，中间值：0x90，前导值：0x5c，数据：[HYNIX ]

这一变化彻底改变了我们的诊断方向。问题远不止是某一个字体缺失，或某个系统标题损坏那么简单。控制台报告的是来自mlc01的媒体错误——这是Wii U内部的MLC存储设备，而涉及的设备正是一个海力士的eMMC芯片。

此时，继续逐个替换文件显然不是正确的策略。如果内部存储设备已经无法可靠地读取数据，仅仅修复一个文件，很可能只会让故障转移到其他地方。

控制台可能在一次启动中因字体而出现故障，下一次又可能因另一个系统标题而崩溃，而在随后的保存目录中也可能再次出现问题。真正的难题在于，系统已经无法再依赖其内部的MLC了。

选择ISFShax与redNAND

这些症状与Wii U社区的“无需焊接”的恢复方法高度吻合。控制台卡在Wii U的标志上，日志中显示海力士eMMC存在读取错误，UDPIH仍然可以正常运行，而系统虽然已经受损，却并未完全无法访问。

硬件修复方法同样存在，包括NAND-AID和MLC2SD风格的更换方案。这些方法往往能带来更接近原厂配置的效果，因为它们通过物理方式替换或重定向故障的eMMC路径。

不过，在这次恢复中，由于我仍可以通过UDPIH获得有效的访问权限，并且能够安装一个早期的启动环境，因此“无需焊接”的ISFShax redNAND方法显得尤为合适。

ISFShax可以让控制台在正常的Wii U操作系统完全启动之前几分钟内完成加载。然后，分钟级的时间段内，可以对IOSU进行补丁处理，并重新定向存储访问。

在本次恢复中，我们的目标仅仅是将MLC路径重定向至SD卡上的专用分区，同时保留控制台上的SLC和SLCCMPT。

其基本理念虽然看似简单，但实现起来却颇具技术难度：与其继续向故障的海力士eMMC请求……