Testing a Windows driver without its source

A signed Windows driver can expose dangerous operations through an ordinary device-control interface. The signature establishes who signed the binary. It doesn’t establish that every operation checks its caller correctly.

We used already known driver vulnerabilities to test a narrower research question: could our pipeline locate a suspicious operation in a stripped binary and verify its behavior in an instrumented Windows VM?

The result was a validation of the analysis workflow, not a claim of new vulnerabilities.

Find the device-control path

A driver receives I/O control requests through a dispatch handler. That handler interprets command codes and input buffers, then calls the implementation for the selected operation.

Even when descriptive function names are gone, useful structure remains. The code that installs a dispatch handler writes a function pointer into a known driver structure. Imported kernel functions can also retain names required by the loader.

Those signals let the analysis work from two ends: the request handler and a potentially dangerous operation such as physical-memory mapping. The task is to recover the path between them and determine where its arguments originate.

A call to MmMapIoSpace is not enough to call something a vulnerability. Mapping a fixed hardware region can be legitimate driver behavior. Whether the caller controls the address, which process can open the device, and what the driver returns all affect the security conclusion.

Observe the operation

The confirmation environment loaded the target driver in a Windows VM with a kernel debugger attached.

For the selected request, the test inspected whether the mapping operation ran, whether its operands matched the values supplied to the request, and whether data returned to user space corresponded to the mapped memory. Negative controls checked how the path behaved with different inputs.

These observations tie a report to an executable path. They are stronger than a decompiler showing a dangerous import.

They also have a limited meaning. A demonstrated memory-access primitive isn’t automatically a working privilege-escalation exploit. An exploit still needs the relevant access conditions, a usable target, and a complete chain under the system’s mitigations.

Keep the threat model attached

Bring-your-own-vulnerable-driver attacks often involve an attacker arranging for a vulnerable driver to be loaded. Loading it and opening its device are distinct access questions.

A report should state both. It should not describe a result obtained with a privileged setup step as though any unprivileged user could reach it on an ordinary installation.

The binary itself also doesn’t establish that no one has fuzzed the driver. Binary instrumentation, emulation, and hardware-assisted approaches can test software without source. Our workflow addresses one way to investigate that surface.

A known bug is still a useful control

The pipeline rediscovered published vulnerabilities during these tests. One run initially labelled a result new because the file’s hash was absent from a catalogue. That was an error, described in our novelty-check case study.

Known vulnerable drivers provide positive controls for the investigation process. Benign uses of the same kernel functions provide negative controls. Both are necessary: a system that recognizes a dangerous import but cannot distinguish its safe uses will produce convincing false positives.

The useful output is a record of the request, access conditions, observed operands, returned behavior, and limitations. That record lets another researcher assess what the test actually established.