The Windows IOCTL Census: A Corpus-Scale, Multi-Architecture Database of the Driver Control-Code Surface

Technical Summary: The Windows IOCTL Census

Problem Statement
The device-control path in Windows represents a critical attack surface where unprivileged processes can reach kernel memory via I/O control (IOCTL) codes. Vulnerabilities in this path, such as unchecked buffer lengths, allow for privilege escalation. While the security community possesses scanners (e.g., ScrewedDrivers, POPKORN, ioctlance) that symbolically execute drivers to find specific vulnerabilities, and curated lists (e.g., LOLDrivers) that track known-bad drivers, there is no systematic, persistent map of the control-code dispatch surface across the entire driver ecosystem. Existing symbolic tools suffer from path explosion, high false-negative rates, and architectural limitations; notably, they often fail on 32-bit (x86) drivers, which constitute roughly half of the shipping driver corpus and are frequently exploited in "Bring Your Own Vulnerable Driver" (BYOVD) attacks. Furthermore, these tools typically emit one-shot finding lists and discard the recovered structural data, preventing cross-driver analysis or re-evaluation.

Methodology
The authors propose a deterministic, architecture-neutral pipeline called the Windows IOCTL Census, which processes a corpus of 27,087 signed Windows drivers through three stages: Recover, Enrich, and Rank.

1. Recover (Deterministic Pass):

   • Architecture: This stage avoids symbolic execution entirely. Instead, it lifts driver binaries into an architecture-neutral intermediate representation (IR) using the glaurung framework.
   • Dispatch Recovery: It identifies the IRP_MJ_DEVICE_CONTROL handler and decodes control codes by analyzing comparison constants and jump tables. This approach successfully recovers dispatch surfaces for both x64 and x86 architectures.
   • Structural Analysis: For x64 drivers, the pipeline constructs inter-procedural call graphs, performs reachability analysis from dispatch routines, and executes a lightweight taint analysis. The taint source is the buffered input pointer (Irp->AssociatedIrp.SystemBuffer), tracking it to sinks (dereferences or stores) to identify unsanitized controlled inputs.
   • Provenance: It extracts PE metadata, Authenticode signing info, and device security descriptors (SDDL) to flag drivers with permissive access control lists (ACLs).
   • Constraints: The analysis is bounded by driver size (skipping full disassembly for drivers >4MB) and architecture (x86 receives surface-only analysis without deep taint/call graph due to lack of independent validation oracles).

2. Enrich (Model Pass):

   • Targeting: This stage runs only on a narrow, high-priority subset: dispatch routines in drivers with permissive device descriptors that contain at least one unsanitized buffered-input sink.
   • LLM Integration: A Large Language Model (LLM) is prompted with a compact feature summary (device descriptor, decoded codes, taint sink details, and a disassembly excerpt) to generate a structured verdict. The verdict includes risk levels, primitive types (e.g., out-of-bounds write), and rationale. The model is explicitly instructed not to see raw decompiled bytes to avoid hallucinations, relying instead on the deterministic facts.

3. Rank (Query Interface):

   • The system exposes the data through relational views. Key views include a "hunt" view ranking user-reachable handlers by unsanitized sink count, a "cross-driver" view grouping shared control codes across vendors, and an "oracle-agreement" view comparing static taint results against ingested symbolic execution results.

Key Contributions

• A Public, Queryable Database: The authors release a dataset containing 27,087 binaries, 3.1 million decoded control codes, 8.18 million functions, and 15.95 million call edges.
• Architecture-Neutral Coverage: By using IR lifting rather than symbolic execution, the tool recovers dispatch surfaces for 80% of the corpus (21,708 drivers), including the 32-bit x86 half that symbolic scanners typically abort on.
• Structural Persistence: Unlike previous tools that discard structure after finding bugs, this census persists the call graph, taint sinks, and decoded codes, enabling queries such as "which drivers share this specific control code?" or "which handlers reach a copy sink without a length check?"
• Hybrid Validation: The system integrates static taint analysis with symbolic execution results (via ioctlance) to cross-validate findings, demonstrating that the two methods have complementary blind spots (e.g., static taint misses METHOD_NEITHER codes, while symbolic execution struggles with path explosion).

Results

• Coverage: The deterministic pass recovered a dispatch surface for 21,708 drivers (80.1% of the corpus). The x64 deep lane yielded 8.18 million functions and 63,263 buffered-input taint sinks.
• Filtering Efficiency: The deterministic filters (permissive descriptor + unsanitized sink) narrowed the 27,087 drivers down to 330 candidate handlers for LLM enrichment.
• Model Performance: The LLM rated 135 of the 329 enriched handlers as "critical" and 159 as "high." The authors emphasize these are prioritization hypotheses, not confirmed bugs, with no reported true-positive rate.
• Cross-Method Agreement: In a comparison with ioctlance on a 1,000-driver sample, the two methods agreed on 65% of the drivers flagged by the symbolic engine. The disagreement was largely attributed to the symbolic engine's inability to reach certain handlers (reachability ceiling) rather than precision errors.
• Backtesting: A backtest against known CVEs and the LOLDrivers catalog showed that the ranking is effective within its scope (e.g., a known vulnerable handler in nvlddmkm.sys ranked in the top 0.14%). However, the system missed vulnerabilities in framework drivers (WDF/KMDF) where input is retrieved via different mechanisms not covered by the buffered-input taint source.

Significance and Claims
The paper claims significance not as a vulnerability detector that proves the existence of new bugs, but as a foundational map of the Windows driver control-code surface.

• Shift from Detection to Navigation: The authors argue that the community needs a persistent, queryable record of the attack surface to prioritize scarce reverse-engineering resources. The census allows researchers to navigate the "long tail" of shipping drivers rather than relying on luck or hand-picked targets.
• Democratizing Access: By releasing the structural data (decoding, call graphs, reachability) while withholding the specific targeting tier (taint sinks and model verdicts) to prevent dual-use exploitation, the authors aim to lower the barrier to entry for analyzing driver security.
• Complementarity: The work demonstrates that deterministic recovery and symbolic execution are complementary; the census provides the structural context that allows these methods to check each other and cover blind spots.
• Future Work: The authors acknowledge limitations, including the lack of taint analysis for x86 and arm64, the exclusion of METHOD_NEITHER and direct-I/O paths, and the inability to handle runtime-applied device descriptors. They frame the census as a living infrastructure that can be extended with new analyzers (e.g., for framework drivers or physical memory primitives) without rebuilding the core.