VMwareHardenedLoader-ng: a Windows kernel driver that filters VMware firmware strings

What VMwareHardenedLoader-ng actually hides, and from whom

The README describes the project as a Windows kernel driver for VMware guest research environments. The two operations it names are filtering selected VMware-related firmware strings and blocking selected VMware PnP registry enumeration. That is a narrow scope. This is not a general purpose virtual machine concealment toolkit; it targets the firmware table and the PnP enumeration path specifically.

The intended audience is people running Windows guests inside VMware for malware analysis, anti-VM research, or sandbox work where the guest is inspected by the code running inside it. If your workload does not run code that probes firmware tables or enumerates PnP devices, the driver has nothing to do. The README does not claim to defeat hypervisor CPUID leaves, timing checks, or hardware fingerprinting, and none of the linked documentation pages are described as covering those. Treat the scope as exactly what the first paragraph says.

How the driver resolves kernel globals without PDBs or signature scans

The mechanism is the part worth understanding before you build anything. The driver needs the addresses of undocumented kernel globals. The README states it resolves them from signed System Informer KPH dynamic data rather than from PDBs, signature scanning, or registry-provided RVAs. System Informer is included as a submodule, and kphtools provides the symbol source and RVAs for two specific symbols: nt!ExpFirmwareTableResource and nt!ExpFirmwareTableProviderListHead.

That design choice has a direct consequence. The driver does not pattern-scan the kernel image at load time, so it does not depend on byte signatures that break when Microsoft recompiles. Instead it depends on a dynamic data blob that has to match the target Windows build. The build process downloads and validates the KPH manifest, generates and signs v20 dynamic data, and publishes the runtime artifacts the install scripts consume. If the blob is stale for your build, the resolution step is where it fails, not the filtering logic. The README points to docs/en/runtime.md for configuring external dynamic data, which is the page to read if you plan to ship the driver to machines you do not control.

Building VMwareHardenedLoader-ng from a Developer Command Prompt

The README gives one build command and points at docs/en/build.md for requirements. You need Visual Studio 2022 with the WDK installed, and you run the build from a Developer Command Prompt. The solution file is VmLoader.sln at the repository root.

msbuild VmLoader.sln /m /t:Rebuild /p:Configuration=Release /p:Platform=x64

The README states this single invocation does several things in sequence: it downloads and validates the KPH manifest, generates and signs v20 dynamic data, and publishes the runtime artifacts needed by the install scripts. Expect the build to reach the network. The maintained configurations are Release|x64, Debug|x64, Release|ARM64, and Debug|ARM64, so the platform property is not decorative; pick the one matching your guest.

Installation and test-signing are not in the README body. It defers them to docs/en/quickstart.md, which the README describes as covering install, test-sign, and uninstall. The README also says to read docs/en/runtime.md before configuring external dynamic data or loading the driver. Those two pages are the real entry point; the command above only produces artifacts.

ARM64 support is documented as unvalidated in practice

The supported systems list is short: Windows 10 and Windows 11, x64 or ARM64 guests. The README then adds a sentence that matters more than the list. ARM64 runtime behavior still depends on undocumented kernel layouts and must be validated on the target Windows build. In other words, the ARM64 build target exists and is maintained, but the project does not assert that it works on any given Windows build out of the box.

That is an honest limitation rather than a hidden one, and it follows from the resolution mechanism. Anything that depends on undocumented kernel layouts inherits the update cycle of those layouts. A Windows cumulative update that shifts the relevant structures can invalidate the dynamic data for a build the project has not regenerated yet. The README does not document rollback, and it does not describe a fallback path when dynamic data resolution fails. If you deploy this, plan for the failure mode yourself: know how to unload the driver and boot without it.

Where it sits next to hypervisor-level concealment tools

The related searches around this project include VMwareCloak and general anti-VM tooling, so the comparison is worth drawing. The difference is the layer. Tools in the VMwareCloak family typically work at the hypervisor or VM configuration layer: they change what the virtual hardware reports, adjust the .vmx configuration, or modify the host-side presentation of the guest. VMwareHardenedLoader-ng works inside the guest, as a kernel driver, and edits what the guest operating system returns to code running in that guest.

That distinction decides which one you want. If the probe runs before your driver loads, or reads hardware directly through a path the driver does not hook, a guest-side filter cannot help. If you do not control the host configuration, the guest-side approach is the one available to you. The README's own framing supports this reading: it describes filtering firmware strings and blocking PnP registry enumeration, both guest-side views, and says nothing about host configuration beyond pointing at docs/en/behavior.md for VMware configuration.

Licence and the cost of keeping it working

The project is released under the MIT License, and the README points to the LICENSE file. MIT is permissive, so redistribution and modification inside a commercial product are not restricted by the licence text itself. Two dependencies deserve attention before you assume the whole stack is yours to relicense: System Informer is included as a submodule, and kphtools provides the symbol source and RVAs. Their licences are separate from this project's, and the README does not state what they are. Check the submodule and the kphtools repository directly. This is a factual observation about the repository layout, not legal advice.

The upgrade cost is the real ongoing expense. The last push was on 2026-09-01, and the most recent release, v20260901a, is dated 2026-09-01, with the prior release v20260806a on 2026-08-05. That cadence suggests the project regenerates dynamic data as Windows builds move. Every Windows update on a machine running the driver is a potential re-validation event, and the ARM64 caveat above applies to that whole cycle. Budget for rebuilding and re-signing rather than treating the driver as install-once software.

Editorial conclusion

Adopt VMwareHardenedLoader-ng if you run Windows 10 or 11 x64 or ARM64 guests for malware or anti-VM research and you can test-sign and load a kernel driver. Do not adopt it if you need a supported, documented interface, if your target is an anti-cheat protected game, or if you cannot rebuild the driver after a Windows update. Verify first that the current KPH dynamic data resolves the two globals the driver needs for your exact Windows build, and check docs/en/troubleshooting.md before you deploy to anything you cannot roll back.

Frequently asked questions

Official sources

1. hzqst/VmwareHardenedLoader on GitHub
2. Issues
3. License: MIT
4. README
5. Releases