リバースエンジニアリングにおける産業革命。

2026年8月に何が変わったのか

この作業の前に、私は多くの手動リバースエンジニアリングを行っていました。 私は説明があるまで関数を検査し、その説明をプログラムに対してテストします。 さらに得ることは、次の機能に自分の時間をもっと費やすことを意味しました。 それはまた、私の頭の中でますます大きな絵を保つことを意味しました。

私の再作業のほとんどは、ゲームにあります. 私はそれらを再構築して、それらの動作を理解し、最終的にソフトウェアポートまたはmodに運ぶことができます。 それがこの記事の背後にある経験です。 このメソッドは他の場所でも役立ちますが、各フィールドは信頼できる参照に対してチェックできるものを確立する必要があります。

2026年8月、私はエージェント主導のREを真剣に探求し始めました。 私は、エージェントがプログラムや通常の開発ツールにアクセスすることでどこまで得ることができるかを見たかったのです。 東方復興は私に見つけるための実質的なプロジェクトを与えました。

初期の進歩は驚くべきものでした。 調査は私がすべての個々のステップを選択せずに移動し続けることができます。 比較に失敗すると、エージェントが別の呼び出し元に送信される可能性があります。 小さな診断を記述し、その結果を使用して次に何を試すかを決定することができます。 自由が違いをもたらしたことをそれに与える：私はプロジェクトの方向性とそのチェックが信頼できるかどうかにもっと注意を払うことができ

ペースは最初に私の注意を得ました。 それから私は現在のプロジェクトを超えて何が生き残るのだろうかと思い始めました。 次のゲームは、私たちが学んだすべてのものから利益を得るでしょうか？

TH08:人間の仕事の上に構築

TH08 、不滅の夜は、の続きとして始まった GensokyoClubの再構築. 彼らの公的な情報源は私に実質的な基盤を与えました。 それは、ビルドの知識と私が継続して保存した貢献の歴史が付属していました。

同年10月場所で初土俵を踏んだ。 私の独立した継続は8月13日に始まりました。 8月19日までに、台帳は1,107の特定されたゲーム機能すべてのソースを記録しました。

Linux再構築ポートは、継続が始まった約十一日後の8月24日にコミットされました。 Web版が続いた。 ネイティブLinux64ビットリリースは8月30日に到着しました。

私を襲ったのは、仕事が人々が実行できるプログラムに達していたということでした。 そこに到達するには、個々の機能を超えた次の問題が必要でした。 二つの関数が別々に正しく見えたとしても、共有されるべき状態の別々のコピーを誤って使用する可能性があります。

これにより、作業の中心となる参照チェックが行われました。 私はそれらを呼び出します 検証参考文献（オラクル）. コード比較は、再構築された関数が元の命令を再現するかどうかを知ることができます。 実行時チェックは、実行されたルートが予想される状態に達するかどうかを確認できます。 エージェントは説明を提案し、それをテストします;不一致はそれに調査するために特定の何かを与えます。

間違った定数と完全に一致する

検証リファレンス（oracle）は、誰かが書いたソフトウェアです。 TH08は、そのソフトウェアにどれだけ依存できるかを明確に思い出させてくれました。

9月には、ダウンストリームスイッチポートから報告されたバグがアイテムの自動収集に戻りました。 再構築されたソースは、プレーヤーのパワーをチェックしました 0.0. 使用される原物 128.0、最大電力しきい値。

通常の電力は負ではないので、再構成された電力チェックは事実上常に満たされていました。 コレクションラインの上に、ゲームは最大の力を必要とせずにアイテムを引き付けることができます。 条件の他の例外は正しかった。 この1つの定数が動作を変更しました。

しかし、関数はすでに正確な比較に合格していました。

再構築は、別のアドレスに定数を置くことができます。 比較ツールは、コンパイルされた命令のアドレスを元の命令と比較する前に調整することによってそれを説明しました。 しかし、参照されたアドレスに格納されている浮動小数点値は決してチェックされませんでした。

