HV2: Engineering a Boot-Time Hypervisor Research Platform Beneath the Operating System

Executive summary

HV2 turns the virtualization boundary into a controlled 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 Type-1 hypervisor research platform.

HV2 establishes a minimal control plane inside the virtualization path during early boot, then exposes a constrained set of memory and translation primitives to a user-mode research library.

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 handles only its own authenticated research commands and delegates unrelated VM exits back to the platform's original path.

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 proves that the exit is one of its own.

The payload checks the exit class and command marker before doing any research operation. If the exit is unrelated, it is forwarded to the original platform path. This makes the interposition narrow and auditable.

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 control plane is deliberately constrained.

HV2 exposes only the primitives required for research memory operations: initialize mappings, discover address-space root, translate, read, write, and copy.

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.

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

Six primitives are enough to build serious research tooling.

The API is intentionally small. A compact command surface is easier to test, easier to audit, and less likely to become an uncontrolled privileged framework.

init_page_tables Installs per-core mapping state so every logical processor can service requests consistently.

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

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

read_guest_phys Copies guest physical memory into a controlled guest-visible buffer.

write_guest_phys Writes bounded data into guest physical memory through the translation layer.

copy_guest_virt Copies between two virtual address spaces using explicit address-space roots.

Core mechanics in pseudocode

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

These examples are intentionally implementation-neutral. They show the control flow, data model, and correctness rules that make HV2 work, while omitting source-level details such as exact instruction sequences, signatures, structure offsets, or backend-specific constants.

Mechanic 01

The command frame is small, explicit, and bounded.

Every operation is represented as a compact frame. The payload does not accept arbitrary procedures from the guest. It accepts a known operation, typed fields, length bounds, and a return slot.

// conceptual data model, not private source
struct HV2Command {
  op:        Operation
  flags:     AccessMode
  root_src:  AddressSpaceRoot
  root_dst:  AddressSpaceRoot
  src:       GuestAddress
  dst:       GuestAddress
  size:      BoundedLength
  status:    HV2Status
}

// invariant: no unbounded copy, no unknown operation
validate(frame):
  require frame.op in known_operations
  require frame.size <= max_transfer_window
  require aligned_or_page_split(frame)

Mechanic 02

VM-exit dispatch must be conservative.

HV2 is not a general replacement for the platform handler. The interposer only handles exits that match the HV2 command contract. Everything else is forwarded unchanged.

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

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

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

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

  return resume_guest

Mechanic 03

Per-core initialization prevents inconsistent mappings.

A single successful initialization is not enough. The user-mode library pins execution across processor groups and logical processors so each core can install its own mapping state.

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

  for group in processor_groups():
    for cpu in processors(group):
      pin_current_thread(group, cpu)

      status = hv2_call({
        op: INIT_PAGE_TABLES
      })

      if status != OK:
        restore_affinity(original_affinity)
        return status

  restore_affinity(original_affinity)
  return OK

Mechanic 04

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

HV2 has to read each paging level, validate presence, detect large pages, and preserve the correct offset. This is the difference between a reliable translator and a demo that works only on easy addresses.

