When do you want a driver ?#

In my case I needed a driver to implement a virtual USB device. Generally, you want to write or use a driver when:

• You need to talk to hardware devices (access registers, handle interrupts, use DMA, etc.).
• You need to expose a virtual device to the OS (virtual USB, virtual NIC, virtual storage).
• You want to interact with the operating system at a low level (filesystem extensions, kernel hooks, power management, etc.).
• You need very low latency or high throughput that user-mode APIs cannot provide reliably.
• You want to extend, intercept or augment other drivers (filter drivers, shims).
• You need kernel-level visibility or enforcement (EDR, anti-cheat, integrity monitoring).

If your requirements don’t match any of the above, prefer user-mode code, it will be safer and easier to develop.

User mode vs kernel mode#

You can picture access control as concentric rings: the closer you get to the center (ring 0), the more privileges you have.

Hardware / system#

Devices like your keyboard, mouse, Wi‑Fi card or USB stick produce signals the OS doesn’t understand directly. Drivers translate those signals into events and data the OS and applications can use. They also manage device state, power, and protocol compliance.

Without drivers, the OS cannot enumerate devices, receive input, or move data to/from hardware.

WDF vs WDM toolchain#

You will likely never use WDM unless you’re working on something really exotic

• WDF (Windows Driver Frameworks) includes KMDF (kernel-mode) and UMDF (user-mode). WDF provides higher-level abstractions and helpers so you focus on device logic rather than plumbing.
• WDM (Windows Driver Model) is the older, lower-level model. Writing WDM drivers often means dealing with a lot of boilerplate and edge cases yourself. It is also more free: you can do almost anything in kernel space without the abstractions or restrictions of WDF, which gives flexibility but increases risks.

In practice: WDM is more barebones, more flexible, but more error-prone, WDF (KMDF/UMDF) is safer, more structured, and recommended for modern development.

Cybersecurity#

Drivers run at high privilege, which makes them useful to both defenders and attackers.

• Offensive use: attackers may abuse vulnerable or legitimately signed drivers to execute code in kernel mode, hide artifacts, or persist (rootkits). Collections like “Living Off The Land Drivers” (LOLDrivers) catalog drivers that have been observed abused or weaponized.
• Defensive use: security products (EDR, anti-cheat) sometimes deploy kernel drivers to obtain visibility or enforcement that cannot be achieved from user-mode.

Everyone fights for the ring-0 (kernel access)

Because of the risk, writing and auditing drivers requires extra caution: memory safety, strict validation of inputs, and minimal privilege usage are essential.

Special types of drivers#

• Function (device) drivers: implement the logic for a specific device.
• Bus drivers: manage a bus (PCI, USB host controller, virtual bus) and detect child devices.
• Filter drivers: attach to an existing driver stack to observe, modify, or augment I/O. Filters can be upper or lower filters and are a common way to add functionality without rewriting the main driver.
• Miniport drivers: implement hardware-specific bits underneath a generic port/driver model (common in networking and storage).
• File system drivers: implement or extend filesystems and require careful interaction with OS internals.

Filter drivers deserve special mention: they intercept I/O requests between the OS and a device driver. They operate in a stack (driver A -> filter -> driver B), can inspect or modify requests, and are often used to bridge userland requirements and kernel operations.

Communication: IOCTLs, IRPs and their role#

• IRP (I/O Request Packet): kernel-internal structure that represents an I/O operation (read, write, device control). Kernel-mode drivers receive and handle IRPs.
• IOCTL (I/O control code): a device-specific control command sent from user space. The OS wraps the request into an IRP and delivers it to the driver.

Frameworks like KMDF/UMDF provide IO queues and helpers to simplify asynchronous/synchronous I/O handling, but the underlying concepts (IRP/IOCTL) remain central.

Introduction to WinDbg#

WinDbg is Microsoft’s debugger for both user-mode and kernel-mode applications. For driver developers, it is the tool of choice for inspecting what happens inside the kernel:

• It can attach to a virtual machine (or another computer) and step through kernel code, set breakpoints, and inspect memory.
• It integrates with Microsoft’s symbol servers to show function names and structures.
• It is invaluable for analyzing Blue Screen of Death (BSOD) crash dumps, which often result from driver bugs.
• Combined with a VM, WinDbg provides a safe loop: write driver, load in VM, trigger bug, inspect with WinDbg, fix, repeat.

If you want to dig into kernel internals, WinDbg is essential — it gives you visibility that no user-mode debugger can provide.