インストール方法は使用しているIDAのバージョンに依存します。組み込みのプラグインマネージャ（したがって hcli
ツールと ida-plugin.json マニフェスト）は IDA 9.0以降 にのみ存在するためです。IDA 7.6および8.xにはプラグインマネージャがなく、プラグインフォルダの最上位レベルしかスキャンしません。
hcli）リポジトリには ida-plugin.json マニフェストが含まれているため、IDA 9.0以降は独自のサブディレクトリからプラグインを読み込みます。次のコマンドでインストールします。
pip install -e .
hcli plugin install DriverBuddyReloaded
これにより、プラグインはユーザーのプラグインフォルダのサブディレクトリ（例：`%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` または `~/.idapro/plugins/DriverBuddyReloaded/`）に配置され、エントリポイントである `DriverBuddyReloaded.py` はそのサブディレクトリの*内側*に保持されます。これが意図されたレイアウトです：IDA はマニフェストを読み取り、宣言されたエントリポイントをサブディレクトリからロードし、サブディレクトリを `sys.path` に追加するため、エントリポイントは同じディレクトリ内の `DriverBuddyReloaded` パッケージをインポートできます。`DriverBuddyReloaded.py` をトップレベルに移動する必要は**ありません**。
`hcli plugin status` でインストールを確認し、IDA を起動してプラグインが `Edit -> Plugins` に表示されることを確認します（起動時の Python エラーは Output ウィンドウで確認してください）。
テスト用にローカルチェックアウトからインストールするには（例：自分の変更後）、リポジトリルートで `hcli plugin install .` を実行します。`hcli plugin lint .` は最初にマニフェスト/レイアウトを検証します。
### IDA 7.6 / 8.x (manual copy)
これらのバージョンにはプラグインマネージャがないため、`hcli` でインストールしたサブディレクトリプラグインは**認識されません**。`DriverBuddyReloaded` フォルダと `DriverBuddyReloaded.py` スクリプトファイルを IDA プラグインフォルダの**トップレベル**に直接コピーしてください。例：
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`
結果のレイアウトは、`plugins\DriverBuddyReloaded.py` が `plugins\DriverBuddyReloaded\`（パッケージフォルダ）と並んで配置されます。
### Notes
IDA が Python 2 で設定されている場合は、`idapyswitch` バイナリ（IDA フォルダにあります）を実行して Python 3 に切り替えてください。
**注:** Driver Buddy Reloaded は Python 3 で IDA 7.6+, 8.x (8.4 を含む) および 9.0+ で動作します。バージョン固有の IDA API の違い（IDA 9.0 での `get_inf_structure` の削除、`ida_struct` モジュールと `idc.*struc*` ヘルパーの削除など）は、`DriverBuddyReloaded/ida_compat.py` 互換性レイヤーによって内部的に処理されます。
## Quick Usage
自動解析機能を使用するには：
1. IDA を起動し、Windows カーネルドライバをロードします。
2. `Edit -> Plugins -> Driver Buddy Reloaded` に移動するか、`CTRL+ALT+A` を押して自動解析を開始します。
3. "Output" ウィンドウで解析結果を確認し、実行終了時に開かれる **Driver Buddy Reloaded - Findings** ウィンドウを確認します（行をダブルクリックして該当アドレスにジャンプします）。
4. 以下のファイルが IDA の DB ディレクトリに書き込まれます（すべて `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-` という接頭辞が付きます）：
- `findings.json` - 機械可読な結果（IOCTL、フラグ付き関数、デバイス名、プールタグ、コールチェーン、ヒューリスティック、デバイス ACL 監査、シンボリックリンク、エクスポート監査、特権オペコード）
- `report.html` - スタンドアロンの、重要度でグループ化された HTML レポート
- `pooltags.txt` - WinDbg 用の `pooltags.txt` 形式でダンプされたプールタグ
- `autoanalysis.txt` - 解析ログ全文（Output ウィンドウの内容をミラーリング）
IOCTL をデコードするには：
1. マウスカーソルを疑わしい IOCTL コードがある行に置きます。
2. 右クリックして `Driver Buddy Reloaded -> Decode IOCTL` を選択するか、`CTRL+ALT+D` ショートカットを押します。
IOCTL ウィンドウまたは Findings ウィンドウを（解析を再実行せずに）いつでも再表示するには：
- `CTRL+ALT+I` を押して IOCTL ウィンドウを開きます。
- `CTRL+ALT+F` を押して Findings ウィンドウを開きます。
### Advanced Usage
- [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/vulnerable_functions_lists) ディレクトリには、潜在的に危険/問題のある関数、Windows API、およびオペコードのリストが含まれています。特定の関数/API がリストされている理由の簡単な説明も提供されています。ドライバ固有の関数を含む `custom` リストを編集できます。
**注**: `winapi_function_prefixes` は関数名の先頭部分一致を行います（例：`Zw` は `ZwClose`、`ZwCommitComplete` などに一致します）が、`winapi_functions` は完全一致のみを行います。
- [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/find_opcodes.py) では、`find_opcode_data` オプション（デフォルトは `False`）により、データセクション内のオペコード一致が抑制されます（[issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11)）。これを `True` に切り替えると、データ内の raw バイト一致も表面化されます。これにより実際のオペコードが見逃された場合、報告されたアドレスに移動してバイトをコードとして再定義することで、通常は回復できます。一致結果は他のすべてのステージと同様に報告されます（結果ウィンドウ、`findings.json`、`report.html`）。
**注意**: `True` に切り替えると、より多くの偽陽性が発生します！
## About Driver Buddy Reloaded
**Driver Buddy Reloaded** は、Windows カーネルドライバのリバースエンジニアリングの面倒なタスクの一部を自動化する IDA Pro Python プラグインです。便利な機能が多数あります。例えば：
* ドライバの種類の識別（WDM、KMDF、UMDF、WDF、ミニフィルター、ストリームミニドライバー、AVStream、PortCls）
* **すべての**ドライバタイプに対する `DispatchDeviceControl` / `DispatchInternalDeviceControl` 関数の特定（`MajorFunction[IRP_MJ_DEVICE_CONTROL]` ストアスキャンにより、レガシーコントロールデバイスを公開するミニフィルター/WDF ドライバでも、また代入が `DriverEntry` ではなくヘルパーにある場合でもハンドラを見つけます）
* `WDF` および `WDM` ドライバの共通構造の設定
* `IRP` や `IO_STACK_LOCATION` などの構造の識別とラベル付けを試みます
* 通常はラベル付けされない `WDF` 関数呼び出しにラベルを付けます
* `IRP_MJ_FUNCTION` IDA 列挙型を作成し、`DriverEntry` 内の `MajorFunction` 配列スロットに適用します（WDM）
* IOCTL コードの検出とデコード
* 特定されたディスパッチャ関数の自動マルチストラテジスキャン（カーソル配置不要）：
逆コンパイラの ctree（即値として現れないジャンプテーブルや二分探索ディスパッチによって隠されたコードを復元）、IDA スイッチテーブル復元、および raw 即値オペランドのフォールバック（フォールバックは実際に IRP の IoControlCode を読み取る関数に対してのみ実行されるため、誤って識別されたライブラリヘルパーが内部定数を偽の IOCTL として漏らすことはありません）
* NTSTATUS 値は IDA タイプデータベースから動的に解決され（広範なハードコードされたフォールバックあり）、ドライバが単に下流に送信する**アウトバウンド** IOCTL（`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile` / ...）は除外されるため、ドライバ自身の攻撃対象領域と誤認されることはありません
* 誤用されやすい関数のフラグ付け
* 潜在的な `DeviceName` の検出（mmap スキャン + IDA Strings DB フォールバック、ソースアドレス付き）
* `Pooltags` のダンプ（インポートベースのプライマリ＋レジスタにステージングされたタグのためのレジスタ伝搬フォールバック）
* 各ディスパッチャとそれが推移的に呼び出す関数に対する**ヒューリスティック脆弱性チェック**：未検証のユーザーコピー、TOCTOU/ダブルフェッチ、解放後使用（関数内および解放されたグローバルを介した関数間）、特権ゲートの欠如、IRQL の不一致、安全でない MDL マッピング、スタック割り当てバッファ（`_alloca`）、サイズ検証なしのプール割り当て、特権 CPU 命令（ポート I/O `in`/`out`、`mov cr*`）、任意書き込み（write-what-where）、および `\Device\PhysicalMemory` 参照（BYOVD パターン） - [ヒューリスティック脆弱性チェック](#heuristic-vulnerability-checks) を参照
* **デバイス ACL 監査とシンボリックリンクトラッキング**：セキュリティ記述子なし（ワールドアクセス可能）で作成された `IoCreateDevice` デバイス / 脆弱な `IoCreateDeviceSecure` SDDL にフラグを付け、`IoCreateSymbolicLink` ターゲットパスをデコードします
* **エクスポート監査**：内部相互参照がゼロのドライバエクスポートにフラグを付けます（潜在的な攻撃対象領域）
* IOCTL ごとの**リスクスコアリング**（`METHOD_NEITHER` / `FILE_ANY_ACCESS` を優先し、IOCTL のスコアをその**独自の**ケースハンドラから到達可能な危険なシンク/オペコードに対してのみ引き上げます - `MmMapIoSpace`、`memcpy`、`__writemsr`、ポート I/O、PCI コンフィグアクセス - そのため、モノリシックディスパッチャ内の良性コードが危険な兄弟のシンクで汚染されることはありません。帰属が不正確な場合、引き上げは制限され、CRITICAL に強制されることはありません）。そしてすべての結果を重要度別にクリック可能な結果ウィンドウに表示します（ダブルクリックでアドレスにジャンプ）
* ディスパッチ / IOCTL ハンドラから危険なシンクへの**コールチェーンの追跡**（ヒューリスティック、名前ベース）
* 結果を機械可読な **JSON** ファイルおよびスタンドアロンの **HTML レポート**としてエクスポート
### Finding DispatchDeviceControl
ツールは `DispatchDeviceControl` ルーチンを自動的に特定して識別できます。この関数は、受信したすべての `DeviceIoControl` コードをそのコードに関連付けられた特定のドライバ関数にルーティングするために使用されます。この関数を自動的に識別することで、各ドライバの有効な `DeviceIoControl` コードの発見がはるかに迅速になります。さらに、クラッシュが原因でドライバの潜在的な脆弱性を調査する際に、この関数の位置を知ることで、クラッシュした `DeviceIoControl` コードに関連する特定の関数呼び出しに焦点を絞り込むことができます。
解析が成功すると、一部のサブルーチンは次のように名前が変更されます：
- `DriverEntry`: ドライバがロードされた後に呼び出される、ドライバが提供する最初のルーチン。ドライバの初期化を担当します。
- `Real_Driver_Entry`: 通常、`DriverEntry` から実行が移譲された関数。通常、`DeviceName` が初期化される場所です。
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: ツールが特定のオフセットで関数を復元できた場合、関数は適切な名前に変更されます。
- `Possible_DispatchDeviceControl_#`: ツールが `DispatchDeviceControl` または `DispatchInternalDeviceControl` を復元できなかった場合、実験的な検索を実行し、実行フローを追跡して、関数が既知の `IO_STACK_LOCATION` および `IRP` アドレスをロードしているケースをチェックします。これは関数が DispatchDeviceControl である可能性を示しています。ヒューリスティックに基づいているため、複数の結果を返す可能性があり、偽陽性が生じやすいです。