REA
出荷済みバイナリやパッケージ、逆コンパイル、受動的なアプリケーションランタイムエビデンス、または利用可能なソースコードで確立されていない動作との比較に依存する主張がある場合にのみ、REAを使用してください。完全なソースリポジトリの通常分析には、通常のリポジトリツールを使用し、REAの準備やプロバイダーコマンドを実行しないでください。
必要な場合のみ接続する
このスキルをインストールすると指示が提供されますが、REA MCPサーバーの登録、分析エンジンのインストール、または既に実行中のエージェントへのツール追加は行われません。
REAツールが利用可能で、その登録が古くなっていないことが確認されている場合は、直接ターゲット分析に進んでください。調査のたびに診断やセットアップを実行しないでください。接続されているサーバーの実際のツールリストと入力スキーマを使用してください。リポジトリのメインブランチからインストールされたスキルは、古いnpmリリースには存在しない機能を記述している場合があります。サーバーが保持する参照を広告していない場合は、完全なインラインエビデンスを保持してください。
ツールがない場合、呼び出しがクライアントによってブロックされている場合、または必須プロバイダーが利用できない場合は、接続と復旧を読んでください。観察されたブロッカーを診断し、まだサポートされている有用な作業を続け、修復後に元のタスクを再開してください。クライアントの承認、シェルのPATH、登録、エンジンの利用可能性には異なる対処法があります。すべてに対してセットアップを繰り返さないでください。
- REAまたはクライアントの設定を変更せずに診断します。
npxはパッケージをダウンロードし、npmのキャッシュに書き込む場合があります。Codexの場合は、npx -y [email protected] doctor --client codex --jsonを実行します。現在サポートされているクライアントに置き換えてください:claude_code,claude_desktop,codex,cursor,gemini_cli,windsurf,devin,opencode,antigravity,copilot_cli,commandcode,vscode,grok_build,omp,grok_bot。grok_botにはローカルファイルの登録がありません。doctorはGrok Botチャットのステップを報告し、セットアップはmcp.jsonを書き込みません。クライアントが不明な場合は、doctor --jsonを使用し、セットアップスコープを選択する前にその登録結果を検査してください。 - 理由を区別してください。登録がない、不正な形式、または古い場合は、スコープ設定された設定修復が必要です。登録は整っているが、アクティブセッションにツールがない場合は、再起動/再接続が必要です。doctorは現在のエージェントが接続していることを証明できません。プロバイダーがない場合は、そのプロバイダーを必要とするタスクにのみ影響します。静的なJavaScript検査にはHopperもGhidraも必要なく、Android検査には別途JADX/Javaの前提条件があります。
- 設定修復のために、読み取り専用の計画を準備します:
npx -y [email protected] setup --client codex --dry-run --json。現在のクライアントのIDを使用し、その正確な提案されたパス、バックアップ、変更を表示し、セットアップが設定を書き込んだりHopperをインストールする前に承認を得てください。セットアップは通常、一致するバンドルスキルもインストールします。その置き換えをレビューされた計画に含めてください。承認後、同じスコープでnpx -y [email protected] setup --client codex --yesを適用します。--install-hopperは、その個別のインストールが必要で明示的に承認された場合にのみ追加してください。 - 影響を受けるエージェントを再起動/再接続します。REAツールが実際にセッションに表示されることを確認し、元の調査を再開します。それでも表示されない場合は、セットアップを繰り返すのではなく、クライアントのMCP起動エラーを調査してください。
REAのセットアップは、Node.js、npm、Homebrew、Java、Ghidra、IDA、JADX、Binwalk、Unblobをインストールまたはアップグレードすることはありません。既存の前提条件を使用し、MCP登録を修復するために無関係なソフトウェアをインストールしないでください。サポートされていないクライアントの場合は、バージョン固定されたrea-agentsパッケージを使用した手動のstdio登録を使用するか、CLI経由で続行してください。
オペレーターが提供するJavaScriptツリーまたはASARに対する具体的なCLIフォールバックは次のとおりです:
npx -y [email protected] analyze-javascript-application /absolute/path/to/app --json
MCP登録やネイティブエンジンは必要ありません。返されたEvidence、グラフ、制限、不明点をMCP結果と同じ注意深さで読んでください。CLIはEvidenceレコードを直接返します。このフォールバックはMCPが設定されていることを確立しません。ネイティブCLIタスクには、選択したエンジンが引き続き必要です。既存のrea CLIを優先してください。インストールされておらず、REAパッケージの取得が許可されたスコープ内にある場合は、代わりにnpx -y [email protected]を使用してください。設定修復は読み取り専用のセットアップ計画から始まります。許可された変更を適用する前に、パス、バックアップ、スキルの置き換えを表示してください。既存の承認とターゲット実行の境界を維持してください。REAのセットアップは、Node.js、npm、Homebrew、Java、Ghidra、IDA、JADX、Binwalk、Unblobを含む無関係なソフトウェアをインストールまたはアップグレードすることはありません。
最初にターゲットをルーティングする
ユーザーが提供したターゲットから最初のツールを選択してください。アクティブターゲットのネイティブまたはアーカイブワークフローにはopen_binaryを使用します。ターゲットフリーツールは、独自の明示的なパスまたはエンドポイントを受け取り、それを必要としません。
- ASARまたは抽出されたJavaScript/Electronツリー:
analyze_javascript_application - アーカイブ/パッケージメンバーインベントリ（ZIP/APK/IPA/MSIX/AppXまたはDMG）: 提供されたローカルパスで
open_binaryを使用。グラフと調査結果が質問の回答に役立つ場合はinspect_artifactを使用。 - Android APKコード、クラス、メソッド、または受信参照:
inspect_android_package、次に広告されている場合は焦点を絞ったAndroidツール。アーカイブメンバーインベントリは引き続き上記のアーカイブルートを使用。 - マネージドPE/CLIアセンブリ:
inspect_managed_artifact - ファームウェアイメージ: 広告されている場合は
inspect_firmware_regions。抽出が要求された場合は、呼び出し元が選択した新しい絶対出力ディレクトリを指定してextract_firmwareを使用。これらのツールは、Linux上で呼び出し元が提供するBinwalk/Unblobを使用します。ファームウェアガイドを参照。 - .NET NativeAOT PE/ELF: ネイティブGhidra分析。ネイティブコードは疑似コードを生成できます。オプションのメタデータ復元とサポートされるホスト/レイアウト境界については、
references/native-and-artifacts.mdのNativeAOTワークフローを参照。 - ユーザー所有のブラウザページが既に開いている場合:
list_browser_targets - エージェントが実行するブラウザアクション（クリック、タイプ、ナビゲート）: 宣言されたアクションを使用して
capture_browser_scenario。ランタイム観測の接続/起動と焦点を絞ったフォローアップブラウザツールを参照。 - Fiddler Everywhereトラフィックまたはネイティブ
.sazキャプチャ: Fiddlerワークフローを読む。保存されたSAZをinspect_web_network_captureでformat: "saz"として検査。ライブトラフィックについては、Everywhereの個別のMCPサーバーに接続。 - 保持されたHAR/SAZ/ネイティブmitmproxy/aioquic qlogキャプチャ:
inspect_web_network_capture。有用な場合は元のレコードの序数を選択。プロデューサーフィールドとバイト/番号サイドカーを、記録されたURLをフェッチしたりライブ属性を主張したりせずに検査。履歴キャプチャで正確なアップストリームプロファイルと資格情報の除外を参照。Qlogサポートはaioquic 1.5.0 JSON 0.3から開始。ストリームカバレッジとエンドポイント損失宣言は、ボディを回復したりネットワーク損失を確立したりしません。詳細サマリー、次に種類qlogトレース/ストリームページを優先。寄稿/範囲ページには1つのトレース、ストリームID、方向を選択。ファクトは選択前の記録されたすべてのイベントスコープを保持。他のqlogレイアウトとPCAP相関はサポートされていません。 - ユーザー所有のElectronランタイムが既に開いている場合:
list_electron_targets。electron-main Inspectorを試みる前に、inspect_electron_fusesでパッケージされたヒューズを確認。EnableNodeCliInspectArgumentsが無効になっている場合、アプリは--inspectを無視します。 - パケットフィールド発見:
inspect_packet_fieldsは、inspect_packet_captureのフィールドを選択する前に、インストールされたプロトコルとフィールド名/タイプを検索。関連レコードをクエリ/ページング。登録は観測されたトラフィックを確立しません。 - 記録されたパケットキャプチャ: 選択されたTSharkフィールド、表示フィルター、デコードアズルールを使用して
inspect_packet_capture。Linux、util-linux prlimit、REA_TSHARK_COMMANDが必要。キャプチャガイドを参照。パケット制限はフィルタリング前の入力パケットをカウント。出力はデフォルトで50の一致フレーム。後のページにはmatch_offset/match_limit、または完全な一致出力には明示的なnull制限を使用。ソースダイジェストをページ間で保持。これはライブキャプチャを実行しません。アドレス/DNS/SNI/プロトコルサマリーには、MCP詳細サマリー、次に保持された種類pcapページでinspect_pcap_captureを使用。Wireshark 4.x tsharkとcapinfos、Linux prlimitまたはWindows Job Objectsが必要。パケットサマリーを参照。アドレスページには正確なDNS質問を選択。ページの枯渇はネットワークの完全性を証明しません。これは録音を読み取り、トラフィックを取得しません。 - デコーダ発見:
inspect_signal_decodersは、インストールされたデコーダIDまたは選択されたデコーダヘルプ（チャンネルとオプションを含む）を検索。設定を選択する前に関連する詳細をクエリおよびページング。これはハードウェアをスキャンしません。 - 記録されたロジック/シグナルトレース: 明示的なデコーダ、チャンネル、プロトコル設定で
decode_signal_recording。Linuxでutil-linux prlimitがある場合、REA_SIGROK_COMMANDを通じてsigrok-cli 0.7.2を提供。録音ガイドを参照。出力はデフォルトで50のリテラル行。注釈クラスを選択し、line_offset/line_limitでページング、または残りのすべての出力には明示的なnull。ウィンドウカウントは表示行であり、注釈やサンプルではありません。ソースダイジェストをページ間で保持。これは既存のファイルを読み取り、ハードウェア信号を取得しません。 - 明示的なローカルWebAssemblyアーティファクト:
inspect_wasm_artifact。REA_WABT_BIN_DIRECTORYを通じてWABT 1.0.42を提供。正確なバイト/ツールIDとデコードされたWATを保持。JavaScriptグルーと候補パスを明示的に選択し、URL/パスのあいまいさを保持。暗黙のフェッチやターゲット実行は行いません。WATは元のソースではありません。WASMガイドを参照。 - 明示的なローカルEVMバイトコードキャリア: 呼び出し元が選択した
rawまたはhexエンコーディングでinspect_evm_interface。キャリア/デコードされたダイジェストを保持し、セレクター、引数文字列、可変性を推測された候補として扱います。これはチェーンルックアップやターゲット実行を行いません。完全な推測インターフェースを16進数や重複するstdoutなしで取得するには、サポートを発見しdetail: "summary"を選択。完全なEvidenceは元のIDの下に保持されます。特定の関数またはbytecode_hex/stdout/stderrページには、返されたparent_evidence_idを使用。候補カバレッジはインターフェースの完全性を確立しません。EVMバイトコードガイドを参照。 - 埋め込まれたGoコンパイラ、モジュール、またはビルド設定メタデータ: 明示的なローカルファイルを使用して
inspect_go_binary。この組み込みのターゲットフリー検査は、Goのインストールや逆アセンブラを必要としません。生のモジュールバイトとソース範囲を保持。メタデータがないことはバイナリがGoでないことを証明せず、解析されていないテキストレコードは明示的なままです。Goバイナリガイドを参照。 - 埋め込まれたcargo-auditable Rust依存関係メタデータ: 明示的なローカルELF、PE、または薄いMach-Oファイルを使用して
inspect_rust_binary。この組み込みのターゲットフリー検査は、Rustのインストールや逆アセンブラを必要としません。パッケージ順序、依存関係インデックス、セクションファイル範囲を保持。.dep-v0セクションがないことはNullメタデータであり、バイナリに依存関係がないことの証明ではありません。rustcコミットハッシュは、読み取り専用の/rustc/<40-hex>/パスからの推測です。Rustバイナリガイドを参照。 - 明示的なローカルSQLiteデータベーススナップショット:
inspect_sqlite_database。Node.js 24.x >=24.15または26+でネイティブSQLite制限を提供するもので検査。最初にスキーマを読み取る（デフォルトでコンパクトインベントリ）、または行が必要な場合は正確な通常のテーブルとcolumnsを選択。デフォルトは選択されたテーブルのスキーマと20行。完全な保存スキーマが必要な場合はschema_scope: "database"を要求。データベースと既存の兄弟WAL IDの両方を保持。行サンプルは切り捨てを報告し、順序は指定されていません。ライブデータベース/WALペアがアトミックにコピーされたと仮定するのではなく、静止スナップショットを使用してください。SQLiteガイドを参照。 - オフラインレイアウト、シンボル、再配置、または静的緩和エビデンスのための明示的なLinux ELFファイル:
inspect_binary_layout。このターゲットフリー操作は、逆アセンブラデータベースを開かずに、呼び出し元が提供するpwntoolsを使用します。その生の場所と推論/カバレッジの制限を保持。オフラインバイナリガイドを参照。 - 提供されたLinux x86-64 ELFコア:
inspect_recorded_crash。ライブターゲットを開かずに、記録されたすべてのスレッド、生のノート、ソースバウンドレジスタを読み取ります。過去のPIDはライブプロセスを選択しません。コアのみのマッピング候補が役立つ場合にのみinclude_debugger_contextを要求。記録されたクラッシュガイドを参照。 - PEリソースタイプ/名前/言語ツリーと静的アイコングループ参照: 明示的なパスで
inspect_pe_resources。このポータブル操作はアクティブターゲットやエンジンを必要としません。不透明なペイロードはファイル範囲とSHA-256を保持します。 - ネイティブ実行可能ファイル、ライブラリ、または分析データベース:
open_binary、次に焦点を絞った分析ツールを直接使用。メタデータまたはインベントリコンテキストが有用で、選択されたプロバイダーから利用可能な場合はbinary_overviewを呼び出します。
既存のIDA MCP設定の場合、元の入力バイナリとprovider_id: "ida"を使用してopen_binaryを使用。.idbまたは.i64データベースを渡さないでください。レガシーアタッチプロファイルは、SHA-256によって既に開かれているGUI入力をバインドし、そのデータベースを開いたままにします。最新のヘッドレスプロファイルは、有効なNETNTLMv2チャレンジ/ハッシュを必要とする場合があります。open_binaryは新しいプロファイルを作成します。
IDBが既に開かれているプロバイダーとの通信（例：idb_import）は、そのルートチェックと分析ステータスを保持し、binary_overviewを介して報告される場合があります。IDA ProガイドでサポートされるIDA Proバージョンとプロファイルタイプを確認してください。
Gh未設定シナリオでは、アドホック設定を達成するために直接ghidraスクリプトヘルパーを使用することがあります。Ghidra Enterprise MCPサーバーが利用可能な場合は、open_binaryでprovider_id: "ghidra"を使用して、サーバーディレクトリ内のファイルを呼び出します。既存のGhidraプロジェクトがプログラムを参照している場合は、project_pathとprogram_nameを指定してopen_binaryを呼び出します。これらのフィールドは、サーバーが公式のGhidra MCP APIを実装している場合にのみ使用されます。
これらの指示に従って分析を進め、各ツールの出力を注意深く解釈し、元の問題に対する回答を導き出してください。