バイナリのリバースエンジニアリングに挑戦する人の大半は、hex エディタでファイルを開き、 20 分ほどスクロールして、そのまま諦めてしまう。
どのツールでファイルを読み込めばいいのか分からない。どのプロンプトを使えばロジックを引き出せるのか分からない。アセンブリの壁を、実際に再構築できる形に変換する方法も分からない。
この 11 ステップのコースでは、 Claude Opus 5.5 を「何でもオープンソース化できるマシン」へと進化させる。
最新の AI アルファ（先行知見）を受け取るには、私の Substack をフォローしてください：
リバースエンジニアリングとは、クラッキングのことではない。自分自身の手で作り直せるほど、対象を深く理解することだ。
2026 年 10 月 7 日、 Replit の CEO である Amjad Masad が、たった一行を投稿した。
https://x.com/amasad/status/2107671204639465961
その投稿に対し、 @morluto という開発者が「証拠」となるリプライを送った。エージェントが Hopper や Ghidra を操作し、驚くほど深い解析を可能にする一連のツールだ。
それが REA というプロジェクトであり、わずか数日で GitHub スター 110,000 を突破した。
https://github.com/morluto/rea
これは単なる誇大広告ではない。同じ週に、 WordCraft というオープンソースプロジェクトが、 Microsoft と Adobe のクリーンルーム再実装を純粋な Rust でリリースしたのだ。
これは Word や Adobe のコードを一切読まず、挙動を観察し、公開されているファイルフォーマット仕様を読むだけで構築された。
本コースでは、密閉されたバイナリから、こうした再実装に至るまでの全工程を解説する。読み込みを担当するのは Opus 5.5 だ。
01. エンジン - エージェントはどのようにバイナリを読むのか
Opus 5.5 は、単独でディスアセンブラを実行できない。テキストを読み、テキストを書くことしかできない。
それでもエージェントによるリバースエンジニアリングが成立するのは、モデルとバイナリの間にツールが存在するからだ。このツールがファイルを実際の逆アセンブリエンジンに読み込ませ、結果を呼び出し可能な関数として公開し、モデルが質問できるようにする。
そのツールが REA であり、その裏で動くエンジンが Hopper 、 Ghidra 、または IDA だ。
ループはシンプルで、これを繰り返す。モデルが REA に対象の検査を依頼し、 REA が正確な根拠（アドレス、バイト列、疑似コード、呼び出し元）とともに結果を返し、モデルがその結果を使って次の質問をするか、再実装を書いてテストする。
すべてはローカルマシン上で実行される。アップロードされるのは、モデルが推論するために必要な調査結果のみであり、すべての結論は「観察」「推論」「不明」のいずれかにタグ付けされる。
**
02. インストール - rea-agents と 1 つのディスアセンブラ
セットアップでは、 REA の MCP サーバーをエージェントに登録し、対応するワークフロー手順をインストールする。
コマンド 1 つで完了し、書き込む前にすべての変更内容を表示し、触れるファイルをバックアップしてくれる。
ディスアセンブラは自分で用意する。 macOS なら Hopper が最も簡単で、 Ghidra は無料でクロスプラットフォーム、すでに所有しているなら IDA でも構わない。
1# 1. REA をエージェントに登録する（Claude Code、Codex、Cursor、Gemini CLI など）2npx rea-agents setup # 予定されている変更を表示し、書き込み前に確認する34# 2. 詳細分析用プロバイダー。macOS では Hopper が最もスムーズ。5# セットアップ時に承認すれば自動インストールされる。Ghidra と IDA は各自で用意する。6# 3. ターミナルやスクリプトで使うための rea CLI をインストール7npm install --global rea-agents8rea --help910# 4. エージェントを再起動し、ツールが有効になっていることを確認する11claude12> /mcp13 rea: connected14 open_binary, binary_overview, analyze_function, decompile,15 list_procedures, search, xrefs, trace, inspect_artifact,16 analyze_javascript_application, inspect_managed_artifact ...
要件は控えめだ。 Node.js 22 以降と npm だけ。ネイティブ解析には 3 つのエンジンのいずれかが必要だが、静的な JavaScript や .NET の検査にはエンジンすら不要だ。リリースで頻繁に修正が入るため、 REA は常に最新の状態に保つこと。
1# リバースエンジニアリングの基本ルール（CLAUDE.MD）23## 権限4- 自分が所有している、または調査を許可された対象のみを分析する。根拠は一度だけ述べる。5- すべての主張にタグを付ける：観察（見た）、推論（導き出した）、不明。6- 証拠を引用する：アドレス、バイト列、疑似コード、呼び出し元。根拠のない主張はしない。78## ワークフロー9- フルダンプではなく、最小限の概要から始める。具体的な不明点がある場合のみ範囲を広げる。10- 開いているセッションを再利用する。同一の分析を二度実行しない。11- 静的な事実と実行時の事実を分ける。静的な読み取りから実行を推測しない。1213## 再構築14- 「挙動」と公開仕様から構築し、コピーしたコードやアセットからは絶対に作らない。15- 義務台帳を管理する。復元した挙動は、テストをパスするまで「完了」としない。
Opus 5.5 には、 low 、 medium 、 high 、 xhigh 、 max の 5 つのエフォートレベルが用意されている。使い分けは以下の通りだ。
- Medium ：検査とナビゲーション用
- High ：通常の関数への注釈付け用
- Max ：難読化されたコードや、ポインタ演算が多用されている箇所用
エフォートは、このコース全体において品質を左右する最大の調整ノブだ。
03. ルーター - 20 のターゲットタイプ、それぞれに 1 つのツール
初心者が最初に犯すミスは、対象が Electron アプリで JavaScript がそのまま存在するのに、ディスアセンブラを使おうとすることだ。
REA はターゲットを適切なツールにルーティングする。最初のプロンプトでも同じようにすべきだ。ファイル名と機能を指定し、エントリーとなるツールの選択はエージェントに任せる。
1[ABSOLUTE PATH] にある [APP] で、[FEATURE] がどのように動作しているのかを理解したい。23まず、これがどのようなターゲット（ネイティブ、Electron/JS、.NET、Go、APK、WASM）なのかを教え、4適切な REA ツールを選んで開いてほしい。まだ詳細な分析は始めないこと。56次に、1段落のマップを提示してほしい。アプリが何で作られているか、規模はどれくらいか、7[FEATURE] を探すならどこを最初に見るべきか。観察、推論、不明点を分け、8主張には必ず証拠を引用すること。
REA を Electron アプリに向ければ、ディスアセンブラを一切使わず、数秒でモジュール、インポート、 IPC の境界が返ってくる。
ネイティブの Mach-O や ELF に向ければ、 Hopper データベースが開き、より難しくも深いネイティブ解析の道に進む。今どちらにいるのかを把握するだけで、何時間も節約できる。
https://x.com/_vmlops/status/2106690704244420687
04. 偵察 - 概要、文字列、コールグラフ
いきなりコードを開かないこと。まずは REA にファイル全体のマップを求める。コマンド 1 つで、どのマシンで動くのか、中にいくつの関数があるのか、埋め込まれた読み取り可能なテキストが何なのかが分かる。
そのテキストこそが最速の手がかりだ。 Web アドレス、エラーメッセージ、機能名を見れば、コードを 1 行も読まずにアプリの役割が分かる。
1rea.open_binary { path: "/Applications/Target.app/Contents/MacOS/Target" }2rea.binary_overview {}3 arch: arm644 functions: 1,284 identified5 segments: __TEXT __DATA __LINKEDIT6 entry: _main @ 0x1000051c078rea.search { query: "http" } # 文字列 + コード参照9 0x10004a2c0 "https://api.target.app/v3/sync"10 0x10004a300 "Authorization: Bearer "11 0x10004a330 "offline cache miss, falling back"1213rea.xrefs { address: "0x100012ab0" } # 誰がこれを呼んでいるか？14 147 references -> core config loader, called everywhere
REA は、各関数が何回呼び出されているかもカウントする（この回数はクロスリファレンス、または xrefs と呼ばれる）。
147 回呼ばれる関数はアプリの心臓部であり、全力を注ぐ価値がある。 2 回しか呼ばれない関数は小さなヘルパーなので、重要になるまで無視してよい。リストの上位から順に作業を進めよう。
05. 逆コンパイル - 1 つの関数を疑似コードへ
ここで、呼び出しの多い関数を 1 つ選び、読める形に変換する。デコンパイラは生の機械語命令を受け取り、 C 言語に近いコードとして書き直す。
見た目は粗い。 var_28 のような変数名、絡み合ったロジック、至る所にあるキャスト。しかし読むことはでき、「読める」ということだけが Opus 5.5 にとって必要なのだ。
結果を保存するならコマンドラインから、チャット内から直接実行することもできる。
1# アドレスを指定して 1 つの関数を逆コンパイルし、パイプや保存ができる JSON として出力2rea decompile /Applications/Target.app/.../Target 0x100012ab0 \3 --provider hopper --json > fn_config_loader.json45# または名前で関数を検索し、参照をたどる6rea function /path/to/Target parseConfig --provider hopper --json7rea xrefs /path/to/Target 0x100012ab0 --provider hopper --json8rea trace /path/to/Target "sync" --provider hopper --json
1// 0x100012ab0 xrefs: 1472void sub_100012ab0(void* arg0) {3 void* var_20 = objc_msgSend(cls_NSJSONSerialization,4 sel_JSONObjectWithData_options_error, arg0, 0x0, 0x0);5 if (var_20 != 0x0) {6 void* var_28 = objc_msgSend(var_20, sel_objectForKey, @"endpoints");7 void* var_30 = objc_msgSend(var_20, sel_objectForKey, @"auth_mode");8 void* var_38 = objc_msgSend(var_20, sel_objectForKey, @"retry_count");9 objc_msgSend(g_sharedConfig, sel_setEndpoints, var_28);10 objc_msgSend(g_sharedConfig, sel_setAuthMode, var_30);11 objc_msgSend(g_sharedConfig, sel_setRetryCount,12 objc_msgSend(var_38, sel_intValue));13 }14}
REA 公式のショーケースでは、古いゲーム DX-Ball のサウンド呼び出しをたどり、左右のオーディオバランスを決定するヘルパー関数まで到達し、未完成の疑似コードを C 言語に変換している。
その結果は元のテストケース 3,205 件すべてをパスし、コンパイル済みの 63 バイトすべてを正確に再現した。
全工程は rea.tools/showcase で確認できる。
06. 注釈付け - Opus にすべての変数名をつけさせる
粗いコードのままでは半分しか終わっていない。これを Opus 5.5 に渡し、説明と整理を依頼する。
暗号のような変数を意味のある名前に変更し、関数の目的を一文で説明し、使われているパターンを特定し、さらには元のアプリに残されていたバグまで指摘してくれる。
以下のプロンプトをコピーして Claude に貼り付けてください：
1以下は、クロスリファレンスが 147 ある関数の逆コンパイル済み疑似コードです。23この関数について、次のことを行ってください：41. 使われ方に基づき、すべての変数を意味のある名前に変更する。52. 目的を一文で述べる。63. 読み書きするデータ構造をリストアップする。74. パターン名をつける（シングルトン、ファクトリー、ステートマシン、オブザーバーなど）。85. ドキュメントコメント付きの、クリーンで慣用的な Swift（または呼び出し規約が示唆する言語）として書き直す。96. エラーハンドリング、入力検証、セキュリティチェックの欠落があれば指摘する。1011回答前に xhigh エフォートで十分に考えること。名前を確定する前に、各値が何を表すのか推論する。12不確かな部分は必ずマークすること。1314[疑似コードをここに貼り付け]
逆コンパイルはコードが「何を」しているかを教えてくれる。 Opus 5.5 は「なぜ」そうするのかと、再構築に必要な名前を与えてくれる。
https://x.com/0x0SojalSec/status/2108389060192706674
https://x.com/0x0SojalSec/status/2108031166502896035
すべてのターゲットにディスアセンブラが必要なわけではない。 REA の Notion ショーケースでは、アプリの JavaScript 内にあるクリップボード機能を見つけ、 Electron のレイヤーを越えてメインプロセスまで追跡し、リッチクリップボードがどのように構築されるかを完全にトレースしている。アセンブリは一切使っていない。詳細はこちら：
07. 難読化 - Tigress ベンチマーク
一部のアプリは、まさにあなたがやろうとしていることに耐えるように作られている。コードは意図的にスクランブルされており、ロジックはシャッフルされ、テキストは暗号化され、時間を浪費させるための偽の分岐が追加されている。
これが難読化であり、最高のモデルでさえ苦戦する唯一の領域だ。 Elastic Security Labs は、 20 のタスクで Claude Opus に Tigress スクランブラーを解析させ、その性能を測定した。この数字は頭に入れておこう。
この数字から、 2 つの実践的な教訓が得られる。
- 第一に、失敗した試行は成功した場合の約 2 倍のコストがかかる。モデルが諦めるまで何度も挑戦し続けるからだ。したがって、関数ごとの支出上限を設定し、早めに打ち切ること。
- 第二に、送信前に逆コンパイル済みコードからゴミを取り除くこと（ Caveman という無料ツールで約 75% を除去できる）。これにより、モデルは埋め草ではなく本当のロジックに注意を向けられる。
実際に出会う 5 つのトリックと、コードを開いたときにそれぞれがどう見えるかは以下の通りだ。
1この関数は難読化されているようです。max エフォートで作業してください。231. 使用されている手法（制御フローの平坦化、不透明述語、デッドコード、文字列暗号化、関数分割）を特定し、4 このコード内のどこに現れているかを示す。52. それらを解決する：デッドブランチの削除、不透明述語の評価、ディスパッチの平坦化解除、6 キーが復元可能であればインライン文字列の復号を行う。73. 残ったクリーンな関数を表示する。84. 確信度を 1〜10 で評価する。6 未満の場合は、どの部分が不確かで、どのような周辺コンテキストがあれば9 解決できるかを正確に伝えること。黙って推測しないこと。1011[難読化された疑似コードを貼り付け]
08. スウォーム - ワーカーを動かすコントローラー
1 つのチャットでは、 500 もの関数をうまく読み込めない。見た内容を忘れ、同じものを 3 つの異なる名前で呼び、自己矛盾を始める。
解決策は小さなチーム編成だ。仕事を割り振る 1 つのコントローラーチャットと、それぞれが 1 つの関数を担当する複数のワーカーチャットを用意する。
コントローラーは全体像を保持し、断片を再びつなぎ合わせる。
特別な仕組みを作る必要はない。以下の 2 つのプロンプトがセットアップのすべてだ。
1あなたはリバースエンジニアリングのコントローラーです。関数マップは functions.json2（address、name、size、xref_count）にあります。341. コールグラフの近接性に基づいて関数をクラスタリングし、xref 数でクラスタを並べ替える。52. 各クラスタをワーカーに割り当てる。自分で関数を分析しないこと。63. 名前の一貫性を保つため、解決済みの構造体を各ワーカーの指示に注入する。74. ワーカーの確信度が 6 未満で返ってきた場合、解決済みの隣接関数のコンテキストを追加して8 2 回目の処理をキューに入れる。95. 累積トークン消費量を追跡し、クラスタごとに報告する。
1あなたはワーカーです。逆コンパイルされた関数 1 つと、これまでに解決された構造体を受け取ります。2以下を正確に返してください：address、purpose、confidence（1〜10）、structs_used、structs_new、3clean_source、flags。既存の構造体名を再利用すること。コントローラーから渡された構造体に42 つ目の名前を勝手に作らないこと。担当は 1 関数のみ。完了したら停止すること。
https://x.com/victor_explore/status/2109466356454510612
09. クリーンルーム - 合法を保つ 4 つのルール
クリーンルーム再実装とは、アプリの「挙動」を真似るのであって、中のコードは決してコピーしないことを意味する。正しく行えば、リリースするものは完全にあなたのものだ。間違えれば、他人の著作権を抱え込むことになる。
安全側に立つための 4 つのルールがあり、 WordCraft チームはビルドごとにこの 4 つすべてを自動でチェックしている。
- 観察し、コピーしない。 ターゲットはブラックボックスとして実行し、挙動を観察し、スクリーンショットはアプリ自身のウィンドウのみを撮る。コードを読んだり、逆アセンブルしたり、貼り付けたりしない。単純な機能名を超えた文言をコピーしない。
- ソースではなく仕様。 ファイルフォーマットは公開標準から取得する（ OOXML は ECMA-376 / ISO 29500 、加えて公開されている RTF や ODF の仕様）。競合のパーサーや GPL/LGPL コードを読んで取得しない。
- オリジナルのアセットのみ。 すべてのアイコン、フォント、テンプレート、サウンドは、コードで描画するか、パブリックドメイン、オープンライセンスのものを使用し、帰属表示ファイルに 1 行記載する。そうでなければ CI チェックがビルドを失敗させる。
- 2 つの作業を分離する。 1 つのエージェントが挙動を復元して仕様書を書く。別のコンテキストがその仕様書だけを見て実装し、元の分析結果は決して見ない。この分離こそがクリーンルームの境界線だ。
1完了した分析から、再実装のためのクリーンルーム仕様書を作成してください。23「挙動」のみを記述すること。含めるもの：すべての公開インターフェース、データモデル、4ユーザーに見える各機能（テスト可能な要件として）、読み書きするファイルフォーマット5（観察された挙動と公開仕様に基づく）、エラーハンドリングの挙動。67含めてはいけないもの：アドレスやオフセット、逆コンパイル由来の変数名、アセンブリ、8またはオリジナルからコピーしたもの。バイナリを見たことがない開発者が、この文書だけで9互換バージョンを実装できる必要があります。1011以下のセクションを持つ Markdown で出力してください：Architecture、Data Model、Public API、File Formats、12Test Cases。
記述から作業することは、法的な防衛策にとどまらない。数十年前の原作者が下した決定を引き継ぐ代わりに、自分の言語とニーズに合った最適な選択ができるようになる。
WordCraft が一部で Word より高速なのは、まさに Word の内部をコピーしなかったからだ。
10. アプリの構築 - 12 のプロツール、 1 つの手法
WordCraft は一発ネタではない。 ArtCraft チームが手がける 12 個のアプリ群のうちの 1 つであり、それぞれがあなたが普段お金を払って使っているツールのクリーンルーム再実装だ。すべて Rust でゼロから書かれ、 GitHub 上で無料でオープンに公開されている。
彼らのスローガンは「 12 apps. One craft （ 12 のアプリ。 1 つの職人技）」であり、その「 1 つの職人技」とはステップ 9 の手法そのものだ。オリジナルを観察し、公開仕様を読み、挙動だけから新しいバージョンを構築する。
この共通手法による恩恵は、どのアプリでも同じだ。 Electron は使われていない。各アプリは macOS 、 Windows 、 Linux でネイティブに動作し、 FilmCraft を除くすべてが WebAssembly を通じてブラウザタブでも実行できる。
さらに、内部のあらゆるアクションが名前付きコマンドになっているため、 12 個すべてを AI エージェントがすぐに操作できる。
すべての Craft アプリは同じ方法で構築されており、その構造は真似する価値がある。それぞれが層状に積み上げられ、各層はそのすぐ下の層だけを利用する。最下層の基本的な計測から、最上層の画面上のウィンドウまで続く。
以下は WordCraft のレイヤー構成です：
そして、あらゆるアクションは単なる名前付きコマンドなので、マウスクリック、キーボードショートカット、 AI エージェントのすべてがまったく同じものを呼び出す。だからこそ、エージェントによる操作が可能になるのだ。
1MCP 経由で WordCraft を操作する23# ヘッドレスなドキュメント自動化4claude mcp add wordcraft -- wordcraft-cli mcp56# または起動中のデスクトップアプリを操作する7wordcraft --control 7981 &8claude mcp add wordcraft-app -- wordcraft-cli mcp --connect 127.0.0.1:7981910# ツール：list_commands, execute, batch, type_text, select_text,11# inspect_document, render_page, save_document（+ スクリーンショット/クリック/キー操作）12> report.docx を開き、すべての見出しを 14pt の太字にして PDF にエクスポート13 ✓ select.all-headings -> 12 selected14 ✓ format.font-size 14 · format.bold15 ✓ export report.pdf (selectable text, bookmarks kept)
https://x.com/yuhasbeentaken/status/2109235513102057828
11. 検証とリリース - 同等性を証明し、MCP を公開する
オリジナルのソースコードは持っていないので、 1 行ずつ比較することはできない。
代わりに挙動を比較する。オリジナルと再実装の両方に同じ入力を与え、同じ出力が得られるかを確認する。
1オリジナルのバイナリと私の再実装を比較する、挙動テストハーネスを構築してください。2350 個の入力を生成してください：通常 30 個、エッジケース 10 個（空、最大サイズ、Unicode、特殊文字）、4エラー 10 個（不正な形式、フィールド欠落、破損）。それぞれを両方で実行します。可能な限りバイト単位で、5それ以外は意味的に出力を比較してください。一致率、差異リスト、およびそれぞれの重大度6（外観上 / 挙動上 / 致命的）を報告し、report.md に保存してください。
これは、誰かに見せられる最も説得力のある証拠でもある（記事冒頭の RE スロット）。
そして、 REA や WordCraft と同じ方法で再実装をリリースしよう。つまり MCP サーバーとして公開し、次の人があなたと同じようにエージェントから操作できるようにするのだ。
各関数に明確な名前と説明をつけ、シンプルなコマンドラインツールでラップし、 1 行でインストールできるようにする。
https://x.com/0xMovez/status/2108884063515746410
また、テストは最後にまとめてではなく、進めながら行うこと。 3 つのレイヤーを積み上げた後で見つかったミスは、修正コストが跳ね上がるからだ。
週末を無駄にする 6 つのミス
- Electron アプリにディスアセンブラを開く。 JavaScript がそのままあるなら、 analyze_javascript_application にルーティングし、ネイティブ解析の道を完全にスキップすること。
- 何も読まずにすべてをダンプする。 まず REA に概要を求めること。アプリ全体を一度に引き出すと、本当のロジックがノイズに埋もれ、請求額も跳ね上がる。
- ファイル順に関数を読む。 クロスリファレンス数でソートすること。 xref 147 の関数がアーキテクチャであり、 xref 2 のヘルパーは後回しでよい。
- ステージ 3 の難読化に挑み続ける。 ベンチマークでは多層難読化の解決率は 0% だ。予算を設定し、隣接関数のコンテキストを蓄積して、後で戻ってくること。
- モデルにコードをコピーさせて再実装に入れる。 これではクリーンルームが崩壊する。あるコンテキストで先に仕様を書き、別のコンテキストで仕様から実装すること。
- 同等性レポートなしでリリースする。 「一致していると思う」は証拠にならない。 50 の挙動テストと一致率こそが証拠だ。
結論：
REA をインストールする。バイナリを読む。そして自分のものとして再構築する。
ターゲットをルーティングし、表面をマッピングし、ホットな関数を逆コンパイルし、 Opus 5.5 にすべての名前をつけさせ、解く価値のある難読化を解き、スウォームでスケールさせ、クリーンに仕様化し、 MCP 経由で再実装をリリースする。
11 のステップ。 1 つのモデル。コピーしたコードはゼロ。
