---
name: reverse-engineering-kernel
description: 'Use for kernel-mode reverse engineering: Windows driver analysis, anti-cheat
  reversing, rootkit detection, kernel debugging, DSE bypass, PatchGuard research,
  EDR kernel callbacks, hypervisor analysis, and any kernel-level binary inspection
  or modification.'
version: 1.0.0
platforms:
- linux
- macos
- windows
triggers:
  - reverse
  - engineering
  - kernel
  - mode
  - windows
  - driver
  - analysis
  - anti
  - cheat
  - reversing
  - rootkit
  - detection
depends_on: []
metadata:
  tags:
  - reverse
  - engineering
  - kernel
---

# Reverse Engineering — Kernel Mode

## Trigger Conditions

- Windows driver (.sys) reverse engineering
- Anti-cheat analysis (EAC, BattlEye, Vanguard, Ricochet)
- Rootkit detection and analysis
- Kernel debugging (WinDbg, KD)
- Driver Signature Enforcement (DSE) bypass research
- PatchGuard analysis and research
- EDR kernel callback analysis
- Hypervisor/VMM reversing
- Kernel exploit development research
- Bootkit/UEFI firmware analysis
- Kernel-mode rootkit development research
- SSDT/Hook analysis
- IRP handling and filter drivers
- Memory manipulation at ring 0

## Core Methodology

### 1. Driver Analysis Setup

**Tools:**
```
IDA Pro + Hex-Rays (x64 decompiler)
WinDbg Preview (kernel debugging)
DriverView (NirSoft) — list loaded drivers
OSR Driver Loader — load/unload drivers
ScyllaHide — anti-anti-debug
VMware/VirtualBox — isolated analysis environment
```

**Initial driver inspection:**
```bash
# Extract driver info
sigcheck -v driver.sys    # signature, version, timestamp
dumpbin /headers driver.sys    # PE headers, sections
strings driver.sys | head -50    # embedded strings

# Check for known packers/protectors
Detect It Easy (DIE) driver.sys

# Analyze imports
dumpbin /imports driver.sys
# Key imports indicate driver type:
# IoCreateDevice, IoCreateSymbolicLink → device driver
# PsSetCreateProcessNotifyRoutine → process monitoring
# ObRegisterCallbacks → object/callback manipulation
# MmMapIoSpace → hardware/memory access
```

### 2. Kernel Debugging

**WinDbg kernel debugging setup:**
```
Target machine (VM):
bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200

Host machine (WinDbg):
File → Kernel Debug → COM
Port: \\.\COM1, Baud: 115200

Commands:
lm                    # list loaded modules
lm m driver*          # find driver base address
!drvobj driver        # driver object info
!devobj device        # device object info
dt nt!_DRIVER_OBJECT  # driver object structure
dt nt!_DEVICE_OBJECT  # device object structure
```

**Breakpoint strategies:**
```
bp driver!DriverEntry          # driver initialization
bp driver!DeviceControl        # IOCTL handler
bp driver!DispatchCreate       # file open handler
bp driver!Unload               # driver unload
ba e1 <addr>                   # execute breakpoint at address
```

### 3. Anti-Cheat Analysis

**Common anti-cheat components:**
```
EasyAntiCheat (EAC):
  - easAntiCheat_EOS.sys (kernel driver)
  - EasyAntiCheat.exe (user-mode service)
  - Scans for known cheat signatures
  - Integrity checks on game memory
  - Kernel callbacks for process/thread monitoring

BattlEye:
  - BEDaisy.sys (kernel driver)
  - BattlEye.exe (user-mode)
  - Memory scanning, signature detection
  - Screenshot capture
  - Behavioral analysis

Vanguard (Riot):
  - vgk.sys (kernel driver, boot-start)
  - vgc.exe (user-mode service)
  - Runs at boot (SERVICE_BOOT_START)
  - Continuous monitoring
  - Hardware ID tracking
```

**Analysis approach:**
```
1. Extract driver from installer/package
2. Static analysis: imports, strings, control flow
3. Identify scan patterns (memory regions, signatures)
4. Identify callback registrations
5. Map communication with user-mode component
6. Identify detection mechanisms
7. Document bypass vectors
```

### 4. Kernel Hooking Analysis

**SSDT (System Service Descriptor Table):**
```c
// Windows x64 doesn't use SSDT directly, but drivers may hook:
// - Inline function hooking
// - IRP major function hooks
// - Callback registration

// Detect inline hooks:
// Compare function prologue with known clean version
// Look for JMP, CALL to non-module addresses

// WinDbg — check for hooks:
u nt!NtCreateFile    // disassemble, look for JMP
!chkimg nt -d        # check for modified code
```

**IRP Hooking:**
```c
// Filter drivers attach to device stack:
// IoAttachDeviceToDeviceStack
// They intercept IRPs before target driver

// Detection:
// Walk device object chain:
// pDeviceObject->AttachedDevice != NULL → filter present
```

