プログラミング
内部ストレージの故障:はんだ付け不要のWii Uリカバリ
When Internal Memory Fails: A No-Solder Wii U Recovery (smolnero.com)
要約
この記事は、Wii Uの内部ストレージ(MLC)が故障し、起動しなくなったコンソールを、はんだ付けなしで復旧させるプロセスを解説しています。UDPIH(USB Host Stack exploit)を使用してリカバリメニューを起動し、ログ分析を通じてHynix製eMMCのメディアエラーが原因であることを特定しました。最終的に、ISFShaxとredNANDという、SDカードにMLCをリダイレクトするノーソルダ―手法を用いてコンソールを復旧させています。
全文翻訳
ある暑い日、smol HQでのいつものように妻と私は、2週間に一度のFaceTimeゲームナイトで家族とゲームをしていました。通話を終えようとしたとき、私の義兄が口を開きました。「ああ、そういえば、電話を切る前にWii Uを捨てようと思ってるんだけど、誰か反対する人はいる? 5…4…」私の義姉はすぐに「え? なんで? どうかしたの?」と答えました。「よくわからない。もうゲームが遊べないんだ。なんかエラーが出るんだよ。」「あー、それ、私にとって思い出があるんだけど。でも、動かないなら、まあ捨ててもいいかな。」何が私にそうさせたのかわかりません。最後に私がエクスプロイトや低レベルリカバリに真剣に取り組んだのは、ブリックしたM1 Max MacBook Proを復活させようと数ヶ月費やした時でした。いくつかの会社や修理店は、その問題を解決するのは不可能だと言っていましたが、数ヶ月かけて取り組み、ついに2024年の元旦にそのマシンを再び動かすことができました。今でも現役で、元気に動作しています。インポスター症候群はほぼ毎週私を悩ませますが、コンピューター、テクノロジー、機械学習への愛が、次に何を発見できるのだろうかと、純粋な喜びとともに私をコンピューターの前に座らせています。しかし、M1を復旧させて以来、そのようなプロジェクトに再び駆り立てられることはありませんでした。エアコンのない家での暑さのせいかもしれません。私のエゴかもしれません。あるいは、その週末に感じた、ふざけてみて何が起こるか試してみたいという、ある種の生意気な衝動だったのかもしれません。1分後、私は口を開きました。「捨てるな。私が動くようにしてやる。」彼らは驚き、すぐにどうやってと尋ねてきました。私は全くわからないが、やってみると答えました。一番年下の子は、私が空約束をしているように聞こえると言いました。私はそうではないと保証しましたが、その時点では、この恩知らずな連中のためにWii Uを動かすことに、ほとんど決意を固めていました。
出発点
Wii Uが最終的に私の手に渡ったとき、私は電源を入れ、見慣れているがイライラする状態を発見しました。電源は入り、Wii Uのロゴが表示され、そのまま無限に止まるのです。この段階では、特定の原因を断定するのは安全ではありませんでした。ロゴのハングは症状に過ぎず、診断ではありません。私はすでに、通常起動できないWii Uでリカバリツールをロードするために使用されるUSB Host StackエクスプロイトであるUDPIH用に、Raspberry Pi Picoをセットアップしていました。何かを修理しようとする前に、リカバリパス自体が機能していることを確認する必要がありました。公式のPicoペイロードは期待通りの動作を示し、必要なリカバリファイルが欠落している場合、コンソールはエクスプロイトがまだ到達していることを示唆する応答をしました。SDカードにrecovery_menuを配置すると、Wii Uの電源LEDが紫色に変わり、リカバリペイロードが実行されていることを確認しました。それが最初の意味のあるブレークスルーでした。コンソールは完全に到達不能ではなく、通常のオペレーティングシステムが起動を完了できなくても、UDPIHは私にコンソールと対話する手段を与えてくれました。
リカバリメニューは機能したが、ディスプレイは機能しなかった
次の障害はビデオ出力でした。標準のrecovery_menuビルドは、紫色のLEDで確認されたように実行されているようでしたが、テレビには古いWii Uのロゴが表示され続けていました。リカバリコードは実行されていましたが、ディスプレイは更新されていませんでした。私はまた、display-initializingビルドであるrecovery_menu_dc_initもテストしましたが、これは出力を生成しましたが、画像は私が利用できるディスプレイでひどく歪んでいました。これにより、一部のリカバリ操作をブラインドで実行する必要がある可能性が生じました。それは私が気軽に近づきたくないものでした。メニューの1回の不正確な選択が、すでに損傷したコンソールをさらに悪化させる可能性があったため、広範または破壊的なrecovery_menu操作は避け、必要に応じて狭く既知のシーケンスのみを使用しました。ディスプレイの問題は、メニューのすべてをはっきりと見ることができることに依存しないアプローチが必要だったため、その後のリカバリ戦略を形作りました。
コールドブート、ECOモード、およびリージョン設定
当初、この故障は単純なストレージの問題のようには見えませんでした。以前のログには、ECO Processタイトルに関する参照が含まれていました:0005001010066000また、eco_process.rpxという参照もありました。これは、間違ったタイトルがコールドブートタイトルとして設定されている場合、またはシステムが通常のWii Uメニューの代わりに特別なプロセスを起動しようとした場合に、Wii Uが起動に失敗する可能性があるため重要でした。リージョン設定も別の原因の可能性がありました。コンソールの製品エリア、ゲームエリア、およびインストールされているシステムタイトルとの不一致は、深刻な起動問題を引き起こす可能性もあります。リージョン情報は以下を示していました:製品エリア:0x2ゲームエリア:0x2これらの値はUSAコンソールと一致していました。後に、MLC再構築ツールが同じ結果を確認しました:リージョンはすでに一致しています(P:2, G:2, C:2)。私はまた、コールドブート関連のリカバリとECO関連のクリーンアップを試みました。これらの手順は最終的にコンソールを修理しませんでしたが、無駄な努力ではありませんでした。それらは、広範または破壊的な変更を加えることなく、いくつかのもっともらしい原因を除外することを可能にしました。トラブルシューティングの多くは、すぐに答えを見つけることではなく、新しい問題を作成することを避けながら、問題を絞り込むことです。
ブレークスルー:MLCメディアエラー
決定的な証拠は、新しいシステムログから得られました。コールドブートとECO作業の後、コンソールは正しいUSA Wii Uメニューを起動しようとしていました:MCP: Master title 0005001010040100 os 000500101000400a from mlc01 flags 0004 タイトル:0005001010040100はUSA Wii Uメニューです。これは、コンソールが主に間違ったタイトルを起動しようとしたために失敗しなくなったことを示していたため、重要でした。それは正しいメニューに到達しましたが、そのメニューが正常にロードされるのを妨げている何かがありました。直後に、ログはMLCからの深刻な読み取り失敗を示しました:FSA: ### MEDIA ERROR ###, dev:mlc01, err:-2228230, cmd:11, path:(null)また、必要な共有フォントファイルの読み取り失敗も示しました:failed to read file /vol/storage_mlc01/sys/title/0005001b/10042400/content/CafeCn.ttf, err -196673 および:failed to read file /vol/storage_mlc01/sys/title/0005001b/10042400/content/CafeTw.ttf, err -196673 ストレージメーカーを特定し、低レベルの読み取りエラーを示した最も啓示的な行は次のとおりでした:mdblk: err=-131099, mid=0x90, prv=0x5c, pnm=[HYNIX ] これにより、診断が変わりました。問題は、単に1つのフォントが欠落している、または1つのシステムタイトルが破損しているだけではありませんでした。コンソールは、Wii Uの内部MLCストレージであるmlc01からのメディアエラーを報告しており、関与したデバイスはHynix eMMCチップでした。その時点で、個々のファイルを交換し続けることは間違った戦略になっていたでしょう。内部ストレージが信頼性をもってデータを読み取れなくなった場合、1つのファイルを修復しても、障害が別の場所に移動するだけかもしれません。コンソールは、ある起動時にはフォントで失敗し、次の起動時には別のシステムタイトルで、その次はセーブディレクトリで失敗する可能性があります。本当の問題は、システムが内部MLCに依存できなくなったことでした。
ISFShaxとredNANDの選択
症状は、Wii Uコミュニティのノーソルダ―リカバリ方法と密接に一致していました。コンソールはWii Uロゴで停止し、ログはHynix eMMC読み取りエラーを示し、UDPIHは機能し続け、システムは完全に到達不能ではないものの損傷していました。ハードウェアベースの修理方法も存在し、NAND-AIDやMLC2SDスタイルの交換が含まれます。これらのアプローチは、物理的に故障したeMMCパスを交換またはリダイレクトするため、よりストックに近い結果を生み出すことができます。しかし、このリカバリでは、ノーソルダ―ISFShax redNAND法が適していました。UDPIHを介してまだ機能的なアクセスがあり、早期のブート環境をインストールできたからです。ISFShaxは、通常のWii Uオペレーティングシステムが完全に起動する直前にコンソールがロードできるようにします。その後、IOSUをパッチし、ストレージアクセスをリダイレクトできます。この場合、目標は、MLCのみをSDカード上の専用パーティションにリダイレクトし、コンソール上のSLCとSLCCMPTはそのままにすることでした。実装は技術的ですが、基本的な考え方は非常にシンプルです。故障したHynix eMMCにWii Uの内部ストレージの読み取りを要求し続けるのではなく、