re-analyze

リバースエンジニアリング分析の入口

入力タイプに応じて、環境の調査が必要かどうかを判断してから、後続の手順に進みます。調査をスキップして、バイナリファイル／サンプルを直接分析することは禁止です。

第〇ステップ：入力タイプの判定と環境の調査

入力タイプ → probe の判定：

入力タイプ	probe
ファイル／サンプル（実行ファイル、ファームウェア、圧縮ファイル、ドキュメント、APK など）	必須
バイナリ／ファームウェアの分析依頼（対象がディスク上にある）	必須
現象の説明／サンプルなし（「あるプログラムがディスクに書き込まない」「動作が異常」など、対象が実行中）	必須（現場での収集にはツールと環境の調査が必要）
コード片（ユーザーが直接貼り付けた C／アセンブリ／疑似コード）	スキップ
逆コンパイルのスクリーンショット／逆アセンブルテキスト（分析可能なファイルなし）	スキップ
プロトコルの説明／ロジックに関する質問（バイナリ対象なし）	スキップ

• probe が必須の場合：references/probe.sh を実行する（またはローカルで同等のコマンドを手動実行する）し、以下を記録します。
  • RE_OS / RE_ARCH / RE_CORES / RE_MEM_GB（調査に失敗した場合→ユーザーに確認）
  • RE_TOOLS：HAVE リスト（インストール済み。優先して使用）と MISS リスト（未インストール。フローは中断しません。必要なスキルがインストール方法を案内します）
  • [[platform-tips]] の本プラットフォームに該当する分岐の知見を参照します
• probe をスキップする場合：OS／ARCH／MEM の要件はありません。RE_OS／RE_ARCH／RE_CORES／RE_MEM_GB／RE_TOOLS を unknown に設定し、後続のステップ／スキルで必要になった時点で確認します。入口で処理を止めることはありません

第一ステップ：好みの確認（段階別）

references/preferences.md の段階別ルールに従って処理します（項目ごとに毎回確認することをデフォルトにはしません）。

• Level 0 クイックエントリー（デフォルト）：目標が初期分析、または明確でない場合 → デフォルト値をそのまま使用します（目標＝初期分析、Ghidra、standard、レポートあり、プラットフォーム auto）。第二ステップに進みます
• Level 1 詳細タスク：目標が詳細タスク（アンパック／脆弱性／プロトコルのリバースエンジニアリング／マルウェアの詳細分析／クラッキング／フォレンジックなど）に該当する場合、またはユーザーから明示的な依頼があった場合 → 5 項目をすべて確認します。
  1. 分析目標（必須回答、最初の項目）——不明確な場合は追加で確認します
  2. 逆コンパイラー：Ghidra（デフォルト）／IDA／radare2
  3. 詳細度：迅速な結論／標準分析／詳細レポート
  4. レポート：要／不要
  5. プラットフォームの確認：自動／手動

結果はセッション変数（RE_GOAL、RE_DECOMPILER、RE_DEPTH、RE_REPORT、RE_TARGET_PLATFORM）に保存し、今回の分析全体で有効とします。呼び出されたスキルが読み取ります。

安全上の最低基準：目標に実行サンプルが含まれる場合は、デフォルトでサンドボックスを使用する原則を伝えます（最優先の原則は [[platform-tips]] を参照）。

第二ステップ：タスクの識別

まず対象を特定します：対象がどのシステムに属するか判断できない場合は、まず [[system-fingerprints]] を確認します。第 0 ステップは証拠の帰属です（コンテナー内にどのオブジェクトがあるか、それぞれの scope、主体はどれか。異なる scope をまたいで見つかったものは、存在するという事実のみを記録）。その後、コンテナーと形式 → スーパーファミリーの絞り込み → ファミリー内での特定 → 混同しやすい対象 → 否定的な判定基準の順に進みます。多くの場合、ELF の EI_OSABI と note セグメントだけで一度に確定できます。コンテナーイメージがない場合はマジックナンバーとシグネチャ文字列を探し、設定ファイルがある場合は、設定形式自体が強い判定基準になります。

