7. Detecting hypervisor based env

EPT hook detection (momo5502)

Momo5502 (Maurice Heuman) published detailed research and opensourced code on detecting hypervisor assisted hooks via EPT, available at github.com/momo5502/ept-hook-detection. The core insight is that EPT hooks create a discrepancy between what you read from a page and what actually gets executed from it — and this dscrepancy is what can be detected. Three main checks are documented in his research:

• Timing Check — Measure time to access a page with write permission vs. executing it. The extra VM exit + page fault overhead from the EPT hook creates a measurable timing difference. Can be partially defeated by RDTSC spoofing (!hideon in HyperDBG) but this is sometimes unstable.

• Thread Check — Create two threads, one reads the page data, one executes it. If EPT-hooked, they observe different content since read and execute physical pages differ. Harder to defeat.

• Write Check — Write a value to a page and read it back. If the written value doesn't match what you read, there's an EPT hook altering the memory view. Directly breaks GPU MMIO spoofing.

pretty neat eh?

Timing based detection and WWHY it's unreliable

Timing checks are intuitively appealing as a detection method every VM exit has overhead, so intercepted instructions should take measurably longer on a hypervisor than on bare metal hardware. However, as the CrackL@b author correctly points out, timing checks are unreliable and quite noisy in practice. CPU frequency scaling, L3 cache effects, background OS activity, and general system load all create timing variance that can easily exceed the VM-exit overhead in many real scenarios. A DRM that triggers on timing anomalies would frequently flag legitimate users on any heavily loaded system, which is exactly what Denuvo cannot afford to do false positives on paying customers are very bad for business. Hence author doesnt recommend timing checks as a primary reliable solution, and in this regard it is agreed by most researchers. :3 cool.

Driver Signature Enforcement (DSE) as a barrier

One of the most practical prevention approach is to enforcing DSE. The kernel evel hypervisor drivers used in the bypass (SimpleSvm.sys, hyperkd.sys) are not Microsoft-signed for production use. If DSE is enforced, these drivers cannot load. Games like Fortnite (via BattlEye/EasyAntiCheat) already check for Windows Test Mode — Test Mode = game won't launch. The CrackL@b analysis notes that the bypass initially required disabling Secure Boot and using EfiGuard (github.com/Mattiwatti/EfiGuard) to strip PatchGuard and DSE. DSE enforcement remains a significant friction point.

CPUID Hypervisor leaf checks

The analyzed bypass DLL itself implements a basic hypervisor detection, it checks CPUID leaf 0x40000001 for the Microsoft Hyper-V interface signature (0x30237648). Denuvo could theoretically implement comprehensive CPUID leaf scanning to detect any hypervisor presence. However, this leads to a cat-and-mouse situation where the bypass simply adds more spoofs for any new leaves checked; which is not a sustainable long term strategy without anchoring to something fundamentally harder to fake.

Other Structural Checks

Several other structural properties differ in hypervisor environments vs. bare metal: - SGDT / SIDT / SLDT / STR instructions return GDT, IDT, LDT, TR base addresses — values differ predictably on Hyper-V guests vs. bare metal. - CR4 and CR0 register values differ in hypervisor-hosted environments due to certain bits set/cleared by the VMM - Non-standard MSR values or access patterns triggering VM exits when they shouldn't on bare metal hardware. - Thread scheduling patterns that reveal the single-threaded nature of simple VCPU loops. - Cache timing attacks via CLFLUSH + RDTSC on memory pages can reveal two-level address translation overhead.