Making Vulnerable Drivers Exploitable Without Hardware – The BYOVD Perspective
Table of contents
- 1 Introduction
- 2 The offensive value of kernel mode drivers
- 3 Device object creation and maintenance – common patterns
- 3.1 Unconditional creation upon driver load
- 3.2 Conditional device creation and maintenance
- 3.3 PnP-specific callbacks as the main location of PnP driver initialization logic
- 3.3.1 AddDevice
- 3.3.2 IRP_MJ_PNP
- 3.4 Active hardware interaction and probing
- 3.4.1 Neutral hardware use
- 3.4.2 Vulnerable hardware use
- 3.4.3 Hardware gating
- 4 How driver deployment can be approached from the BYOVD perspective
- 4.1 Simple sc.exe deployment
- 4.2 Creating software-emulated devices with spoofed hardware ID
- 4.2.1 The idea
- 4.2.2 Initial test results
- 4.2.3 Creating software-emulated devices with SoftwareDevice and PnpManager
- 4.2.3.1 SetupAPI and PnpManager – process overview
- 4.2.3.2 SetupAPI and PnpManager – device node creation only
- 2.3.3 SetupAPI and PnpManager – complete and successful deployment
- 4.2.3.4 Software Device API
- 4.3 Jumping device stacks
- 4.3.1 Filter restacking
- 4.3.2 Per-device and per-class filters
- 4.4 Forced driver replacement
- 4.4.1 The problem with INF files
- 4.4.2 Bypassing the INF file mechanism
- 4.5 Working around active hardware probing
- 5 Final thoughts
1. Introduction
This article provides a technical analysis of how many Windows kernel mode drivers can be interacted with from user mode without the hardware they were developed for. This work was motivated by driver-oriented vulnerability research and the need to evaluate the exploitability of individual findings, which frequently affect code whose reachability is hardware-gated. The methodology presented here should help anyone determine whether a particular Windows kernel mode driver vulnerability remains reachable — and thus potentially exploitable — even in the absence of the hardware the driver was developed for.
The reader is expected to have basic Windows driver knowledge, especially regarding device objects. The rest of this article is written with the assumption that the reader is already familiar with the concepts described in the introduction article: Anatomy of Access: Windows Device Objects from a Security Perspective.
Just like the introduction article, this resource is not focused on any specific bug class, but rather the attack surface and, to an extent, the Windows Plug and Play architecture.
All the tests demonstrated here were conducted on Windows 11 23H2 (winver 10.0.22631.3007).
2 The offensive value of kernel mode drivers
In addition to the obvious Local Privilege Escalation potential, vulnerable drivers are often abused in BYOVD attacks – a post-exploitation technique leveraged by attackers to disrupt system defenses such as EDR components.
Two main criteria determine whether a driver vulnerability is a strong candidate for BYOVD attacks:
-
- Exploitation allows meaningful disruption of an otherwise tamper-resistant security component. Examples include kernel-level vulnerabilities granting arbitrary memory read/write access, arbitrary code execution, or arbitrary resource abuse (e.g., overwriting files, closing handles, or terminating processes).
- Its exploitability is independent of rare system conditions, such as the presence of specific hardware.
Although BYOVD-style attacks have been well documented for years, with numerous public reports and research papers on the topic (e.g. https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf, https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/, https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants), none of them specifically examines the role of hardware-gating in driver vulnerability reachability.


