Inside HV2: Memory Introspection Is a Translation Problem First

Executive summary

HV2 turns an existing virtualization boundary into a narrow research interface.

The project studies what becomes possible when memory introspection is performed below the guest operating system instead of through a driver, debugger, or in-guest agent. The goal is not to publish an operational tool. The goal is to document a disciplined private platform for controlled lab research.

What it is

A boot-time interposer, not a replacement hypervisor.

HV2 establishes a small control path inside an existing virtualization stack, then exposes a compact legacy set of memory and translation operations to a trusted local research client.

Why it matters

Modern security boundaries increasingly sit below the kernel.

Virtualization-backed isolation means kernel-level tooling is not always the lowest useful vantage point. HV2 studies memory from a layer where guest state can be observed independently.

What is withheld

The implementation remains private.

We do not publish source code, byte signatures, structure offsets, build-specific internals, installation paths, or bypass procedures. The public value is architectural documentation and research methodology.

The challenge

OS-level tooling observes a system from inside the system it is trying to measure.

User-mode tooling is constrained by process boundaries. Kernel-mode tooling is powerful, but still shares the operating system's trust model, patching rules, and compromise surface. HV2 moves the observation point below that layer.

Research position	What it can see	Primary limitation
User mode	Public APIs, process-visible memory, debugger-approved state.	Subject to handles, access checks, anti-debug logic, and user-mode tampering.
Kernel mode	Most operating-system structures, page tables, driver-visible memory.	Still inside the OS trust boundary and vulnerable to kernel-level concealment.
Hypervisor layer	Guest state, nested translation, physical backing behavior, VM-exit context.	Harder to initialize, debug, validate, and keep compatible across releases.

Core architecture

HV2 is a narrow interposer, not a replacement hypervisor.

The design depends on preserving normal behavior. HV2 recognizes a narrow command path and delegates unrelated VM exits back to the platform's original handler. Recognition is routing, not authentication; the current trust model is a single-owner, controlled lab.

01 [Boot Integration Layer] Establishes HV2 during the early boot window before the target environment has fully initialized its virtualization stack.

02 [Payload Mapper] Prepares the private payload and passes a compact context record into the hypervisor-side runtime.

03 [VM-Exit Interposer] Recognizes controlled research commands and delegates all unrelated exits to the original handler.

04 [Translation Engine] Resolves guest virtual addresses through guest paging and second-level translation.

05 [User-Mode Library] Provides a stable research API while hiding backend-specific hypervisor complexity.

Why it works

VM exits are already the processor's clean handoff from guest execution to hypervisor control.

HV2 uses that hardware-defined transition as a controlled command transport. Once in the hypervisor-side context, it can examine guest state and translation metadata that ordinary user-mode code cannot authoritatively access.

Exit classification

HV2 first classifies whether the exit belongs to its command path.

The payload checks the exit class and a private command marker before dispatch. If the exit is unrelated, it is forwarded to the original platform path. The marker prevents accidental routing; it does not establish caller identity or authorization.

State recovery

The payload extracts exactly the state needed to complete the command.

The implementation needs the guest instruction pointer, address-space root, register context, exit metadata, and nested translation root. The way this state is recovered differs by backend.

Resume correctness

The guest must continue as though a normal instruction completed.

HV2 writes the return status, advances guest execution, and avoids disturbing unrelated register or hypervisor state. This is where many unstable prototypes fail.

Small command surface

The operation inventory is small; its trust surface is still powerful.

The legacy contract contains initialization, address-space discovery, translation, physical read/write, and virtual copy. Compactness helps auditing, but these operations remain privileged and require explicit bounds, caller trust, and negative-path validation.

Translation model

Reading memory is really a two-stage translation problem.

The phrase "read memory" hides the real engineering work. On a virtualized x64 system, a guest virtual address must first be resolved through guest page tables, then the resulting guest physical address must be resolved through second-level translation. Correctness depends on preserving which stage failed instead of collapsing every failure into a zero address.

Guest virtual address The address as seen by the process or kernel component being studied. VA

Guest page walk HV2 walks the guest page hierarchy using the target address-space root. VA -> GPA

Large-page handling The translator must handle page-size variation instead of assuming only 4 KB mappings. 4K / 2M / 1G

Nested translation Guest physical memory is translated through the virtualization layer's second-stage mapping. GPA -> HPA

Temporary mapping window HV2 maps bounded pages into a controlled hypervisor-side window for copy operations. copy

