About Hypervisor Cheats, Part 4: Freshness, Timing, and View Management

A hypervisor cheat does not become practical only because it can read memory from below the operating system. It has to keep CPU control state, second-stage views, cached translations, interrupt delivery, timers, and game-thread timing aligned on a real multi-core machine.

Scope

Part 3 looked at EPT/NPT hooks, VM exits, VMI-style monitoring, and where those ideas begin to touch actual game-cheat behavior.

Part 4 moves one layer deeper into the machinery that makes those ideas usable or unusable on a real endpoint:

• per-vCPU VMCS/VMCB state
• SMP and scheduler migration
• EPT/NPT view management
• TLB, VPID, ASID, PCID, and invalidation scope
• VM-exit payloads and event reinjection
• APIC, AVIC, SynIC, posted interrupts, and timer behavior
• MSR and I/O bitmaps
• debug, PMU, and branch-trace virtualization
• Hyper-V, VBS, VTL, and nested ownership
• SEV-SNP, TDX, and other secure-memory boundaries

This post stays on the cheat-side mechanics. The working question is:

What does a below-OS cheat need the machine to do,
and what CPU or platform state must stay coherent for that to work?

Running Example

To keep the rest of the post grounded, imagine one concrete design.

It is a hypervisor-assisted ESP/radar reader with a clean-view EPT monitor:

game runs on Windows
  -> VMM tracks the game address-space root
  -> VMM reads a small set of entity and camera state
  -> selected pages can be watched with EPT/NPT permissions
  -> byte readers should see a clean view
  -> execution or selected accesses can still generate events
  -> an external overlay or companion process receives the output

This model is deliberately small, but it touches most of the failure modes that matter:

• the entity list must belong to the current game process epoch
• the camera and entity state must come from a compatible frame
• EPT/NPT view switching must not leak stale translations to another core
• VM-exit payloads must be decoded well enough to resume cleanly
• interrupt and timer behavior must not push the overlay one frame behind
• clean-view logic must separate ordinary byte reads from execution or monitor events
• the delivery path still has to reach the player without living inside the game process

The sections below keep returning to this example and the state that has to remain coherent for such a small feature to work.

The Primitive Is Fresh State, Not Raw Memory

The oversimplified explanation of a hypervisor cheat often looks like this:

hypervisor sits below Windows
  -> reads game memory
  -> shows ESP or radar

That skips the state problem.

On a modern game endpoint, memory is not a single stable snapshot. A game frame may involve:

• simulation state on one worker thread
• render state on another thread
• input processing on an interrupt-driven path
• network state on a different timing source
• GPU-visible copies or upload buffers
• object pools that reuse addresses
• client prediction that is later corrected by the server
• camera state and entity state sampled on different ticks

Raw memory access is not enough. The cheat needs a coherent snapshot:

target process epoch
  + current address-space root
  + current first-stage translation
  + current second-stage view
  + current object generation
  + current frame or tick epoch
  + delivery path to the player

A hypervisor can help with some of those pieces, but it does not supply all of them. It owns CPU transitions and second-stage translation.

Game meaning, render timing, server authority, and protected memory boundaries still have their own rules.

In the running example, the overlay is only as good as the snapshot.

A perfect EPT read of an old entity list is still a bad radar. A hidden clean-view hook still fails if the camera matrix came from the wrong frame.

What a Cheat Wants from the Hypervisor

A hypervisor-assisted cheat usually wants one or more of these primitives.

Primitive	What the cheat gains	What must stay coherent
out-of-process memory acquisition	game bytes without a normal process handle or injected module	CR3/PCID or ASID, first-stage walk, second-stage walk, page residency, object lifetime
access-driven monitoring	notification when selected code or data is touched	exit payload, page role, instruction context, re-entry state
split-view memory	one observer sees clean bytes while another sees modified or watched bytes	EPTP/NPT root, VPID/ASID, TLB invalidation, sibling-core visibility
temporary permission window	allow one read, write, or execute after trapping an access	single-step or MTF-like progress, event history, restore timing
context tracking	know when the target process, thread, or address-space root is active	CR3 writes, scheduler migration, KVA shadow, PCID, teardown and reuse
time shaping	hide exit cost or align sampling with frame/input timing	TSC/QPC/reference time, APIC timers, synthetic timers, scheduler epoch
interrupt-aware sampling	sample near input, render, or network phases	APIC/AVIC/SynIC state, interruptibility, EOI completion, DPC timing
hosted VMI	move cheat logic outside the guest	host scheduling, virtual GPU/input behavior, VMI semantic reconstruction
DMA hybrid support	use a device or second machine for acquisition/display	virtual-to-physical freshness, IOMMU domain, device TLB, shared buffers

None of these is only “running at Ring -1.” Each one depends on a set of control fields and cached hardware state.

For the running example, the goal is not to “own the machine.” The goal is narrower:

recognize the game context
  -> translate a small set of game addresses
  -> sample entity and camera state with low disturbance
  -> turn selected page accesses into events when useful
  -> keep clean and monitored views separated
  -> deliver a player-facing view before the data goes stale

That is how the hypervisor contributes. It supplies context, translation, view control, and event control around the guest. The game-specific meaning still has to be reconstructed on top of those primitives.

The same idea can be mapped by feature goal:

Cheat-side goal	Hypervisor primitive used	What the reader should notice
read object state without living in the game process	CR3/PCID or ASID tracking, first-stage walk, second-stage read path	the value comes from joining process context with translation state, not from a single global memory view
know when selected code or data is touched	EPT/NPT permission change, VM-exit or NPF payload, access-type classification	the event is meaningful only if the VMM knows who touched the page and why
show clean bytes to one observer while monitoring another path	second-stage root selection, temporary views, permission splits, invalidation	the mechanism is observer separation, not only hiding a modified page
keep radar or ESP usable	low-exit acquisition, frame-aware sampling, TLB/cache freshness	stable and current data is more useful than trapping every access
line up a timing-sensitive feature	timer model, interrupt phase, scheduler epoch, input or render relation	a correct memory read can still be late for the feature

A better split is:

cold path:
  identify target process
  resolve roots and offsets
  track map transitions
  validate object generations

hot path:
  read small selected state
  update overlay or side channel
  avoid frequent exits on hot render/simulation pages
  keep timing stable

Broad trapping looks attractive in a lab trace because it lights up activity. In a real-time game, it often burns the budget the feature needs for freshness.

The more a VMM traps, the more it has to emulate, reinject, invalidate, and account for in its timing model.

For the running example, the hypervisor should not try to trap every entity update or every render read. It wants a few stable roots, a few watched pages, and a predictable refresh path from game memory to overlay.

Field Notes from Public Cheat Discussions

Public cheat-forum threads and open-source hypervisor projects make the same point more bluntly. The failures that matter are rarely about whether the VMM can read bytes.

They show up when the watched page, clock, or interrupt path becomes hot.

Repeated field signals include:

Field signal	What it usually means at this layer
EPT hook works in a demo but freezes under a protected game	the hook is not only a leaf PTE problem; exit type, page walks, memory type, reinjection, or sibling-core visibility is wrong
CR3 exits make the setup stable but destroy performance	CR3 is a high-frequency scheduler signal, not a game-event signal
timing checks improve after one clock is normalized but still fail elsewhere	TSC, QPC, reference time, APIC timers, and frame pacing are coupled only indirectly
mouse movement causes frame collapse	HID interrupt delivery, EOI behavior, posted interrupts, DPC timing, or synthetic interrupt handling has been pulled into the hot path
changing R/W/X hook shape changes stability	instruction fetches, data reads, writes, and page walks produce different exits and different cache behavior
memory allocations or shadow pages behave differently depending on placement	host page tables, MTRR/PAT state, alignment, large pages, and executable backing pages are part of the primitive

Those failures are the reason this post keeps coming back to freshness, timing, and view management.

The discussion may start with a feature idea. It quickly turns into CR3 pressure, EPT thrashing, interrupt storms, stale translations, memory-type mismatches, and partially virtualized clocks.

SMP Turns a Demo into a Distributed System

Single-core diagrams are where many explanations quietly break.

On Windows, the game process is not a single stream of instructions. Threads migrate. DPCs run on different cores. Interrupts arrive while the VMM is inside a handler.

Worker threads update objects while render threads consume a previous frame. A sibling core may still have a translation cached after the core that took the exit already switched its view back.

That gives a hypervisor cheat a distributed-state problem:

per-vCPU VMCS/VMCB state
  -> active first-stage root and tag
  -> active EPTP or N_CR3
  -> VPID, ASID, PCID, and paging-structure cache state
  -> interruptibility and pending-event state
  -> timer and TSC transform state
  -> game thread and object-generation epoch

If any of those are only correct on the faulting core, the primitive is local. Local correctness may be enough for a toy hook, but it is not enough for a stable game feature.

Common break points:

• the simulation thread updates an actor on core 3 while the overlay samples camera state from core 7
• an EPT permission is restored on the faulting vCPU while a sibling worker still has the relaxed translation cached
• the cheat tracks one CR3 transition but misses a worker thread entering the same address space later
• a DPC runs between the watched memory access and the intended re-entry point
• a timer adjustment hides exit cost on one clock but leaves drift in QPC or Hyper-V reference time
• an NMI or debug event arrives while an event is already being reinjected

The design pressure is to stay narrow. A practical cheat tries to minimize hot pages, hot exits, and cross-core synchronization points.

This is not only about hiding. It is also about correctness. Every extra exit is another place where event history, TLB state, or frame timing can diverge.

In the ESP/radar example, a same-core demo might look perfect: the VMM traps a watched page, opens the clean view, resumes, and closes it again.

The failure starts when the render thread moves to another core, a worker thread updates the actor array, and the overlay process samples the data after the camera already advanced.

The hypervisor did not fail to read memory. It failed to keep the snapshot fresh across the machine.

A Small Failure Story

A small failure shape makes the problem concrete.

Frame N:
  simulation worker on core 3 updates the actor array
  VMM samples the entity list under the right CR3