それは小切手に穴を残しました。 それは元ので再構築された命令を指すことができます 128.0 ソースがまだ言っている間 0.0. 命令バイトが一致しました。 ソースは別の何かを意味しました。

ザ- 2月の修正 ソースを修正し、参照された定数の実際のバイトを比較チェックしました。 A より広い監査 次に、1,548個の浮動小数点定数参照を調べました。 それは5つの受け入れられた関数間で別の12の誤った参照を見つけました。

比較では、このようなすべての浮動小数点定数がチェックされます。 そのテストには、意図的に間違った値が含まれており、拒否されていることを確認します。 また、弱いチェックに合格した結果を再検討する必要がありました。

検証リファレンス（oracle）も再構築する必要がありました。 それを修復することは、ゲームを修復することの一部でした。

それは、チームが主にエージェントと協力している一人の人である場合に重要です。 私は個人的に彼らが生産するすべてのラインを検査することはできませんので、私の自信の多くは彼らのチェックにかかっています。 Shared verification reference（oracle）の死角は、私が気付く前に多くの調査に影響を与える可能性があります。 チェッカーが実際に何を検証し、失敗するはずのケースに対してテストするかを理解する必要があります。

作業が進むにつれて、これらのチェックはリポジトリの一部になりました。 ソースの変更の理由と、以前のセッションが停止した場所で後のセッションがピックアップできるようにするメモもそうでした。 ソースコードリポジトリはプロジェクトのワーキングメモリになりつつありました。

バッチが成功すると、復元されたコードと次のバッチのためのより良い環境の両方が得られました。

再建の2つの異なるアイデア

GensokyoClubの パブリックREADME この種の作業との意見の相違を明示的にします。 この通知により、さらなる開発が完了するまで非公開で行われることが発表されました。 一つの通路が読みます:

私たちの仕事から取って、この空間でのグリフター（AIの逆コンパイルとポート）の台頭は、将来の逆コンパイルの努力のための悪いイメージを描きます…

この通知には、メンテナーの心理的な犠牲も記載されています。 彼らの貢献ポリシーは、主にAIで生成されたプルリクエストを除外します。 彼らは自分の自由な時間を困難な仕事に入れており、その仕事は私の継続を可能にするのに役立ちました。 私はその背後にある努力を尊重します。 私が議論したい意見の相違は、復興をどのように進めるべきか、そして貢献をどのように判断すべきかということです。

私が知っていた手動ワークフローでは、機能の理解を開発し、それを再構築することは、通常、同じ人に落ちました。 プロジェクトはその人の専門知識に大きく依存していました。 彼らが働いている間に推論の多くが起こったので、貢献者への信頼は重要でした。

既存のプロジェクトは、ソースとビルドツールの知識をすでに保持しています。 私にとって変わったのは、エージェントがその知識を使って次の調査を単独で追求できるということでした。

私の継続では、私は結果を受け入れるための目的と基準を決定します。 エージェントは調査する幅広い自由を持っています。 その提案された再建は、関連するチェックを生き残るために持っています。 エージェントがほとんどの作業を行ったとしても、他の人がなぜ実装を選んだのかを調べることができるようにしたいと思います。

これは難しい移行になる可能性があります。 注意深い仕事の年は大いにより速く動く継続のための基礎になるかもしれない。 それは信用についての実質の質問を上げる。 また、コントリビューションを受け入れる前にメンテナが知る必要があることも変更されます。

産業的な類推は、私がこれについて考えるのに役立ちます。 工芸品では、プロセスの多くはそれを実行する人のスキルに依存します。 機械はその技術が必要とされるところで変わる。 誰かがまだプロセスを設計し、その出力が間違っているときに認識する必要があります。 さまざまなコミュニティが、その変更のどれだけを実行したいかを選択できます。

私の選択は、継承された作品がクレジットされ、その歴史が保存されたまま、公然と継続することです。 新しい作品をレビューできるようにしたいです。 それは私たちにこのアプローチがどこまで行くことができるかを尋ね、道に沿って何がうまくいかないかから学ぶ方法を与えます。

