HN 日本語サマリー

← 一覧へ戻る
プログラミング

Nintendo 64ゲームを84日間で逆コンパイルする

Decompiling a Nintendo 64 Game in 84 Days (blog.chrislewis.au)

54 pointsby knackers16 コメント

要約

この記事は、Nintendo 64のゲーム「スノーボードキッズ」をわずか84日間で完全に逆コンパイルしたプロジェクトについて詳述しています。この迅速な完了は、AIツールの活用、過去のプロジェクトで培われた経験、そしてコミュニティの専門知識の組み合わせによるものです。特に、IDO 5.3という独自のコンパイラへの対応が課題となりましたが、AIエージェントと人間による協力、そして専用ツールの開発によって克服されました。

全文翻訳

Nintendo 64ゲームを84日間で逆コンパイルする 2026年8月26日 オリジナルの「スノーボードキッズ」が100%逆コンパイルされたことを発表できることを大変嬉しく思います!これは、すべての関数1にC言語の実装が対応しており、コンパイルすると元のゲームと全く同じマシンコードが生成されることを意味します。 これは明らかに一人での作業ではありませんでした。このプロジェクトに多大な貢献をしてくれたinspectredc、Bl00D4NGEL、queueRAMには特に感謝しています。AIだけでは彼らの代わりを務めることはできなかったでしょう。2また、iFuzzle、JamesBLewis、douglasjvにも、彼らのトークンをこの大義のために貸してくれたことに感謝したいと思います。 完全な逆コンパイルが「スノーボードキッズ」コミュニティにとって有用であることを願っています。特にスピードランナーは、最初のゲームに長年焦点を当ててきました。動作するソースコードは、CPUのパスやプレイヤーの速度に寄与する正確な要因など、外部から観察された現象に光を当てるのに役立ちます。ソースコードの完全な理解は、静的再コンパイルや、将来のより野心的な改造の取り組みにも役立つでしょう。 プロジェクトが完了した速度も注目に値します。「スノーボードキッズ」の逆コンパイルにはわずか84日しかかかりませんでしたが、「スノーボードキッズ 2」の596日と比較すると、経過時間の約7分の1です。3 「スノーボードキッズ」逆コンパイルの週ごとの進捗状況。 この違いは何で説明できるのでしょうか?まあ、2026年ですから、その答えは少なくとも部分的にはAIです。しかし、その違いを完全にLLMに帰するのは、あまりにも単純化しすぎでしょう。 何が違ったのか 明白なことを言えば、私はゼロから始めていませんでした。この時点で、私はすでに類似のプロジェクトにほぼ2年間費やしており、始めたときよりもはるかに速くなっていました。この利点は定量化するのが難しく、異なるコンパイラを扱うといった新たな課題によっていくらか相殺されました。 全体として、一致したコミットの約4.8%には専門家の介入が関わっていました。4これらの素晴らしい人々にはすでに一度感謝しましたが、繰り返す価値があります。このプロジェクトは、逆コンパイルコミュニティ、特にinspectredc、queueRAM、Bl00D4NGEL <3からの多大な助けなしには不可能でした。 困難は、一般的に、関数が何をするかを理解することから来るのではなく5、そのロジックがC言語でどのように表現され、結果として得られるコードがどのようにコンパイルされたかということでした。「スノーボードキッズ」は、GCC 2.7.2コンパイラではなく、IDO 5.3でコンパイルされました。GCC 2.7.2は「スノーボードキッズ 2」で使用されていました。 ほとんどのプログラマーはGCCに精通しているでしょう。これは広く使用されているオープンソースコンパイラであり、今日でも活発に開発されています。一方、IDOはSGIによって開発されたプロプライエタリなコンパイラであり、SGI自体の物語はNintendo 64の物語と密接に絡み合っています。6そのソースは利用できず、オリジナルの開発環境は古いSGIのハードウェアとソフトウェアに結びついていました。今日、それを使用し、正しく理解するためには、逆コンパイルコミュニティはコンパイラツールチェーンの一部をリバースエンジニアリングおよび逆コンパイルし、IDO 5.3および7.1スイートを最新のハードウェアで実行できるように静的に再コンパイルする必要がありました。その閉鎖的な歴史により、IDOはGCCのようなオープンなコンパイラよりも推論するのが困難です。 IDOは、最適化とコード生成をいくつかの異なるパスに分割し、その過程でコードをかなり積極的に変換します。7C言語のわずかな変更でも、それらのパス全体に波及し、全く異なるレジスタ割り当てを生成する可能性があります。 コミュニティはIDOとその奇妙な癖の理解において大きな進歩を遂げましたが、これは依然として科学というよりは芸術です。LLMと私は、その出力を再現することに特に長けていません。私とエージェントの両方にとって、通常のワークフローは、関数が何をするかを理解してから、その目的に近似するC言語を記述することでした。そこから、パーミュテーターの助けを借りた小さな調整で、残りの違いを捉えることができました。しかし、根本的な構造が間違っている場合、すべてのケースでパーミュートして一致させることはできません。IDOの動作により、このワークフローははるかに予測不可能になりました。 適切な専門知識と直感を持った意欲的な人間チームは、「スノーボードキッズ」の逆コンパイルのペースに匹敵するか、それを超えることができます。「パイロットウィングス64」の逆コンパイルはわずか74日で完了しました。8「パイロットウィングス64」は「スノーボードキッズ」よりも関数数が16%少なかったですが、全体としてはコンパイルされたコード量が多かったため、これもクリーンな比較ではありません。 「パイロットウィングス64」は、魅力的なフライトシミュレーターであり、Nintendo 64のローンチタイトルであり、今日でもカルト的な人気を保っています。 「スノーボードキッズ」は続編よりも小さく、2,145関数を含んでいましたが、「スノーボードキッズ 2」は2,995関数でした。関数数は困難さの粗い尺度ですが、逆コンパイルすべき関数が単純に少なかったのです。 エージェントが役立った場所 以前に、関数を逆コンパイルするためにエージェントを使用することについて elsewhere で書きました。ここでは同じ基本的なプロセスが使用されたため、何が変わったかに焦点を当てます。前回のプロジェクトとは異なり、このプロジェクトは最先端のモデルと有能なエージェントハーネスへのアクセスから始まりました。 ライブラリコードとその他の容易な成果 プロジェクトの初期段階でエージェントがどのように機能するかを見ることに興味がありました。彼らが成功した分野の1つは、標準ライブラリコードの一致でした。理論的には、これはほぼすべてのNintendo 64逆コンパイルの最も明白な部分です。コードはゲーム固有ではなく、そのバージョンはオンラインで利用可能です。「スノーボードキッズ」には、任天堂のlibultraからの100以上のソースセグメントと、libmusオーディオライブラリからの関数が含まれています。N64Symのようなツールは、ROM内の可能性のあるライブラリ関数を識別できます。 このパスはかなり成功しました。主な障害は、エージェントに既存のライブラリソースに依存させること、または同じ関数をゼロから再度逆コンパイルさせることでした。これにはより強力なプロンプトが必要でした。可能性のあるライブラリ関数が特定されると、エージェントは対応するソースを開始点として扱い、独自の С実装を試みる前に、可能性のあるSDKバージョン、コンパイラオプション、および条件付きコンパイルパスをすべて使い果たすように指示されました。 もう1つの最適化は、エージェントにスクリプトを作成させ、一致しないすべての関数に対してm2cを実行し、正確な一致を自動的に統合することでした。これは、エージェントが個々の関数を個別に処理することに依存するのではなく、行われました。9このスクリプトは1,830関数のうち17関数しか一致しませんでしたが、成功率は信じられないほど低い0.93%でしたが、この方法で一致したものはすべて、エージェントトークンを消費するよりも安価でした。 IDOツールとスキル IDOは奇妙ですが、しばしば繰り返される方法で奇妙です。1つの関数を正常に一致させると、他の多くの関数に適用されるコンパイラの奇妙な癖が明らかになることがあります。Codexは、ローカルメモリのような機能を通じて、タスク間で教訓を運ぶのが得意になりました。単一のエージェントを超えてこれらの教訓を利用できるようにするために、エージェントにDECOMPILATION_LEARNINGS.mdファイルに観測されたIDOの動作を記録するように促しました。エージェントが一般的なコンパイラの奇妙な癖を発見した場合、後続の試行のために証拠をそこに記録することができました。これにより、有用なフィードバックループが作成されました。エージェントはIDOの文書化を助け、その結果の文書化により、後続のエージェントはIDOコードの一致をより良く行うことができました。 しかし、最も有用なリソースはN64 Decomp Workbenchでした。これは、後期MIPS逆コンパイルの不一致をデバッグするためのツールとドキュメントのコレクションです。不一致を分類し、リロケーションを考慮し、個々のコンパイラパスを再生し、構造的な問題とレジスタ割り当ての問題を区別するのに役立ちます。パスの再生には、関連するコンパイラバイナリとプロジェクト固有のセットアップが必要ですが、一度設定されると、生のバイナリ差分では得られない情報を提供します。生の差分は、2つの関数が異なることを示します。Workbenchは、エージェントに、関数が異なる理由と、それを修正する可能性のある変更の種類について、はるかに良いアイデアを提供できます。 ワークツリーと同期 このプロジェクトでは、4つのGitワークツリーに逆コンパイルハーネスを実行しました。各ワークツリーはエージェントにリポジトリの独立したコピーを提供し、複数の関数を並列で試行することを可能にしました。 小さくても有用な改善点は、各タスクに明示的な締め切りを与え、その締め切りをエージェントに公開することでした。「スノーボードキッズ 2」プロジェクト中、エージェントはパーミュテーターが100%一致を見つけるまで実行し続けるため、パーミュテーターを効果的に使用するのに苦労することがよくありました。