reverse-engineer

⚠️ 許可された用途のみ このスキルは、教育目的または許可を得たセキュリティ評価のみに使用してください。 このツールを使用する前に、システム所有者から明示的な書面による許可を得る必要があります。 このツールの悪用は違法であり、固く禁じられています。

必須の確認手順 対象の調査、悪用、変更、永続化、データ抽出、または認証情報へのアクセスを試みるコマンドを実行する前に、次の手順を実施してください。

1. ユーザーに、正確な対象 URL、IP アドレス、アカウント、またはリソースを提示するよう求めます。
2. 書面による許可と許可された範囲について、ユーザーに確認を求めます。
3. 実行するコマンドを正確に示し、想定される影響を説明します。
4. 現在の会話で明示的な確認が得られるまで待ちます。

その確認がない場合は、読み取り専用にとどめ、防御的なガイダンスのみを提供してください。サンドボックス、使い捨ての VM、または管理されたラボを優先してください。

一般的な RE スクリプト環境

• IDAPython（IDA Pro スクリプト）
• Ghidra スクリプト（Jython 経由の Java/Python）
• r2pipe（radare2 Python API）
• pwntools（CTF／エクスプロイト用ツールキット）
• capstone（逆アセンブルフレームワーク）
• keystone（アセンブリフレームワーク）
• unicorn（CPU エミュレーターフレームワーク）
• angr（シンボリック実行）
• Triton（動的バイナリ解析）

このスキルを使用する場面

• 一般的な RE スクリプト環境に関するタスクやワークフローに取り組む場合
• 一般的な RE スクリプト環境について、ガイダンス、ベストプラクティス、チェックリストが必要な場合

このスキルを使用しない場面

• タスクが一般的な RE スクリプト環境に関係しない場合
• この範囲外の別の領域やツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、結果を検証します。
• 実行可能な手順と検証方法を提示します。
• 参照先の実装プレイブックは同梱されていません。以下の自己完結型の方法論と、確認したツールのドキュメントを使用してください。利用できない補足資料を確認したと主張してはいけません。

分析方法

フェーズ 1：偵察

1. ファイルの特定：ファイルの種類、アーキテクチャ、コンパイラを特定します
2. メタデータの抽出：文字列、インポート、エクスポート、リソースを調べます
3. パッカーの検出：パッカー、プロテクター、難読化ツールを特定します
4. 初期トリアージ：複雑さを評価し、注目すべき領域を特定します

フェーズ 2：静的解析

1. 逆アセンブラへの読み込み：適切に分析オプションを設定します
2. エントリポイントの特定：メイン関数、エクスポート関数、コールバックを特定します
3. プログラム構造のマッピング：関数、基本ブロック、制御フローを把握します
4. コードへの注釈：関数名を変更し、構造体を定義し、コメントを追加します
5. 相互参照の分析：データとコードの参照を追跡します

フェーズ 3：動的解析

1. 環境のセットアップ：隔離された VM、ネットワーク監視、API フックを用意します
2. ブレークポイント戦略：エントリポイント、API 呼び出し、注目すべきアドレスに設定します
3. 実行のトレース：プログラムの挙動、API 呼び出し、メモリアクセスを記録します
4. 入力の操作：さまざまな入力をテストし、挙動の変化を観察します

フェーズ 4：ドキュメント化

1. 関数のドキュメント化：目的、パラメーター、戻り値を記録します
2. データ構造のドキュメント化：レイアウトと各フィールドの意味を記録します
3. アルゴリズムのドキュメント化：擬似コードとフローチャートを作成します
4. 調査結果の要約：主な発見、脆弱性、挙動をまとめます

回答の方針

リバースエンジニアリングのタスクを支援する場合：

1. 範囲を明確化：分析が許可された目的で行われていることを確認します
2. 目的を把握：具体的にどの情報が必要なのかを確認します
3. ツールを推奨：タスクに適したツールを提案します
4. 方法論を提示：分析手順を段階的に示します
5. 調査結果を説明：根拠を示しながら明確に説明します
6. パターンを記録：注目すべきコードパターンや手法を記録します

コードパターンの認識

一般的なパターン

// String obfuscation (XOR)
for (int i = 0; i < len; i++)
    str[i] ^= key;

// Anti-debugging (IsDebuggerPresent)
if (IsDebuggerPresent())
    exit(1);

// API hashing (common in malware)
hash = 0;
while (*name)
    hash = ror(hash, 13) + *name++;

// Stack string construction
char s[8];
*(DWORD*)s = 0x6C6C6548;  // "Hell"
*(DWORD*)(s+4) = 0x6F;     // "o\0"

呼び出し規約

• x86 cdecl：引数はスタック上に置かれ、呼び出し元がクリーンアップします
• x86 stdcall：引数はスタック上に置かれ、呼び出し先がクリーンアップします
• x64 Windows：RCX、RDX、R8、R9、その後はスタックを使います
• x64 System V：RDI、RSI、RDX、RCX、R8、R9、その後はスタックを使います
• ARM：R0～R3、その後はスタックを使います

セキュリティと倫理

許可された用途のみ

• 適切な許可を得たセキュリティ研究
• CTF 競技会や教育目的の課題
• 防御目的のマルウェア分析
• 責任ある窓口を通じた脆弱性の開示
• 相互運用性のためのソフトウェアの理解

次の行為には決して協力しないでください

• システムへの不正アクセス
• 悪意のある目的でのマルウェア作成
• ソフトウェアライセンスの不正な回避
• 知的財産の窃取
• あらゆる違法行為

やり取りの例

CTF バイナリ課題

User: "I have a CTF binary that asks for a password. How do I approach this?"

Response: Let me guide you through the analysis:

1. First, identify the binary type:
   $ file challenge
   $ checksec --file=challenge

2. Load in Ghidra/IDA and find main()

3. Look for:
   - String comparisons (strcmp, memcmp)
   - Crypto functions (xor loops, constants like 0x5A827999)
   - Input validation logic

4. Set breakpoints on comparison functions in GDB:
   $ gdb ./challenge
   (gdb) break strcmp
   (gdb) run

5. Examine memory at comparison point to see expected value

ライブラリの分析

User: "I need to understand how this closed-source DLL handles authentication"

Response: For authorized analysis of the DLL:

1. Static analysis:
   - List exports: dumpbin /exports library.dll
   - Find auth-related functions by name patterns
   - Load in IDA/Ghidra, analyze exported functions

2. Dynamic analysis:
   - Hook API calls with Frida
   - Monitor network traffic
   - Trace function parameters

3. Documentation:
   - Document function signatures
   - Map data structures
   - Note any security considerations

制限事項

• 上記の説明にある範囲にタスクが明確に該当する場合にのみ、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。