The D L L, dynamic link library, lessons followed identity, loading, and A P I, application programming interface, resolution inside a process. The driver lessons then followed a request through the I/O manager, checked buffers, and device registers. We can now ask what authority those components actually carry. A game tool’s process handle grants limited access; a kernel driver can affect the whole machine. This lesson makes that trust boundary visible with a read-only inventory of the drivers Windows has loaded.
Section: Ring 3 and ring 0 in plain English.
The Windows kernel is the part of the operating system trusted to manage memory, devices, processes, and security boundaries. A normal game and the tools in this book run in user mode, often called ring 3. A kernel driver runs in kernel mode, often called ring 0.
The important model is which invariants a component can break. User-mode code runs with page-table and privilege checks that confine ordinary faults to its allowed address space and handles. Kernel-mode code participates in enforcing those checks; it can change mappings, device state, process state, and security decisions for the whole system.
In brief: Kernel code helps enforce system-wide memory and privilege checks, so its failures can reach beyond one game process.
A user-mode crash normally ends one process. A bad kernel pointer can crash the entire computer or corrupt data belonging to any process. Moving code into a driver therefore enlarges both its authority and the damage caused by a bug. “More privilege” is not the same as “better engineering.”
The boundary is useful because callers do not receive kernel authority merely for asking Windows to do something. The kernel checks the request, and a sound driver checks it again before touching device or privileged memory.
Section: Why a kernel bug takes the whole machine down.
When user-mode code follows a bad pointer, the kernel finds that nothing valid lives at that address and turns the page fault into an access-violation exception for that one process. The program’s own handler, a debugger, or Windows Error Reporting deals with it, and in the worst case one process ends. The kernel is the safety net under every user-mode program.
There is no separate part of Windows that can repair arbitrary damage to its own kernel state. A hypervisor may isolate a whole guest from the host, as Lesson 13.3 will show, but it cannot resume a guest kernel whose internal records are already corrupted. Kernel code does catch faults it expects, such as touching a user buffer that another thread may have freed; the copy behind ReadProcessMemory is written to catch exactly those. But a driver that follows a bad pointer by mistake can raise an unexpected fault inside the kernel, and kernel code and drivers share an address space and a set of data structures: the scheduler’s lists, the memory manager’s page records, and the locks that guard them. The fault may have struck halfway through updating one of those structures, with a lock still held. Windows cannot generally prove which of its own records remain sound, and carrying on could write corrupted data to disk. For an unrecoverable kernel failure, Windows stops on purpose.
That deliberate stop is a bug check, better known as the blue screen. Windows shows a stop code, such as hexadecimal 5 0 PAGE_FAULT_IN_NONPAGED_AREA or hexadecimal D 1 DRIVER_IRQL_NOT_LESS_OR_EQUAL, writes a crash dump of the whole machine if it can (Lesson 14.3 will capture a dump of one process), and restarts.
Inside a virtual machine, even a bug check stops only that virtual machine (Lesson 13.3), which is one more reason the book’s labs run inside one, in user mode.
Section: Why the course labs stay in user mode.
The old open-source games in this book do not need a driver. Their offline processes can be studied with documented Windows APIs, a debugger, a user-mode D L L, and reversible patches.
The course deliberately does not build:
arbitrary kernel or physical-memory read/write commands;
privilege-escalation paths;
security-product or anti-cheat bypasses;
hidden drivers, callbacks, threads, or processes;
loaders for vulnerable or untrusted drivers.
Those capabilities would expand the problem from studying one game process into controlling the operating system and concealing that control.
Microsoft’s own driver security guidance begins with the same design question: confirm that a kernel driver is actually required. If a service or application can do the job, it is the lower-risk boundary.
Section: Why Windows insists on signed drivers.
Loading a driver puts new code into ring 0, so Windows checks where a driver came from before loading it. 64-bit Windows refuses kernel-mode code without a valid digital signature, the kind of signature Lesson 10.8 checked on game files. Since Windows 10 version 1607, on a PC with Secure Boot on, a new driver must be signed by Microsoft itself, through its hardware developer program, which requires the publisher to prove its identity with an extended-validation certificate. Secure Boot is the firmware check that allows only signed boot components to start, which also keeps these signature checks from being relaxed before Windows is running. Developers’ test-signing modes relax them on purpose, so they belong only on a disposable test machine, and this book never uses them.
A signature answers two questions: who published this driver, and has it changed since? It does not say whether the code is safe, as the next section shows. Attackers look for old, legitimately signed drivers with an exploitable bug and load one to borrow it. Microsoft’s answer is the vulnerable driver blocklist: a list of signed drivers known to be exploitable, which Windows refuses to load. Since the Windows 11 2022 update the blocklist is on by default, and it is always enforced when memory integrity is on.
Section: The defensive problem: trusted code can still be vulnerable.
A signed driver is not automatically a safe driver. If it exposes a badly protected command that can read or write arbitrary privileged memory, another program may abuse that power.
Narration: A valid signature identifies approval of a driver’s bytes; it cannot prove that every command the driver exposes checks permissions correctly.
Defenders should treat driver loading as a rare, high-impact event:
Do not “test” a suspicious driver by loading it on your daily computer. Use an isolated disposable virtual machine and vendor-provided analysis guidance.
Section: Why a cheat driver endangers its own user.
Some cheats for online games ship as drivers, on the theory that ring 0 sees everything. Whatever such a driver does to a game, here is what it does to the machine running it:
It runs with the kernel’s full authority and comes from an anonymous author. Its bugs become bug checks and corrupted files on the user’s own computer, with no vendor, testing, or update process behind it.
It often comes with instructions to switch protections off, such as Secure Boot, memory integrity, the vulnerable driver blocklist, or signature checks. Each of those protects the machine against all kernel malware, not only against cheats, and turning one off lowers the defense for everything.
Many rely on an old signed driver with a known bug to reach ring 0. The bug cannot tell who is asking: while that driver is loaded, any other program on the machine can send the same control code and read or write kernel memory.
A kernel driver is the most powerful place malware can live. Installing one from an anonymous seller hands that seller the whole computer: saved passwords, browser sessions, banking, and the power to hide further software.
Anti-cheat systems look for exactly these drivers, and the penalties usually apply to the whole account, sometimes to the hardware.
Section: Build a read-only driver inventory.
The inventory calls EnumDeviceDrivers and GetDeviceDriverBaseNameW through the windows crate. It queries visible driver images, prints their base names, and uses no mutation APIs.
enumerate does not know the driver count in advance, so it grows its buffer and asks again until Windows reports the whole list fit:
Additional detail: Complete defensive lab source: driver_inventory.rs.
Code example. The code’s comments explain: SAFETY: the vector owns byte_capacity writable bytes and the output count lives until the Windows call returns. SAFETY: the address came from Windows and the UTF-16 buffer is writable.
Build and run it from a normal terminal:
Terminal window
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
The program does not enable debug privileges. On a hardened or newer Windows installation, the account may see fewer details. Treat that as the security boundary working; do not weaken the machine to make the list longer.
Section: Turn an inventory into a baseline.
One list is only a snapshot. A useful defensive baseline also records:
Alternative: An inventory is a photograph; a baseline adds labels and comparisons that explain which driver changed and where it came from.
Windows build and capture time;
driver file name, version, publisher, and signature result;
cryptographic hash;
why the driver is installed;
the approved update source.
Compare snapshots after installing a game, hardware utility, or anti-cheat component. A new driver is not automatically malicious, but it deserves a reason and a trustworthy origin.
Section: Windows protections worth keeping on.
Memory integrity, also called HVCI, uses virtualization-based security to enforce kernel code-integrity rules. The Microsoft vulnerable-driver blocklist prevents known risky drivers from loading when the relevant Windows protections or application-control policy enforce it.
For a normal learning machine:
keep Windows and driver updates current;
leave Secure Boot and memory integrity enabled when the hardware supports them;
use the Microsoft vulnerable-driver blocklist or an approved application-control policy;
remove abandoned hardware utilities and drivers you no longer need;
download drivers through Windows Update or the hardware vendor;
do not turn off protections merely to run an experiment.
If an old driver conflicts with memory integrity, first look for a supported update or remove the dependent software. Compatibility trouble is not a reason to leave the protection disabled.
Section: Detect driver changes.
Sysmon’s Driver Load event, Event ID 6, can record a loaded driver’s hash and signature information. On a managed lab machine, alert on:
an unknown or unexpected publisher;
an invalid or missing signature;
a hash not present in the approved baseline;
a driver introduced outside the normal update process;
a driver name associated with a block policy or security advisory.
Detection is not “spot one weird filename and delete it.” Confirm the file, service, signature, source, and owning software before taking action.
Section: If you genuinely need to develop a driver.
Use Microsoft’s Windows Driver Frameworks, a disposable test V M, virtual machine,, Driver Verifier, strict device access control, narrow IOCTLs, checked buffer lengths, least privilege, peer review, and the proper test-signing and release-signing workflows. Never expose arbitrary kernel, physical, or device memory to a user-mode caller.
The full read-only inventory is driver_inventory.rs.
References: Microsoft driver security checklist, recommended vulnerable-driver block rules, HVCI compatibility, and Sysmon Driver Load events.