- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 271
- Reaction score
- 7
Working on a kernel-mode spoofer and hit the wall with native API leaks? You're not alone. The standard IOCTL path is solid for WMI/Win32_DiskDrive, but once you start digging into Get-PhysicalDisk and virtual adapter routing, the anti-cheat telemetry catches the real hardware signatures cached at boot.
1. The stornvme Cache Dilemma
Get-PhysicalDisk leverages the Storage Management Provider (SMP) to read directly from the stornvme.sys DeviceExtension memory pools. DKOM sweepers relying on MmIsAddressValid are asking for a BSOD, specifically AV_VRF_nt!IopReadFile. If you are doing manual non-paged pool patching, the TOCTOU race conditions are killers. A cleaner route is hooking the Storage Query structures before they reach the SMP layer or nullifying the specific query paths, rather than trying to scrub live memory pools post-boot.
2. NDIS Virtual Adapters
Standard OID filtering on your NIC works for physical hardware, but Windows spins up virtual adapters (Wi-Fi Direct, WAN Miniports) that derive their own descriptors. Instead of focusing only on physical OIDs, look into hooking the NDIS Protocol drivers. You need to handle the underlying miniport structure generation.
3. PnP and Registry Anchors
If your Disk Instance IDs (PCI slot hashes) are leaking, stop touching the DeviceNode via DKOM. The SetupAPI cross-referencing is too aggressive. It's safer to intercept the registry lookups for the PnP configuration keys when the driver queries the hardware topology, rather than trying to rewrite the PnP tree live.
Anyone else dealt with these persistent leaks in their kernel builds? How are you handling the NDIS virtual mapping without breaking the stack?
1. The stornvme Cache Dilemma
Get-PhysicalDisk leverages the Storage Management Provider (SMP) to read directly from the stornvme.sys DeviceExtension memory pools. DKOM sweepers relying on MmIsAddressValid are asking for a BSOD, specifically AV_VRF_nt!IopReadFile. If you are doing manual non-paged pool patching, the TOCTOU race conditions are killers. A cleaner route is hooking the Storage Query structures before they reach the SMP layer or nullifying the specific query paths, rather than trying to scrub live memory pools post-boot.
2. NDIS Virtual Adapters
Standard OID filtering on your NIC works for physical hardware, but Windows spins up virtual adapters (Wi-Fi Direct, WAN Miniports) that derive their own descriptors. Instead of focusing only on physical OIDs, look into hooking the NDIS Protocol drivers. You need to handle the underlying miniport structure generation.
3. PnP and Registry Anchors
If your Disk Instance IDs (PCI slot hashes) are leaking, stop touching the DeviceNode via DKOM. The SetupAPI cross-referencing is too aggressive. It's safer to intercept the registry lookups for the PnP configuration keys when the driver queries the hardware topology, rather than trying to rewrite the PnP tree live.
- Avoid DKOM on device trees; use Filter Drivers or object callbacks if possible.
- For the stornvme issue, track the DeviceExtension structure dynamically rather than hard-coding offsets.
- Check SystemInformation GUIDs against local registry hives instead of trying to patch them in-memory; sometimes a read-redirect is cleaner than a write.
Anyone else dealt with these persistent leaks in their kernel builds? How are you handling the NDIS virtual mapping without breaking the stack?
