pith. sign in

arxiv: 2606.07732 · v1 · pith:AQLVUUPRnew · submitted 2026-06-05 · 💻 cs.SE

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

Michael J. Bommarito II This is my paper

Pith reviewed 2026-06-27 21:10 UTC · model grok-4.3

classification 💻 cs.SE
keywords windows driversioctlcontrol codesdatabasecorpusstatic analysisdispatch tableskernel security
0
0 comments X

The pith

A queryable database recovers the IOCTL dispatch surfaces of 27,087 signed Windows drivers using a deterministic pass.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper builds a public database that maps the control-code dispatch surfaces across a corpus of 27,087 signed Windows drivers. It achieves this coverage through one deterministic, architecture-neutral analysis pass over a lifted intermediate representation rather than symbolic execution. The method processes both x86 and x64 binaries and succeeds on 80 percent of the drivers, including the 32-bit cases that prior scanners skip. The released dataset contains 3.1 million decoded control codes along with millions of functions and call edges, plus reachability, taint, and call-graph data on the 64-bit subset. An LLM then ranks reachable handlers to support triage of the kernel attack surface.

Core claim

The Windows IOCTL Census is a queryable database of the control-code dispatch surface of 27,087 signed Windows drivers, recovered by one deterministic, architecture-neutral pass with no symbolic execution. Reading a lifted intermediate representation instead of running a symbolic engine lets it recover a dispatch surface for 80% of the corpus across x86 and x64, including the 32-bit half existing scanners abort on. On the 64-bit lane it adds handler reachability, taint, and the call graph. An LLM ranks the reachable handlers for triage. We release the census as a public dataset of tens of millions of rows: 27,087 binaries, 3.1M decoded control codes, 8.18M functions, and 15.95M call edges.

What carries the argument

The deterministic architecture-neutral analysis pass over the lifted intermediate representation that extracts dispatch tables and control-code logic from driver binaries.

If this is right

  • The database enables queries over 3.1 million decoded control codes and 15.95 million call edges.
  • Analysis now covers both 32-bit and 64-bit drivers in the same corpus where prior tools handled only one architecture.
  • Reachability, taint, and call-graph data become available for the 64-bit drivers.
  • An LLM-based ranking step produces a triage list of reachable handlers.
  • The full dataset is released for public use with tens of millions of rows.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Security researchers could use the census to prioritize scanning of drivers that expose many reachable handlers.
  • The recovery method might be extended to track additional properties such as buffer-length checks on the same IR.
  • Similar corpus-scale extraction could be applied to other kernel interfaces that use dispatch tables.
  • Periodic re-runs of the census on new driver releases would track changes in the exposed surface over time.

Load-bearing premise

The lifted intermediate representation accurately captures the dispatch tables and control-code logic for the 80% of drivers that succeed, without architecture-specific decoding errors or missed handlers.

What would settle it

A manual or dynamic check on a random sample of drivers that finds the extracted control codes or handler addresses differ from actual runtime dispatch behavior in more than a small fraction of cases.

Figures

Figures reproduced from arXiv: 2606.07732 by Michael J. Bommarito II.