ソース：GensokyoClubの READMEのお知らせ、2026年10月10日にチェックされ、その 貢献方針. 引用は短縮された抜粋です。 TH08の クレジットと出所 継続境界を記録します。

TH095:経験は配合を開始します

TH095 、弾丸を撃つ、その経験の価値をはるかに見やすくしました。 同月29日にはゲームソフトの発売が開始された。 私たちはまだゲームを学ばなければなりませんでした。 しかし、私たちはすでに再建を開始する方法とそれを動かし続ける方法についてはるかに多くを知っていました。

9月7日までに、特定された697のゲーム機能すべてがソースを持っていました。 8年（696年）までには、正確な比較として受け入れられていた。 プログラム全体は9月にリンクされています。 Windows i386は、初期化から約10日後の10月に再構築された。

私はこれが最初のプロジェクトのスピードよりも刺激的だと感じました。 新しいターゲットは、別のゲームで行われた作業の恩恵を受けることができます。 この経験は、ツールとプロジェクトの編成方法にすでに存在していました。

たとえば、TH08は、組み立てられたプログラムに早期に注意を払うように教えてくれました。 いくつかの回復された関数が同じ状態に依存している場合、それらの分離された比較は重要な質問を開いたままにします。 彼らが一緒に働いているのを見る必要があります。 このレッスンは、TH095のプログラム全体のビルドにどのようにアプローチしたかを形作るのに役立ちました。

私がそこにいる間、私の頭の中にとどまるレッスンは役に立ちます。 別のセッションが実行できるチェックになると、私が移動した後も助け続けることができます。 次のエージェントは、それにつながった調査を繰り返すことなく、結果を使用することができます。

浮動小数点定数のバグもそのメモリに属しています。 参照をチェックするには、その背後にあるデータをチェックする必要がある理由を説明します。 コードでその修正を維持することは、後のプロジェクトが古いチェックの死角を継承するのを避けるのに役立ちます。

この方法は、次のゲームの出発材料の一部になります。 私たちは、次のプロジェクトの努力の多くを、その目標について実際に新しいものに費やすことができます。

同じ利点は、後で参加する人々に利用可能です。 彼らは決定を検査し、作業を続行する前にそのチェックを再実行することができます。 彼らは、ソースがそれがないように見える理由を見つけるために、プロジェクト全体の履歴を再構築する必要はありません。

TH04:ワークフローは異なるアーキテクチャで存続します

TH04 、ロータスランド物語は、PC-98 DOS時代にこの作品を取りました。 ターゲットは現在、4つの協力プログラムを持つ16ビット環境でした。 そのハードウェアの動作を理解するには、Windowsゲームとは異なる証拠が必要でした。 既存の Rec98作品 私たちに貴重な知識とソース材料をここにも与えました。

DOSの再構築は現在機能しています。 私の手動テストでは、私は彼らのエンディングを介して完全な通常のルートを再生し、保存を確認しました。 現在の作業はネイティブの64ビットポートです。 動作中のDOSバージョンを確立すると、最初にそのポートに参照が与えられます。

建築は私達が調査するために必要としたものを変えた。 また、作業をチェックしたコンパイラとランタイムも変更されました。 しかし、エージェントはまだ結果に至るまでの質問に従うことができ、その結果は次の実験を導くことができます。

ゲームプレイからエンディングへの移行を考えてみましょう。 私たちは、どの州がその境界を越えて運び、どのプログラムがそれを担当しているかを知る必要があります。 それはDOS製品に対して調査できるものです。 証拠とチェックが利用可能になると、エージェントはWindowsタイトルと同じように質問を処理することができます。

これが、TH04が引数に重要である理由です。 プラットフォームを大幅に変更しても、新しい作業方法でやり直すことはできませんでした。 アーキテクチャは問題を定義しましたが、ワークフローはまだそれを解決する方法を与えてくれました。

64ビットポートについては、DOS上で既に回復されている動作に対して新しい実装を調べることができます。 再構築からの知識は、ポートに構築するための何かを与えます。

2026年10月10日現在のプロジェクト状況: DOSの再構成および手動テスト · 64ビットポート. 港は開発中のままです。