Frame N + 1:
  render thread moves to core 7
  camera matrix is updated for the next visual frame

Meanwhile:
  an EPT temporary view was opened on the faulting vCPU
  a sibling core still has an older translation cached
  an input or timer event shifts the overlay update later

Result:
  every individual read can look valid
  but the overlay combines entity positions from frame N
  with camera state from frame N + 1

The user-visible failure is mundane: boxes drift, flicker, or point at stale actors.

The low-level reason is less visible. The cheat did not lose access. It lost a coherent view across cores, translation caches, event timing, and game-frame state.

This failure mode sets the theme for the rest of the post. A below-OS primitive only becomes useful when the CPU state and the game state describe the same moment.

Per-vCPU Control State

VMX and SVM are not global switches that mean “the hypervisor owns the machine.” They provide per-processor control state.

For Intel VMX, a VMM has to reason about:

• VMXON state per logical processor
• the current VMCS pointer on that processor
• VMCS launch state
• guest-state fields
• host-state fields
• execution controls
• entry and exit controls
• exception, I/O, and MSR bitmaps
• EPTP and VPID state
• VM-exit information fields

For AMD SVM, the shape is different:

• EFER.SVME enables SVM instruction availability
• VMRUN consumes a memory-resident VMCB
• the VMCB has a control area and save-state area
• intercept vectors select exits
• IOPM and MSRPM pages control I/O and MSR trapping
• ASID tags guest translations
• N_CR3 selects the nested page-table root
• TLB_CONTROL requests flush behavior
• VMCB clean bits let hardware reuse cached field groups
• EXITCODE, EXITINFO1, EXITINFO2, and EXITINTINFO carry native exit state

AMD clean bits are worth calling out. A VMCB dump is not necessarily the state the processor consumed.

If software changes a VMCB field group but leaves the corresponding clean bit in a state that permits reuse, the next VMRUN may follow cached control state rather than the memory image a tool later prints.

The rule is practical:

control field in memory
  != control field consumed by hardware
  unless the transition epoch and cache/clean state agree

For a cheat, this is practical rather than academic.

A thin SVM layer wants to mutate as little as possible because broad reloads and flushes cost time. Mutating too little can make the mechanism behave differently across cores or across successive entries.

A better way to read control fields is to treat them as knobs with different blast radii.

Control surface	Cheat-relevant use	Main technical cost
exception bitmap or intercept vector	catch page faults, breakpoints, debug traps, or selected faults near watched code	high event rate and fragile reinjection
CR masks and shadows	track CR3, paging mode, write-protect, SMEP/SMAP, or mode transitions	scheduler and process-root tracking become part of the design
MSR bitmaps or MSRPM	observe or shape time, syscall, APIC, debug, or Hyper-V synthetic state	partial emulation breaks dependent MSR families
I/O bitmaps or IOPM	watch selected device, firmware, or compatibility paths	low direct game-state value but high emulation burden
EPTP or N_CR3	select the active second-stage view	view changes require tag and cache freshness
VPID or ASID	reduce flush cost by tagging translations	stale tags can make an old view look current
VM-entry event fields or EVENTINJ	resume after hiding, delaying, or replaying an event	invalid priority or blocking state breaks guest event history
APIC, AVIC, or SynIC controls	reduce exits or align sampling with timing paths	missing exits no longer mean missing virtualization
TSC offset or scaling	smooth guest-visible time around exits	other clocks may still expose drift

The cheat-friendly setting is rarely the broadest one. It is the smallest set of controls that keeps the target semantic pipeline alive.

There are three versions of control state to keep separate:

memory image:
  VMCS region, VMCB, bitmaps, page tables, helper metadata

processor-consumed image:
  field groups cached or latched by the core during VM entry

analysis image:
  what a debugger, scanner, or later dump can read after the fact

A serious design cannot treat those as the same object. VMX and SVM both let software point at memory-resident control structures, but the live contract is the transition that consumed those fields on a specific logical processor.

For cheat mechanics, that distinction matters more than the raw presence of a VMCS or VMCB page. A structure in memory can be old, prepared but unused, already superseded, or valid only for a different vCPU epoch.

For the running example, the VMM does not need to own every architectural event. It may only need:

CR3 or address-space transitions
  + a small set of EPT/NPT permissions
  + selected MSR or timer behavior
  + enough event injection state to resume cleanly
  + enough per-core state to keep the same view across migration

That small set is still difficult because each item lives in a different part of the control plane.

CR tracking is not EPT tracking. EPT tracking is not timer tracking. Timer tracking is not event reinjection.

A stable cheat has to make them agree at the moment the overlay consumes the data.

VM-Exit Payloads Are Part of the Primitive

An EPT violation, NPF, MSR intercept, I/O intercept, debug exit, or interrupt-window exit is more than a notification. It is a typed transition record.

On Intel, key fields include:

• exit reason
• exit qualification
• guest linear address, when valid
• guest physical address, when reported
• VM-exit interruption information
• IDT-vectoring information
• VM-exit instruction length
• VM-exit instruction information

On AMD, key fields include:

• EXITCODE
• EXITINFO1
• EXITINFO2
• EXITINTINFO
• EVENTINJ
• nRIP, when available
• decode-assist information, when available

A cheat that treats exits as strings loses information it needs to resume cleanly. For example:

• a final data access and a page-walk access are not the same event
• a guest linear address may be invalid or unavailable
• an interrupted exception may need to be completed, not replaced
• instruction length may not mean the instruction completed
• an NPF on AMD has a different shape from an EPT violation on Intel
• event injection on the next entry must respect interruptibility and priority

Access-driven monitoring is harder than it looks. The VMM is not asking only “did this page get touched?” It is deciding:

which layer rejected the access
  -> whether the instruction may advance
  -> whether an event was already in flight
  -> whether the guest should see a fault
  -> whether the page view must be restored before or after progress
  -> whether another core can observe the temporary state

That last line is where many hidden-hook descriptions are too clean.

Suppose the VMM watches a page that often contains actor pointers.

An exit that occurs while the processor is walking guest page tables is not the same as an exit caused by the game reading the actor array.

If the handler treats both as “the entity page was touched,” the overlay may update from the wrong event.

If an exception was already being delivered and the handler injects a new one, the guest may continue with an event history that could not have happened on real hardware.

VM-exit payloads are part of the cheat primitive. They decide whether the VMM has a useful game event or only a low-level CPU event near a similar address.

The exit payload is also a boundary. It tells the VMM why the processor stopped, but it does not automatically tell the VMM why the game cared.

That missing join is where shallow explanations skip a layer:

CPU event:
  access type, GPA, optional GLA, qualification, pending event state

OS context:
  process root, thread, interruptibility, exception history

game context:
  object role, frame epoch, map generation, visibility or projection meaning

The VMM has to join those layers without inventing causality. An EPT violation near an object address may be a real object read, a page-table walk, a scanner touching memory, or a different thread crossing the same page.

EPT/NPT View Management

EPT and NPT are second-stage translation systems. They translate guest physical addresses into system physical addresses and enforce second-stage permissions.

EPT/NPT gives the VMM a view selector:

same guest physical page
  -> different backing page
  -> different R/W/X permission
  -> different memory type
  -> different view for read, write, execute, or scan

That is the cheat-relevant power of second-stage translation. The guest can believe it is using the same virtual address and the same guest physical page, while the processor still consults a VMM-owned second-stage view before the access reaches real memory. A hypervisor can use that position to make an access run normally, fault into the VMM, or resolve through a different backing page.

That makes EPT/NPT attractive for:

• hidden execute hooks
• clean-view scans
• read/write access monitors
• software breakpoint hiding
• watchpoint-like behavior beyond architectural debug registers
• page-level object access monitoring
• temporary clean page exposure
• temporary modified page exposure

The state that matters to the cheat is broader than one leaf entry.

State	Why it matters to the primitive
first-stage root	tells whether the guest virtual address belongs to the intended process epoch
second-stage root	decides which guest physical view the VMM is presenting
leaf R/W/X bits	decide whether read, write, or execute becomes a trap or runs normally
memory type	affects cacheability, ordering, GPU/device paths, and timing
large-page shape	decides whether a 4 KB target is isolated or still part of a 2 MB authority region
accessed/dirty behavior	can turn passive observation into a stateful side effect
VPID or ASID	decides whether old translations can survive root or permission changes
paging-structure caches	can keep a stale walk alive after the table bytes changed
invalidation scope	decides whether the changed view reached one core, one tag, one root, or the whole affected set
external observer	DMA, GPU, or host-visible paths may not share the CPU’s current view

But the primitive is not the table edit. The primitive is the whole view transition:

select watched page
  -> split large mapping if needed
  -> install second-stage permission or backing change
  -> retire stale cached translations
  -> take EPT violation or NPF
  -> classify access type and page role
  -> open temporary view if needed
  -> allow one bounded progress interval
  -> restore restricted view
  -> retire stale translations again
  -> preserve event history and sibling-core state

The expensive parts are not always the trap itself. They are large-page splitting, TLB shootdown, VPID/ASID reuse, memory-type continuity, sibling-core coherence, and event reinjection.

It helps to think of EPT/NPT manipulation as three clocks:

table clock:
  what the second-stage tables say now

translation clock:
  what TLB and paging-structure caches can still use

game clock:
  what frame, object generation, or thread epoch the bytes belong to

A hook can be correct on the table clock and wrong on the other two.

“The EPT entry was restored” is not enough. The question is whether every relevant observer has stopped using the old translation before the game consumes the data.

Intel and AMD also describe failures differently. An Intel EPT violation is not the same thing as an AMD nested page fault, and neither should be flattened into “memory event.”

Event shape	Cheat-relevant meaning
Intel EPT violation on final access	the guest reached a GPA whose second-stage permissions rejected the access
Intel EPT violation during page walk	the processor touched guest paging structures and hit a second-stage restriction there
Intel EPT misconfiguration	the second-stage entry itself was malformed or encoded an illegal combination
AMD NPF on final physical access	the final guest-physical access failed under NPT permissions or presence
AMD NPF during guest page-table walk	the processor faulted while reading guest paging structures
#VE-style delivery	the event is routed into guest-visible virtualization-exception handling instead of a normal VMM exit

