Re Hypervisor

虚拟化逆向（VT-x / SVM / 分区 hypervisor）

<CORE RULE>
本域有两条互不相同的分析轴，先分清在哪一条上：

• 轴 A：分析 hypervisor 本身（VT-x/SVM 指令、VMCS/VMCB、EPT/NPT）→ 本主文档
• 轴 B：目标处在某种虚拟化之下，判断"看到的地址/设备/中断是不是虚拟化层造出来的"→ 见 [[xen]] / [[qnx-hypervisor]] / [[jailhouse]] / [[acrn]] / [[bao]]

轴 B 的共同坑是把本地句柄当全局标识、把虚拟地址当物理地址：

grant ref 是 grant table 的条目索引      ≠ 物理地址
event-channel port 是通知端口           ≠ IRQ 号
guest BAR / GPA                         ≠ 物理 BAR / HPA
shmem_id 才是共享对象 identity          ≠ 两个 VM 里的映射地址

</CORE RULE>

何时使用 / 何时不用

• 前置：先判是哪一类虚拟化（宿主厂商串 / 配置格式 / 结构性证据）→ [[re-analyze/system-fingerprints]] 的 Hypervisor 段
• 用：目标是 hypervisor / VMM 二进制或驱动（恶意 hypervisor、rootkit 虚拟化、VM-based 保护）
• 用：样本/程序检测自己是否运行在虚拟机或嵌套虚拟化中（CPUID 指纹、时序检测）
• 用：分析 VT-x（VMX）或 SVM 相关的启动代码、VMCS/VMCB 布局、EPT 相关操作
• 用：目标跑在分区/嵌入式 hypervisor 之下——PV 设备、静态分区、vdev、跨 VM 共享内存与虚拟中断（见下方分支）
• 不用：普通 Windows 驱动/rootkit（走 [[re-kernel]]）；只要识别"我在不在 VM 里"（快速判断走 [[re-triage]] 思路或 virt-what）
• 不用：无 CPU 虚拟化支持 / 无嵌套虚拟化环境时的动态验证（静态分析先行，见坑 1）
• 注意：动态实验（QEMU/KVM 嵌套）按 [[re-analyze/platform-tips]] 最高原则在沙箱内进行；hypervisor 样本具有高特权，只在与宿主隔离的实验环境运行

工具准备

静态分析（CPUID 检查 / 反编译）免沙箱；QEMU/KVM 动态实验属动态执行，默认沙箱 + 快照（[[re-analyze/platform-tips]] 最高原则）。

CPUID 检查工具（hypervisor 识别）

• Linux 内置：grep -E 'vmx|svm' /proc/cpuinfo——VT-x/SVM 支持标志（零安装，先用它）
• cpuid 工具（dump 各 CPUID 叶子的完整输出）：
  • Debian/Ubuntu: apt install cpuid；Fedora: dnf install cpuid
  • Arch 无独立 cpuid 包 → 用 kcpuid（pacman -S kcpuid，linux-tools 组）或 libcpuid 附带的 cpuid_tool（pacman -S libcpuid）
  • 验证: cpuid -1 输出含各叶子详情；cpuid -1 -l 0x40000000（hypervisor 厂商字符串叶子）
• Windows 侧：WinDbg 内核调试下 !cpuid（[[re-windbg]] 扩展命令）

QEMU / KVM —— 嵌套虚拟化实验环境

• Debian/Ubuntu: apt install qemu-system-x86（Debian 12+ 已移除 qemu-kvm 过渡包，直接装 qemu-system-x86 即含 qemu-system-x86_64；Ubuntu 的 qemu-kvm 过渡包仍存在，装了等价于 qemu-system-x86；Ubuntu 另加 libvirt-daemon-system）
• Fedora: dnf install qemu-system-x86-core libvirt virt-install（或 dnf group install virtualization）
• Arch: pacman -S qemu-system-x86 libvirt virt-manager（启用 systemctl enable --now libvirtd）
• macOS: brew install qemu（无 KVM，用 HVF）
• 验证: qemu-system-x86_64 --version；ls /dev/kvm（KVM 加速可用）；kvm-ok（Debian/Ubuntu 专用，来自 cpu-checker 包——先 apt install cpu-checker）

反编译工作台（[[re-ghidra]] / [[re-ida]]）

