Somewhere around driver number four hundred, I stopped pretending this was a weekend project. What started as curiosity about a single signed kernel driver had turned into an automated pipeline, roughly four hundred Ghidra project directories, and a question I could not let go of. Is there a signed Windows driver out there that hands kernel memory access to any user on the machine? No admin needed to load it. No access control on the device object. Just open a handle and start reading physical RAM.
This is my hunt for the golden driver.
Why golden
Most BYOVD research assumes you already have administrator access. You need admin to call NtLoadDriver or sc create, and once you have admin you are already past most security boundaries. The driver is a means to an end: you load it to disable EDR, patch kernel callbacks, or get a read/write primitive into physical memory. The blocklists are growing and the cat-and-mouse continues, but the game is fundamentally post-exploitation.
What if you did not need admin at all?
A golden driver would already be installed on the target, or installable without elevation. Its device object would have no DACL, or one that grants access to Everyone or Authenticated Users. And it would expose primitives worth having: physical memory access, MSR reads, PCI config space. A signed binary that converts "logged-in user" into "kernel-level access" with nothing in between.
That is the question I spent the better part of a season trying to answer.
The pipeline
I built an automated analysis pipeline called DVF, for Driver Vulnerability Factory. It ingests signed Windows kernel drivers, checks them against the HVCI blocklist and LOLDrivers, then runs them through a multi-stage analysis that includes import resolution, Ghidra decompilation, and primitive scoring across eight categories and over thirty primitive types.
The categories cover the things that matter: physical memory read/write via MmMapIoSpace or ZwMapViewOfSection, MSR access through rdmsr/wrmsr, PCI configuration space manipulation, IO port access, unsigned kernel code loading, process manipulation, kernel-mode registry access, and DMA-capable memory allocation with known physical addresses.
I fed it 807 unique driver binaries sourced from Windows Update Catalog searches, over fifty packages extracted via winget (hardware monitoring tools, GPU utilities, gaming peripherals, system management software), and manual extraction from vendor installers. Of those 807, the pipeline discarded 745 immediately. They matched the HVCI blocklist or were already documented in LOLDrivers. Known quantities.
Of the remaining 62, 57 received full automated analysis with scoring and report generation. Fourteen got the real treatment: manual reverse engineering, proof-of-concept code, and live VM testing. Sixty-eight automated reports were generated. About 27 gigabytes of intermediate files got cleaned up when I was done.
The gap between scoring and reality
Here is the thing about automated analysis. It lies to you constantly. Not maliciously. Optimistically.
The pipeline scores drivers by import reachability. If a driver imports MmMapIoSpace and that import is reachable from an IOCTL dispatch path, the driver scores points for physical memory mapping. Sounds reasonable. The problem is that reachability tells you nothing about whether the parameters are user-controlled.
One driver scored as having arbitrary MSR read/write and arbitrary physical memory access. On paper, it looked perfect. I spent two full days in Ghidra proving that every single MSR call used hardcoded register indices. The physical addresses came from PCI BAR values plus fixed offsets, never from user-supplied input buffers. Every claimed primitive was a false positive. The imports were there. The code paths were there. The user control was not.
This was not an isolated case. It was the pattern. The distance between "this driver calls MmMapIoSpace" and "this driver lets you map any physical address you want" is often the entire reverse engineering effort.
The many ways drivers disappoint you
Even when a driver genuinely exposes dangerous primitives, there are a dozen ways it can still fail to be useful.
DACL hardening was the sneakiest problem. I found one driver family where the IOCTL table was identical across versions. Same primitives, same handler code. But newer versions silently added device-level access control in DriverEntry, restricting the device handle to specific callers. This hardening is invisible in static analysis because it is set through IoCreateDeviceSecure or explicit security descriptor manipulation during initialization, not through imports the pipeline would flag. The only way to find it is to load the driver and try to open the device. One older version of this same driver had no DACL at all. The difference between "golden" and "useless" was a version number.
Hardware dependencies killed several promising candidates. Two WHQL-signed drivers from a gaming peripheral vendor both had permissive access control, one with an Everyone SDDL. But one failed to load due to a KMDF version mismatch on my test system, and the other required specific vendor hardware to be physically plugged in. PnP-gated.
One driver's physical memory unmap IOCTL was simply broken. Both the physical-address-based and kernel-virtual-address-based unmap approaches failed. The driver allocated mapping slots from a fixed-size table, and once all 32 slots were consumed, no more memory could be mapped. Ever. Not until reboot.
Cache attribute conflicts caused blue screens. A driver calling MmMapIoSpace with MmNonCached on a RAM range that is already mapped write-back by the OS causes a fatal conflict on some platforms.
Then there were the ecosystem-dependent drivers. They created devices, accepted IOCTLs, but returned STATUS_INVALID_DEVICE_REQUEST for everything because the full vendor software stack was not running. The device was a shell without its controller.
And acquisition was its own grind. Vendor installers that turned out to be web stubs with no offline package. Nested archive formats requiring four layers of extraction. Drivers that could not be separated from their installer at all.
What survived
After all the false positives, dead ends, and broken primitives, genuine findings emerged. Thirty-three of the forty-three drivers I reported were not previously documented in either LOLDrivers or the HVCI blocklist.
The findings fell into patterns.
Three different consumer software vendors had independently forked the same open-source kernel driver. All three shipped the original authentication protocol unchanged, using a hardcoded static string as the credential. All three provide unsigned kernel code loading and physical memory allocation. All three are signed, one with WHQL certification. None appear in any blocklist. I wrote about these separately in a post called "The magic word" because the story deserved its own telling.
Hardware monitoring software was a reliable source of dangerous primitives. These drivers need kernel access for CPU temperatures and voltage readings, but several expose far more than sensors. One provides forty-five IOCTLs including unrestricted MSR read/write, physical memory mapping, PCI config access, IO port manipulation, SMI triggers, and BIOS ROM reads. It scored 1,462 in the pipeline, the highest of any driver I tested.
One WHQL-signed driver embeds an entire scripting virtual machine. It exposes physical memory mapping, MSR access, IO ports, and PCI configuration, but gates everything behind RSA-signed script modules. The catch is that officially signed modules are publicly available in a GitHub repository. Kernel code execution was confirmed using those publicly available modules.
A laptop vendor's system management driver validates callers by checking if the calling process's executable path starts with a directory read from a registry key. No cryptographic verification. Just string prefix matching. Set a registry key, name your binary appropriately, and the driver hands you MSR reads (including IA32_LSTAR) and physical memory access. This driver appears in LOLDrivers, but only for its process termination IOCTL. The far more dangerous MSR and physical memory primitives are completely undocumented.
The strangest find was a device proxy driver that opens any kernel device object via kernel-mode ZwOpenFile, then forwards IOCTLs from usermode to the target. It bypasses usermode access checks entirely. In theory, this is a force multiplier that turns any DACL-protected driver into an unprotected one. In practice, it blue-screens with most non-HID targets. Interesting idea, limited utility.
The answer
So, do golden drivers exist?
Yes.
One hardware monitoring driver variant has no device ACL at all. Any user on the machine can open a handle to it. It provides confirmed physical memory read and physical memory write at arbitrary addresses with no range checking. It is signed by a trusted certificate authority. It is not in the HVCI blocklist. It is not in LOLDrivers, despite forty-two other hash variants from the same driver family being blocked. The specific variant with the most permissive access and the best primitives just happens to be the one that slipped through.
I built a cross-process memory scanner using this driver to prove the primitive worked end-to-end. It made 530,000 IOCTL calls to walk two gigabytes of physical RAM, finding process structures by signature matching and reading another process's PE header directly from physical memory. No process handle. No OpenProcess. No access check of any kind. Physical write works the same way.
A second driver from a different vendor provides an unrestricted 16-byte arbitrary physical write at any address. No range validation. Five hash variants exist, four of which appear in no blocklist.
These are not theoretical. They are signed, shipping, and installable without elevation on consumer Windows systems.
One thing caught me off guard during the physical memory scanning work. While searching for the CR3 register value by looking for self-referencing PML4 entries, the scan found exactly one match. It was the KVAS shadow page table, the Meltdown mitigation copy that deliberately excludes kernel address space mappings. A security mitigation designed for an entirely different class of vulnerability accidentally interfered with a BYOVD technique. I found that genuinely funny.
Blocklist gaps
The research kept bumping into coverage holes. One driver family has forty-two hashes in the HVCI blocklist, but the variant with the most permissive access control is missing. LOLDrivers documents one driver for its process-kill capability while the same binary's physical memory and MSR primitives go unrecorded.
Blocklists are growing, but they grow by hash, and one missed build is all it takes.
I also hit a substring false positive in my own blocklist checking. One driver's name matched inside an unrelated driver's longer name in the HVCI blocklist because the shorter name appeared as a substring at position 1. That took longer to debug than I would like to admit.
By the numbers
The full pipeline processed 807 drivers. 745 were already known. 57 were fully scored. 14 were deeply reversed. 33 of the 43 I reported were new. The golden driver question has an answer, and I have a backlog of vendor disclosures to work through. The pipeline code needs cleanup before I would inflict it on anyone else, but the methodology works and I have a healthy distrust of any automated score that does not come with a Ghidra project to back it up.