For a game cheat, those distinctions decide what the event means:

• the game object was touched
• the process page table was walked
• the hook table is malformed
• the guest handled a virtualized exception

Treating them as one event class is how a design becomes unstable under real workloads.

For the ESP/radar example, the meaningful event is not “some EPT exit happened.” It is closer to:

the current game process,
under the current CR3 or ASID,
touched the watched object or page role,
under the expected access type,
while the frame snapshot is still fresh.

That is much harder than the phrase “EPT hook” suggests.

Large Pages

Games and drivers often live around large mappings. Watching one 4 KB subpage may require splitting a 2 MB mapping. That changes more than one address. It can change:

• page-walk depth
• TLB pressure
• memory-type inheritance
• adjacent-page behavior
• accessed/dirty behavior
• invalidation cost
• sibling-page authority

A shallow explanation may say “split the large page and hook one page.” A more accurate explanation is:

large leaf becomes a subtree
  -> every sibling leaf needs coherent permissions and memory type
  -> existing combined translations must be retired
  -> the watched leaf must not accidentally change neighboring behavior

If the cheat only cares about one object inside a hot page, the split itself can become more expensive than the read.

Large-page splitting also changes evidence locality. Before the split, one large translation covers many neighboring objects or code paths. After the split, one leaf has special behavior while siblings try to look ordinary.

That creates three obligations:

retire the old large translation
  -> preserve sibling permissions and memory type
  -> keep the watched 4 KB leaf from changing nearby timing

The visible bug is often not “the hook failed.” It is an adjacent object, code path, or scanner taking a different timing or cache path because the page neighborhood changed.

Temporary Views

A common hidden-hook shape is a temporary view window:

restricted view active
  -> guest access causes EPT/NPF event
  -> VMM opens clean or altered view for the intended access
  -> guest makes bounded progress
  -> VMM closes the view again

On Intel, Monitor Trap Flag can be used to regain control after one instruction. Other designs use debug state, event reinjection, or emulation.

AMD SVM does not expose the same MTF mechanism, so SVM designs tend to rely on different event or emulation paths.

The limitation is locality. A temporary view is not automatically temporary for the whole machine. It is temporary for a specific combination of:

• vCPU
• EPTP or N_CR3
• VPID or ASID
• translation-cache state
• interrupt window
• sibling-core visibility
• external observer path

If a render worker, DPC, or DMA-side reader observes during the wrong interval, the cheat can see inconsistent data or expose the wrong view.

In the running example, this can fail in two opposite ways.

A normal byte reader may see the altered view when it should see clean bytes. The overlay reader may see the clean view when it expected the monitored one.

Both failures come from the same root: the view is local, but the game workload is distributed.

EPT Thrashing

Forum threads often use phrases like “EPT trashing” or “EPT thrashing” when a hypervisor becomes unstable under a protected game.

At this level, the phrase means the VMM has built a hot fault loop around second-stage translation.

A typical failure shape looks like this:

hot code or data page
  -> second-stage permission change
  -> frequent EPT violation or NPF
  -> temporary view opening
  -> single-step, emulation, or event reinjection
  -> second-stage permission restore
  -> INVEPT, INVVPID, ASID reuse, or shootdown pressure
  -> sibling core or later frame observes a stale view

The page may be technically hooked, but the hook is no longer useful as a game primitive. The system is spending too much of its budget on view churn, and the game-facing data can arrive late or inconsistent.

This is where R/W/X hook shape matters.

Execute traps, read traps, write traps, and page-walk faults are not interchangeable. They hit different paths through the core, carry different exit payloads, and create different pressure on caches and event reinjection.

A hook shape that survives a quiet kernel test can still collapse on a hot render, input, or anti-tamper path.

Clean Views

Clean-view techniques are often described as:

ordinary byte reader sees original page
game execution sees modified page

Mechanically, this is not one feature. It can be built from several lower-level ideas:

• different EPTP roots
• permission-triggered view switching
• execute-only or read/write permission splits
• temporary backing-page swaps
• page aliases with matching content but different authority
• VMFUNC/EPTP switching where available and configured
• #VE-style in-guest virtualization exception paths in selected environments

For a cheat, the value is not only hiding bytes. It is separating observers:

ordinary byte reader
  -> clean bytes

execution observer
  -> altered semantics

monitor observer
  -> access event

The fragile part is keeping those observers separated under thread migration, hot-page pressure, and cached translations.

This separation is what a cheat wants. The radar path wants fresh data. The clean-view path wants ordinary readers to see boring bytes. The monitor path wants access events.

EPT/NPT can help build that separation, but only if the VMM keeps the observer identity straight.

CR3 Tracking and Address-Space Freshness

Game cheats often talk about finding the game process. At this layer, the more precise problem is finding the active address-space epoch.

The cheat needs to know:

• which process owns the client-side game state
• which CR3 or process page-table root is active
• whether PCID or KVA shadow changes the visible root
• whether the relevant thread has migrated
• whether the object is in process-private memory, shared memory, mapped assets, or a graphics allocation
• whether the map, match, or object generation changed

A CR3 value helps, but it is not a process oracle. It is a page-table root under a scheduling epoch.

The context has to include:

CR3 or root value
  + PCID or ASID
  + process lifetime
  + thread lifetime
  + first-stage walk result
  + second-stage walk result
  + object-generation check
  + frame or tick relation

On modern Windows, that root can also be split by policy and optimization. PCID, KVA shadow, session-space behavior, kernel/user address splits, and hypervisor enlightenments can all make “the current CR3” less useful than it sounds.

The cheat wants a semantic epoch, not a register value:

the thread that matters
  -> running under a root that maps the target object
  -> in the match and map generation being displayed
  -> before the object or camera state is reused

Stale reads are common in weak external or hypervisor-assisted cheats because the low-level memory transport can keep working after the semantic target has moved:

• an object address was reused
• an entity became dormant
• a player pawn changed ownership
• a map transition rebuilt the object graph
• a camera matrix came from a later frame than the entity list
• a replicated field lagged behind server-authoritative state
• a GPU-visible copy was older than CPU-side gameplay state

Hypervisor control helps with acquisition. It does not remove the semantic freshness problem.

In practice, a below-OS reader needs two joins.

The first join is address-space freshness:

thread or vCPU is running
  -> current CR3, PCID, or ASID is known
  -> first-stage page walk matches the intended process
  -> second-stage walk maps the same guest physical page
  -> cached translations belong to the same epoch

The second join is game-state freshness:

world root or object manager
  -> level or scene generation
  -> actor or entity collection
  -> player, pawn, controller, component relation
  -> transform, mesh, weapon, team, visibility, status
  -> frame, tick, or replication generation

The hypervisor can help with the first join. It can watch root changes, trap selected address-space transitions, or read page tables without opening process handles.

The second join is game-specific. If the object graph changes faster than the reader validates it, a technically successful read can still produce wrong gameplay information.

This is the core path behind many below-OS readers:

game virtual address
  -> current process root
  -> guest page-table walk
  -> guest physical page
  -> second-stage translation
  -> sampled bytes
  -> game semantic validation

The hypervisor is strongest in the middle of that chain. It can observe roots, walk or validate translations, and read below ordinary process APIs. It is weaker at the two ends: deciding which game address matters and proving that the sampled bytes still describe the current player-visible moment.

Those same discussions around EAC-style freezes and hypervisor instability often circle back to CR3 exiting.

That makes sense. CR3 changes are one of the easiest ways to know which address-space root is active, but they are also among the noisiest signals on a Windows system.

The mistake is to treat every root transition as useful game context:

CR3 write or load
  -> process or kernel/user root transition
  -> PCID or KVA-shadow detail
  -> scheduler movement
  -> possible target-process epoch

Only the last item is close to what the cheat actually needs.

Exiting on too many root transitions gives the VMM more context but burns frame time. Exiting on too few keeps performance intact but risks losing the current address-space epoch.

A read-only hypervisor cheat still has moving parts. It avoids many write/injection footprints, but it still has to solve:

• process root selection
• pointer lifetime
• object reuse
• dormant or irrelevant actors
• replicated state delay
• map and match transitions
• camera and entity frame alignment
• projection from world space to screen space
• delivery to the player without adding a bad timing signature

In the running example, CR3 tracking gives the reader a starting point, not a finished radar.

The entity pointer chain must still belong to the current map. The actor must still be alive.

The team and visibility fields must still mean what the cheat thinks they mean. The camera used for projection must still match the entity positions.

Interrupts and Timers Are Part of Game-Cheat Mechanics

Many game-cheat features look like memory features but are actually timing features.

Examples:

• radar can tolerate some delay if positions remain stable
• ESP needs camera and entity state from the same visual epoch
• trigger assistance depends on input-edge timing
• aim assistance depends on current camera, weapon state, target position, and smoothing interval
• cooldown or ability awareness depends on tick alignment and replicated state freshness

That makes interrupt and timer virtualization part of the cheat surface.

Relevant mechanisms include:

• external-interrupt exiting
• interrupt-window exiting
• NMI-window exiting
• APIC-access virtualization
• virtual-APIC page
• EOI-exit bitmap
• posted interrupts
• Intel APICv
• AMD AVIC and x2AVIC where available
• Hyper-V SynIC and synthetic timers
• VP assist and EOI assist
• VMX preemption timer
• APIC timer virtualization
• TSC offsetting and scaling
• Hyper-V reference time and reference TSC page

A cheat does not necessarily want to intercept every interrupt. Often it wants a stable sampling schedule:

sample after game state update
  -> before overlay projection
  -> close enough to input or render phase
  -> without creating frame-time spikes

The interrupt path has its own state machine:

device or timer source
  -> remapping or synthetic delivery path
  -> virtual pending state
  -> guest interruptibility and priority
  -> handler, ISR, DPC, or worker thread
  -> scheduler epoch
  -> game frame, input, render, or network phase

