概要
REA は MCP を通じて AI コーディングエージェントをリバースエンジニアリング機能に接続し、ソースコードなしでネイティブバイナリ、JavaScript/Electron アプリケーション、.NET アセンブリ、ウェブサイトを分析できます。Hopper と Ghidra を統合して高度な静的解析を行い、ローカルで実行して証拠と制限事項の説明を添えた結論を提供します。また、コマンドラインツールとして単独で使用することもできます。
README プレビュー
\n\n**English** · [简体中文](README_zh.md) · [日本語](README_ja.md) · [한국어](README_ko.md) · [العربية](README_ar.md)\n\n# REA: Reverse Engineer Anything\n\n### One MCP for reverse engineering across binaries, applications, and runtime behavior.\n\n**See a feature you like. Understand how it works, down to the binary level.**\n\n[](https://www.npmjs.com/package/rea-agents)\n[](https://github.com/morluto/rea/actions/workflows/ci.yml)\n[](#tool-catalog-for-investigation)\n[](https://nodejs.org/)\n[](LICENSE)\n[](https://discord.gg/GkcryMnJDM)\n\n\n\n[Quick start](#quick-start) · [Current status](#current-status) · [Investigation model](#the-investigation-model) · [Tool catalog](#tool-catalog-for-investigation) · [Roadmap](#roadmap) · [How it works](#how-it-works)\n\nnpx rea-agents setup\n\n\n\n\n\n\n\n\n\n\n \n \n Join the Reverse Engineering Community\n \n Discord · Q&A · Show and Tell\n\n\n\n\n\n\n\n\n---\n\nSee a feature in an app that you want in your own product? Ask your agent to investigate it with REA. It can inspect the app without its source code, explain how the feature works, show the evidence, and build a version for your project.\n\nREA connects your agent to tools for inspecting native binaries, JavaScript and Electron apps, .NET assemblies, and websites. You can also use the same tools from your terminal. Analysis runs locally, and results include the evidence and limitations behind each conclusion.\n\nSetup registers REA with your agent and installs matching workflow instructions. Native analysis can use an existing Hopper or Ghidra installation; setup can optionally install Hopper with approval. Static JavaScript analysis needs neither engine.\n\n## Quick start\n\n### Run setup (recommended)\n\nSet up REA with your agent:\n\n```bash\nnpx rea-agents setup\n```\n\nChoose which supported agents should use REA, then review the exact paths and changes before approving. Existing REA registrations are selected by default; newly detected agents are avail
FAQ (5)
トラブル対応なぜGhidra MCPのレスポンス（例: list_procedures）は、わずか~20k行で10 MiBのresource_constraint制限に達してしまうのですか？また、重複したraw_resultデータを修正するにはどうすればよいですか？
これは REA ≤6.7.0 に存在したバグです。Ghidra アダプター（GhidraProviderClient.ts の projectExecution）は、bridge の応答が normalized_result とバイト単位で同一であるにもかかわらず、それを無条件に raw_result へコピーしていました。その結果、各 Evidence レコードは結果を2重に保持し、さらに MCP レスポンスは Evidence を text と structured content の両方に埋め込むため、応答には約4つのコピーが含まれることになり、10 MiB のレスポンスバジェットに収まるインベントリが半減していました（大規模なインベントリは ~40k 行ではなく ~20k 行で resource_constraint により失敗していました）。修正: PR #5355 を含むビルドにアップグレードしてください。この PR は、normalized_result と raw_result がバイト単位で同一である場合に raw_result を null に設定します（AnalysisProvider.ts および docs/mcp-contracts.md の契約によれば、raw_result は result とは異なるプロバイダー表現のみを保持すべきです）。ラッパーの limitations はすでに Evidence の limitations にマージされているため、データが失われることはありません。破壊的変更に関する注意: analyze_function の出力を raw_result.value 経由で解析していたクライアントは、これらの操作では raw_result が null になるため、normalized_result に切り替える必要があります。
トラブル対応rizin_debug_session_status が CJK または絵文字の出力において、16KB の直近の出力バジェットを超えて保持してしまうのはなぜですか？
直近フレームの履歴が UTF-8 バイト数ではなくコードポイント数で切り詰められていたため、雪 のような3バイトの CJK 文字では保持サイズが3倍になり（16,384 ではなく 49,152 バイト）、切断によって絵文字のサロゲートペアが分断され、不正な形式の UTF-8 が残る可能性がありました。これは PR #5246 によりバージョン 6.8.0 で修正されました。6.8.0 以降にアップグレードしてください。この修正ではバイト長を計測し（例: TextEncoder().encode）、コードポイント境界でのみ切断するため、CJK 出力は 16,384 バイトの上限内に収まり、絵文字のプレフィックスも正しい形式に保たれます。
トラブル対応なぜ Rizin の recent_output は CJK や絵文字の出力で 16 KB のフレーム制限を超えてしまうのか、また UTF-8 バイト予算の3倍を維持しながら切り詰めを修正するにはどうすればよいか？
根本原因: src/rizin/RizinDebugSessionManager.ts(1068-1078行目)で、最近のフレームの切り詰め処理がframe.text(デコード済みのJS文字列)をスライスしているため、String.prototype.sliceはバイト数ではなくUTF-16コードユニットを数えてしまいます。MAX_RECENT_FRAME_BYTES = 16 * 1024の場合、3バイトのCJK文字が1コードユニットとしてしかカウントされないため、1フレームが最大49,152バイト(予算の3倍)を保持し、64フレームのリングが意図した1 MiBから3 MiBへと膨らみます。
修正: Bufferを使ってバイト側でスライスし、UTF-8の継続バイトを遡ります。これは1046-1052行目の#startupCapturedOutputですでに使われているのと同じアプローチです:
const bytes = Buffer.from(frame.text, "utf8");
let end = Math.min(bytes.length, MAX_RECENT_FRAME_BYTES);
// avoid splitting a multi-byte sequence: back off continuation bytes (0b10xxxxxx)
while (end > 0 && (bytes[end] & 0xc0) === 0x80) end--;
const kept = bytes.subarray(0, end).toString("utf8");
const historyFrame =
frameBytes > MAX_RECENT_FRAME_BYTES || frame.truncated
? `${kept}[recent frame truncated]`
: frame.text;補足: 既存のテストはASCII(コードユニット == バイト数となるケース)のみをカバーしているため、このリグレッションが見過ごされていました。CJK/絵文字の切り詰めテストを追加してください。このissue(#5242)は#5091の重複です。修正はそちらで追跡してください。
トラブル対応reaでReactバンドルを解析する際に発生する'Owned JavaScript worker exhausted its heap'エラーの修正方法
これは、PR #4243（コミット 42fc6c53a）で導入された、rea の JavaScript メンバー変更パスにおける既知のリグレッションです。循環検出がバインディングから個々の初期化子へ移動したため、エイリアス循環内の結果が一切メモ化されなくなり、解析が初期化子の順序を列挙するようになった結果、React スタイルのバンドル（playwright-core、Notion レンダラー、Next.js の framework-*.js チャンク）でワーカーのヒープが（4 GiB に設定しても）枯渇します。
修正方法：
1. npm リリース以降のバージョンにアップグレードする。このバグは rea-agents@6.7.0（現在の npm 最新版）に存在しますが、main ブランチのコミット e4c3d7239 で修正されています。npm パッケージではなく、main からのビルド（58d6043 で動作確認済み）をインストールしてください。
2. 回避策：#4243 以前のビルド（コミット 1bd5c5c87）にピン留め／ダウングレードしてください。このビルドでは同じファイルを約 1〜2 秒で解析できます。
注記：ヒープ上限を引き上げても効果はありません。探索が指数関数的に増大し、約 17 秒で 4 GiB を使い果たします。修正後は、同じファイルが約 10 秒で完了し、RSS は約 430 MB で、リソース制約による unknown も発生しません。
トラブル対応match_native_functions が大規模な関数インベントリを拒否する場合に 'AnalysisResourceConstraintError'（96 MiB の許容量）を修正する方法
match_native_functions (main のみ、6.7.0 リリースには含まれない) は、呼び出しごとに固定の 96 MiB の表現割当量を計上し、片側あたり約 10k 行を超える Ghidra 形式のインベントリを拒否する (単純な address+name 行では約 19.5k 行超)。修正点: (1) PR #7108 は、共有インベントリの Evidence ID が関数ごとではなく 1 回だけ計上されるよう計上処理を修正し、従来どおりの 96 MiB デフォルトのまま上限を片側あたり約 22k の Ghidra 形式行に引き上げる。(2) PR #7112 はオーバーライドを追加する: config で native.matching_representation_bytes を設定するか (rea setup によってコピーされる)、または REA_NATIVE_MATCHING_REPRESENTATION_BYTES 環境変数を設定する — デフォルト 96 MiB、最大 1 GiB。512 MiB では、片側あたり 50,000 行のマッチングが正常に完了した (CLI: 8.7 秒、ピークメモリ 1.34 GB; MCP: 2.7 秒)。拒否はリトライ不可のままであり、details.limit に上限とオーバーライドが示される。