Driver Analysis

Agent Skills › buzzer-re/Rikugan › Driver Analysis

Driver Analysis

GitHub

用于Windows内核驱动二进制分析，定位DriverEntry、提取分发表及IOCTL处理函数，识别关键数据结构，并检测内存越界、权限提升等常见安全漏洞。

rikugan/skills/builtins/driver-analysis/SKILL.md buzzer-re/Rikugan

Trigger Scenarios

Windows内核驱动逆向分析驱动程序安全审计 IOCTL漏洞挖掘

Install

npx skills add buzzer-re/Rikugan --skill Driver Analysis -g -y

More Options

Non-standard path

npx skills add https://github.com/buzzer-re/Rikugan/tree/main/rikugan/skills/builtins/driver-analysis -g -y

Use without installing

npx skills use buzzer-re/Rikugan@Driver Analysis

指定 Agent (Claude Code)

npx skills add buzzer-re/Rikugan --skill Driver Analysis -a claude-code -g -y

安装 repo 全部 skill

npx skills add buzzer-re/Rikugan --all -g -y

预览 repo 内 skill

npx skills add buzzer-re/Rikugan --list

SKILL.md

Frontmatter

{
    "name": "Driver Analysis",
    "tags": [
        "driver",
        "kernel",
        "windows",
        "ioctl",
        "vulnerability"
    ],
    "description": "Windows kernel driver analysis — DriverEntry, dispatch table, IOCTL handlers, vulnerability audit"
}

Task: Windows Kernel Driver Analysis. You are analyzing a kernel-mode driver binary.

Mandatory First Steps

Find DriverEntry — usually the binary entry point
- Signature: NTSTATUS DriverEntry(DRIVER_OBJECT*, UNICODE_STRING*)
- Use decompile_function on the entry point
From DriverEntry, extract:
- MajorFunction dispatch table assignments
- DriverUnload pointer
- DeviceName and SymbolicLinkName
Identify IOCTL handlers — look for IRP_MJ_DEVICE_CONTROL dispatch entry

Key Data Structures

Use create_struct and set_type early — these appear in virtually every driver:

DRIVER_OBJECT, DEVICE_OBJECT
IRP, IO_STACK_LOCATION
UNICODE_STRING

Apply types with set_function_prototype and apply_type_to_variable to make decompiled code readable immediately.

IOCTL Analysis

For each IRP_MJ_DEVICE_CONTROL handler:

decompile_function on the dispatch function
Find the switch statement on IoControlCode
For each IOCTL code, document:
- IOCTL value and decoded method/access
- Expected input/output buffer sizes
- Operation performed
Check for dangerous patterns:
- Kernel memory read/write gadgets
- Process token manipulation
- Arbitrary code execution paths

Common Vulnerabilities to Flag

KeSetEvent with user-controlled address — kernel write primitive
Missing ProbeForRead/ProbeForWrite before kernel-mode buffer copy
Unchecked buffer sizes in METHOD_NEITHER IOCTLs — pool overflow
MmMapIoSpace with user-supplied physical address — arbitrary physical memory access
Direct stack buffer reads without size validation — kernel stack overflow
ObReferenceObjectByHandle without proper access checks

Analysis Workflow

Map the dispatch table → understand all supported IRPs
Deep-dive each IOCTL handler → document input/output
Trace data flow from usermode input to kernel operations
Flag every path where user-controlled data reaches a sensitive kernel API
Rename functions as you understand them: DispatchDeviceControl, HandleIoctlReadPhysMem, etc.