If the cheat reads memory at the wrong point in that chain, it may get a coherent CPU snapshot that is still wrong for the game frame.

Different cheat features stress different parts of that chain.

Feature style	Timing dependency	Hypervisor state that matters
radar	stable entity refresh matters more than exact input edge	low exit rate, stable CR3/root tracking, object-generation checks
ESP overlay	camera and entity data must come from the same visual epoch	render-thread timing, projection data freshness, TSC/QPC/frame relation
trigger helper	crosshair relation must be sampled close to input handling	interrupt timing, input-device path, scheduler delay, timer drift
aim assistance	target state, weapon state, smoothing interval, and input output must agree	frame time, interpolation state, synthetic or hardware input timing
cooldown or ability view	replicated state and timer fields must be interpreted under the right tick	game tick, network update cadence, local prediction correction

A hypervisor can try to use timers and interrupts as anchors, but every anchor has a cost.

• External-interrupt exiting gives the VMM strong timing visibility but can add jitter.
• Posted interrupts and APICv reduce exits but also remove some expected handler opportunities.
• SynIC and synthetic timers make the guest’s timing path paravirtual rather than LAPIC-native.
• A VMX preemption timer can bound execution intervals, but its cadence may not align with game frames.
• TSC offsetting can smooth a local transition while QPC or reference time still exposes drift.
• DPC and ISR timing can move a decision later than the memory sample that triggered it.

A common mistake is to read “no exit” as “no event.”

APICv, AVIC, posted interrupts, and SynIC are designed to remove exits from common paths. That can improve performance while hiding the timing edge a naive monitor expected to see.

For a cheat, lower exit count is useful only if the remaining timing anchors still identify the right game phase. Otherwise the feature becomes smooth and wrong.

HID input makes this concrete. Public field reports often mention systems that look fine until mouse movement begins, then frame rate collapses.

At this layer, that is not a special “mouse bug.” It means the VMM has accidentally pulled the input interrupt path into the hot path.

The failure chain can be this short:

high-rate mouse input
  -> interrupt or synthetic interrupt activity
  -> exits, EOI handling, or DPC scheduling pressure
  -> frame pacing changes
  -> overlay or input decision misses its useful window

Interrupt-aware sampling has to be selective. A cheat may care deeply about input timing, but if the VMM creates exits on the same path it is trying to observe, the observation changes the feature.

Time does not need to look perfect. The memory sample, game phase, and delivery phase only need to stay close enough for the player-facing feature to remain usable.

For the running example, nanosecond-perfect time is unnecessary.

What matters is that the entity list, camera matrix, and overlay projection describe the same visual moment closely enough that boxes stay stable instead of drifting, flickering, or pointing at stale actors.

Time Virtualization

Timing is not one clock.

On a Windows endpoint, relevant time sources may include:

• TSC and RDTSCP
• QPC
• APIC timers
• HPET or platform timers
• Hyper-V reference time
• Hyper-V reference TSC page
• synthetic timers
• scheduler runtime
• ETW timestamps
• game frame time
• client tick
• replay tick
• server tick

Each source has a different owner and reader. TSC may be adjusted by VMX/SVM controls.

QPC may route through platform or paravirtual time. Hyper-V reference time can be a guest contract with the host. Frame time belongs to the game and renderer.

A VMM can offset or scale some guest-visible time. It can trap selected timestamp instructions. It can also try to hide exit latency by normalizing one clock.

The trouble is that games and operating systems compare clocks indirectly.

For example:

RDTSC looks smooth
  but QPC migration shows a discontinuity
  or Hyper-V reference time disagrees
  or frame pacing shows clustered delay
  or input timestamps fall out of line with server tick

The better question is not “can the VMM forge time?” It is:

Can the VMM avoid disturbing the clocks that the feature actually depends on?

A stable low-frequency acquisition loop is often easier to keep plausible than a high-frequency exit storm with time smoothing.

Radar-style features are more forgiving than trigger or aim timing. A radar can survive a little delay. A trigger path can lose its useful window in one frame.

The clock contract has three parts:

monotonicity:
  time should not move backward or jump in impossible ways

relative agreement:
  TSC, QPC, reference time, APIC timers, and frame time should not disagree

feature alignment:
  the sampled state should still belong to the input or render window being used

The third part is the one game cheats often feel first. A clock model can look plausible to a microbenchmark and still miss the useful input edge.

There is also a sampling contract:

clock value
  + vCPU or core that observed it
  + scheduler epoch
  + interrupt or DPC phase
  + game frame relation

Without that relation, a timestamp is only a number. It does not prove that the memory sample and the player’s view belong to the same moment.

Attacker-side tuning often focuses on CPUID, RDTSC, RDTSCP, and selected RDMSR paths. Those are not one timing check. They are a family of probes that touch different exit paths and different guest-visible clocks.

The mistake is to make one path look clean while the rest of the platform still disagrees:

CPUID exposure looks ordinary
  but timestamp exits cluster
  or RDMSR timing differs from nearby native MSRs
  or QPC and reference time disagree
  or frame pacing records the cost anyway

For a game-facing feature, the best timing strategy is usually low disturbance rather than perfect spoofing.

MSR and I/O Bitmaps

MSR and I/O bitmaps are compact control planes. They decide which guest accesses run natively and which accesses exit to the VMM.

MSR handling tends to matter more than legacy port I/O because MSRs touch:

• TSC behavior
• syscall entry points
• APIC and x2APIC state
• debug and performance controls
• VMX/SVM capability reporting
• Hyper-V synthetic interfaces
• memory type through PAT/MTRR
• CET and related control state

MSRs are families, not isolated values. A VMM can spoof one common check and still drift elsewhere.

Examples:

• IA32_EFER must agree with long mode, NX behavior, syscall behavior, and entry/exit load controls
• PAT/MTRR state must agree with guest page attributes, EPT/NPT memory types, and cache symptoms
• TSC-related state must agree with QPC, scheduler migration, synthetic time, and network-observed timing
• x2APIC MSRs must agree with APIC virtualization, interrupt delivery, EOI behavior, and Hyper-V enlightenments
• Hyper-V synthetic MSRs must agree with CPUID hypervisor leaves, TLFS feature exposure, and guest driver behavior

On Intel, the MSR bitmap has separate low/high read/write ranges. Some MSRs exit because they are outside covered ranges, not because a specific bit was selected.

On AMD, the MSRPM uses AMD-defined ranges and read/write permission bits under SVM controls. Those structures are similar in purpose but not interchangeable.

As with VMCS and VMCB fields, the live contract is more than the bitmap page in memory:

bitmap memory
  + control field that points to it
  + vCPU entry epoch that consumed it
  + cached or implied intercept behavior
  + handler policy for the affected MSR family

Changing a bitmap without aligning the handler policy can be worse than trapping nothing. The VMM may take an exit it cannot emulate consistently, or let one related MSR run natively while shaping another.

The bitmap is not the policy. The policy is the set of MSR families that must remain mutually believable after an exit.

For example, a TSC decision can pull in APIC timer behavior, Hyper-V reference time, QPC migration, and scheduler accounting. A syscall-adjacent decision can pull in IA32_EFER, LSTAR, STAR, FMASK, CET state, and entry/exit load controls.

A better cheat-oriented way to think about MSRs is to ask which feature path touches which family:

Feature path	MSR family pressure
periodic radar read	TSC/QPC relation, synthetic time, APIC timer behavior
ESP projection	TSC/QPC/frame-time relation, APIC timer behavior
hidden hook stepping	debug controls, entry/exit state, event reinjection, TSC stability
syscall-adjacent observation	syscall MSRs, IA32_EFER, CET state, entry/exit load controls
x2APIC-aware timing	x2APIC MSRs, APICv/AVIC behavior, EOI and posted-interrupt state
Hyper-V guest or nested path	synthetic MSRs, reference time, VP assist, TLFS feature exposure

A broad bitmap gives the VMM many opportunities to observe and spoof. It also forces the VMM to emulate more of the platform. A small bitmap is harder to build but easier to keep coherent.

In the running example, MSR handling mostly matters through time and interrupt state.

If the VMM smooths RDTSC but leaves Hyper-V reference time, QPC migration, or x2APIC behavior inconsistent, the overlay may look stable in one local clock while drifting against the actual frame and input path.

The cheat does not need to virtualize every MSR family perfectly. It needs the few MSR families it touches to agree with the game moment it is trying to display.

The test is narrow: do the clocks, interrupt controls, and synthetic interfaces touched by the feature describe the same frame?

Debug, PMU, and Branch-Trace State

Debug and performance facilities are tempting because they can observe execution without rewriting code in the guest process.

Relevant surfaces include:

• debug registers
• DR6 and DR7
• single-step state
• Monitor Trap Flag on Intel VMX
• RDPMC
• performance counter MSRs
• LBR
• PEBS
• Intel PT
• BTS or DS-buffer style state on older paths
• PMIs and overflow delivery

Those surfaces answer different questions.

Facility style	What it can tell the cheat	Why it is fragile
debug registers	whether a small address range was touched	limited slots, visible state, exception ordering
single-step or MTF-like progress	whether one instruction advanced after a view change	entry/exit and interruptibility rules matter
LBR or branch trace	which nearby control-flow path executed	per-core history can be over-interpreted
PMU counters	whether a small timing or execution pattern changed	counters are multiplexed, virtualized, or policy-limited
Intel PT-style tracing	richer execution trace outside ordinary code patching	volume, synchronization, and privilege boundaries grow quickly

In a virtualized system, those facilities can be:

• passed through
• trapped
• masked
• saved and restored on transitions
• virtualized per guest
• disabled by policy
• multiplexed by a host performance subsystem

For a cheat, these surfaces can help with internal calibration, access monitoring, or execution tracing around a small target.

The cost is state continuity. Debug and PMU state is visible to more than one layer, and it interacts with exception delivery, timer behavior, and scheduler placement.

