REAでできること、条件付きでできること、対応していないこと

コミットを固定した公式ドキュメントをもとに、REAの能力を表にまとめました。標準の静的解析、provider が必要な経路や状態を変える経路、対応外の対象、Evidence と「不明」の読み方まで。

開発セキュリティリバースエンジニアリングAIエージェント

「Reverse Engineer Anything」は名前であって、仕様ではありません。REA が実際に扱える範囲は、対象の種類、OS、あなたがインストールしてライセンスを揃えた外部ツール、そしてその作業がファイルを読むだけなのか何かを実行するのかによって変わります。この記事では、それをできること、条件付きでできること、対応していない・範囲外のことの3つに分けます。

概要記事に続く4本のうちの2本目です。

  1. 最近の記事は実際に何を試したのか
  2. できることと限界(この記事)
  3. 長所と引き換えになるもの、これからのシナリオ
  4. 安全に始めるために

確認日は 2026年10月14日です。 以下の内容は、main ブランチのコミット 29d3dcb に固定した REA の公式ドキュメントと、6.4.0 リリースに基づいています。プロジェクトが文書に書いている内容であって、Motitory が計測した結果ではありません。私たちは REA を実行していません。完全で最新の一覧は README の能力表にあり、この記事では多くの人が出会うであろう行だけを選んでいます。珍しい対象は元の表を見てください。

まず、手元の REA はどれなのか

表を見る前に、バージョンの問題があります。「REA」が同時に3つのものを指しうるからです。

  • npm のリリースと main は同じではありません。 6.4.0 のパッケージと main ブランチは中身が違い、main にしかない機能を使うにはソースからビルドするか、次のリリースを待つ必要があります(インストール:リリース版と main)。
  • MCP の設定は、設定したときのバージョンに固定されます。 @latest で実行するとその時点で公開されているパッケージが選ばれますが、MCP クライアントの設定は変更するまで設定時のバージョンを使い続けます。
  • 一覧にあることと、使えることは別です。 tools/list にツールが出ていても、あなたのマシンで動くとは限りません。ドキュメントによれば、実際に使えるかどうかは接続したセッションの binary_session.result.tool_availability が示し、これは実際に揃っている provider とプラットフォームを反映します(識別と検出)。

ですから、この記事も含めてブログが「REA で X ができる」と書いていたら、正直な読み方は「あるコミットのドキュメントが、ある provider があれば X が可能だと書いている」です。ご自身のセッションで確かめてください。

能力表

対象・作業 状態 必要なもの 静的・ランタイム 状態の変更 不明のまま残りうるもの
JavaScript・Electron のバンドル 可能、標準 ネイティブ provider は不要 静的、アプリは実行しない なし 圧縮されたコード、動的 import、計算されたパス、ソースマップの欠如、ネイティブモジュールの境界
.NET アセンブリ 可能、標準 ネイティブ provider は不要 静的なメタデータと CIL なし リフレクション、実行時に生成されるコード、P/Invoke が実際に行うこと
ネイティブ実行ファイルの詳細な疑似コード・相互参照 条件付き 自分でインストールした Hopper、Ghidra、IDA のいずれか(各自のライセンス) 静的 対象は実行しない、provider が独自のプロジェクトファイルを残すことがある 逆コンパイル結果はソースではない、型や間接呼び出しは推定
ネイティブ実行ファイルの簡易な検査 条件付き、限定的 GNU objdump または Rizin 静的 なし 逆コンパイラよりずっと浅い
Android APK 条件付き JADX と JDK 静的 なし 難読化、実行時に読み込まれるコード、ネイティブライブラリ
Android 端末 条件付き ADB と自分で管理する端末 ランタイム あり:ファイルの転送、アプリのインストール・削除、起動・停止 観察していた間に起きたことだけ
ブラウザのシナリオ 条件付き CDP や Playwright で操作する Chrome 系ブラウザ ランタイム あり:移動、クリック、入力、ストレージ・ネットワーク・アプリの状態変更 記録した区間だけ
既存の HAR・SAZ キャプチャ 可能 手元のキャプチャファイル 静的な解析 なし キャプチャに記録されていないもの
新しいプロキシキャプチャ 条件付き 自分で用意したプロキシ経路 ランタイム あり、他人のデータを含む通信も記録しうる 記録した区間だけ
ファームウェアイメージ 条件付き Binwalk または Unblob 静的だが抽出したファイルを書き出す 抽出結果をディスクに書く 暗号化された、または独自形式のファイルシステム
Frida による計装 条件付き、高リスク Frida ランタイム あり:注入したスクリプトが対象プロセスのメモリ・ファイル・ネットワークの権限で動く その後の対象の状態が不確かになりうる
Windows のプロセスキャプチャ このコミットでは非対応 — — — —
Windows x64 での Ghidra 実験的、読み取り専用 Ghidra 静的 — ドキュメントで実験的と明記

各行の出典は、能力表、Hopper・Ghidra・IDA は必要か、MCP 契約文書のローカルへの影響の節です。