• [[re-ghidra]]（默认）/ [[re-ida]]：导入 hypervisor 二进制（内核模块 / 裸二进制）
• 验证: 导入后能反编译出 VMXON / VMPTRLD / VMREAD / VMWRITE 调用点

Intel SDM / AMD APM（VMCS 字段编码参考，无安装）

• Intel SDM Volume 3C 附录 B（VMCS field encoding 表）；AMD APM Volume 2（VMCB 布局）
• 用途: VMREAD/VMWRITE 操作数解码、exit reason 编号对照（无独立包，官方文档）

操作步骤

按顺序执行，每步产物（CPUID 输出、VMCS 字段表、QEMU 配置）记录证据路径 + sha256（见 [[re-triage]]），供报告引用。

1. hypervisor 识别（CPUID 叶子 / VMX 标志）：

   grep -E 'vmx|svm' /proc/cpuinfo | head -1        # 宿主 CPU 虚拟化支持
   cpuid -1 -l 0x1 | grep -i -A1 'hypervisor'        # CPUID.1:ECX[31] hypervisor present bit
   cpuid -1 -l 0x40000000                            # 0x40000000 叶子的 hypervisor 厂商字符串
   #   "KVMKVMKVM" = KVM、"Microsoft Hv" = Hyper-V、"VMwareVMware" = VMware、"XenVMMXenVMM" = Xen

   • 检测要点：hypervisor present bit（CPUID.1:ECX[31]）→ 有 hypervisor；0x40000000 返回厂商字符串（12 字符按序分布在 EBX:ECX:EDX 各 4 字节，EAX 返回最大 hypervisor 叶子号）
   • 恶意样本常在启动早期做此检测决定后续行为（[[re-evasion]] 联动，见坑 5）
   • 记录：宿主支持情况（vmx/svm）、是否已在 VM 内（含嵌套，坑 4）

2. VMCS 结构分析（VT-x）：

   • 启动路径：VMXON（进入 VMX 操作模式）→ VMPTRLD（加载当前 VMCS）→ 配置 VMCS 字段 → VMLAUNCH/VMRESUME（进 guest）→ VM exit 后查 VM_EXIT_REASON 字段分派
   • 反编译定位：搜 VMXON/VMPTRLD/VMWRITE/VMREAD/VMLAUNCH 指令（Ghidra 反汇编直接可读）；VMCS 区域是内存块，先找 VMCS 缓冲区分配与初始化代码
   • VMREAD/VMWRITE 的操作数是 VMCS 字段编码（32 位，Intel SDM 附录 B 表 B-1~B-4）：bit0 = 访问类型（0=full field、1=high 32 bits）；索引在 bits 9:1（9 位，不是 bits 9:0）；类型在 bits 11:10（00=control、01=read-only、10=guest-state、11=host-state）；宽度在 bits 14:13（00=16 位、01=64 位、10=32 位、11=natural）；bit 12 与 bits 31:15 保留（必须为 0）。解码示例：0x400C=VM-exit controls（32 位，bits 14:13=10）、0x2000=I/O bitmap A（64 位，bits 14:13=01）、0x681E=GUEST_RIP（natural，bits 14:13=11）、0x681C=GUEST_RSP（natural）、0x4402=VM-exit reason（32 位 read-only）——即 access=enc&1; index=(enc>>1)&0x1ff; type=(enc>>10)&3; width=(enc>>13)&3，在 Ghidra/IDA 里建枚举/结构标注
   • 关注三块：guest-state（保存 guest 寄存器/CR3/RSP）、host-state（VM exit 后宿主现场）、control 字段（execution control 决定哪些事件触发 VM exit）
   • SVM 对应：VMCB（物理地址经 VM_HSAVE_PA MSR），字段是固定偏移——按 AMD APM 布局标注
   • 产物：VMCS 字段标注表（编码 → 字段名 → 作用）+ 初始化/exit 处理流程

