cyber.hendryadrian.com
Threat Research · thehackernews.com

Research Shows How Some Hardware-Gated Windows Drivers Can Be Reached Without Hardware

· Original article ↗

Summary

The analysis shows how emulated devices, spoofed hardware IDs, filter restacking and forced binding can expose some Windows PnP driver code without its intended hardware, potentially expanding BYOVD risk. Generic hardware-probe bypasses may still require kernel or hyper

Key points

  • PnP drivers often rely on AddDevice to create device objects and initialize state; simply loading a driver with sc.exe does not invoke that callback.
  • SetupAPI/PnPManager and Software Device API can create emulated device nodes with spoofed hardware IDs, prompting PnP to bind a compatible driver and call AddDevice.
  • In preliminary experiments, the author found nearly twice as many new device objects with emulated-device deployment as with simple service loading, and reports confirming driver vulnerabilities this way, including BYOVD candidates.
  • Opening a device stack requires at least one driver to handle IRP_MJ_CREATE; a bare PnPManager-owned PDO rejects it, preventing user-mode access when no other driver in the stack accepts the request.
  • The article demonstrates making filter drivers accessible by placing them above a usable disk-device stack through UpperFilters and a virtual disk, including filters intended for other device classes.
  • Forced driver binding through device registry structures can bypass normal INF matching, but using an unsuitable driver may disrupt the device or destabilize the system.
  • The author assesses that generic hardware-probe bypasses cannot be done purely from user mode and may require additional kernel-mode components or hypervisor access.

Article Details

Attack Vectors
  • An administrator can create a software-emulated device with a spoofed hardware ID and bind a driver to it, triggering PnP initialization without the original hardware.
  • A filter driver can be added to a device class's UpperFilters registry entry and loaded into an accessible device stack, potentially exposing otherwise unreachable code.
  • A driver can be bound to an existing or emulated device by modifying device and class registry structures, bypassing the normal INF-based matching process.
  • Simple service creation and startup can expose drivers that create accessible device objects directly during initialization.
Defensive Notes
  • Assess driver vulnerabilities for reachability without their intended hardware, including through emulated devices and alternative device stacks.
  • Examine forensic traces of software-emulated device creation, driver service installation, device binding changes, and UpperFilters or LowerFilters modifications.
  • Successful AddDevice invocation alone does not establish exploitability; device creation, handle access, internal state and hardware checks can still prevent access.

Products

AwinicSmartKAmps.sysWe will use AwinicSmartKAmps.sys (I2C smart amplifier controller) driver as an example.GMLXDFltrIf we inspect the driver object in WinDBG, we will see the entire device stack, including GMLXDFltr with its unnamed FiDO on top of it:Windows 11All the tests demonstrated here were conducted on Windows 11 23H2 (winver 10.0.22631.3007).

Tools

Ghidracallbacks we can usually find in a device driver’s DriverEntry function looks like this (decompiled in Ghidra, comments added manually):NtObjectManagerUse NtObjectManager to list the Devices directory and save that list.windbgNow, if we want to test if the driver created any named device objects, the easiest way not involving WinDBG usage is to:

Related Articles