Command surface

The legacy surface has six operations; the hard part is their contract.

The names below are publication-safe labels, not source identifiers. A compact operation inventory is easier to audit, but size alone does not make a privileged interface safe: framing, bounds, authorization, and error semantics matter just as much.

INIT_MAP Prepares processor-local temporary mapping state and validates the mapping path.

QUERY_ROOT Returns the current guest address-space root for later translation work.

TRANSLATE_VA Resolves a guest virtual address into a guest physical address under a chosen root.

READ_GPA Copies guest physical memory into a guest-visible destination after both translation stages.

WRITE_GPA Copies from a guest-visible source into guest physical memory; policy bounds must sit above the legacy primitive.

COPY_VA Copies between two virtual address spaces using explicit address-space roots and page-aware chunking.

Trust boundary: the legacy command marker is an identifier, not an authenticator. HV2 currently assumes a single-owner research machine and trusted local callers. A multi-principal or remotely reachable design would need a versioned frame, explicit capabilities, per-session authorization, replay resistance, bounded buffers, and a substantially different threat model.

Core mechanics in pseudocode

The important details are the invariants, not the private implementation.

These examples are implementation-neutral hardening contracts derived from the source audit. Where the legacy path does not yet enforce an invariant consistently, the text says so. Exact instruction sequences, signatures, structure offsets, constants, and deployment details remain private.

Mechanic 01

A compact frame still needs an explicit envelope.

The legacy command union is small, but the current path trusts more caller input than a hardened interface should. Version, frame size, transfer cap, checked arithmetic, and a complete-frame boundary check belong in the contract.

// target contract, not private source
struct CommandFrame {
  version:        ProtocolVersion
  frame_bytes:    BoundedLength
  operation:      Operation
  rights:         CapabilityMask
  source:         AddressDescriptor
  destination:    AddressDescriptor
  transfer_bytes: BoundedLength
  status:         HV2Status
}

// invariants missing from a marker-only protocol
validate(frame):
  require complete_frame_is_mapped(frame)
  require supported(frame.version, frame.operation)
  require frame.transfer_bytes <= policy.max_transfer
  require checked_address_ranges(frame)
  require authorize(frame.rights, frame.operation)

Mechanic 02

VM-exit dispatch must be conservative.

HV2 is not a general replacement for the platform handler. The current implementation correctly forwards unrelated exits. A hardened revision must additionally separate command recognition from authorization and return an explicit error for unsupported operations.

// target control flow, not private source
function on_vmexit(raw_context):
  exit = backend.read_exit(raw_context)

  if not is_recognized_command(exit, raw_context):
    return original_handler(raw_context)

  frame  = backend.read_command_frame(raw_context)
  status = validate_authorize_dispatch(frame)

  backend.write_return(raw_context, status)
  backend.advance_guest_ip(raw_context)

  return resume_guest

Mechanic 03

Processor-local mappings require processor-complete initialization.

The library pins one thread across processor groups so each logical processor installs its own temporary mapping entries. The audit also exposes two hardening needs: affinity must be restored on every failure path, and mapping-slot selection must be validated against modern topology identifiers.

// target user-mode orchestration
function initialize_all_processors():
  original_affinity = current_thread_affinity()

  try:
    for cpu in enumerated_logical_processors():
      require pin_current_thread(cpu)
      require mapping_slot_is_valid(cpu)
      require hv2_call(INIT_MAP) == OK
    return OK
  finally:
    restore_affinity(original_affinity)

Mechanic 04

Guest virtual translation is a page-table walk, not a lookup.

The legacy walker handles standard and large-page paths. The hardened contract must also validate canonical input, presence, reserved-bit constraints, requested permissions, and the physical-width assumptions used to reconstruct each result.

// target page walk, simplified
function translate_guest_virtual(root, va):
  require canonical(va)
  idx = split_virtual_address(va)

  pml4e = read_entry(root, idx.pml4)
  if not pml4e.present: return PML4E_NOT_PRESENT

  pdpte = read_entry(pml4e.page, idx.pdpt)
  if not pdpte.present: return PDPTE_NOT_PRESENT
  if pdpte.large and entry_is_valid(pdpte):
    return pdpte.base + idx.offset_1g

  pde = read_entry(pdpte.page, idx.pd)
  if not pde.present: return PDE_NOT_PRESENT
  if pde.large and entry_is_valid(pde):
    return pde.base + idx.offset_2m

  pte = read_entry(pde.page, idx.pt)
  if not pte.present: return PTE_NOT_PRESENT

  require entry_is_valid_for_access(pte)
  return GPA(pte.base + idx.offset_4k)