3. 虚拟化技术检测对抗（EPT 隐藏内存）：

   • EPT（Extended Page Tables）：guest 物理地址 → 宿主物理地址的第二层页表（VMM 控制）；恶意 hypervisor 可用 EPT 把同一 guest 页映射到不同宿主页、或在 EPT 层面修改页内容而 guest 页表看起来不变
   • 分析思路：反编译里找 EPT 相关操作——INVEPT/INVVPID（TLB 失效）使用点、EPT 指针字段（VMCS EPTP）赋值、EPT 页表构建函数（从 EPT 指针沿页表结构走）
   • 检测对抗的观察法：guest 内看到的内存内容与宿主侧直接读同一物理页不一致 → EPT 重映射证据（两个视图对照）；[[re-kernel]] 内核调试配合在宿主与 guest 两侧各 dump 同一页
   • EPT Hook 双视图机制（无痕 hook 核心）：同一 GPA 准备两个 HPA——原始页（RW/NX）与影子页（X-only 或补丁代码）——数据访问映射原始页、指令取指映射影子页；CPU 取指触发 Execute Violation（VM-exit reason 48）后在 VM-exit 里切影子页并 INVEPT 失效缓存；扫描器/CRC 读地址得到干净字节，执行却是补丁代码（读侧无痕）
   • EPT 无痕 INT3：只在影子页放 0xCC，原始数据页不变——读内存看到原指令、取指却断下；VMCS Exception Bitmap 拦截向量 3 后匹配地址用 guest_rip - 1（一字节 INT3 的 RIP 在断点字节之后）；处理完单步恢复再重新布断点；非本框架的 #BP 必须 reinject 回 guest（不能吞其他调试器/系统断点）
   • MTF（Monitor Trap Flag）解决"读执行同页"：影子页指令若读取同页常量（取指要影子页、数据要原始页冲突）→ 临时放开原始页执行并置 MTF，CPU 单步执行一条指令后在 MTF VM-exit 里收紧权限；MTF 是 VM-execution control，不动 guest RFLAGS.TF、不占 DR0-DR7
   • EPT 监视 = 模拟无限硬件断点：DR0-DR3 仅 4 槽，EPT 监视撤销目标页 R/W/X 权限让匹配访问 VM-exit，数量仅受内存/性能限制；硬件断点类需求（含与传统调试器互通，如 hook SetThreadContext 探测是否下硬件断点再转发到 EPT 监视）用这套替代
   • VMCALL 无痕通信：guest 执行 VMCALL 产生 VM-exit reason 18（不调用 guest 内任何地址），RAX 放协议标识、RCX 放操作号、其余寄存器传参，是 hypervisor 与 guest 的私有通信通道
   • 产物：EPT 构建/切换代码路径 + 内存视图差异证据

4. 嵌套虚拟化（VMM 内调试）：

   # KVM 开启嵌套（宿主）——module_param 权限为 0444，sysfs 只读，echo 写入会失败
   sudo modprobe -r kvm_intel && sudo modprobe kvm_intel nested=1    # Intel（AMD 用 kvm_amd nested=1）
   # 持久化：/etc/modprobe.d/kvm.conf 写 `options kvm_intel nested=1`（重启后仍生效）
   cat /sys/module/kvm_intel/parameters/nested                       # 验证（Y/1 为已开启）
   # QEMU 启动带 VT-x 透传的嵌套 VM（`-cpu host` 暴露 vmx 标志）
   qemu-system-x86_64 -enable-kvm -cpu host,+vmx -m 4096 disk.img &
   # 嵌套 VM 内再验证: grep vmx /proc/cpuinfo 可见 → 可在此跑 hypervisor 样本

   • 用法：宿主上的调试器（gdb/lldb 或 [[re-windbg]] 内核调试）直接观察嵌套 VM 内 hypervisor 的执行——样本以为自己在最底层，实际仍在宿主调试视野内
   • VMware/Hyper-V 同理（虚拟机设置里开"虚拟化引擎/嵌套虚拟化"）
   • 产物：嵌套配置存档 + 调试会话记录

5. 反虚拟化绕过（[[re-evasion]] 联动）：

   • 识别检测手段：CPUID 厂商字符串（步骤 1）、时序（RDTSC 指令耗时）、设备名（VM 虚拟设备）、固件/ACPI 特征
   • 按 [[re-evasion]] 的"规避识别→绕过点定位"框架：hook CPUID（cpuid 是指令而非导出符号，findExportByName 拿不到——改 hook libc 导出函数 __get_cpuid/__get_cpuid_max 改返回值，或 Stalker 指令级追踪拦截 cpuid 指令；内核侧 hook/patch 指令）、QEMU -cpu 参数伪造厂商字符串、设备名改名
   • 恶意样本"检测到 VM 就改变行为"（不执行恶意逻辑）也是常见对抗——记录检测点与分支
   • 产物：检测点清单 + 绕过方案（授权研究场景）