判定できなくても無理に決めつけないでください：ファミリーは特定できてもシステムを特定できない場合は、システムを推測して分析全体を誤った方向に進めるより適切です。この場合はファミリーレベルの分岐から先に進みます。

references/triage.md の判断表に従い、RE_GOAL と入力ファイルを編成パスに割り当てます。複合目標の場合は、依存関係の順に複数の大分類を連結します。

まず認可コンテキストを判定します：triage の第 0 ステップに従って RE_AUTH（owned / ctf / research / unknown）を判定します。パッチ／回避／動的実行などの機微なパスはこれに従います（[[re-cracking]] の認可境界と同じです）。

第三ステップ：ルーティングエンジン（ステートマシン）

スキルは呼び出しチェーンではなく、状態遷移です。各スキルの実行後に新たな証拠が生成され、その証拠に基づいて次の処理へ進みます。

triage → route → skill execution → evidence → route（循环）

該当する大分類のゲートウェイスキル（[[re-binary-core]] [[re-malware]] [[re-firmware]] [[re-protocol]] [[re-mobile]] [[re-anti-analysis]] [[re-cracking]] [[re-vuln]] [[re-ctf]] [[re-managed]] [[re-forensics]]）を呼び出します。各ゲートウェイが内部で適切なアトミックスキルを選択します。

Route State（ループ防止）：

• visited：すでに実行したスキルの一覧（セッション変数 RE_VISITED）
• max revisit：1
• ルール：同じスキルを2回目に実行する場合は、新しい証拠を必ず提示します（前回の実行時と比べた証拠の増分——新しい文字列／新しい動作／新しい構造上の特徴）。新しい証拠がない場合は再実行せず、現在のスキルの代替分岐に戻るか、[[rerouting]] の B 表に従って収束させます（binary-core ↔ crypto ↔ anti-analysis 系のループを防止します）

二重トラックの再ルーティング（必須、[[rerouting]] を参照）：

• トラック 1（ゲートウェイ完了時に必ず確認）：各ゲートウェイの完了後、新しい証拠を [[rerouting]] の A／B 表と照合します。該当する場合 → 対応するスキルを呼び出し、完了後にトラック 1 に戻って続行します
• トラック 2（証拠が現れた時点で確認）：分析中に新しい証拠の種類（鍵／C2／パッカー名などの文字列、セクションテーブル、動作、暗号化の特徴）が得られるたびに、ただちに A 表と照合します。該当する場合 → スキルを呼び出します
• どの項目にも該当しない場合 → B 表の制約に従って行動します（アプローチの変更／前の段階への差し戻し／部分的な結論の提示）。独自に無理な推論を続けることは禁止です

システム間の誤判定表（判定前に必ず確認）：「これは hook／dead code／loader bug／悪意がある」と書く必要があるときは、まず [[cross-system-models]] を確認します。高頻度の誤判定10項目とシステム間の共通原則（ローカルハンドル≠グローバル識別子、ready≠実行資格あり、カーネルへの入口がない≠I/O がない、CFG エッジがない≠発生していない、ディスク上≠実行中）、および異常処理ツリーを参照し、その実行モデルで許容される正常なメカニズムを一つずつ除外します。除外のプロセスと根拠をレポートに記載し、すべて除外できるまで結論を書いてはいけません。

分析の全工程で [[analysis-contract]] を遵守します。分析前にコンテキスト一覧（調査予算を含む。対象ごとにツール呼び出しは ≤8 回）を収集し、工程間ではデータ契約に従ってフィールドを受け渡し（スキャンを重複させない）、結論を提示する前に独立した再確認（証拠と結論を一つずつ照合し、信頼度を含む構造化形式で出力）を行います。

第四ステップ（任意）：知見の振り返り

分析結果を提示した後、今回のつまずきや新しい手法をスキルライブラリにフィードバックするかユーザーに確認します。必要な場合は [[re-feedback]] を呼び出します（3 段階：issue を投稿／ローカルに登録／登録しない。知見の抽出時には匿名化が必須です。同ゲートウェイのレッドラインを参照）。