Mechanic 05

Guest physical memory still needs nested translation.

In a virtualized system, guest physical is not the final backing address. HV2 resolves the second-stage mapping before creating a temporary hypervisor-side mapping. Each nested level needs the same presence, large-page, physical-width, and permission discipline as the guest walk.

// conceptual nested translation path
function map_guest_physical(gpa, access):
  nroot = backend.read_nested_root()
  hpa   = walk_nested_tables(nroot, gpa)

  if hpa is invalid:
    return INVALID_GUEST_PHYSICAL

  slot = choose_per_core_mapping_slot(access)
  map_slot(slot, hpa.page_base)
  invalidate_local_translation(slot)

  return slot.virtual_base + gpa.page_offset

Mechanic 06

Copies are split across page boundaries.

Real ranges cross page boundaries. The implementation correctly limits each iteration to the remaining bytes in both mapped pages. That does not impose a total request bound; the hardened entry contract must do that before the loop starts.

// target page-safe copy loop
function copy_guest_range(src_root, src_va, dst_root, dst_va, size):
  require size <= policy.max_transfer
  require ranges_do_not_overflow(src_va, dst_va, size)

  while size > 0:
    src_gpa = translate_guest_virtual(src_root, src_va)
    dst_gpa = translate_guest_virtual(dst_root, dst_va)

    src = map_guest_physical(src_gpa, READ)
    dst = map_guest_physical(dst_gpa, WRITE)

    chunk = min(
      bytes_left_in_page(src_va),
      bytes_left_in_page(dst_va),
      size
    )

    copy_bytes(dst, src, chunk)
    src_va += chunk
    dst_va += chunk
    size   -= chunk

  return OK

Mechanic 07

Backend parity should be a contract, not an assumption.

The two legacy backend trees duplicate parts of dispatch and memory logic. Their intended behavior is similar, but duplication allows fixes to land in one path only. A shared semantic test suite is the immediate requirement; a common implementation layer is the longer-term simplification.

// target backend boundary
interface HV2Backend {
  read_exit(context)          -> ExitInfo
  read_guest_root(context)    -> AddressSpaceRoot
  read_guest_ip(context)      -> GuestIP
  read_nested_root(context)   -> NestedRoot
  read_command_frame(context) -> HV2Command
  write_return(context, status)
  advance_guest_ip(context)
}

// shared semantics; private state recovery stays behind the boundary
dispatch(frame, backend):
  return operation_table[frame.op](frame, backend)

Mechanic 08

An error taxonomy is useful only when every path preserves it.

The legacy code defines granular status values, but some translation paths still collapse failure into a zero address or report success around an invalid result. The research interface needs tagged results and consistent propagation across both backends.

// target status taxonomy
enum HV2Status {
  OK,
  PML4E_NOT_PRESENT,
  PDPTE_NOT_PRESENT,
  PDE_NOT_PRESENT,
  PTE_NOT_PRESENT,
  INVALID_GUEST_VIRTUAL,
  INVALID_GUEST_PHYSICAL,
  MAPPING_NOT_INITIALIZED,
  UNSUPPORTED_OPERATION
}

// invariant: fail closed, return evidence
if translation_failed:
  frame.status = precise_failure
  do_not_copy()

Research examples

Examples should explain the method, not leak the implementation.

The following examples are deliberately conceptual. They document the research workflow and threat-model value without publishing code paths that directly reproduce HV2.

Example A

Out-of-band memory forensic check.

A lab tool compares the guest OS view of a process or kernel object against the memory view resolved by HV2. Differences can reveal hiding, unlinking, stale structures, or tampering.

# conceptual request, not implementation code
request = {
  operation: "translate_and_sample",
  address_space: observed_root,
  region: suspect_object_range
}

compare(
  guest_reported_state,
  hv2_observed_state
)

Example B

Cross-address-space memory experiment.

Instead of asking the OS to copy between two processes, HV2 treats each side as an explicit page-table root and performs translation on both source and destination.

# conceptual request, not implementation code
copy = {
  source_root: root_A,
  source_va: range_A,
  dest_root: root_B,
  dest_va: range_B,
  bounds: page_limited
}

Example C

Endpoint visibility validation.

