インストール方法は使用している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 である可能性を示しています。ヒューリスティックに基づいているため、複数の結果を返す可能性があり、偽陽性が生じやすいです。
### Labelling WDM and WDF Structures
いくつかのドライバ構造はすべての `WDM`/`WDF` ドライバ間で共有されています。ツールは `IO_STACK_LOCATION`、`IRP`、`DeviceObject` などのこれらの構造を自動的に識別でき、リバースエンジニアリングプロセス中の時間を節約し、これらの関数が使用されているドライバの領域にコンテキストを提供します。
### Finding and Decoding IOCTL Codes
ドライバをリバースエンジニアリングする際、解析の一部として IOCTL コードに遭遇することはよくあります。これらのコードはデコードされると有用な情報を明らかにし、脆弱性が存在する可能性が高いドライバの特定部分に焦点を当てるのに役立ちます。
潜在的な IOCTL コードを右クリックすると、コンテキストメニューオプションが表示され（または `Ctrl+Alt+D` ショートカットをカーソルが疑わしい IOCTL コードを含む行にあるときに使用）、値をデコードするために使用できます。これにより、デコードされたすべての IOCTL コードのテーブルが出力されます。逆アセンブリビューでデコードされた IOCTL コードを右クリックすると、無効としてマークできます。これにより、非 IOCTL コメントはそのまま残ります。
- デコードされた IOCTL は Output ウィンドウに出力され、重要度で色分けされた IOCTL ウィンドウに一覧表示されます。自動解析後は、`findings.json` / `report.html` にも記録されます。
自動解析はさらに、特定されたディスパッチャ関数に対してマルチストラテジスキャンを実行し、手動でのカーソル配置を必要とせずに IOCTL を自動的に発見します。各ディスパッチャに対して、利用可能な場合は Hex-Rays 逆コンパイラを使用して、再構築された制御フローから switch-case ラベルと `==`/`!=` 比較定数を直接読み取り、次に IDA のスイッチテーブルメタデータ、最後に raw 即値オペランドスキャンにフォールバックします。逆コンパイラパスは、逆アセンブリに逐語的に現れないコードを復元します。例えば、コンパイラがジャンプテーブルとして出力したディスパッチャ（テーブルのベース/バウンドのみが即値として残る）や二分探索比較ツリー（中間コードはデルタとしてのみ残る）などです。代表的なコーパスでは、これにより回復率が 7/28 から 28/28（HEVD）、および 4/17 から 17/17（ALSysIO64）に向上し、偽陽性はありませんでした。
### Flagging Functions
Driver Buddy Reloaded には、一般的に脆弱であるか、バッファオーバーフロー状態を引き起こす可能性のある C/C++ 関数、オペコード、Windows API のリスト（[vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/vulnerable_functions_lists) ディレクトリに定義）があります。見つかったすべてのインスタンスは自動解析中に報告され、機密関数に到達する可能性のあるユーザー制御コードパスを探すのに役立ちます。
### Finding DeviceName
ツールは自動的にドライバの登録されたデバイスパス（`DeviceName`）を見つけようとします。バイナリ内の Unicode 文字列を調べてもパスが見つからない場合、アナリストは手動で Madiant の [FLOSS](https://github.com/mandiant/flare-floss/) を使用して難読化されたパスを見つけることができます。
### Dumping Pooltags
自動解析中に、ツールはバイナリで使用されている `Pooltags` を `pooltags.txt` と互換性のある形式でダンプします。出力をファイルの最後にコピー＆ペーストし、後で WinDbg で読み込むことができます。
- ダンプされたすべての Pooltag を含む `DriverName.sys-DATE-TIME_STAMP-pooltags.txt` ファイルが IDA の DB ディレクトリに書き込まれます。
### Heuristic Vulnerability Checks
`heuristics.py` モジュールはコールチェーン追跡の後に実行され、各ディスパッチャ**およびそれが推移的に呼び出す関数**を検査します。そのため、ディスパッチャのプロローグだけでなく、IOCTL ごとのハンドラも分析されます。呼び出し先のマッチングはインポート認識型です（インポートされた `call cs:__imp_<Name>` はローカル呼び出しと同じ名前にマッチします）。結果は **heuristic** カテゴリで出力されます（特権命令の結果は **opcode** カテゴリを使用します）：
| チェック | フラグ付けされるもの | 重要度 |
|---|---|---|
| 未検証のユーザーコピー | 近くに `ProbeForRead`/`ProbeForWrite`/セーフストリングガードがない `memcpy`/`RtlCopyMemory`/など | HIGH（ハンドラ）、MEDIUM（その他） |
| TOCTOU / ダブルフェッチ | 介入する `ProbeForRead` なしで、ある制御フローパス上でユーザーモードポインタフィールドが再読み取りされる（METHOD_NEITHER ハンドラのみ、そのためカーネルバッファの再読み取りはフラグ付けされない） | MEDIUM |
| Use-after-free | 解放されたポインタが関数内で再利用される（レジスタ CFG ウォーク）、または NULL に設定されずに解放されたグローバルが別の関数から逆参照される | HIGH |
| 特権ゲートの欠如 | パス上のどこにも `SeAccessCheck`/`SeSinglePrivilegeCheck`/トークンチェックがないディスパッチャから到達可能な機密操作（`ZwOpenProcess`/`MmMapIoSpace`/PCI コンフィグ/など） | HIGH |
| IRQL の不一致 | IRQL を上げる関数も存在する場合のページング可能 / `Zw*` / `MmMap*` 呼び出し | MEDIUM |
| 安全でない MDL マッピング | 逆アセンブリに `UserMode` がある `MmMapLockedPages`/`MmProbeAndLockPages`/など | HIGH、それ以外は MEDIUM |
| スタック割り当て | `_alloca`/`_malloca`/`_chkstk` 呼び出し（大規模または動的なスタック割り当て） | LOW |
| サイズ検証なしのプール割り当て | 近くに安全な算術ガードがない `ExAllocatePool*` 呼び出し（割り当て前の整数オーバーフローパターン） | HIGH |
| 特権命令 | ハンドラから到達可能なポート I/O（`in`/`out`）、制御/デバッグレジスタ移動（`mov cr*`/`mov dr*`）、ディスクリプタテーブルロード、`cli`/`sti`/`hlt`（BYOVD ハードウェアアクセスプリミティブ） | CRITICAL（`out`）/ HIGH（`in`）/ MEDIUM |
| 任意書き込み (write-what-where) | 二重に間接参照されたユーザポインタ `*(*p) = c` を介したストア。`*p = *q` 制御されたコピーは弱いリードとして報告されます | HIGH / MEDIUM |
| `\Device\PhysicalMemory` 参照 | 物理メモリデバイスオブジェクト文字列への相互参照（`ZwOpenSection`/`ZwMapViewOfSection` を介した BYOVD パターン） | HIGH（ハンドラ）、MEDIUM（その他） |
これらは**リードジェネレーター**であり、確認された脆弱性ではありません。HIGH/CRITICAL の結果は手動レビューの出発点として扱ってください。
## Feature Flags
すべてのオプションの解析ステージは `DriverBuddyReloaded/config.py` で制御されます。`Feature` クラスを編集して有効/無効にします：
| フラグ | デフォルト | 説明 |
|---|---|---|
| `IOCTL_SCAN` | `True` | IOCTL の検出とデコード（ディスパッチャスキャン + `IoControlCode` フォールバック） |
| `IOCTL_DECOMPILER` | `True` | ディスパッチャスキャンで Hex-Rays ctree を使用（ジャンプテーブル/二分探索コードを復元） |
| `HEURISTICS` | `True` | ヒューリスティック脆弱性チェック（上の表を参照） |
| `TOCTOU_CHECK` | `True` | ダブルフェッチ / TOCTOU ヒューリスティック |
| `UAF_DETECT` | `True` | Use-after-free ヒューリスティック（関数内レジスタウォーク + 関数間グローバル） |
| `ACL_AUDIT` | `True` | ワールドアクセス可能な `IoCreateDevice` / 脆弱な `IoCreateDeviceSecure` SDDL にフラグ付け |
| `SYMLINK_TRACK` | `True` | `IoCreateSymbolicLink` ターゲットパスをデコード |
| `CALLCHAIN` | `True` | ハンドラから危険なシンクへの BFS コールチェーン追跡 |
| `EXPORTS_AUDIT` | `True` | 内部相互参照がゼロのドライバエクスポートにフラグ付け |
| `POOLTAG_FALLBACK` | `True` | レジスタ伝搬プールタグスキャナ（インポートベーススキャンで何も見つからなかった場合に使用） |
| `IRP_MJ_ENUM` | `True` | `IRP_MJ_FUNCTION` IDA 列挙型を作成し、`MajorFunction` スロットに適用（WDM のみ） |
| `RISK_SCORING` | `True` | IOCTL リスクスコアリング（METHOD/ACCESS 重み + ハンドラごとのシンク引き上げ） |
| `RESULTS_WINDOW` | `True` | 解析後に Driver Buddy Reloaded Findings ウィンドウを表示 |
| `JSON_EXPORT` | `True` | `findings.json` を書き込む |
| `HTML_REPORT` | `True` | `report.html` を書き込む |
| `SEGMENT_OPCODE_SCAN` | `False` | セグメント全体のリニアオペコードスキャン（ノイズが多い、デフォルトでオフ） |
## Testing
高速から徹底までの3つのレイヤー：
- **Pure-Python 回帰テスト**（IDA 不要） - ライブデータベースに触れないすべてのロジックをカバー： ```
python tests/test_dbr.py
DBR_SDK=900 python tests/test_dbr.py # simulate the IDA 9.0 import paths
.sys ファイルのマトリクスに対してパイプライン全体を実行し、pass/fail テーブルを表示します: pwsh tests/run_cross_version.ps1pwsh tests/run_golden.ps1 は、tests/drivers/ 内の各リファレンスドライバのクリーンなコピーに対して解析全体を再実行し、その結果をコミット済みの tests/drivers/<driver>.golden.json ベースラインと比較します（カテゴリ、タイトル、重大度、IOCTL コード/メソッド/アクセスについては順序非依存）。新たに追加された発見（偽陽性）、欠落した発見（偽陰性）、または重大度の変更は実行を失敗とみなします。変更によって意図的に発見内容が変更される場合にのみゴールデンファイルを再生成し、その差分を確認してください。ゴールデンはキャプチャ時に使用した IDA 逆コンパイラビルド（8.4）に紐づいているため、回帰テストはそのバージョンで実行してください。_is_valid_ctl_code() によって CTL_CODE 構造に対して検証されます。DeviceType フィールド（ビット31～16）はゼロ以外でなければならず、値が既知の NTSTATUS コードや、0xFFFFFFFF という (DWORD)-1 センチネル（実際のディスパッチャ内部で見られる比較定数、例：WinRing0）と一致してはいけません。これにより、ループカウンタ、小さな即値、エラーコードを除外しつつ、ベンダー定義のデバイスタイプ（0x8000+）を含むすべての有効な IOCTL を保持します。同じフィルターが4つの発見パスすべてに適用されます：IoControlCode xref スキャンと3つのディスパッチャコレクタ（逆コンパイラ ctree、IDA スイッチテーブル復元、および生の即値オペランドスキャン）。DriverBuddyReloaded/config.py にあります。DispatchDeviceControl 検索は x64 ドライバでのみ機能します。find_opcode_data オプション（デフォルト False）により、データセクションに含まれるオペコードマッチを抑制します。これを True にすると、データ内の生バイトマッチも表面化しますが、偽陽性が多い傾向があります。実際のオペコードが見逃された場合、報告されたアドレスに移動してバイトをコードとして再定義することで、通常は復旧できます。マッチは他のすべてのステージと同様に報告されます（結果ウィンドウ、、）。findings.jsonreport.html