正確なコードから読みやすいコードへ

復興がうまくいったら、他の誰かにそれを理解してもらいたいです。

私にとって、アセンブリと生のオフセットは古い友達のように感じることができます。 私はこれが「読みやすい」という少し変わった定義であることを認識しています。「ほとんどの人は、実行可能ファイルのメモリレイアウトを頭の中に保持せずに、ゲームのロジックに従うことを好むでしょう。

それはどこですか セマンティック再構成 入ってきます。 回収されたフィールドは、主にそのオフセットによって依然として知られていてもよい。 その役割を説明できるまで、ゲームがどのようにそれを使用するかに従います。 それから、意味のある名前と証拠に合ったタイプを与えることができます。 次の人がその解釈がどこから来たのかを見ることができるように、私たちは推論をソースと一緒に保ちます。

これは、ソフトウェアポートにとって特に重要になります。 絶対アドレスは、古い実行可能ファイルのどこに何かが住んでいたかを教えてくれます。 これは、どのオブジェクトがその状態を所有すべきかを決定する上で、64ビットの実装にはほとんど助けになりません。 動作を安全に移動するには、古いメモリアクセスの背後にある関係を回復する必要があります。

私が今使用している順序は次のとおりです:

1. 正確なベースラインを回復します。 歴史的なコンパイラで再構築された部分をコンパイルします。 関連するコードとデータを元の実行可能ファイルと比較します。 未解決の差分を記録して、次のフェーズの開始点を明確にします。
2. 元のプラットフォーム上でそれを構築し、再生します。 元のアーキテクチャとコンパイラを使用して、それらの部分を実際のプログラムにリンクします。 重要なゲームプレイパスを行使します。 これは、分離された関数の比較が見逃した共有状態または初期化に関する問題を見つけることができる場所です。
3. 両方の参照に対してセマンティクスを再構築します。 一度にゲームの一つの一貫した部分を取り、その回復されたソースが何を意味するかを確立します。 正確な比較と再生可能な歴史的なビルドを維持しながら、その表現を改善します。
4. モダンなポートを作ります。 確立された動作を、ネイティブの64ビットビルドなどの新しい環境に移動します。 再構築された元のプラットフォームのゲームは、ポートがどのように動作するかを比較するための参照のままです。

第二段階からの再生可能なビルドは、次のようになります 第二検証リファレンス(オラクル) 第三の間に。 最初の検証リファレンス(oracle)では、変更されたソースが関連する元のコードとデータを再現しているかどうかを確認します。 第二は、再構築されたプログラムがまだ構築され、我々が行使するパスに沿って正しく動作することを確認します。

彼らはさまざまな間違いをキャッチします。 型の変更は、生成された命令を変更することができます。 所有権の変更は、状態の異なるコピーを使用してゲームの2つの部分を残すことができます。 両方のチェックを利用できるようにしておくと、リファクタリングをさらに実行する前にエージェントが具体的に調査できなくなります。

名前はそれ自身の証拠を必要とします。 正確な比較は、フィールドが本当に"不死身の時間"を意味するかどうかを私たちに伝えることはできません。「ゲームがどのように書いて使用するかから、それを確立する必要があります。 意味が不確かなままである場合、中立的な名前は自信を持って推測するよりも次の読者にとってより有用です。

私たちはプロジェクトを通してこの順序を学びました。 TH08は、後の歴史的なプラットフォーム監査のいくつかの前に、すでに再生可能なポートを持っていました。 これにより、特定の欠陥が見えにくくなりました。 ザ- Factoryの現在のワークフロー 元のプラットフォームのビルドを最初に置くので、セマンティック作業は移植が始まる前にそれを参照として使用できます。

正確な再構成は私たちに参照を与えます。 セマンティック再構成は、回収された知識を使用可能にする。 ポートは、両方の上に構築することができます。

これを産業シフトにするものは何ですか

これらのプロジェクトは、私が注意を払った場所を変えました。 エージェントが調査の多くを前進させることができれば、彼らの作業環境を改善することは私ができる最も有用なことの一つになりました。 より良いツールは、それを必要とするすべての後の機能を助けることができます。