// conceptual page walk, simplified
function translate_guest_virtual(root, 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:
    return pdpte.base + idx.offset_1g

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

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

  return pte.base + idx.offset_4k

Mechanic 05

Guest physical memory still needs nested translation.

In a virtualized system, guest physical is not necessarily the final backing address. HV2 resolves the second-stage mapping before it creates a temporary hypervisor-side mapping window.

// 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 memory ranges rarely stay inside one page. HV2 copies the largest safe chunk that fits both source and destination pages, then repeats until the bounded transfer is complete.

// conceptual bounded copy loop
function copy_guest_range(src_root, src_va, dst_root, 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

The backend is a contract, not duplicated research logic.

The two architecture backends differ in how they recover guest state. Above that layer, the translation and command-dispatch model can stay largely shared.

// conceptual backend abstraction
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 layer never needs private backend offsets
dispatch(frame, backend):
  return operation_table[frame.op](frame, backend)

Mechanic 08

Error codes are part of the research interface.

Precise errors matter. A failed translation, invalid guest page, missing nested entry, or uninitialized per-core mapping should be distinguishable in the lab output.

// conceptual 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 supports 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.

[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

Memory forensics

Acquire and compare memory state without relying only on in-guest APIs, handles, or potentially tampered kernel lists.

02

Rootkit research

Study discrepancies between what the OS reports and what page tables, physical pages, and object remnants reveal.

03

Malware analysis

Observe evasive behavior from outside the normal user-mode and kernel-mode instrumentation layers in a contained lab.

04

EDR validation

Measure whether endpoint tools detect memory deltas, hidden regions, suspicious mappings, or unusual cross-space behavior.

05

Kernel exploit research

Study memory side effects of authorized exploit experiments without depending exclusively on the compromised guest view.

06

Integrity monitoring

Build baselines for sensitive regions and compare them against later snapshots from below the OS trust boundary.

07

Anti-tamper evaluation

Evaluate how protected software behaves when observed from a lower instrumentation layer than it expects.

08

Virtualization-backed security research

Analyze how memory integrity, credential isolation, and secure-kernel designs affect visibility, timing, and mapping rules.

09

Incident-response tooling

Prototype out-of-band acquisition models for systems where in-guest collectors may be unreliable or already subverted.

10

Hypervisor education

Teach VM exits, guest state recovery, nested translation, and per-core mapping through a real private research platform.

11

Policy interaction studies

Test how boot policy, memory integrity, and virtualization isolation change what can be observed and when.

12

Defensive architecture review

Reason about which security guarantees depend on the guest kernel and which depend on the lower virtualization layer.

Technical findings

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

The local project artifacts show an architecture-first research effort: existing legacy build modeling, two backend families, a compact command surface, and a structured validation plan. We do not claim performance numbers until the benchmark harness is built.

Finding	Why it matters	Status
10 legacy target configurations modeled	Version drift is treated as a first-class engineering problem, not an afterthought.	Existing build metadata
4 newer target families planned	The modernization roadmap prioritizes compatibility before broader research claims.	Research plan
2 architecture backends	The same command model can sit above two different x64 virtualization state models.	Implemented paths present
6 primitive operations	The API is small enough to audit but powerful enough for memory-forensics experiments.	Documented surface
Per-core initialization	Host/root paging behavior can differ per logical processor, so mapping state must be initialized across cores.	Required by design
15 validation lanes	The project validates boot activation, payload reachability, VM-exit interception, hypercalls, stress behavior, and security-mode interaction.	Defined matrix

Validation matrix

HV2 is tested as a platform, not as a single trick.

The planned validation flow moves from offline compatibility analysis to VM boot-chain verification, hypercall correctness, 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.

Loader-stage observationConfirm the payload preparation point is reached and produces expected telemetry.

Payload activationProve the private hypervisor payload is mapped, initialized, and reachable.

VM-exit interpositionConfirm controlled exits reach HV2 while unrelated exits are preserved.

Initialization commandSet up per-core mapping state and return precise error codes on failure.

Physical readRead known guest physical regions and compare against expected bytes.

Physical writeWrite bounded data and verify via independent readback in a lab environment.

Virtual copyCopy between address spaces using explicit roots and page-boundary handling.

Virtual translationResolve known virtual addresses to physical addresses across page sizes.

Stress loopRepeat operations to detect instability, leaks, corrupt mappings, or race conditions.

Memory integrity modeStudy whether integrity policies alter boot timing, visibility, or payload assumptions.

Credential isolation modeEvaluate how isolated secrets and secure-kernel designs affect research visibility.

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

End-to-end packagingVerify that the lab workflow can be reproduced internally without manual one-off steps.

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 current design proves the architecture. The next research phase focuses on runtime discovery, automation, 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

Safer payload strategy Study less brittle ways to maintain visibility while respecting modern integrity constraints. hardening