In an authorized lab, researchers can compare whether defensive tools detect memory changes that are visible from below the guest OS boundary.

# conceptual lab protocol
baseline = hv2.snapshot(region)
exercise = authorized_test_event()
after    = hv2.snapshot(region)

report(
  memory_delta,
  defender_observation
)

Example D

Virtualization security research.

HV2 gives researchers a way to study how memory-integrity features, isolated secrets, and virtualization-backed policies change boot timing and page visibility.

# conceptual observation model
for mode in security_modes:
  boot_lab(mode)
  observe(
    initialization_order,
    page_visibility,
    translation_result
  )

Backend split

One command model, two fundamentally different x64 state models.

HV2 contains paths for two major x64 virtualization families. We refer to them as [Architecture-A] and [Architecture-B] to keep the article focused on methodology instead of vendor-specific replication details. They target one semantic command model, but duplicated legacy code means parity must be demonstrated by shared tests rather than inferred from similar function names.

[Architecture-A] backend

State access Guest state is available through hardware-defined control-state reads.

Exit classification The backend reads a structured exit reason and branches only on the HV2 command path.

Resume behavior Guest execution resumes by updating the recorded instruction pointer and returning through the original path.

Primary fragility Release-to-release changes in the platform VM-exit dispatch layout.

[Architecture-B] backend

State access Guest state is recovered through an active control-block model tied to the current virtual CPU.

Exit classification The backend reads an exit code and command registers from the recovered guest context.

Resume behavior Guest execution advances to the next recorded instruction pointer for the intercepted command.

Primary fragility Control-block discovery and pointer-chain drift across target builds.

Cybersecurity research value

HV2 is useful because many modern threats manipulate what the OS can truthfully report.

In defensive research, an independent vantage point matters. HV2 can help compare guest-reported state against memory and translation state observed below the guest OS, inside an authorized lab environment.

01

Differential memory forensics

Acquire the same declared region through an in-guest collector and HV2, attach address-space and translation provenance, then explain each delta. The experiment tests collector trust without assuming every difference is malicious.

02

Endpoint-control validation

Apply a predeclared, authorized memory change in an isolated guest; record the lower-layer delta and the endpoint tool's telemetry. The useful result is a coverage boundary, not a claim that one missed event defeats a product.

03

Rootkit and malware analysis

Compare guest-reported objects, page-table reachability, and physical remnants at controlled checkpoints. HV2 supplies an independent acquisition path; behavioral interpretation still belongs to the analysis workflow.

04

Kernel exploit experiments

Capture before-and-after mappings, target regions, and crash-adjacent state during authorized exploit research. This makes postcondition analysis less dependent on a guest that may already be unstable.

05

Virtualization-policy interaction

Run a controlled matrix of boot policy, memory-integrity, and isolation modes; record activation, visibility, and timing outcomes. The study maps compatibility and trust boundaries without publishing bypass procedures.

Technical findings

The hard part is not a memory copy. It is making the copy correct across boot, cores, paging, and versions.

These findings come from read-only inspection of the legacy implementation and its modernization plan. They are engineering evidence, not a claim that every planned target boots today. No latency, throughput, or long-run stability result is published because the repository does not contain a representative benchmark run.

Finding	Why it matters	Status
Unrelated exits are forwarded	The interposer preserves the platform handler for traffic outside the recognized command path.	Observed in both legacy backends
The operation inventory is compact	Six legacy operations cover mapping setup, root discovery, translation, read, write, and cross-space copy.	Implemented; envelope hardening needed
Translation is explicitly composed	Guest virtual translation and nested guest-physical translation are separate walkers with large-page paths.	Implemented; malformed-entry corpus needed
Copies are page-aware	Each loop iteration is limited by both source and destination page boundaries.	Implemented; total transfer cap needed
Mapping state is processor-local	The client visits logical processors and initializes temporary mapping entries for each execution context.	Implemented; topology and cleanup paths need tests
Status propagation is incomplete	A useful error taxonomy exists, but some paths still collapse translation failure into a zero result or weak success signal.	Source-audit gap
Compatibility assumptions are build-sensitive	Early-boot integration and backend state recovery depend on target layouts that can drift between releases.	Legacy support present; newer targets are roadmap
No performance baseline exists yet	VM-exit overhead, cold/warm translation cost, copy throughput, and long-run stability remain unmeasured.	No benchmark claim

Transferable lessons

