Listen to this Post
Introduction
Windows kernel drivers operate at the highest privilege level (Ring 0), making them both powerful tools for system extension and prime vectors for privilege escalation, rootkits, and detection evasion. Mastering legacy Windows Driver Model (WDM) and Plug-and-Play (PnP) driver development—from IRP handling to synchronization primitives—is essential for red teams writing exploit payloads and blue teams hunting advanced persistence.
Learning Objectives
- Understand the architecture of Windows legacy and PnP drivers, including the `DRIVER_OBJECT` structure, device stacks, and IRP flow.
- Implement and debug driver code using Visual Studio, WDK, WinDbg, and deployment tools like `devcon` and
pnputil. - Apply kernel synchronization mechanisms (spinlocks, mutexes, DPCs, work items) to write race-free drivers.
1. Building Your Windows Driver Lab Environment
Before writing a single line of driver code, you need a safe, debuggable environment. Use a Windows 10/11 VM (not your host) with Kernel-Mode Debugging enabled.
Step‑by‑step setup:
- Install Visual Studio 2022 with “Desktop development with C++” workload.
- Install Windows Driver Kit (WDK) – matching your Windows build version.
- Enable test signing on the target VM (administrator PowerShell):
bcdedit /set testsigning on bcdedit /set debug on bcdedit /dbgsettings serial debugport:1 baudrate:115200
- Set up WinDbg on your host machine to connect via COM port or network.
- Create a new driver project in Visual Studio: Kernel Mode Driver → Empty KMDF/WDM driver.
Security note: Test signing allows loading unsigned drivers for development. Never enable this on production systems.
2. Legacy Driver Anatomy: DriverEntry and DRIVER_OBJECT
Every legacy driver starts with DriverEntry, where you initialize dispatch routines and create device objects.
Step‑by‑step guide:
1. Write a minimal `DriverEntry` function:
NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObj, PUNICODE_STRING pRegistryPath) {
UNICODE_STRING devName = RTL_CONSTANT_STRING(L"\Device\MyDevice");
UNICODE_STRING symLink = RTL_CONSTANT_STRING(L"\DosDevices\MySymbolicLink");
PDEVICE_OBJECT pDeviceObj = NULL;
// Create device object
IoCreateDevice(pDriverObj, 0, &devName, FILE_DEVICE_UNKNOWN, 0, FALSE, &pDeviceObj);
IoCreateSymbolicLink(&symLink, &devName);
// Set dispatch routines
pDriverObj->MajorFunction[bash] = MyDispatch;
pDriverObj->MajorFunction[bash] = MyDispatch;
pDriverObj->MajorFunction[bash] = MyDispatch;
pDriverObj->DriverUnload = MyUnload;
return STATUS_SUCCESS;
}
- Explain the `DRIVER_OBJECT` – it holds all entry points, the device list, and the driver’s unload routine. Red teams often overwrite these pointers to hook kernel functions.
-
Unload routine must delete symbolic link and device object:
void MyUnload(PDRIVER_OBJECT pDriverObj) { UNICODE_STRING symLink = RTL_CONSTANT_STRING(L"\DosDevices\MySymbolicLink"); IoDeleteSymbolicLink(&symLink); IoDeleteDevice(pDriverObj->DeviceObject); } -
IRP Handling and I/O Control Codes: Methods and Security
I/O Request Packets (IRPs) are the fundamental communication mechanism between user mode and kernel drivers. For custom commands, you implement `IRP_MJ_DEVICE_CONTROL` with METHOD_BUFFERED, METHOD_IN_DIRECT, METHOD_OUT_DIRECT, or METHOD_NEITHER.
Step‑by‑step guide to implementing a vulnerable IOCTL handler (and how to fix it):
1. Define IOCTL code – use `CTL_CODE` macro:
define MY_IOCTL_GET_DATA CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)
2. Dispatch routine skeleton:
NTSTATUS MyDispatch(PDEVICE_OBJECT pDevObj, PIRP pIrp) {
PIO_STACK_LOCATION pStack = IoGetCurrentIrpStackLocation(pIrp);
if (pStack->MajorFunction == IRP_MJ_DEVICE_CONTROL) {
ULONG code = pStack->Parameters.DeviceIoControl.IoControlCode;
if (code == MY_IOCTL_GET_DATA) {
// Copy buffer safely
char userBuffer = pIrp->AssociatedIrp.SystemBuffer;
size_t inSize = pStack->Parameters.DeviceIoControl.InputBufferLength;
size_t outSize = pStack->Parameters.DeviceIoControl.OutputBufferLength;
// Vulnerability: missing size check leads to buffer overflow
if (outSize >= sizeof(MyData)) {
RtlCopyMemory(userBuffer, &g_MyData, sizeof(MyData));
}
}
}
pIrp->IoStatus.Status = STATUS_SUCCESS;
pIrp->IoStatus.Information = outSize;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
3. User‑mode caller:
HANDLE hDevice = CreateFile(L"\\.\MySymbolicLink", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL); DeviceIoControl(hDevice, MY_IOCTL_GET_DATA, NULL, 0, &buffer, sizeof(buffer), &returned, NULL);
Critical security: Using `METHOD_NEITHER` directly passes user‑mode addresses into kernel without validation – a classic exploit primitive. Always use
ProbeForRead/ProbeForWritewith exception handling.
- Synchronization in Kernel Mode: Spinlocks, Mutexes, and IRQL
Kernel code runs at different Interrupt Request Levels (IRQL). Writing concurrent code without proper locking leads to crash, deadlock, or security bypasses.
Step‑by‑step usage of a spinlock (DISPATCH_LEVEL):
1. Declare a spinlock (usually in device extension):
typedef struct _DEVICE_EXTENSION {
KSPIN_LOCK MyLock;
LIST_ENTRY MyQueue;
} DEVICE_EXTENSION, PDEVICE_EXTENSION;
2. Acquire/release spinlock – raises IRQL to DISPATCH_LEVEL:
KIRQL oldIrql; KeAcquireSpinLock(&pDevExt->MyLock, &oldIrql); // Access shared structures KeReleaseSpinLock(&pDevExt->MyLock, oldIrql);
- Use a mutex (PASSIVE_LEVEL) for operations that can wait:
KeInitializeMutex(&pDevExt->MyMutex, 0); KeWaitForSingleObject(&pDevExt->MyMutex, Executive, KernelMode, FALSE, NULL); // Critical section KeReleaseMutex(&pDevExt->MyMutex, FALSE);
-
Deferred Procedure Calls (DPC) – execute code after IRQL drops:
KeInitializeDpc(&pDevExt->MyDpc, MyDpcRoutine, pDevObj); KeInsertQueueDpc(&pDevExt->MyDpc, NULL, NULL);
-
Deferred Procedure Calls and Work Items: Avoiding ISR Starvation
Interrupt Service Routines (ISRs) run at high IRQL (DIRQL) and cannot call many kernel APIs. Use DPCs for follow‑up work, and work items for even lower‑priority background tasks.
Work item example – runs at PASSIVE_LEVEL with full API access:
PIO_WORKITEM pWorkItem = IoAllocateWorkItem(pDevObj); IoQueueWorkItem(pWorkItem, MyWorkRoutine, DelayedWorkQueue, pContext);
IRP Queue Draining with cancel‑safe queues (CSQ) ensures IRPs are not lost during driver unload:
IoCsqInitialize(&pDevExt->Csq, CsqInsert, CsqRemove, CsqPeek, CsqAcquire, CsqRelease, CsqComplete);
- Plug and Play Driver Deep Dive: AddDevice and PnP IRPs
PnP drivers respond to device arrival, removal, power events, and resource assignment. The `AddDevice` routine creates the device object and attaches it to the device stack.
Step‑by‑step implementation:
- In
DriverEntry, point `DriverObject->DriverExtension->AddDevice` to your `AddDevice` routine. - AddDevice creates the device and attaches to the stack:
NTSTATUS AddDevice(PDRIVER_OBJECT pDriverObj, PDEVICE_OBJECT pPhysicalDeviceObj) { IoCreateDevice(pDriverObj, sizeof(DEVICE_EXTENSION), &devName, FILE_DEVICE_UNKNOWN, 0, FALSE, &pMyDev); PDEVICE_EXTENSION pExt = (PDEVICE_EXTENSION)pMyDev->DeviceExtension; pMyDev->Flags |= DO_BUFFERED_IO; IoAttachDeviceToDeviceStack(pMyDev, pPhysicalDeviceObj); pMyDev->Flags &= ~DO_DEVICE_INITIALIZING; return STATUS_SUCCESS; }
3. Handle PnP IRPs like `IRP_MN_START_DEVICE`:
case IRP_MJ_PNP:
switch (pStack->MinorFunction) {
case IRP_MN_START_DEVICE:
// Translate raw resources (interrupts, memory ranges)
PIO_RESOURCE_LIST pList = pStack->Parameters.StartDevice.AllocatedResources;
// Configure hardware
break;
case IRP_MN_STOP_DEVICE:
case IRP_MN_REMOVE_DEVICE:
IoDetachDevice(pDevExt->AttachedDevice);
IoDeleteDevice(pDevObj);
break;
}
IoSkipCurrentIrpStackLocation(pIrp);
return IoCallDriver(pDevExt->AttachedDevice, pIrp);
- Installing and Testing Your Driver: devcon and pnputil
Deploying a PnP driver requires an INF file that matches your hardware ID. For testing, you can use `devcon` or `pnputil` to force installation.
Commands to install a test PnP driver:
- Build your driver – produces a `.sys` file and an INF.
2. Copy files to `C:\DriverPackage`.
3. Run as administrator:
pnputil /add-driver C:\DriverPackage\MyDriver.inf /install
Alternatively, using `devcon` (from WDK):
devcon install MyDriver.inf "ROOT\MyDevice"
4. List loaded drivers:
driverquery /v | findstr "MyDriver"
5. Remove driver:
pnputil /delete-driver oem0.inf /uninstall
Debugging tips with WinDbg:
– `.reload /f` to load driver symbols.
– `!drvobj MyDriver` to inspect driver object.
– `!irp` to list pending IRPs.
Power‑pageable flag (
DO_POWER_PAGABLE) – setting this flag allows the driver’s code to be paged out during power transitions, reducing non‑paged pool usage but requiring careful IRQL handling.
What Undercode Say
- Legacy driver knowledge remains a critical offensive skill – many EDR bypasses and rootkits still rely on hijacking IRP dispatch tables or abusing `METHOD_NEITHER` IOCTLs.
- Synchronization bugs are the 1 cause of kernel crashes and privilege escalation – failing to raise IRQL or using wrong primitives can lead to use‑after‑free or double‑fetch vulnerabilities.
- PnP driver complexity (resource requirements, removal locks, CSQ) is often overlooked – attackers target incomplete PnP handlers to cause denial‑of‑service or arbitrary memory manipulation.
Analysis: While Microsoft pushes for Windows Driver Framework (WDF) to simplify development, thousands of legacy drivers remain in enterprise environments. Understanding raw WDM and IRP management is indispensable for reverse engineering third‑party drivers, writing kernel exploits, and auditing firmware interfaces. The course content highlights essential mechanisms like `StartIO` (serialized IRP processing) and `RemoveLocks` (synchronizing device removal) – areas where even experienced developers introduce race conditions.
Prediction
As endpoint detection and response (EDR) products increasingly move sensor logic to kernel mode, demand for driver development expertise will surge – both for building resilient telemetry and for circumventing it. However, Microsoft’s upcoming “Windows 12” security baselines may restrict legacy driver loading via Hypervisor‑Protected Code Integrity (HVCI) and mandatory driver signing. This will force the industry toward modern frameworks (KMDF for PnP, UMDF for user‑mode drivers), but the deep‑seated knowledge of IRP stacks and synchronization will remain essential for analyzing legacy systems, embedded IoT platforms, and bespoke hardware interfaces. Expect a rise in driver‑fuzzing tools (like kDriver Fuzzer) and a parallel market for legacy driver vulnerability hunting – where every missing `ProbeForRead` becomes a zero‑day.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Nikhil T – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
