Driver triage: separating correlated heuristics from reachable behavior

A primitive does not explain its caller

Memory-mapping imports, MDL-related operations, and privileged instructions are useful leads during a driver review. They are also ordinary ingredients in legitimate kernel software.

Finding one does not establish where the input comes from, which callers can reach the operation, what authorization occurs, or how the result crosses a trust boundary. Even a plausible IOCTL constant needs to be tied to real code and dispatch semantics before it means much.

Raw instruction-byte matching introduced another problem: a byte pattern can occur without representing the instruction the scanner thinks it found. Giving a short pattern the same authority as decoded, reachable behavior amplified the noise.

The initial score compressed these uncertainties into a severity label. The report looked more certain than its evidence.

Correlated features can create artificial confidence

A simple additive score often treats each detected feature as another independent reason for concern. In driver binaries, that assumption is weak. An MDL allocation, a mapping operation, and related strings may all originate from the same legitimate memory-management path. Counting them independently can reward one ordinary subsystem three times.

The first useful distinction is between feature count and evidence diversity. Multiple observations from the same code path do not carry the same meaning as independent evidence of an exposed endpoint, controlled input, and a missing authorization check.

In probabilistic terms, multiplying feature likelihoods would require assumptions about conditional independence that this scanner had not established. The implementation did not have a calibrated probability model, and its numeric score should not be read as a probability of exploitation.

A more useful review model preserves the origin of each feature: which function or byte range supplied it, whether it came from disassembly or a raw pattern, and which larger behavior it may belong to. That allows correlated observations to be grouped instead of silently accumulating certainty.

This is a design direction for stronger triage, not a claim that the initial scanner already performed whole-program data-flow analysis.

Represent the unresolved edges of the trust boundary

For a memory-related finding, the analyst's reasoning generally has to connect several distinct questions:

These are not five interchangeable points in a score. A missing link changes the claim. If caller reachability is unresolved, the defensible output is a capability lead with unresolved reachability, even when the underlying memory operation is unambiguous.

Negative observations need similar care. Failure to access an endpoint under one token and configuration constrains that experiment. It does not demonstrate that no authorized or differently configured caller could reach it. The report needs enough context to preserve that distinction without exposing private host details.

Separate identity matches from heuristic leads

I revised the scoring so ordinary imports and raw opcode patterns could no longer drive a file into the highest category. Critical classification was reserved for exact matches against configured known SHA-256 rules; heuristic scores were capped below it.

An exact hash match still inherits the quality and meaning of its rule. It establishes that the scanned bytes match an entry, not that every machine containing those bytes is exploitable in its current configuration.

Heuristic findings serve a different purpose: deciding where an analyst should spend time next. Their reports need to preserve the individual reasons for selection so a reviewer can distinguish a suspicious path from a collection of normal capabilities.

Filenames were kept out of the role of reliable identity. A familiar name cannot establish either trust or vulnerability.

Signature verification needed its own baseline

The signature path also required calibration. Batch checks under Windows PowerShell 5.1 encountered a module and type-data loading conflict. The revised path used PowerShell 7 with explicit security-module support and recognized catalog signatures.

A standard Windows driver provided a useful control: null.sys was recognized as trusted and informational in the recorded check. That baseline tested a specific implementation problem in trust reporting. It did not make signing a substitute for security analysis.

When verification is unavailable, the report should retain that uncertainty. A failed verification mechanism must not silently become a claim that the file is unsigned or untrusted.

What the completed checks covered

The retained development record reports a Release build with zero warnings or errors and five passing tests. These covered command-line parsing, synthetic x64 PE parsing and IOCTL decoding, compound scoring, hash-rule normalization, and a real catalog-signature check.

The full inventory contained 1,019 unique driver files and recorded no analysis failures. After calibration, the scanner still produced many high-priority results. That left false-positive tuning as unfinished work rather than a solved problem.

The 342 / 1,019 figure is an alert proportion, not a measured false-positive rate. Calculating a false-positive rate would require a ground-truth set of negatives; measuring precision would require adjudicating the flagged findings. The development record established overaggressive rules and motivated calibration, but it did not provide a fully labeled benchmark from which to derive those metrics.

This also limits comparisons between scoring revisions. A lower alert count can reflect improved discrimination, or it can simply reflect a stricter threshold. Without adjudicated examples, fewer alerts do not establish higher accuracy.

For a later benchmark, byte-level deduplication would be necessary but insufficient. Closely related driver builds can share most of their implementation while having different hashes. If near-identical families appear in both tuning and evaluation sets, apparent generalization can be overstated. Separating families or provenance groups would make an evaluation more informative than randomly splitting individual files. That benchmark remains proposed work.

Successful parsing, passing tests, and clean execution show that a tool can process its inputs. They do not by themselves measure how well its ranking separates useful leads from noise.

The next meaningful improvement is a better-evaluated ranking: representative known-good drivers, explicitly labeled findings, and stronger connections between a capability and the path that exposes it. The scanner's job is to make that review easier, with enough evidence to disagree with its score.

Evidence note: based on the retained August 26–27 DriverRiskScanner development and calibration record. Inventory totals and test results are historical; no fresh host scan was performed for this article. This entry makes no new vulnerability claim about a third-party product.