CPUID指令检测是最轻量通用的虚拟机识别方式，通过查询0x40000000等扩展叶子及厂商签名字符串实现，需先验证CPUID支持；辅以DMI厂商字段和/sys/hypervisor等系统级路径可提升准确率。
检测 CPUID 指令返回值识别常见虚拟化平台
直接执行 cpuid 指令并检查特定叶子节点的返回值，是 C++ 中最轻量、最通用的虚拟机检测方式。现代虚拟化软件（如 VMware、VirtualBox、KVM、Hyper-V）通常会在 cpuid 的某些功能位中暴露自身标识，且该方法无需管理员权限，也不依赖外部库。
关键操作是调用 __cpuid（MSVC）或内联汇编（GCC/Clang），查询 0x80000001 或 0x40000000 等扩展叶子：
-
0x40000000是 Hyper-V 和 KVM 的“Hypervisor CPUID leaf”，若eax返回值 >0x40000000，基本可确认运行在 hypervisor 上 - VMware 会在
0x80000001的ecx[31:16]写入签名字符串 “VMwareVMware” 的部分哈希，配合字符串比对更可靠 - VirtualBox 在
0x80000002–0x80000004返回 “VirtualBox” 字符串（需拼接 eax/ebx/ecx/edx）
注意：启用 CPUID 检测前应先确认处理器支持该指令（通过 __cpuid(0, &info[0], &info[1], &info[2], &info[3]) 判断 eax 是否非零），否则会触发非法指令异常。
读取 /sys/hypervisor/type（Linux）或注册表键（Windows）
操作系统级路径更稳定，但受限于平台和权限。Linux 下可直接 open /sys/hypervisor/type 并读取内容，常见值包括 kvm、xen、vmware；若文件不存在或读取失败，不表示非虚拟机（例如某些容器或精简镜像可能不暴露该接口）。
立即学习“C++免费学习笔记（深入）”；
Windows 下检查注册表路径 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters，存在且 HostName 或 VirtualMachineID 非空，大概率是 Hyper-V；VMware 则常在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmhgfs 或 VMTools 键下留有痕迹。
- Linux 方式需包含
<fcntl.h>和<unistd.h>，用open()+read()，避免用fstream（可能因 noexec 或挂载选项失败） - Windows 注册表访问需链接
Advapi32.lib，用RegOpenKeyExW，注意宽字符和权限——普通用户可读大部分虚拟机相关键，但某些安全加固环境会禁用 - 两者都可能被 rootkit 或 hypervisor 隐藏（如某些云厂商屏蔽
/sys/hypervisor），不能作为唯一依据
检查 DMI/SMBIOS 信息中的系统制造商字段
很多虚拟机在 BIOS 层伪造 DMI 表，把 System Manufacturer 设为 “VMware, Inc.”、“innotek GmbH”（旧版 VirtualBox）、“QEMU” 或 “Microsoft Corporation”。C++ 可通过 mmap /dev/mem（需 root）或调用 dmidecode 命令解析输出（较慢但无需特权）获取。
更实用的做法是用 libudev（Linux）或 WMI（Windows）间接读取：
- Linux：
udev_device_get_property_value(dev, "ID_VENDOR_FROM_DATABASE")可能返回 “QEMU” - Windows：WQL 查询
SELECT Manufacturer FROM Win32_ComputerSystem，返回值含 “VMware” 或 “VirtualBox” 即高概率命中 - 注意：部分物理服务器（如 Dell、HP）也使用 “QEMU” 作为固件测试标识；而某些云实例（如 AWS EC2）制造商为 “Amazon EC2”，需单独建白名单，不能仅靠“非物理厂商”判断
避免误报：时间戳计数器（TSC）漂移与 I/O 端口探测
单纯依赖单一特征极易误判。比如 TSC 不稳定（RDTSC 两次差值异常大）曾是 Xen 的标志，但现代 KVM 和 Windows Hyper-V 已启用 TSC 虚拟化，该指标失效；又如向 0x5658（VMware 后门端口）发 inb 指令，虽能触发响应，但在未启用 VMware Tools 或开启 I/O port 白名单时会直接 crash 进程（SIGSEGV）。
- 禁止在生产代码中无条件执行
inb(0x5658)或类似特权指令——它需要 ring 0 权限，普通用户态程序会段错误 - 不要把 “无法访问 /sys/hypervisor” 当作物理机证据：systemd-nspawn、podman 容器、WSL2 都不提供该路径，但显然不是裸金属
- 真实场景建议组合判断：CPUID + DMI 厂商 + /sys/hypervisor 存在性，三者中满足两个即可信度 >90%；单一信号只用于快速排除
虚拟化检测本身在反作弊、DRM、性能调优等场景有用，但越底层的检测越容易被 hypervisor 主动欺骗——比如 KVM 的 kvm.ignore_msrs=1 或 Hyper-V 的 “enlightened” 模式，会让多数传统指纹失效。真要强保障，得结合行为分析（如中断延迟分布、内存页共享痕迹），那已超出 C++ 标准库能力范围了。