Five lessons from HV2 apply to any privileged systems interface.

The project is unusual, but its engineering lessons are not. They apply to debuggers, firmware agents, kernel instrumentation, device-control planes, and other software that executes beneath an ordinary application trust boundary.

01

Pass-through is the default behavior.

An interposer should handle only traffic it can classify and validate. Unknown exits, operations, versions, and states need an explicit path, never an accidental fallthrough.

02

Translation results need provenance.

A final address is not enough. Record the guest root, page size, nested root generation, permissions, and the stage that failed so later analysis can distinguish data from acquisition error.

03

Page boundaries are part of the API contract.

Mapping one page and copying an arbitrary range are different operations. Frame containment, checked range arithmetic, per-page chunking, and a total transfer cap solve different failure classes.

04

Processor-local state makes topology a correctness input.

Initialization, affinity restoration, identifier width, processor groups, and migration behavior need tests on the machines the platform claims to support.

05

Separate implemented, planned, and measured.

Source code can prove that a path exists. It cannot prove current compatibility, acceptable tail latency, or long-run stability. Those require reproducible test artifacts.

Validation matrix

HV2 has to be tested as a platform, not demonstrated as a single trick.

The repository defines a validation direction rather than a completed evidence set. A credible program moves from offline compatibility analysis to boot-chain verification, command correctness, adversarial translation cases, stress testing, and security-feature interaction.

Offline target analysisConfirm that build-specific assumptions are valid before boot testing.

Boot integrationVerify that the early initialization path activates without destabilizing the platform.

Pass-through fidelityCompare unrelated exit behavior before and after interposition, including status and guest-state preservation.

Command-frame negativesExercise unknown versions, unsupported operations, cross-page frames, malformed lengths, and unauthorized rights.

Processor topologyVerify every logical processor gets an independent mapping window and that affinity is restored after injected failures.

Guest page-walk corpusCover canonicality, absent entries, large pages, reserved bits, permissions, and address-width limits.

Nested page-walk corpusRepeat the same adversarial cases for second-stage translation and preserve stage-specific failures.

Page-crossing copiesTest source-only, destination-only, and simultaneous boundary crossings with independent readback.

Range arithmeticReject zero-policy, over-limit, and overflowing ranges before any mapping or copy occurs.

Backend parityRun the same semantic vectors against [Architecture-A] and [Architecture-B].

Stress and migrationRepeat operations under thread migration and parallel guest activity to detect stale mappings or races.

Security-mode matrixRecord activation, visibility, and failure behavior under supported integrity and isolation configurations.

Fault injectionForce mapping, allocation, translation, and backend discovery failures and verify clean status propagation.

Multi-version coverageRepeat compatibility tests across target families to quantify drift.

Benchmark evidencePublish p50/p95/p99 exit overhead, cold/warm translation cost, copy throughput by size, and long-run error rate.

Responsible scope

This article documents research, not deployment.

Low-level hypervisor work is inherently dual-use. We describe the system at a level useful to expert readers while withholding replication details that would turn the article into an operational guide.

No source codeThe implementation remains private.

No byte signaturesBuild-specific identification patterns are omitted.

No offsetsControl-block and structure offsets are intentionally redacted.

No install pathWe do not document deployment or persistence steps.

No bypass procedureSecurity-feature interaction is discussed only at a research level.

HV2 is intended for controlled cybersecurity research, memory-forensics experimentation, platform-security analysis, and defensive tooling validation. It is not being released as an operational tool.

Future outlook

The next milestone is reducing brittleness and adding measurement.

The legacy implementation establishes the mechanism and exposes its assumptions; it does not by itself prove current compatibility or production readiness. The next research phase focuses on runtime discovery, protocol hardening, backend parity tests, safer compatibility handling, and benchmark instrumentation.

Runtime target detection Select compatible assumptions at runtime instead of fragmenting builds whenever possible. portability

Dynamic structure discovery Replace fragile static offsets with validated discovery logic and sanity checks. resilience

Offline compatibility scanner Analyze target binaries before boot testing to shorten the reverse-engineering feedback loop. iteration speed

Benchmark harness Measure VM-exit latency, translation cost, copy throughput, and long-run stability. evidence

Security-mode observability Add structured telemetry for boot timing, memory-integrity behavior, and isolation interactions. security research

Protocol and backend hardening Add a versioned bounded frame, explicit authorization, tagged results, and one semantic conformance suite for both architecture paths. correctness