A trace is also not self-authenticating. It has a producer, a privilege context, a core, a time window, and a reset point.

trace meaning:
  producer facility
  + vCPU or physical core
  + process and thread epoch
  + privilege and virtualization policy
  + sampling or overflow boundary

If any of those are guessed, the trace becomes a hint, not evidence.

A hidden breakpoint that only hides the code byte but leaves impossible debug state is not a complete primitive. A branch trace that belongs to one core but is interpreted as global execution history is also not complete.

The facility has to be tied back to the same vCPU, process epoch, and game phase.

For the ESP/radar reader, debug and trace state is usually useful only when it stays small: calibrating a short path, confirming that one watched routine ran, or measuring a tiny timing window.

Once the feature depends on broad tracing, the VMM has created another synchronization problem on top of the memory problem.

VM-Entry, VM-Exit, and Event Reinjection

Every hypervisor cheat that traps anything has to resume execution.

That sounds boring, but it is one of the deepest parts of the design. After an exit, the VMM must decide:

• did the intercepted instruction complete?
• should RIP advance?
• was an exception or interrupt already being delivered?
• should an event be reinjected?
• is the guest temporarily blocking interrupts?
• is NMI blocking active?
• did debug state need reconciliation?
• did the exit happen during a page walk or final data access?
• did the handler change memory ordering or flags?

Intel and AMD name these fields differently, but the shape is the same. The VMM has to preserve event history.

The dangerous cases are the ones that look local:

• a page-walk fault that arrives while another exception is being delivered
• an interrupt-window exit that opens while the guest is blocking events
• a single-step or MTF path that collides with debug state
• a nested path where L1 and L0 disagree about who owns the pending event

The memory view can be perfect and the resume path can still be wrong.

The minimum event ledger has to answer:

before exit:
  was an event being delivered?
  was the guest blocking interrupts or NMIs?
  did debug state already carry a pending cause?

after handler:
  did the instruction complete?
  should the guest see a fault?
  should the VMM reinject, delay, or suppress an event?

A small hidden hook can fail without any visible memory mismatch:

page access traps correctly
  -> handler returns plausible bytes
  -> event reinjection is wrong
  -> guest sees impossible exception order
  -> timing or control-flow state becomes unstable

For game cheats, that pressure is immediate. There may not be room to recover from a bad reinjection path during a hot render or input phase.

Memory Type and Device Visibility

Byte equality is not memory equality.

The same apparent value can come from:

• ordinary write-back RAM
• a write-combined upload buffer
• a shared section
• a copied semantic cache
• MMIO-adjacent state
• a GPU-visible allocation
• a DMA-visible page
• encrypted or private memory metadata

The missing word is behavior.

A page has bytes, but it also has cacheability, ordering, producer history, device visibility, large-page ancestry, and translation-cache history. Two views can return the same bytes and still behave differently under a real workload.

EPT/NPT permission changes do not make those properties disappear. An EPT leaf on Intel carries a memory-type decision. AMD NPT participates in the guest-to-system translation path under AMD’s own memory-type and caching rules. The guest also has PAT and MTRR state, and the host/root side has its own mappings and allocation choices.

For a hidden page or shadow page, the question is not only:

do the bytes match?

It is closer to:

does this page keep the same cacheability,
ordering,
accessed/dirty behavior,
device visibility,
and translation-cache lifetime
as the page it is pretending to be?

For cheats, modern game state is not limited to CPU heap memory. Relevant state can pass through:

• renderer upload buffers
• constant buffers
• mapped resources
• shared memory between processes
• anti-tamper broker processes
• device-visible capture paths
• second-PC or hardware-overlay paths

That matters because a game often has several copies of something that looks like “the same” state:

gameplay object
  -> render proxy
  -> upload buffer
  -> GPU-visible resource
  -> capture or presentation path
  -> user-visible frame

If the cheat reads a CPU copy that is one frame old, the memory read is technically correct but wrong for the player-visible game state.

If it reads a GPU-visible copy without understanding projection timing, the ESP may drift. If it reads a shared buffer without knowing the producer epoch, it may see stale but plausible data.

The same issue appears inside the VMM.

Public hypervisor projects and issue threads often point at MTRRs, PAT, host page tables, and allocation placement when EPT hooks behave differently on otherwise similar pages. Those are architectural details, not superstition.

Memory type is part of the observer contract. A shadow page that is byte-identical but mapped with a different cache type is not behavior-identical.

The same applies to device-visible state. A CPU reader, a GPU copy engine, a DMA device, and a host VMM mapping may not share the same ordering, cacheability, or visibility window.

An EPT-backed shadow page is not only “another page with different bytes.” It has:

• a host physical backing page
• a host virtual mapping used by root-mode code
• an EPT/NPT leaf entry with a memory type
• guest-visible cache and ordering behavior
• possible large-page ancestry
• CPU translations that may outlive the table edit
• possible device translations through an IOMMU or device TLB
• a producer and consumer epoch in the game or renderer

If any of those disagree with the surrounding mapping, the hook may work in a quiet test and fail under a real game or protected driver.

The page can be byte-correct and still wrong in cacheability, ordering, execute authority, or sibling-core visibility.

The cheat-relevant failure is usually not dramatic. It looks like mild drift:

object bytes match
  but the renderer consumed an older copy
  or the shadow page changed cache behavior
  or a device path observed a different generation
  or a sibling core kept using a stale translation

That is enough to make a radar box lag, a trigger condition fire late, or a clean-view hook behave differently under load.

The low-level acquisition path and the game semantic path have to meet at the same memory generation.

A useful page view needs five labels:

address authority:
  which process and translation root made this address meaningful?

byte authority:
  which backing page supplied the bytes?

memory-type authority:
  which cache and ordering policy governed the access?

device authority:
  which CPU, GPU, DMA, or host path could observe this state?

semantic authority:
  which game frame or object generation made the value useful?

EPT/NPT can help with the second label. It can sometimes influence the third. It does not automatically solve the other three.

Nested Virtualization and Hyper-V Coexistence

Modern Windows systems may already have a legitimate hypervisor stack:

• Hyper-V
• VBS
• HVCI
• Credential Guard
• WSL2 or Virtual Machine Platform
• nested virtualization
• root partition enlightenments
• synthetic timers
• VP assist pages
• eVMCS or enlightened VMCB behavior

That changes the cheat design space.

A bare-metal-style VMM wants to own VMX/SVM directly. If Windows already owns that layer, the cheat has to coexist, nest, interfere, or fail.

A hosted VMI design can instead place the game inside a guest and run the observer outside it, but then the guest has virtual devices, virtual GPU behavior, host scheduling, and virtual input paths.

Nested ownership changes the meaning of fields:

L2 guest sees virtualized state
L1 may own a virtual VMCS or VMCB
L0 owns the real hardware transition
Hyper-V or another host may own final scheduling and timers

An EPT event visible to one layer may not be the final hardware EPT event.

A flush visible to one layer may be an enlightened contract that asks the lower layer to perform the hardware operation. A timer seen by the guest may be synthetic rather than local APIC behavior.

This is not only a compatibility issue. It affects correctness:

• which layer owns the real second-stage root
• which layer owns TLB invalidation
• which layer owns APIC or synthetic interrupt delivery
• which layer owns reference time
• which layer sees the target memory bytes
• which layer can deliver output to the player

The useful mental model is provenance:

field value:
  who wrote it?
  who consumed it?
  who cached it?
  who is allowed to retire it?
  who can observe the outcome?

In a nested or enlightened path, those answers may point to different layers. A guest-visible VMCS field can be a contract with L1, while L0 owns the hardware VMCS and the actual exit path.

A cheat that assumes bare-metal ownership can become wrong before it becomes visibly broken. It may see a field, timer, or flush request that is real at one layer and only advisory at another.

The difficult cases are the ones where the field name is familiar but the consumer has changed.

Examples:

Surface	Bare-metal reading	Nested or enlightened reading
VMCS control field	consumed by the processor on VM entry	may be an eVMCS field consumed by L1 or translated by L0
VMCB clean field	tells hardware which groups can be reused	may become part of an enlightened VMCB contract
EPTP or N_CR3	selects the second-stage root used by hardware	may select an L1-owned view that is itself nested by L0
TLB flush	retires translations under a hardware-defined scope	may become a hypercall or direct virtual flush request
APIC/EOI path	causes exits according to local controls	may be assisted by APICv, AVIC, VP assist, or SynIC
timer source	LAPIC, TSC, or preemption-timer relation	may be synthetic time exposed through TLFS contracts

For a cheat, this changes the meaning of a “successful” operation.

L1 view changed
  does not prove
L0 hardware view changed

guest-visible time normalized
  does not prove
host scheduling and reference time agree

virtual interrupt delivered
  does not prove
the physical interrupt path had the same ordering

This is why nested VMI can be attractive and treacherous at the same time. Moving the observer into the host gives it a cleaner place to read guest memory, but it also makes host scheduling, virtual GPU behavior, virtual input, synthetic timers, and virtual TLB ownership part of the cheat primitive.

The model needs a layer tag on every piece of state:

L2 game state:
  process root, object graph, game frame

L1 virtual machine state:
  virtual VMCS/VMCB, guest EPT/NPT, virtual APIC state

L0 host state:
  hardware controls, real TLB retirement, real scheduling, real devices

delivery state:
  overlay, stream, input path, or external display

A field without its layer tag is ambiguous.

The same ambiguity appears in timing. A nested guest may see smooth synthetic time while the host is the layer that actually pays the scheduling cost. A host-side observer may read memory at a moment that is current for L0 but already stale for the L2 frame being displayed.

The cheat-side rule is strict:

do not ask whether a field exists;
ask which layer owns the transition that makes the field true.

VBS, VTL, HVCI, and Protected Translation State

“Below the OS” is not the same as “above every trust boundary.”

Windows virtualization-based security splits parts of the system into Virtual Trust Levels. HVCI and MBEC-style execute policy can make executable authority a policy decision, not only a page byte.

