单靠CPUID指令无法可靠判断是否在虚拟机或沙箱中运行，必须交叉验证CPUID扩展叶子0x40000000的vendor ID、DMI/SMBIOS厂商字符串、虚拟设备ID及WMI/注册表等多信号，否则在AWS Nitro、Azure Gen2、GCP Shielded VM等现代云环境中易被隐藏或伪造而误判。
单靠 CPUID 指令无法可靠判断是否在虚拟机或沙箱中运行，必须交叉验证多个信号，否则在 AWS Nitro、Azure Gen2、GCP Shielded VM 等现代云环境中大概率误判。
为什么 __cpuid(1, cpuInfo) 的 ECX[31] 位不能信
这个位（hypervisor present bit）由 VMM 控制，不是硬件强制暴露的。它只表示“VMM 选择告诉你它在那儿”，而非“它一定在那儿”。
常见错误现象：ECX & (1 返回 0，就认为是物理机——结果在 EC2 c6i 或 Azure Dv5 实例上直接翻车。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须先调用
__cpuid(0, cpuInfo)确认 CPUID 基础功能可用，否则老 CPU 会触发 #UD 异常 - 不要仅依赖 EAX=1；要继续查扩展叶子
0x40000000：若 EAX 返回 0，说明无 VMM 扩展支持，才更倾向物理机（仍不绝对） - 即使
0x40000000有响应，真正关键的是 EBX/ECX/EDX 拼出的 vendor ID 字符串，比如"KVMKVMKVM"或"Microsoft Hv"，而不是存在本身
怎么安全读取 0x40000000 叶子的 vendor ID
这是目前最轻量、用户态可用、且几乎无误报的检测点。物理 CPU 绝不会返回这些字符串，只要拿到就基本可断定是虚拟化环境。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用编译器内建函数，别手写内联汇编：
__cpuid(cpuInfo, 0x40000000)（MSVC）或__get_cpuid(0x40000000, &eax, &ebx, &ecx, &edx)（GCC/Clang） - 检查
cpuInfo[0]（EAX）是否 ≥0x40000001，否则后续读 vendor ID 无效 - 把
cpuInfo[1]（EBX）、cpuInfo[2]（ECX）、cpuInfo[3]（EDX）按小端顺序拼成 12 字节字符串（注意字节序，EBX 是低 4 字节），再 memcmp 判定，例如：memcmp(vendor_str, "VMwareVMware", 12) == 0 - 避免用
std::string构造临时对象做比较——某些沙箱会 hook 字符串构造函数
Linux 下 DMI 信息怎么读才不被权限卡住
/sys/class/dmi/id/product_name 和 /sys/class/dmi/id/sys_vendor 是辅助验证的关键路径，但普通用户读取时容易踩坑。
常见错误现象：代码直接 open /sys/firmware/dmi/tables/ 失败，却没 fallback 到已开放的 /sys/class/dmi/id/ 路径；或读到空值就放弃，其实可能是 Shielded VM 主动清空了字段。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先读
/sys/class/dmi/id/product_name和/sys/class/dmi/id/sys_vendor，这两个路径在绝大多数发行版中无需 root - 若读到空或通用值（如
"Google"而非"Google Compute Engine"），不要立即否定，应结合CPUID结果做加权判断 - 避免用
system("dmidecode -s system-product-name")：该命令需 root，且可能被容器或沙箱禁用 - 可补充检查
/proc/cpuinfo中的hypervisorflag（仅 KVM/QEMU 透传时存在），但它不可靠，因为多数云平台根本不会透传这一项
Windows 上 WMI 失效时的注册表 fallback
WMI 查询 Win32_ComputerSystem 是常用手段，但企业环境常禁用 WMI 服务或限制权限，导致 Get-WmiObject 报 Access denied 或返回空。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先尝试 WMI：
SELECT Manufacturer, Model FROM Win32_ComputerSystem，超时或异常后立刻 fallback - 注册表路径
HKEY_LOCAL_MACHINE\SYSTEM\HardwareConfig\Current下的SystemBiosVersion值更稳定，含"VMware"、"VirtualBox"等字样概率高 - 不要查
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System下的SystemManufacturer——该值在 Windows 10/11 中常被设为"Microsoft Corporation"，无论是否 Hyper-V - 注意：注册表读取需用
RegOpenKeyEx+RegQueryValueEx，避免用_wgetenv等不安全方式
真正难的不是拿到某个特征，而是当 CPUID 显示无 hypervisor、DMI 返回空、WMI 被禁、注册表无痕迹时，你得意识到——这很可能是 AWS Nitro 或 Azure Confidential Computing 这类主动隐藏全部虚拟化痕迹的环境，此时任何单一检测都会失效，只能靠行为侧信（如内存延迟突变、RDTSC 不单调）或放弃检测。