2つの行はもう一度見ておく価値があります。何も追加せずに使えるのは JavaScript・Electron と .NET の静的解析だけで、公開されている2件の独立した実行が触れたのもこの経路だけでした(第1回)。そしてネイティブコードについて、REA は Hopper、Ghidra、IDA の代わりではなく、それらにつなぐ橋です。どれもなければ詳細な疑似コードや相互参照は使えず、objdump や Rizin で得られるものはずっと少なくなります。

ツールに関係なく範囲外のもの

REA の責任ある利用の節は、次をサポートする用途の外に置いています。DRM・ライセンス確認・アンチチートの回避、チートの作成、許可のない認証やボット対策の回避、独占的なコードやアセットの複製です。将来の provider で解消される技術的な制約ではなく、プロジェクトがその用途をサポートしないと表明しているということです。

すべての行にかかわる7つの条件

表は対象ごとに1行ですが、あなたにとって実際に使えるかどうかは、すべての行をまたぐ条件で決まります。

  1. provider。 多くの行が外部ツールに頼っています。REA は大きなツールを黙ってインストールしないので、インストール、ライセンス、更新はあなたの仕事です。
  2. OS。 プラットフォームによって対応が違います。このコミットでは Windows のプロセスキャプチャは非対応で、Windows x64 の Ghidra は実験段階です。
  3. ライセンス。 REA の MIT ライセンスは REA だけのものです。Hopper と IDA は商用ツールで独自の条件があり、ほかの provider にもそれぞれの条件があります(外部ツールとライセンス)。いずれも解析対象への権利は与えません。自分が所有している、または明示的に許可を得た対象だけを解析してください。この記事は法的助言ではありません。
  4. 権限。 ランタイムの経路は実際の権限で動きます。ブラウザはあなたのセッションを持ち、ADB の接続は端末を操作し、Frida のスクリプトはプロセスの中で動きます。REA のセキュリティポリシーは、REA がサンドボックスではないとはっきり書いています。
  5. 静的か動的か。 静的な経路はバイトを読むだけで対象を実行しません。動的な経路は1回の実行を観察するので、その間に起きたことしか見えません。
  6. 副作用。 動的な経路はファイルの作成・削除、アプリのインストール・削除、リクエストの送信、保存された状態の変更を起こしえます。destructive、executesForeignCode、mutatesDevice といった MCP の注釈はクライアントへのヒントであり、呼び出しごとの承認を強制するのは REA ではなくクライアントやホストです(ローカルへの影響)。
  7. データの流れ。 解析はローカルで動きますが、エージェントはツールの結果(文字列、逆コンパイルしたコード、キャプチャした通信など)をモデル提供者に送ります。「ローカル」はツールが動く場所を指すだけで、結果が届く先を指してはいません。

Evidence の読み方:答えが語っていないこと

REA は結果を、識別情報、カバレッジ、制限、不明点を含む Evidence という構造で返します(ツールの結果)。REA でいちばん役に立つ部分であり、いちばん読み違えやすい部分でもあります。

  • 空のリストは「ない」ことの証拠ではありません。 ある側面(facet)が使えない、一部しか見ていない、またはカバレッジが宣言されていない場合、空の配列は「見た範囲では見つからなかった」という意味にすぎません。一部だけ、あるいは不明の状態の呼び出しリストが空でも、その関数が何も呼ばないことにはなりません。
  • 関数のテキストが変わっても、関数が変わったとは限りません。 ビルド間で関数のテキストを比べると、アドレスの移動や自動生成された名前の変化だけによる差分が出ることがあります。逆に、観察した制御フローの性質が同じでも、動作が同じとは言えません。
  • 大きな答えは参照として返ってきます。 標準の stdio の結果上限は 10MiB です。それを超えると完全な Evidence は保存され、呼び出しはリソース制約を示す参照を返すので、要約やページ単位で取り出す必要があります。第1回の HackerNoon の実行はまさにこのケースでした。
  • 対象が話しかけてくることがあります。 結果には、文字列や provider のエラー出力のように、対象が制御する内容が含まれえます。ドキュメントは、それをエージェントへの指示として扱わないよう求めています(信頼できない対象コンテンツ)。バイナリの中に「これまでの指示を無視せよ」という文字列があっても、それはデータです。

どんな結果も証明しないこと

デモが暗にほのめかしがちなので、はっきり書いておきます。

  • 静的解析は実行時の動作を証明しません。 コードにできることを示すだけで、ある実行で実際に何をしたかは示しません。
  • 疑似コードは元のソースではありません。 逆コンパイラが組み立て直したものです。
  • 一部の検査で同じでも、同等とは言えません。 静的な性質の一致、ソースのように見える出力、書き直したコードのルール検査の合格は、あらゆる場合に同じように動くことの証明ではありません。同じ調査から作ったテストは独立した基準ではありません。
  • 誰のものかについては何も語りません。 仕組みがわかっても、それに対する権利が生まれるわけではありません。

第3回では、同じ事実をもとに、REA が何に強く何に弱いのか、これからどこへ向かいうるのかを考えます。

参考資料

リンクと内容は 2026年10月14日に確認しました。

ブログへ