ここでは自治が重要です。 有用な次のステップは、多くの場合、失敗した実験の後にのみ明らかになります。 エージェントは、予想外のどこかでその結果に従うのに十分な自由を必要とします。 私が各ステップを処方するのを待たなければならない場合、仕事の多くは私の注意に結びついています。

私はエージェントが間違った仮説を立てることを期待しています。 重要なのは、それらをテストし、結果から学ぶことができるかどうかです。 失敗したチェックは、それが再試行するのに十分な間違いを理解するのに役立つはずです。 私はまだ蓄積された証拠がプロジェクトのマイルストーンをサポートしているかどうかを判断する必要があります。

REAは、エージェントが分析ツールにアクセスできるようにします。 関数の呼び出し元に関する質問は、その呼び出し元の検査に直接つながる可能性があります。 Reconstructionプロジェクトは、コンパイラとそれ自身の参照チェックを提供します。 エージェントはそれらを使用して、提案するソースをテストし、その説明がどこに保持されているかを確認できます。

TH08のバグは、これらのチェックが独自のエンジニアリングの注意を払うに値する理由を示しています。 同じ比較が何百もの関数で使用されている場合、そのギャップは、1つの実装での間違いよりもはるかに広がる可能性があります。 チェッカーをテストすると、後のすべての作業で利用可能なフィードバックが向上します。

産業の類推は、ここで有用な歴史的な例を持っています。 ボールトンとワットは、 1796年の蒸気機関の表示器 エンジン弁の調節を助けるため。 録音バージョンはピストンストロークを介して圧力を追跡しました。 それはエンジンの内部動作を点検のために利用できるようにした。 私たちの比較ツールは、同様の目的を果たしています：彼らは私たちがそれを改善しながら、機械が何をしているかを調べてみましょう。

私たちはこの産業シフトの初期段階にあります。 インフラストラクチャの多くはまだ未成熟です。 エージェントは、私たちのチェックがサポートするように設計されていたよりも速く移動できるため、プロセスはそれらと一緒に開発する必要があります。 共有ツールに欠陥が見つかった場合は、それを修復し、影響を受けた結果を再検討する必要があります。 次のプロジェクトは、より強力なツールを継承することができます。

いずれかの会話には実用的な制限もあります。 大規模な再構築が完了する前に終了します。 ソースコードリポジトリは、最後の決定の理由を失うことなく、別のセッションを継続できるようにする必要があります。

ザ- 東方復興工場 その必要性から成長しました。 それはプロジェクトに彼らの点検およびレッスンを先に運ぶ共有された方法を与える。 あるゲームでの作業は、別のゲームの開始条件を改善することができます。

それが私にとって産業的な類推を意味のあるものにしているのです。 経験は、他の人が使用できるツールの一部になり始めます。 これらのツールを改善することで、次の人、または次のエージェントがどれだけ達成できるかが変わります。

今考えられるプロジェクトは

ペースは、それが開始する決定を変えるので、重要です。 ゲームはリバースエンジニアリングにとって魅力的であり、現実的にそれを与えることができるよりも私自身の注意を要求することができます。 多くのプロジェクトは、アイデアを滞在します。

今、私はそのようなプロジェクトを繰り返し調査を通して動かし続ける方法を見ることができます。 作業再構成を取得すると、ソフトウェアポートがより実用的になります。 読み取り可能なセマンティクスを回復すると、他の誰かがmodを探索するのが簡単になります。 ゲームを理解するための努力は、最初のバージョンが実行された後も報われ続けることができます。

私は今、なじみのないプログラムを見て、尋ねる: どのようなアクセス、フィードバック、蓄積された知識が、エージェントがこれに確実に取り組むことを可能にするでしょうか？

その質問は、私が以前に一人で残していたであろうプロジェクトを考えさせます。 それぞれが私たちが次のアプローチ方法を改善することができます。 私はそれが私たちをどこまで連れて行くことができるかを探求し続けたいです。

より多くの記事 · TH04調査を探る