Precision note: this post uses “MBEC-style” to describe the HVCI execution-control shape, not to claim that every vendor exposes the same mechanism under the same name. On Windows, the Mode Based Execution Control property is reported for Intel MBEC and AMD Guest Mode Execute Trap capabilities.

The mechanism here is ownership, not policy.

VTL0 is the normal Windows world where the game and most drivers live. Higher trust levels can hold secrets, policy, or isolated services. The hypervisor provides the separation contract. That means a below-OS observer may still be outside the trust domain that gives a byte its meaning.

For a hypervisor-assisted cheat, the consequences are:

• VTL0 memory is not always the whole endpoint state
• code bytes are not always enough to explain execution authority
• a lower layer may observe some pages but not own the policy that makes them meaningful
• synthetic MSRs and TLFS state may be normal, not proof of a second hidden layer
• process memory, execution permission, and platform trust state can have different owners

The cheat-side mistake is to collapse those owners into one phrase: “below Windows.”

A below-OS observer may still be outside the policy domain that decides whether code can execute, which memory is isolated, or which synthetic interface is authoritative.

For Part 4, the mechanical lesson is narrow:

byte visibility
  != execute authority
  != trust-level authority
  != useful game semantics

There are three different contracts in play:

translation contract:
  which address resolves to which page?

execution contract:
  which code is allowed to execute under this trust and integrity policy?

semantic contract:
  which value actually describes the game moment the feature wants?

A VMM-style cheat can have a strong position in the first contract and still be weak in the second or third.

HVCI makes this concrete. The relevant question is not only whether bytes can be read. It is whether the endpoint’s code-integrity and execute-permission chain is being enforced by a layer the cheat does not own cleanly. If execution authority is influenced by hypervisor-managed policy, a hidden code view or shadow page has to match more than bytes.

It has to match:

guest page state
  + second-stage execute permission
  + integrity policy
  + MBEC or execute-control behavior
  + VTL ownership
  + event and fault history

That is a much tighter contract than ordinary “show clean bytes to a scanner.”

The same issue applies to synthetic interfaces. Hyper-V leaves, synthetic MSRs, VP assist pages, SynIC, and reference-time pages can be normal parts of a Windows security configuration. Seeing them does not automatically identify a hidden cheat layer, and spoofing one piece does not make the rest of the stack coherent.

From the cheat side, the practical consequence is boundary selection. If one boundary is hard to read directly, the cheat may try to use a different semantic source:

• non-isolated client state
• shared buffers
• render/output surfaces
• device-visible data
• timing and input behavior
• hosted VMI observation
• video-based interpretation

That does not make the work easier. It shifts the difficulty from raw memory acquisition to semantic reconstruction.

In the running example, protected or isolated state can force the cheat to stop looking for “the” memory source.

The useful semantic source may become a shared render buffer, a device-visible copy, a video frame, or a timing signal. The source changed, but the cheat still has to rebuild freshness.

The boundary for Part 4 is not “can a lower layer read something?” It is:

can the lower layer read the right thing,
from the right trust domain,
at the right frame epoch,
without breaking the execution or timing contracts around it?

SEV-SNP and TDX as Boundary Lessons

SEV-SNP and TDX are not typical desktop gaming environments, but they are useful boundary cases because they show where modern virtualization is going.

They break the old assumption:

host or hypervisor can map guest physical memory
  -> host sees plaintext guest bytes

With SEV-SNP, ordinary SVM/NPT is only part of the memory-ownership model. The Reverse Map Table, validation state, VMPL checks, encrypted VMSA state, GHCB protocol, and PSP-mediated guest messages add authority above the nested page table.

With TDX, Secure EPT, private memory, PAMT state, TDVPS/TDCS state, shared-versus-private pages, GHCI, and attestation separate host control from guest-private memory meaning.

The split to watch is private versus shared. A host may still see shared pages, device-facing buffers, metadata, or guest-cooperative messages. That is not the same as owning private guest memory.

For cheat mechanics, this turns “where can I read?” into a more precise question:

which memory is private?
which memory is shared?
which metadata crosses the boundary?
which output or input path remains visible?
which semantic source survives encryption or isolation?

This does not mean “confidential computing stops every cheat.” The boundary is more precise:

host position
  != plaintext authority

plaintext authority
  != game semantic authority

game semantic authority
  != delivered player advantage

A hosted or cloud-like cheat may still use shared buffers, video output, metadata, input timing, device-visible state, or guest-cooperative disclosure.

The old assumption that a lower layer can always read every byte is no longer valid in those environments.

SEV-SNP and TDX are useful here because they force the right vocabulary.

SEV-SNP adds a page-ownership contract around guest memory. A page is not only present or not present in NPT. It also has RMP-controlled ownership and validation state. VMPLs split privilege inside the guest. GHCB mediates selected guest-host communication. The host can schedule, inject some events, and manage devices, but private guest memory is no longer ordinary host-readable plaintext.

TDX makes a similar point through a different architecture. Secure EPT, PAMT metadata, TD control structures, private/shared page state, and SEAM-module enforcement separate host mapping power from guest-private byte authority.

TDX Attestation Is a Measurement Boundary

TDX attestation deserves its own mental slot because it is often mixed with memory protection.

Secure EPT and PAMT decide which memory belongs to a Trust Domain and which parts of that memory are private or shared. Attestation is different. It gives a relying party a signed measurement record about the TD, the TDX module, and selected runtime measurements. That is powerful, but it is not the same thing as a host reading game memory, a VMM seeing a private page, or a cheat reconstructing game semantics.

The TDX measurement path has several separate owners:

TDX item	Main owner	What it means	What it does not mean
MRTD	TDX module during TD build and finalization	build-time measurement of the TD’s initial contents and configuration	every runtime byte still matches that initial state
RTMR0-RTMR3	TD runtime and measured boot chain	runtime measurement registers that can be extended as boot/runtime components are measured	a complete event log by themselves, unless the event log can replay into the same values
MRSEAM and MRSEAMSIGNER	SEAM loader and TDX module trust base	measurement and signer context for the TDX module/SEAM component	guest application identity or game-object state
TEE_TCB_SVNs and related TCB fields	platform TDX TCB	security-version context for the TDX platform/module stack	absence of a hosted observer, device path, or shared-buffer leak
REPORTDATA	guest or verifier-provided input	a freshness or binding value, often a nonce or hash chosen by the attestation protocol	an architectural measurement by itself
TDREPORT	TDX module, generated inside the TD	local report containing TD measurements, module measurements, TCB data, REPORTDATA, and a MAC	remote verification by itself; the MAC is local-platform scoped
TD quote	quoting path and remote verifier	remotely verifiable statement derived from the TD report	plaintext memory access, process-memory authority, or gameplay authority

The transition to keep separate is:

MRTD and RTMR state
  -> TDREPORT generated inside the TD
  -> quote generation path
  -> remote verifier decision

Each arrow changes the owner. The TD report is local evidence generated by the TDX module. The quote is the remotely verifiable artifact. The verifier-side conclusion is made outside the guest. Collapsing those into “TDX proves the system state” erases the mechanics that matter.

The hypervisor-cheat lesson is narrower and more technical:

TD quote can support:
  this TD measurement, runtime-measurement state, TDX module context,
  and nonce-bound report reached a verifier through a quote path

TD quote cannot support by itself:
  the host saw private plaintext bytes,
  a game process was read,
  an ESP or radar source existed,
  or a player acted on hidden game information

That distinction matters on both sides of the boundary. If a hosted observer is outside a TD, it may still own scheduling, device plumbing, shared pages, or output capture. It does not automatically own private TD memory. If a report cites a TD quote, it has a measurement and freshness artifact, not a process-memory observation. To reach game meaning, it still needs a bridge from measurement state to the memory, device, render, input, or replay state being discussed.

A cheat-oriented explanation should not overclaim either technology. The sharper lesson is:

mapping authority:
  can the host create or alter a translation?

plaintext authority:
  can the host read meaningful bytes?

event authority:
  can the host observe or influence execution events?

semantic authority:
  can the observer reconstruct game meaning?

delivery authority:
  can the observer turn that meaning into a player-facing advantage?

Older explanations often collapse those into one layer. Confidential-VM designs split them apart.

That split matters even outside confidential computing. A desktop game may not run inside TDX or SEV-SNP, but parts of the endpoint can still be isolated, device-visible, shared, encrypted, brokered, delayed, or owned by a layer the cheat does not control.

So the boundary lesson loops back into the running example:

if entity bytes are private,
  look for shared or output-derived semantics

if render state is visible but delayed,
  rebuild the frame epoch

if host memory is encrypted,
  treat video, input, and metadata as separate sources

if attestation proves a boundary,
  do not assume host position proves byte authority

The low-level cheat primitive becomes weaker as it moves away from plaintext game objects and toward derived signals. It may still work, but it becomes more like reconstruction than memory reading.

From the Running Example to Other Patterns

The running example was an ESP/radar reader with clean-view monitoring. The same planes show up in other cheat feature shapes too, but each feature stresses a different part of the machine.

Running Example Revisited: Radar or ESP

A radar or ESP feature usually wants stable object state more than single-instruction precision.

game process root selected
  -> world or scene root resolved
  -> entity collection sampled
  -> entity identity, team, position, and lifetime checked
  -> camera or local-player state sampled
  -> screen or radar projection updated

Hypervisor value:

• avoids a normal process handle
• can read without an in-process module
• can sample from below common user-mode visibility
• can pair CR3/root tracking with second-stage reads

What makes it hard:

• entity list and camera state may come from different frames
• actor memory may be reused
• network-relevant state may not be player-visible state
• render upload buffers may lag behind CPU gameplay state
• overlay delivery still has timing and capture behavior

For this feature class, heavy EPT trapping is often a poor fit. A small periodic acquisition loop with strong freshness checks is usually more practical than trapping every object access.

The useful hypervisor work is usually root tracking, low-disturbance reads, and frame freshness. The less the feature depends on access traps, the less it fights render-thread timing.

Trigger or Aim Timing

Trigger and aim assistance are much more timing-sensitive.

