REA：AIエージェントでバイナリとアプリを逆解析

背景と概要

リバースエンジニアリングは、参入障壁の高い作業です。アプリの一つの機能がどう動くかを知りたいとき、研究者はネイティブバイナリ、バンドル済みのJavaScript、Electronアプリ、.NETアセンブリ、稼働中のWebサイトを一度に相手にすることがあります。対象ごとにツールチェーンが違います。従来は Hopper、Ghidra、IDA といった逆アセンブラを行き来し、手がかりを手作業で記録し、最後に文章へまとめていました。

REA（Reverse Engineer Anything）は、この流れを変えようとするAIエージェント向けのMCPサーバーです。morluto が保守し、TypeScriptで書かれ、npmパッケージ rea-agents として配布されています。新しい逆コンパイラを作るのではなく、既存の解析エンジンの上に載ります。そして Claude Code、Codex、Cursor、Gemini CLI などから同じ方法で呼び出せる層を提供します。

公式サイト、ガイド、事例集、FAQ、MCP契約ドキュメントも用意されています。READMEは十数言語で読め、質問や作品共有のための Discord コミュニティもあります。

深掘り分析

REAはソースコードのないアプリを、AIエージェントにどう解析させるのでしょうか。REAは、ネイティブバイナリ、JavaScriptとElectronアプリ、.NETアセンブリ、Webサイトを一つのMCP入口にまとめます。エージェントがそこを呼び出すと、各結論には根拠と制約の説明が付いて返ります。ネイティブ解析では、インストール済みの Hopper、Ghidra、IDA を使えます。静的なJavaScript解析には、ネイティブエンジンは不要です。 設計上の特徴は三つあります。第一に、同じツール群をエージェントからもターミナルからも使えます。まずエージェントに一巡させ、結果をコマンドラインで確かめることができます。第二に、解析はローカルで実行されます。第三に、根拠と制約を添える約束事です。大規模言語モデルは、確信ありげに裏付けのない説明をしがちです。この点が、逆解析での最大の弱みです。読み手は答えをただ信じるのではなく、根拠をたどって確かめられます。 導入の手順は短く済みます。Node.js と npm があれば、npx rea-agents setup を実行します。接続するエージェントを選び、インストーラーが示す変更内容を確認します。既存の設定はバックアップされ、終わったらエージェントを再起動します。READMEは Claude Code、Codex、Cursor、Gemini CLI、Grok Build を対応先として挙げ、それ以外は別のインストール文書で案内しています。インストール時にはワークフロー指示も書き込まれます。エージェントはこれで、ツールを使う順序を把握できます。リポジトリのトピックにある agent-skills、binary-analysis、decompiler も、道具と手順を一緒に届ける発想を示しています。

Linuxでは注意点が一つあります。Ghidra、JADX、ファームウェアツールの起動、静的なJavaScriptとElectronの解析には、procps互換の ps が PATH 上に必要です。REAはこれでプロセスの所有者を確認します。復旧手順は docs/installation.md の該当箇所に書かれています。

業界への影響

典型的な使い方は単純です。デスクトップアプリで気になる機能を見つけたら、エージェントに REA で調べさせます。エージェントはソースなしでアプリを検査し、機能の仕組みを根拠付きで説明します。そのうえで、自分のプロジェクトに合わせた実装を書く手伝いもできます。リバースエンジニアリングが一部の専門家の手作業から、エージェントが支援できる作業フローへ近づきます。

個人開発者や小さなチームにとっては、競合調査、互換性の問題調査、レガシーソフトの理解を始めるコストが下がります。セキュリティ研究者にとっては、統一されたMCPインターフェースにより、異なる解析エンジンの強みを孤立させず組み合わせられます。

リスクもあり、入力資料にも明記されています。他者のソフトウェアを解析することには、ライセンスと法律の問題があります。利用者自身が、契約条件と各地域の法令を確認する必要があります。エージェントの説明は根拠付きでも、人による確認が欠かせません。特に逆コンパイル結果からの推測は要注意です。ネイティブ解析の質は、Hopper、Ghidra、IDA の状態にも左右されます。READMEは配布元の偽装にも注意を促しています。入手先は morluto/rea、rea.tools、npmパッケージのみとし、名前の似たリポジトリは公式の証明にならないとしています。

今後の展望

注目点は三つあります。一つ目は対象範囲です。現在の四種類以外に、REAがどこまで広がるかが問われます。二つ目はコミュニティの知見です。事例集と agent-skills の考え方が、再利用できる手法の蓄積へ育つかどうかは、検証済みのワークフローが投稿され続けるかにかかっています。

三つ目は約束事そのものです。REAはすべての結論に根拠と制約を求めます。他のエージェントツールも同じ習慣を採れば、機械生成の解析を検証しやすくなります。広がらなければ、有用でも孤立した例にとどまります。

当面の確かめ方は控えめで十分です。npx rea-agents setup で導入し、すでに仕組みを知っているアプリで試します。示された根拠が正しいかを見れば、未知のアプリでどこまで信頼できるかが、すぐに分かります。