使用する場合／使用しない場合

• 使用する：リバースエンジニアリング／マルウェア／ファームウェア／プロトコル／モバイル／クラッキング／CTF の分析依頼全般
• 使用しない：具体的なスキルがすでにトリガーされた、明確な依頼（例：「このコードを Ghidra で分析して」は [[re-ghidra]] に直接進めます）

常见坑与陷阱

• 探测不是摆设：内存 <4GB 却选了 Ghidra → 提示改用 radare2

• 目标是"看逻辑"却直接上沙箱 → 静态优先，动态按需

• 用户没装任何工具是常态——不要因为 MISS 卡住，按「工具准备」引导安装

• 自挖前先搜社区逆向成果：现象——为同类目标（协议/壳/签名）自写解析器/算法还原，耗时是移植的 10 倍；原因——开源逆向项目（协议实现、脱壳器、模拟器回调集）是前人成果沉淀，直接可移植；对策——先搜 GitHub/码云/codeload 同类项目（即使版本不同，结构/模式可复用），确认无现成成果再自挖

• 走完入口不再调用技能：现象——入口编排后自己硬琢磨，中途发现新特征（壳/加密/反调试）不调对应技能；原因——再路由未执行；对策——按第三步双轨：每网关完成/每新证据对照 [[rerouting]] 触发表，命中即调

• 把大目标当一步棋，要求一次全量分析：现象——接到"分析这个程序"直接要求整套分析+完整报告，工具/技能一次返回全量结果，上下文膨胀且重复扫描；原因——没把长任务拆成小步骤链，大而全的输出牺牲了可探索性与可跟踪性；对策——拆成原子小步（列字符串→查 xref→单函数反编译），每步产物带地址/符号等结构化字段直接喂下一步，大输出按行范围/分页按需拉取，不一次拉全 （来源：ReVa（cyberkaida），Apache-2.0）

• 工具参数不匹配就换路，不先做输入归一化：现象——传参报错（地址/符号名形态不符、类型不匹配）立即判定工具不可用或换思路；原因——工具输入层本就容忍常见偏差，LLM 的典型错误可在输入端消化；对策——重试前先归一化：地址↔符号名互相尝试、数字/布尔参数补类型转换、签名文本消除空白差异（如 char *func( 与 char* func( 等价）；互斥参数冲突时按错误提示去掉其一再重试 （来源：ReVa（cyberkaida），Apache-2.0）

• 报错当死路，不读错误消息里的下一步指引：现象——工具报错即停或换路，忽略错误文本中的修复建议；原因——把错误当终点而非决策点；对策——错误消息通常带够纠错上下文（相似名建议、可用清单、前置条件提示如"先反编译再改名"/"先定义函数再修改"），按指引修正重试，重试成本低于换路 （来源：ReVa（cyberkaida），Apache-2.0）

• 长任务上下文膨胀：同步等全量 vs 游标增量轮询：现象——分钟级分析（全量自动分析、批量对比）同步死等或反复重查旧结果，重复内容挤占上下文，后期判断被稀释；原因——没用"小片段+增量"机制管理长任务上下文；对策——长任务交后台作业，先拿回作业标识+日志游标立即继续，轮询只取游标之后的新增行，终态再取完整结果，期间并行其他环节；输出侧同理：列表先 count 后 list、默认紧凑模式（名称+地址+大小），需要细节再开 verbose——大集合绝不一次拉全 （来源：ReVa（cyberkaida），Apache-2.0）

• 预设工具覆盖不了就卡死，不启用脚本逃逸舱：现象——标准工具链缺对应能力（批处理、自定义逻辑）就停滞或放弃；原因——没把脚本直通当备选通道，或反过来滥用脚本绕过专用工具；对策——工具优先：先确认无专用技能/工具再绕道脚本；脚本执行带护栏（输出截断、超时、异常捕获、只写注册脚本目录），inline 代码走临时文件；脚本产物回填结构化字段继续后续环节 （来源：ReVa（cyberkaida），Apache-2.0）