target relation sampled
  -> local view or crosshair relation evaluated
  -> weapon and input state checked
  -> decision delivered near an input edge

Hypervisor value:

• can watch timing sources
• can observe selected input or timer-related state
• can keep cheat logic outside the game process
• can reduce some user-mode footprint

What makes it hard:

• a stale target position is worse than no target position
• smoothing can create unnatural timing if the clock model drifts
• input delivery must line up with the game frame and server tick
• interrupt and DPC timing can move the decision after the useful window

For this feature class, the time plane and interrupt plane matter as much as the memory plane.

Here, memory correctness is necessary but not sufficient. The sampled target relation has to survive until the input edge where the feature acts.

Hidden Hook or Clean View

A hidden hook wants different observers to see different truths.

execute observer:
  sees altered behavior or watched execution

read observer:
  sees clean bytes or an unmodified page

monitor observer:
  receives access or execution events

Hypervisor value:

• EPT/NPT can split read, write, and execute behavior at second-stage translation
• temporary windows can let one instruction progress under a different view
• clean-view logic can keep simple byte reads from seeing the active execution view

What makes it hard:

• view switching must be synchronized with VPID/ASID and TLB state
• large-page splits change neighboring authority
• event reinjection must remain valid
• another core may observe the wrong view
• memory type and A/D behavior can reveal that the page is not ordinary RAM

This is the pattern where EPT/NPT looks cleanest in diagrams and most brittle in production.

It is also the pattern that exposes whether the VMM understands observer identity. A clean scanner, an executing thread, and a monitor path are different consumers, even when they touch the same guest physical page.

Hosted VMI

A hosted VMI cheat moves the observer outside the game guest.

host owns the observer
  -> guest memory is sampled through VMI
  -> OS and process structures are reconstructed
  -> game objects are decoded outside the guest
  -> output is delivered through host overlay, stream, or external path

Hypervisor value:

• no cheat process has to run inside the guest
• memory acquisition can be moved to the host
• event and page monitoring can be centralized outside the guest

What makes it hard:

• the VM itself has device, GPU, input, and timing behavior of its own
• host scheduling can desynchronize memory and display
• virtual GPU paths can change what the player actually sees
• guest memory still needs game-specific semantic decoding
• input delivery may look unlike normal local input

Hosted VMI relocates where the footprint lives. It does not remove the need for fresh game semantics.

The difficult part is often not reading guest memory. It is keeping host-side decoding, host display timing, guest render state, and player input aligned.

DMA Hybrid

A DMA hybrid uses a device or second machine for some part of the pipeline.

external reader
  -> physical memory acquisition
  -> translation helper or cached CR3/root state
  -> semantic decoder
  -> external display or input path

Hypervisor value:

• can provide or cache virtual-to-physical translations
• can track when the game process root is active
• can signal map or object-generation changes
• can keep a local coordinator away from normal process inspection

What makes it hard:

• IOMMU and device-remapping state may block or reshape access
• physical memory is not process memory without a current translation
• stale virtual-to-physical mappings create wrong overlays
• external display or input still creates timing and behavior constraints

DMA does not replace the hypervisor problem. It moves part of the acquisition path outside the CPU and makes freshness matter even more.

The hypervisor part still matters when virtual-to-physical translation, map changes, or process-root epochs have to be supplied to the external reader.

Putting the Primitive Together

A working hypervisor cheat has to join several planes:

control plane:
  VMCS/VMCB fields, intercepts, bitmaps, entry/exit controls

translation plane:
  CR3/PCID, ASID, EPTP, N_CR3, VPID, TLB state, invalidation

event plane:
  exits, exceptions, IDT-vectoring, EVENTINJ, MTF, debug state

time plane:
  TSC, QPC, reference time, APIC timers, synthetic timers, game tick

interrupt plane:
  APICv, AVIC, SynIC, posted interrupts, EOI, DPC/ISR timing

semantic plane:
  object graph, transform, visibility, camera, weapon state, frame epoch

delivery plane:
  overlay, side channel, external display, input shaping, player decision

The practical cheat-side value of the hypervisor is that it can hold several of those planes below or outside the game process:

context:
  which address space and vCPU are active?

translation:
  which guest virtual address resolves to which guest physical page?

view:
  which second-stage mapping and permission set is currently visible?

event:
  did this access, instruction, interrupt, or timer transition carry useful meaning?

phase:
  does the sample still belong to the frame, tick, or input window the feature uses?

That is the mental model for this part. Hypervisor assistance is not one capability. It is a way to move acquisition, observation, and view control away from ordinary process instrumentation while still trying to preserve game-time meaning.

The mistake is to read that list as a stack.

It behaves more like a set of ledgers. Each ledger has its own owner, cache, and epoch.

machine ledger:
  which vCPU, root, view, event, timer, and interrupt state was current?

memory ledger:
  which backing page, memory type, device path, and translation cache supplied the bytes?

game ledger:
  which object generation, frame, camera, and replication epoch made the value meaningful?

delivery ledger:
  which overlay, stream, external display, or input path reached the player?

The VMM can be excellent at the machine ledger and still produce a bad cheat if the game ledger is stale.

A good semantic decoder can still fail if the memory ledger is only correct on one core.

Real hypervisor-cheat engineering comes down to currentness:

current root
  + current view
  + current cache state
  + current event history
  + current frame
  + current object generation

Not all of those are solved by being below the OS.

The running example gives the compact version:

radar or ESP wants:
  current target process root
  + current entity collection
  + current camera or local-player state
  + current second-stage view
  + current translation cache state
  + current delivery path

If any item is from a different epoch, the feature may still render something. It will render the wrong state.

That is why Part 4 spends so much time on state that looks secondary in simpler diagrams:

• VMCS/VMCB state is the control contract.
• Exit payloads are the event contract.
• EPT/NPT roots, VPID, ASID, and invalidation are the view contract.
• APIC, AVIC, SynIC, posted interrupts, and timers are the phase contract.
• PAT, MTRR, memory type, and device visibility are the byte-behavior contract.
• Hyper-V, VBS, VTLs, SEV-SNP, and TDX are ownership-boundary contracts.

A below-OS position can give a cheat unusual observation power. It does not give it automatic authority.

The primitive only becomes useful when those contracts describe the same moment on the same machine.

Research Threads That Shape This Primitive

The notes below map recent research and platform work back to the same primitive discussed above.

The basic shape does not change:

observe from below or outside the guest
  -> reconstruct the guest and game state
  -> keep the view, event, and timing planes current
  -> deliver useful information or timing to the player

What changes is ownership. Newer VMI research, EPT-hook work, event-delivery features, Hyper-V enlightenments, and secure-memory designs all move some part of that chain to a different layer.

The trend is less about one hidden layer and more about split authority. Observation, translation, event delivery, timing, memory privacy, and player-facing output can all sit behind different owners.

VMI Cheats Move the Cheat Boundary Outward

VIC-style research is useful here because it frames cheating as virtual machine introspection rather than as an in-process implant. The game process does not need to contain the radar or trigger logic.

The observer can live outside the guest, reconstruct memory, and deliver information through a host-side or external path.

Here, the relevant dependency chain is:

host or lower layer owns observation
  -> guest physical memory or event source is sampled
  -> guest OS and process structures are reconstructed
  -> game objects are interpreted
  -> timing is aligned with the player's view
  -> assistance is delivered outside the game process

That chain still depends on cross-core freshness, timer alignment, second-stage translation freshness, and virtual-device behavior. Moving the binary footprint out of the guest does not remove stale object graphs, wrong frame epochs, GPU presentation latency, or host scheduling.

That is the main reason VMI cheating belongs in this discussion. It moves the artifact, but it does not move the need for game semantics.

VMI also changes the word “local.” The observer may be local to the host, not local to the guest.

That creates three localities:

guest-local:
  game process, guest OS, guest devices, and guest-visible time

host-local:
  VMI reader, host scheduler, host display path, and host input path

player-local:
  screen, stream, overlay, second device, or input edge

A hosted VMI cheat can be clean inside the guest and still be stale for the player. The fragile work is keeping those three localities aligned.

EPT Hooks Are View-Management Problems

HyperDbg’s public EPT hook and monitor designs show the full shape of the primitive:

restrict a page
  -> take an EPT event
  -> temporarily restore or switch the view
  -> let progress happen
  -> restore the restricted state

In a game cheat, the same pattern is attractive for:

• clean-view hooks
• execute monitors
• read/write monitors
• hidden breakpoint-like behavior
• object access sampling
• small code-path observation

R/W/X bits are only the start. View management carries the complexity:

watched page selected
  -> large page split if needed
  -> second-stage permission changed
  -> cached translations retired at the right scope
  -> faulting access classified
  -> temporary view opened
  -> event or instruction progresses
  -> restricted view restored
  -> sibling cores and external observers reconciled

MTF, single-step equivalents, INVEPT, INVVPID, VPID reuse, ASID reuse, AMD clean bits, and Hyper-V nested flushes are not footnotes. They decide whether the hook is a reliable game-state primitive or a same-core demonstration that collapses under load.

The strongest way to describe an EPT hook is not “it hides a patch.” It is:

one page participates in more than one observer contract

The executing instruction, a byte reader, a monitor path, a page-table walk, and a sibling core can all be different observers. A hidden hook is stable only when the VMM knows which observer caused the event and which view that observer is allowed to see.

That is why a high-quality EPT/NPT explanation needs invalidation, exit classification, memory type, and reinjection. Without those pieces, it describes a table edit, not a working primitive.

FRED Adds Event-Delivery State

Intel FRED and AMD FRED virtualization add another reason to avoid old “interrupt equals IDT” explanations. FRED changes event delivery, return, stack-level semantics, shadow-stack interaction, and event-data handling.

Precision note: FRED should be treated as capability-gated. The existence of Intel and AMD FRED virtualization documentation does not mean every Windows gaming endpoint currently runs with FRED enabled. The point here is narrower: if the OS and CPU are using FRED, a VMM has to preserve the newer event-delivery contract rather than relying on legacy IDT-only assumptions.