Figure 1
Figure 1. Figure 1: The Recover-Enrich-Rank pipeline. Recover extracts dispatch, decoded codes, handler reachability, controlled-input taint, the call graph, and provenance from a driver binary. Enrich attaches a feature-grounded model verdict to the user-reachable handlers. Rank serves views over the unaudited surface. Only a compact feature summary of a reachable handler reaches the model, never decompiled bytes. Update Cat… view at source ↗
Figure 2
Figure 2. Figure 2: The deterministic filter, not the model, does the narrowing. From the 27,087-driver [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Control-code-surface coverage of the corpus. One architecture-neutral pass recovers a [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Decoded control codes per driver, over the surface-recovered drivers that carry at least one [PITH_FULL_IMAGE:figures/full_fig_p010_4.png] view at source ↗
read the original abstract

A Windows driver exposes its kernel through I/O control (IOCTL) codes, and a single unchecked length on the buffer behind one turns an unprivileged call into a kernel write. The research community has strong scanners for this surface and a curated list of known-bad drivers, but no map of the surface itself. We build that map. The Windows IOCTL Census is a queryable database of the control-code dispatch surface of 27,087 signed Windows drivers, recovered by one deterministic, architecture-neutral pass with no symbolic execution. Reading a lifted intermediate representation instead of running a symbolic engine lets it recover a dispatch surface for 80% of the corpus across x86 and x64, including the 32-bit half existing scanners abort on. On the 64-bit lane it adds handler reachability, taint, and the call graph. An LLM ranks the reachable handlers for triage. We release the census as a public dataset of tens of millions of rows: 27,087 binaries, 3.1M decoded control codes, 8.18M functions, and 15.95M call edges.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The paper presents the Windows IOCTL Census, a queryable public database of the control-code dispatch surfaces recovered from 27,087 signed Windows drivers. Recovery is performed via a single deterministic, architecture-neutral lift to an intermediate representation (no symbolic execution), achieving 80% coverage across x86 and x64 (including 32-bit drivers). The release contains 3.1M decoded control codes, 8.18M functions, and 15.95M call edges; 64-bit analysis additionally includes handler reachability, taint tracking, and call graphs, with an LLM used to rank reachable handlers for triage.

Significance. If the IR-based recovery is reliable, the work supplies the first corpus-scale map of the Windows driver IOCTL surface, directly addressing a gap between existing scanners and the need for a comprehensive view of potential kernel-attack surfaces. The deterministic single-pass design, explicit multi-architecture support, and public release of tens of millions of rows constitute clear strengths that enable downstream security research without requiring symbolic execution or architecture-specific tooling.

major comments (1)
  1. [Abstract] Abstract: the central claim that the lifted IR recovers dispatch surfaces for 80% of the corpus rests on the unvalidated assumption that the IR accurately captures dispatch tables and control-code logic; no ground-truth comparison, false-positive rate, or manual validation set is referenced, which is load-bearing for any assertion of recovery accuracy.
minor comments (2)
  1. The abstract reports aggregate counts (3.1M control codes, 8.18M functions, 15.95M edges) but does not break down success rates or failure modes by architecture or driver size; adding a small table or paragraph with these statistics would improve interpretability of the 80% figure.
  2. The description of the LLM-based ranking step is brief; clarifying the prompt template, model used, and how rankings are stored in the released dataset would aid reproducibility.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for highlighting the need for explicit validation of the IR recovery accuracy. We address this point directly below and will revise the manuscript accordingly.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the central claim that the lifted IR recovers dispatch surfaces for 80% of the corpus rests on the unvalidated assumption that the IR accurately captures dispatch tables and control-code logic; no ground-truth comparison, false-positive rate, or manual validation set is referenced, which is load-bearing for any assertion of recovery accuracy.

    Authors: We agree that the abstract (and current manuscript) does not reference a ground-truth comparison or manual validation set, making the 80% figure an unvalidated claim as stated. The 80% metric is computed as the share of binaries in which the deterministic IR lift located a dispatch table structure and extracted at least one control code; it does not yet include precision/recall against decompiled ground truth. We will add a new validation section that reports: (1) manual review of a stratified sample of 200 drivers (100 x86, 100 x64) with source or PDBs where available, (2) estimated false-positive rate from cross-checking decoded codes against reachable handler logic, and (3) a small false-negative probe on known drivers. This revision will be incorporated without altering the core single-pass methodology. revision: yes

Circularity Check

0 steps flagged

No significant circularity; data collection and IR-lifting effort

full rationale

The paper presents a deterministic, architecture-neutral lifting pass over 27k signed drivers to recover dispatch surfaces and build a public database. No equations, fitted parameters, predictions, or derivations appear in the abstract or described method. The 80% recovery claim is an empirical outcome of the single-pass process rather than a reduction to prior fitted values or self-citations. The work is self-contained as corpus construction; accuracy questions are external and do not create internal circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The work rests on the domain assumption that binary lifting produces faithful control-flow and dispatch information; no free parameters or new postulated entities are introduced in the abstract.

axioms (1)
  • domain assumption The lifted intermediate representation faithfully represents the control flow and dispatch logic of the drivers.
    The deterministic recovery method depends on this assumption to extract control codes without symbolic execution or runtime.

pith-pipeline@v0.9.1-grok · 5728 in / 1140 out tokens · 19346 ms · 2026-06-27T21:10:31.810911+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. The Linux IOCTL Census: A Source-Derived Database of the Linux Kernel Control-Code Surface

    cs.CR 2026-06 conditional novelty 7.0

    Presents the Linux IOCTL Census, a source-derived database of 586 dispatch points, 1289 command codes, 3583 input sinks and 1298 permission gates extracted from the kernel, with capability-ungated surface separated an...

Reference graph

Works this paper leans on

20 extracted references · 2 canonical work pages · cited by 1 Pith paper

  1. [1]

    Rajamani, and Abdullah Ustuner

    Thomas Ball, Ella Bounimova, Byron Cook, Vladimir Levin, Jakob Lichtenberg, Con McGarvey, Bohus Ondrusek, Sriram K. Rajamani, and Abdullah Ustuner. Thorough static analysis of device drivers. InProceedings of the 1st ACM SIGOPS/EuroSys European Conference 13 on Computer Systems (EuroSys), pages 73–85, 2006. Static Driver Verifier (SDV).https: //doi.org/10...

    work page doi:10.1145/1217935.1217943 2006

  2. [2]

    Bommarito II

    Michael J. Bommarito II. glaurung: A permissive, modern binary-analysis toolkit with a Rust/Python core and first-class agentic integration, 2026.https://github.com/mjbommar/gl aurung

    2026

  3. [3]

    Bommarito II

    Michael J. Bommarito II. IOCTLance: Refactored fork, 2026. Refactor of the original IOCTLance with a parallel batch runner and time and space bounds for the out-of-memory and pathological-runtime cases whole-driver symbolic execution hits at corpus scale.https: //github.com/mjbommar/ioctlance

    2026

  4. [4]

    Bommarito II

    Michael J. Bommarito II. The linux IOCTL census: A source-derived database of the kernel control-code surface, 2026. Companion source-derived census of the Linux ioctl control-code surface on the shared schema. Preprint

    2026

  5. [5]

    Bommarito II

    Michael J. Bommarito II. Needles at scale: LLM-assisted target selection for Windows vulnera- bility research, 2026. Preprint (forthcoming)

    2026

  6. [6]

    Bommarito II

    Michael J. Bommarito II. The windows IOCTL census (structural tier). Hugging Face dataset, 2026.https://huggingface.co/datasets/mjbommar/ioctl-census

    2026

  7. [7]

    DIFUZE: Interface aware fuzzing for kernel drivers

    Jake Corina, Aravind Machiry, Christopher Salls, Yan Shoshitaishvili, Shuang Hao, Christopher Kruegel, and Giovanni Vigna. DIFUZE: Interface aware fuzzing for kernel drivers. InProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 2123–2138, 2017.https://doi.org/10.1145/3133956.3134069

    work page doi:10.1145/3133956.3134069 2017

  8. [8]

    IRPMon: A tool for monitoring requests sent to windows drivers, 2015.https: //github.com/MartinDrab/IRPMon

    Martin Drab. IRPMon: A tool for monitoring requests sent to windows drivers, 2015.https: //github.com/MartinDrab/IRPMon

    2015

  9. [9]

    Sift or get off the PoC: Applying information retrieval to vulnerability research with SiftRank, 2025.https://arxiv.org/abs/2512.06155

    Caleb Gross. Sift or get off the PoC: Applying information retrieval to vulnerability research with SiftRank, 2025.https://arxiv.org/abs/2512.06155

    arXiv 2025

  10. [10]

    POPKORN: Popping Windows kernel drivers at scale

    Rajat Gupta, Lukas Patrick Dresel, Noah Spahn, Giovanni Vigna, Christopher Kruegel, and Taesoo Kim. POPKORN: Popping Windows kernel drivers at scale. InProceedings of the 38th Annual Computer Security Applications Conference (ACSAC), 2022. https://sites.cs.ucsb. edu/~chris/research/doc/acsac22_popkorn.pdf

    2022

  11. [11]

    Hunting vulnerable kernel drivers, 2023

    Takahiro Haruyama. Hunting vulnerable kernel drivers, 2023. VMware Threat Analysis Unit. https://blogs.vmware.com/security/2023/10/hunting-vulnerable-kernel-drivers.h tml

    2023

  12. [12]

    VulBinLLM: LLM-powered vulnerability detection for stripped binaries, 2025.https://arxiv.org/abs/2505.22010

    Nasir Hussain et al. VulBinLLM: LLM-powered vulnerability detection for stripped binaries, 2025.https://arxiv.org/abs/2505.22010

    arXiv 2025

  13. [13]

    IOCTLance: Enhanced vulnerability hunting in Windows driver model drivers with symbolic execution and taint analysis, 2023

    Zeze Lin. IOCTLance: Enhanced vulnerability hunting in Windows driver model drivers with symbolic execution and taint analysis, 2023. CODE BLUE 2023.https://github.com/zeze-z eze/ioctlance

    2023

  14. [14]

    Efficacy of large language models in detecting vulnerabilities in Windows kernel-mode drivers, 2025

    Matthias Loong. Efficacy of large language models in detecting vulnerabilities in Windows kernel-mode drivers, 2025. CSIT tech blog.https://medium.com/csit-tech-blog/effica cy-of-large-language-models-llms-in-detecting-vulnerabilities-in-windows-kerne l-mode-ff468c498c63. 14

    2025

  15. [15]

    Aravind Machiry, Chad Spensky, Jake Corina, Nick Stephens, Christopher Kruegel, and Giovanni Vigna. DR. CHECKER: A soundy analysis for Linux kernel drivers. InProceedings of the 26th USENIX Security Symposium, pages 1007–1024, 2017.https://www.usenix.org/conference/ usenixsecurity17/technical-sessions/presentation/machiry

    2017

  16. [16]

    LOLDrivers: Living off the land drivers, 2023

    MagicSword. LOLDrivers: Living off the land drivers, 2023. Open catalog of vulnerable and malicious Windows drivers.https://www.loldrivers.io/

    2023

  17. [17]

    Winbindex: The windows binaries index, 2020.https://winbindex.m417z

    Michael Maltsev. Winbindex: The windows binaries index, 2020.https://winbindex.m417z. com

    2020

  18. [18]

    Unveiling BYOVD threats: Malware’s use and abuse of kernel drivers

    Andrea Monzani, Antonio Parata, Andrea Oliveri, Simone Aonzo, Davide Balzarotti, and Andrea Lanzi. Unveiling BYOVD threats: Malware’s use and abuse of kernel drivers. In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2026. https: //www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf

    2026

  19. [19]

    Screwed Drivers: Signed, sealed, delivered, 2019

    Mickey Shkatov and Jesse Michael. Screwed Drivers: Signed, sealed, delivered, 2019. DEF CON 27; Eclypsium research.https://eclypsium.com/research/screwed-drivers-signed-sea led-delivered/

    2019

  20. [20]

    Building a scalable Windows driver vulnerability analyzer, 2026

    Threat Unpacked. Building a scalable Windows driver vulnerability analyzer, 2026. Parts 1–2. https://threatunpacked.com/2026/01/21/building-a-scalable-windows-driver-vulne rability-analyzer-part-1/. 15

    2026