**Callback Analysis:**
```c
// Common kernel callbacks:
PsSetCreateProcessNotifyRoutine      // process creation
PsSetCreateThreadNotifyRoutine       // thread creation
PsSetLoadImageNotifyRoutine          // module loading
ObRegisterCallbacks                  // object access
CmRegisterCallback                   // registry operations
ExRegisterCallback                   // generic callbacks

// List registered callbacks (WinDbg):
// Process callbacks:
dt nt!_EX_FAST_REF PspCreateProcessNotifyRoutine
// Image load callbacks:
dt nt!_EX_FAST_REF PspLoadImageNotifyRoutine
```

### 5. DSE (Driver Signature Enforcement)

**Research context:**
```
DSE prevents loading unsigned drivers.
Research approaches:
- Exploit vulnerable signed driver (BYOVD)
- DSE variable manipulation (g_CiOptions)
- Boot configuration (test mode, debug mode)
- CVE exploitation in signed drivers

Test mode (legitimate):
bcdedit /set testsigning on
bcdedit /set nointegritychecks on
```

### 6. EDR Kernel Analysis

**EDR kernel components:**
```
Common EDR drivers:
- CrowdStrike: CSDeviceControl.sys
- SentinelOne: SentinelMonitor.sys
- Carbon Black: cbk.sys
- Microsoft Defender: WdFilter.sys

Analysis focus:
1. Mini-filter registration (file system monitoring)
2. Process/thread callbacks
3. Image load callbacks (DLL monitoring)
4. Registry callbacks
5. Network filtering (WFP callouts)
6. Memory scanning patterns
7. ETW provider registration
```

**Mini-filter analysis:**
```c
// EDRs register mini-filters for file system monitoring:
FltRegisterFilter(DriverObject, &Registration, &Filter);
FltStartFiltering(Filter);

// Registration structure indicates monitored operations:
// IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_SET_INFORMATION
// Pre-operation and post-operation callbacks

// WinDbg — list filters:
!fltmgr
```

### 7. Hypervisor/VMM Analysis

**Detection techniques:**
```
CPUID instruction:
  CPUID(1).ECX bit 31 → hypervisor present
  CPUID(0x40000000) → hypervisor vendor ID
  CPUID(0x40000001) → hypervisor interface

Timing-based:
  RDTSC before/after privileged instruction
  VM exit causes timing anomalies

Instruction behavior:
  SIDT, SGDT, SLDT — different in VM
  INVD instruction behavior
  MSR access patterns
```

**Hypervisor reversing:**
```
1. Extract hypervisor binary (if accessible)
2. Identify VM-exit handler (VMX: vmexit handler)
3. Map EPT (Extended Page Table) manipulation
4. Analyze intercepted instructions
5. Identify introspection capabilities
6. Map communication with guest
```

### 8. Bootkit/UEFI Analysis

**UEFI firmware analysis:**
```
Tools:
- UEFITool — parse UEFI images
- Universal Extractor — extract firmware
- Chipsec — firmware security analysis

Analysis:
1. Extract firmware from update package
2. Parse UEFI image structure
3. Identify DXE drivers
4. Analyze SMM (System Management Mode) code
5. Check for bootkit persistence
6. Verify Secure Boot configuration
```

### 9. Kernel Exploit Research

**Common kernel vulnerability classes:**
```
- Pool overflow/underflow
- Use-after-free in kernel objects
- Type confusion in IOCTL handlers
- Race conditions in synchronization
- Integer overflow in size calculations
- NULL pointer dereference (pre-Windows 8)
- Uninitialized memory usage
- Arbitrary read/write via IOCTL
```

**IOCTL analysis:**
```c
// Find IOCTL handler in driver:
// DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL]

// Analyze IOCTL codes:
// CTL_CODE(DeviceType, Function, Method, Access)
// METHOD_BUFFERED, METHOD_IN_DIRECT, METHOD_OUT_DIRECT, METHOD_NEITHER

// METHOD_NEITHER is most dangerous — direct user buffer access
// Can lead to arbitrary kernel memory access if not validated
```

## Implementation Standards

- All kernel analysis includes safety warnings for analysis environment
- Provide both static and dynamic analysis approaches
- Include WinDbg scripts and automation
- Document kernel structures and APIs used
- No partial analysis — complete or nothing

## Output Format

For kernel RE tasks:
1. **Driver Identification** — type, version, signature, dependencies
2. **Static Analysis** — imports, strings, key functions, callbacks
3. **Dynamic Analysis** — behavior, kernel debugging findings
4. **Hook/Callback Map** — what the driver monitors/intercepts
5. **Communication** — user-kernel communication mechanism
6. **Artifacts** — scripts, WinDbg commands, analysis tools

Всё, брат.


## Related
- `skill windows-kernel — Windows`
- `skill reverse-engineering-binary — бинари`