This affects hidden hooks and event-driven monitors.

If an EPT event, debug event, interrupt-window exit, or synthetic event occurs while FRED-style delivery is in flight, the VMM must preserve the event-data carrier and return semantics.

A design that only copies legacy IDT assumptions can appear stable in a quiet lab and fail when the OS uses newer event-delivery paths.

For this post, the shift is not the instruction mnemonic. It is the state contract:

event source
  + event data
  + target privilege and stack level
  + shadow-stack relation
  + return semantics

A hidden hook that changes only page visibility can still damage that contract. If the VMM resumes with the wrong event data or return state, the memory hook may look correct while control flow becomes architecturally impossible.

For cheat mechanics, FRED matters because it raises the cost of hand-waving around event delivery.

An EPT monitor, debug trap, NMI-window exit, interrupt-window exit, or single-step path is not isolated from the guest’s event model. If the OS and processor are using a newer event-delivery contract, a VMM that still assumes legacy IDT-only behavior is preserving the wrong state.

The visible symptom may look like a timing failure or a fragile hook. The root cause may be event-data loss.

Hyper-V Enlightenments Change Ownership

Hyper-V TLFS is useful here because Windows endpoints may already run with a legitimate hypervisor contract. Nested virtualization and enlightenments can change the meaning of a field:

• an eVMCS field can be L1-visible state rather than the hardware VMCS consumed by L0
• an enlightened VMCB can delegate clean-field and virtual TLB behavior
• direct virtual flushes can differ from raw INVVPID, INVLPGA, or ASID expectations
• SynIC and synthetic timers can replace the timing behavior a bare-metal diagram assumes
• VP assist and EOI assist can remove exits that an older monitor expected to see

That creates two paths.

A bare-metal-style VMM has to coexist with or contradict the Windows hypervisor stack.

A hosted or nested VMI design can intentionally use that stack, but then the cheat logic must respect paravirtual timers, virtual TLB ownership, virtual APIC behavior, and host scheduling.

The practical shift is from fields to contracts.

raw field model:
  read or write the field and assume hardware consumed it

enlightened model:
  read or write a contract that another layer may translate, cache, merge, or defer

That distinction is central to Part 4. The live primitive is the transition path, not the memory object that names the transition.

Secure-Memory Features Limit Hosted Assumptions

SEV-SNP and TDX show the direction of travel: below-OS position does not automatically mean plaintext authority over every byte.

RMP, GHCB, encrypted VMSA, Secure EPT, PAMT, guest-private backing, shared-memory disclosure, and attestation all separate hosting power from memory meaning.

The boundary is precise.

A hosted or cloud-like cheat can move observation outside the guest, but if the workload is inside a confidential or isolated memory domain, the host may see only shared buffers, metadata, encrypted pages, or guest-mediated disclosures.

The cheat then needs a different semantic source: video-based interpretation, shared-state leakage, guest-cooperative exposure, device-side data, or behavioral inference.

That does not make confidential computing a direct model for desktop game security. It matters here because it breaks a bad assumption:

lower privilege position
  -> total byte authority
  -> total semantic authority

Modern virtualization keeps separating those arrows. A hosted observer may own scheduling and devices, but not plaintext private memory. It may see output, but not the internal game object that produced the output.

Recent SEV-SNP and TDX boundary research also shows why this should not be summarized as “host can read” or “host cannot read.”

• HECKLER focuses on malicious non-timer interrupt injection against confidential VMs.
• WeSee focuses on malicious #VC injection against AMD SEV-SNP.
• RMPocalypse focuses on RMP initialization and the catch-22 around protecting the RMP with RMP entries.
• Fabricked focuses on Infinity Fabric routing, platform initialization, and PSP-to-RMP routing weakness.

These results do not collapse confidential VMs back into ordinary VMs. They show that secure-memory systems also depend on event, firmware, routing, and metadata ledgers.

That separation is also a useful way to read less exotic systems. A cheat can observe one layer and still be forced to infer another. Once it leaves direct client memory and moves toward render output, timing, shared buffers, or device-visible state, it is no longer a pure memory reader.

It becomes a reconstruction system.

Where This Is Going

The trend is not that hypervisors make cheats invisible. A better reading is:

older model:
  inject into game or kernel
  -> patch or read local process state
  -> deliver overlay or input

hypervisor/VMI model:
  move observation below or outside the guest
  -> use second-stage translation and event control
  -> reconstruct game semantics externally
  -> fight SMP, timing, nested ownership, and secure-memory boundaries

That is the density behind Part 4.

The work is no longer only offsets and pointer chains. It is freshness, ownership, timing, and view management across a modern virtualization stack.

This also sets up the next post. Once memory and CPU-side state stop being the whole picture, I/O becomes the next boundary. Devices have their own translations, caches, request queues, isolation domains, and sharing contracts.

That is where SR-IOV, SIOV, SVA, PASID, ATS, PRI, GPU virtualization, CXL, and TEE-I/O enter the series.

---

Next

Next, the series moves from CPU-side freshness to advanced I/O. The next problem is how devices, accelerators, DMA paths, and shared address spaces change what it means to observe game state from outside the normal process boundary.

---

Credits

• @Intel80x86 and @HyperDbg for the HyperDbg work on hardware-assisted debugging, EPT hidden hooks, transparent memory hooks, and monitor-style EPT tracing.
• memN0ps for the hypervisor memory-introspection writeup and the illusion-rs and matrix-rs projects, especially the EPT shadowing, MTF, dual-EPT, and Rust hypervisor design notes.
• DarthTon and Gbps for HyperBone and Gbhv, which provide public VT-x/EPT hooking references for page substitution, EPT TLB splitting, shadow hooks, and MTRR-aware EPT work.
• jonomango for the hv project and public discussion around lightweight VT-x design, VM-exit handling, timing behavior, and EAC-related stability reports.
• Panicos Karkallis and Jorge Blasco Alis for the VIC research on virtual machine introspection cheats.
• Benedict Schlueter, Supraja Sridhara, Mark Kuhne, Andrin Bertschi, Christoph Wech, and Shweta Shinde for the HECKLER, WeSee, RMPocalypse, and Fabricked research that clarifies malicious interrupt, #VC, RMP initialization, and Infinity Fabric routing failure modes around confidential VMs.
• jxttah, None4334, lauralex, and the public UnknownCheats anti-cheat-bypass discussion participants for field reports around EPT hook instability, CR3 exit pressure, timing probes, MTRR/host-page-table hints, and interrupt-related frame drops.

---

References

• Intel, Intel 64 and IA-32 Architectures Software Developer’s Manual, combined volumes: https://cdrdv2-public.intel.com/825743/325462-sdm-vol-1-2abcd-3abcd-4.pdf
• Intel, Flexible Return and Event Delivery Specification: https://cdrdv2-public.intel.com/780121/346446-flexible-return-and-event-delivery.pdf
• AMD, AMD64 Architecture Programmer’s Manual Volume 2, System Programming, Rev. 3.44: https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2
• AMD, AMD64 Flexible Return and Event Delivery Virtualization, Pub. 69191 Rev. 1.00: https://docs.amd.com/v/u/en-US/69191-PUB
• Microsoft, Hyper-V Top-Level Functional Specification: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs
• Microsoft, Virtualization-based Security overview for OEMs: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs
• Microsoft, Enable virtualization-based protection of code integrity: https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity
• Microsoft, System Guard Secure Launch and SMM protection: https://learn.microsoft.com/en-us/windows/security/hardware-security/system-guard-secure-launch-and-smm-protection
• Intel, Intel TDX Module Base Architecture Specification: https://cdrdv2-public.intel.com/733575/intel-tdx-module-1.5-base-spec-348549002.pdf
• Intel, Intel TDX DCAP Quote Generation Library and Quote Verification Library API: https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
• AMD, SEV Secure Nested Paging Firmware ABI Specification: https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf
• AMD, AMD-SB-3034 SEV-SNP Routing Misconfiguration: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3034.html
• AMD, AMD-SB-3020 SEV-SNP RMP Initialization Vulnerability: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html
• Linux Kernel Documentation, Intel Trust Domain Extensions: https://docs.kernel.org/arch/x86/tdx.html
• Linux Kernel Documentation, Intel Trust Domain Extensions in KVM: https://docs.kernel.org/virt/kvm/x86/intel-tdx.html
• HyperDbg Documentation, Design of !epthook: https://docs.hyperdbg.org/design/features/vmm-module/design-of-epthook
• HyperDbg Documentation, Design of !monitor: https://docs.hyperdbg.org/design/features/vmm-module/design-of-monitor
• Panicos Karkallis and Jorge Blasco, VIC: Evasive Video Game Cheating via Virtual Machine Introspection: https://arxiv.org/abs/2502.12322
• HECKLER: Breaking Confidential VMs with Malicious Interrupts: https://arxiv.org/abs/2404.03387
• WeSee: Using Malicious #VC Interrupts to Break AMD SEV-SNP: https://arxiv.org/abs/2404.03526
• RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP: https://rmpocalypse.github.io/
• Fabricked: Misconfiguring Infinity Fabric to Break AMD SEV-SNP: https://xca-attacks.github.io/fabricked/
• UnknownCheats, Hypervisor EAC Loads Freezes System: https://www.unknowncheats.me/forum/anti-cheat-bypass/523529-hypervisor-eac-loads-freezes-system.html
• jonomango/hv, EPT-related freezes and EAC discussion, issue #54: https://github.com/jonomango/hv/issues/54
• DarthTon, HyperBone: https://github.com/DarthTon/HyperBone
• Gbps, Gbhv: https://github.com/Gbps/gbhv
• memN0ps, Hypervisors for Memory Introspection and Reverse Engineering: https://memn0ps.github.io/hypervisors-for-memory-introspection-and-reverse-engineering/
• memN0ps, illusion-rs: https://github.com/memN0ps/illusion-rs
• memN0ps, matrix-rs: https://github.com/memN0ps/matrix-rs