第一次尝试恶意代码分析就遇到了虚拟机检测，于是就想着先学习一下检测的技术然后再尝试绕过。学习后最终发现，似乎最好的方法不应该是去patch所有检测方法，而是直接调试并定位检测函数再绕过。但既然已经研究了两天，索性将收集到的资料整理一下，方便后人查找。

1. 基于特征的检测

1.1 文件以及目录

相关 API ：GetFileAttributes、etModuleHandle
通常，各种 hypervisor 会在虚拟机上安装驱动程序和其他软件，以使客户机能够利用 hypervisor 提供的功能。恶意软件可以搜索这些文件、目录或进程的存在。VMware 虚拟机中可能会有如下的文件列表：

1.2 Devices

相关API：CreateFile
在Windows虚拟机中，虚拟机通常拥有独特命名的 “devices”。

• \\.\HGFS，主机和虚拟机之间共享的文件系统
• \\.\vmci，虚拟机和主机之间的通信管道

1.3 MAC 地址

相关API：GetAdaptersAddresses、GetAdaptersInfo、Netbios
Hypervisors 通常为虚拟机提供虚拟化的网卡(NICs)，具有独占于hypervisor供应商的MAC地址。
已知的 VMware 虚拟机的 MAC地址有：

• 00:50:56:XX:XX:XX
• 00:1C:14:XX:XX:XX
• 00:0C:29:XX:XX:XX
• 00:05:69:XX:XX:XX

1.4 BIOS 字符串

相关API：RegOpenKeyEx、RegQueryValueEx
虚拟化产品通常会附带一个基本输入/输出系统（BIOS），其中包含虚拟机特有的字符串。可以通过检查Windows注册表来查看。

• HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System 中键值 “SystemBiosVersion” 包含 “VMware, Inc.”
• HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS 中包含键值
  • “BIOSVendor” 为 “VMware, Inc.”
  • “BIOSVersion” 的起始字符串为 “VM.”
  • “SystemManufacturer” 为 “VMware, Inc.”
  • “SystemProductName” 包含 “VMware.”
• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SystemInformation 中也有类似的信息

1.5 其他 Windows 注册表项

VMware中，以下注册表项会带有 “VMWARE” 或者 “VM” 字符串

1.6 SMBIOS 字符串

相关API：GetSystemFirmwareTable
System Management BIOS 是由BIOS读取的一组数据结构。虚拟机会带有有特殊的字符串。VMware 虚拟机会带有 “VMware”。

1.7 ACPI 字符串

相关API：GetSystemFirmwareTable
Advanced Configuration and Power Interface (ACPI) 是操作系统通过 BIOS 或 UEFI 与各种硬件组件进行通信的接口。VMware 虚拟机会带有 “VMware”。

1.8 进程

相关API：CreateToolhelp32Snapshot、Process32First、Process32Next
一些虚拟机利会有特殊的后台进程。这些进程主要提供一些方便的功能，例如自动配置屏幕分辨率和配置网络设置等。
VMware虚拟机中可能会有以下进程：

• Vmtoolsd.exe
• Vmwaretray.exe
• Vmwareuser.exe
• VGAuthService.exe
• Vmacthlp.exec

有些恶意软件还会通过进程数来检测虚拟环境，比如 ”EvilBunny“ 会检测是否存在至少15个进程。

1.9 硬盘硬件ID以及名称

相关API：SetupDiGetClassDevs、SetupDiGetDeviceRegistryProperty
Win32/Winwebsec的一些变种使用了一种通过 Setup API来检查硬盘设备名的方法。类似的也可以检测硬盘硬件ID。

1.10 通过 WMI 获取硬件信息

Windows Management Instrumentation（WMI），提供了一种标准化的接口，允许程序获取系统信息并执行管理任务。WMI是基于COM（Component Object Model）技术构建的，并使用WQL（WMI查询语言）来查询数据。

• 可以通过 WMI 获取 BIOS 序列号并查看是否带有类似“VMWARE”的字符串。类似的还可以检测 Win32_ComputerSystem 下的 Model 以及 Manufacturer 字段。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

  VOID CheckBIOSSerialNumberWMI() {   IWbemServices* pSvc = NULL;   IWbemLocator* pLoc = NULL;   IEnumWbemClassObject* pEnumerator = NULL;   BOOL bFound = FALSE;   HRESULT hRes;     // Init WMI   if (!InitWMI(&pSvc, &pLoc, _T("ROOT\\CIMV2")))       return;     // If success, execute the desired query   if (!ExecWMIQuery(&pSvc, &pLoc, &pEnumerator, _T("SELECT * FROM Win32_BIOS")))       return;     // Get the data from the query   IWbemClassObject* pclsObj = NULL;   ULONG uReturn = 0;   VARIANT vtProp;     while (pEnumerator)   {       hRes = pEnumerator->Next(WBEM_INFINITE, 1, &pclsObj, &uReturn);       if (0 == uReturn)           break;         // Get the value of the Name property       VariantInit(&vtProp);       hRes = pclsObj->Get(_T("SerialNumber"), 0, &vtProp, 0, 0);       if (SUCCEEDED(hRes)) {           if (vtProp.vt == VT_BSTR) {               if (StrStrI(vtProp.bstrVal, _T("VMWare")) != 0)               {                   bFound = TRUE;                   VariantClear(&vtProp);                   pclsObj->Release();                   break;               }           }           VariantClear(&vtProp);       }         // release the current result object       pclsObj->Release();   }     // Cleanup   pSvc->Release();   pLoc->Release();   pEnumerator->Release();   CoUninitialize();     PrintResult(bFound, _T("Checking SerialNumber from BIOS using WMI")); }

• 可以通过返回结果的条目数，检查是否存在一些物理机应该有的硬件，比如：

  1 2 3 4 5 6 7 8 9

  SELECT * FROM Win32_Fan // 风扇 SELECT * FROM Win32_CacheMemory // SELECT * FROM Win32_VoltageProbe // 电压探针 SELECT * FROM Win32_PerfFormattedData_Counters_ThermalZoneInformation // 热区信息 SELECT * FROM CIM_Memory // 物理内存 SELECT * FROM CIM_Sensor // 传感器设备 SELECT * FROM CIM_NumericSensor // 数字传感器 SELECT * FROM CIM_TemperatureSensor // 温度传感器 SELECT * FROM CIM_VoltageSensor // 电压传感器

2. 基于指令的检测

某些CPU指令在虚拟机中执行时返回值与在物理机机上执行时返回值不同。恶意软件可以执行这些指令，并尝试根据返回值推断虚拟机的存在。虽然这些检测方法不普遍适用于所有虚拟机，且随着虚拟机的迭代也已经部分失效，但仍然有必要了解。下面列出已知的用于虚拟机检测的指令。

2.1 IN

IN指令从指定的I/O端口读取值到指定的内存地址。I/O端口是操作系统和I/O设备（如磁盘控制器和声音设备）之间的通信手段。基于VMware的虚拟机具有端口号为 0x5658 的I/O设备，允许hypervisor 和虚拟机之间通信。通常，在非特权用户模式下运行IN指令将触发特权指令异常。但在 VMware 中，不会引发此类异常。VMware 公司甚至将此作为官方检测 VMware hypervisor 的手段。VMware 也提供了一个接口，允许用户“关闭”此方法。

2.2 CPUID

CPUID是一种x86指令，用来获取CPU的各种信息。该指令通过输入 EAX 中的值来确定要在EAX，EBX，ECX和EDX寄存器中返回的信息。下面给出三种基于 CPUID 指令的检测方法。

1. 当 EAX=0 时， CPUID 将按EBX，EDX和ECX寄存器的顺序返回一个12个字符的制造商ID字符串。Intel CPU返回“GenuineIntel”，而AMD CPU在K5型号之后返回“AuthenticAMD” 。当在虚拟机中运行时，ID将被专属于某些虚拟机的自定义字符串替换。VMware虚拟机中理论上将返回 “VmwareVmware”。

   1 2 3 4 5 6 7 8 9 10 11 12 13

   BOOL CheckCPUIDVendor() {  INT CPUInfo[4] = { -1 };  CHAR szHypervisorVendor[0x40];    __cpuid(CPUInfo, 0x40000000);  SecureZeroMemory(szHypervisorVendor, sizeof(szHypervisorVendor));  memcpy(szHypervisorVendor, CPUInfo + 1, 12);    if (_strcmpi(szHypervisorVendor, "VMwareVMware") == 0)      return TRUE;      return FALSE; }

2. 当 EAX=1 时，CPUID将返回有关处理器功能的信息，例如处理器支持的指令。返回值 ECX 中的第 31 位确定是否存在 hypervisor。在物理机中此值为 0，在虚拟机中为 1。

   1 2 3 4 5 6 7 8 9 10

   BOOL CheckCPUIDVendor() {  INT CPUInfo[4] = { -1 };    __cpuid(CPUInfo, 1);    if ((CPUInfo[2] >> 31 ) & 1)      return TRUE;      return FALSE; }

3. 在虚拟机中执行 CPUID 还会触发 VM-Exit Event，使得进程从 guest 切换到 VMM。可以用 RDTSC 指令来计算这个开销。

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

   BOOL rdtsc_diff_vmexit() {  ULONGLONG tsc1 = 0;  ULONGLONG tsc2 = 0;  ULONGLONG avg = 0;  INT cpuInfo[4] = {};    // Try this 10 times in case of small fluctuations  for (INT i = 0; i < 10; i++)  {      tsc1 = __rdtsc();      __cpuid(cpuInfo, 0);      tsc2 = __rdtsc();        // Get the delta of the two RDTSC      avg += (tsc2 - tsc1);  }    // We repeated the process 10 times so we make sure our check is as much reliable as we can  avg = avg / 10;  return (avg < 1000 && avg > 0) ? FALSE : TRUE; }

2.3 SIDT（已失效）

SIDT是 Intel x86 指令，用于检测旧单核处理器上的虚拟机存在。这个指令被 “ScoopyNG” 以及 “Redpill” 使用，来检测虚拟机的存在。该命令将中断描述符表寄存器 （IDTR）的内容存放到指定内存地址中。中断描述符表（IDT）是一种重要的操作系统数据结构，用于处理来自硬件（如键盘和鼠标）的中断命令。hypervisor 会将虚拟化操作系统的 IDT 的地址移动到 hypervisor 可预测的地址。Klein 和 Rutkowska 都发现VMware在当时将 IDT 存储在地址0xFFXXXXXX上，从而在单核处理器上检测 VMware 虚拟机。

然而，随着多核处理器的引入，这种虚拟机检测技术不再可靠，因为处理器内的每个核心都具有唯一的中断描述符表，而每个表的地址都不同。此外，在我们对 VMware 的虚拟机测试SIDT命令时，即使只分配了一个处理器核心，IDT 的地址也从未出现在0xFFXXXXXX的地址上。因此，这种虚拟机检测方法已失效。

2.4 SGDT（已失效）

SGDT是 Intel x86 指令，用于将全局描述符表寄存器（GDTR）的内容存放到指定内存地址中。GDT 是处理器使用的数据结构，用于定义有关进程内存的详细信息，例如基址、大小和内存权限。这种虚拟机检测方法曾被“ScoopyNG”使用。与SIDT指令类似，当在基于VMware的虚拟机中运行时，该指令会返回0xFFXXXXXX的值。然而，这个指令也面临着 SIDT 指令引入多核处理器后遇到的同样问题。在使用 VMware Workstation 测试这种检测方法时，返回的值并不是0xFFXXXXXX。因此，这种检测方法已失效。

2.5 SLDT（已失效）

SLDT 是 Intel x86 指令，用于将本地描述符表寄存器（LDTR）的内容存放到指定内存地址。LDT包含有关进程内存段的信息，例如代码段、数据段以及堆。当在虚拟机中执行此命令时，将返回非零值，而在非虚拟化环境中返回0。“ScoopyNG”和恶意软件“Conficker”曾使用过这种虚拟机检测方法。我们在 VMware Workstation、VirtualBox、XEN、HyperV 和 KVM/QEMU 虚拟机上测试了此命令，发现所有虚拟机都返回0。这种检测方法已失效。

2.6 STR（已失效）

STR是 Intel x86 指令，它返回当前执行进程的任务状态寄存器（TSR）内容到指定内存地址。任务状态段 TSS 用于存放操作系统用于任务切换的数据，其中包括进程 threads 和 registry 信息，供处理器操作系统处理线程调度。Klein 发现在虚拟机内运行此命令时，它返回格式为 0x0040XXXX 的地址。对VMware Workstation、VirtualBox、XEN、HyperV和KVM/QEMU虚拟机上测试此命令，发现这种检测方法已失效。

2.7 SMSW（已失效）

SMSW是 Intel x86命令之一，用于将机器状态字返回到指定的内存地址。机器状态字的信息来自CR0寄存器，与 CPU 用于指示是否启用某些功能（如内存分页）的 flags 有关。Quist 发现，在VMware虚拟机内运行此命令，当 EAX=0xCCCCCCCC 时，将返回 0x8001XXXX。经测试在VMware虚拟机内和物理机上测试此命令都会返回值 0x8005XXXX。因此这种检测方法已失效。

2.8 VM “Synthetic Instructions”（已失效）

Traut在2003年提出了一种使用“合成CPU指令”的虚拟机检测方法。这些指令仅被虚拟机支持，在物理机上执行时会触发无效指令异常。由于这些是无效的CPU指令，因此它们未在Intel或AMD的程序员手册中记录。这些指令的格式为“0FC7C8XXXX”。其中最“VMCPUID”指令被“Necurs”僵尸网络用于检查虚拟机的存在。

在 VMware Workstation、VirtualBox、XEN、HyperV 和 KVM/QEMU 虚拟化平台上测试 “VMCPUID” 指令的代码如下：

结果所有测试的虚拟化平台都不支持 VMCPUID 命令。实际上，这个命令被错误地解释为两个命令：

3. 其他检测方法

3.1 Thermal Zone Temperature

恶意软件“Win32/gravityRAT”采用了一种通过检测系统 thermal zone 来检测虚拟机存在的方法。通过使用下面的powershell脚本，可以轻松检查机器是否支持“MSAcip_ThermalZoneTemperature”对象。如果此脚本没有返回结果，则假定该计算机在虚拟机中，因为虚拟机默认不支持热力监控。由于Thermal zone sensors 可以在系统的BIOS或UEFI中禁用和启用，在多个物理机上测试结果不一致，所以该方法并不可靠。

Ref:
Anti-VM Technique with MSAcpi_ThermalZoneTemperature

3.2 IP Timestamp Patterns

这种虚拟机检测方法是由Noorafize等人发现的 ，它基于虚拟机无法像物理机一样保持准确的时间。虚拟机通常通过与主机计算机共享时间来进行时间同步，以尝试伪装成物理机，但来自虚拟机的IP报文时间戳存在不一致性。研究人员发现，由于虚拟机需要与 hypervisor 进行交互，导致虚拟机的时间戳信息略有不同。为了使用此检测方法，攻击者需要向目标系统发送大量的IP / ICMP 数据包以获取足够的信息，以推断目标机器是否为虚拟机。

Ref:
M. Noorafiza, H. Maeda, T. Kinoshita and R. uda, "Virtual Machines Detection Methods using IP Timestamps pattern Characteristic," vol. 8, 2016

3.3 CPU Detail Anomalies

通过检查CPU物理核心数、逻辑核心数和cache容量与实际产品配置的不一致性来检测虚拟机。

Ref：Mettrick D. Virtual machine detection through Central Processing Unit (CPU) detail anomalies[D]. , 2022.

3.4 Physical memory resource maps

在 Windows 中，设备驱动程序需要访问硬件资源（如内存、I/O 端口、中断等），这些资源的地址通常是硬件相关的，因此在不同的系统上地址可能会发生变化。为了方便驱动程序的编写和移植，Windows 内核提供了资源映射机制，将硬件相关的地址转换为系统相关的地址，从而使驱动程序可以在不同的系统上运行而不需要进行修改。内存翻译就是其中一种资源映射类型，它将硬件设备的物理内存地址映射为系统中的虚拟内存地址，使驱动程序可以通过虚拟地址来访问设备内存。

可以通过比对虚拟地址的不同检测虚拟机环境。测试发现Hyper-V虚拟机具有与 00001000-000a0000 匹配的物理内存映射区域。VirtualBox虚拟机具有与 00001000-009f000 匹配的物理内存映射区域。

Ref:
VM Detection Tricks, Part 1: Physical memory resource maps

3.5 Driver Thread Fingerprinting

驱动程序可能创建一定数量的线程，并具有可预测的属性，因此这些属性可以用于指纹识别并构建有用的检测启发式算法。

Ref:
VM Detection Tricks, Part 2: Driver Thread Fingerprinting

3.6 基于鼠标行为的方法

恶意软件 Win32/Okrum 使用了基于行为的一些方法来检测沙箱：

• GetTickCount函数调用两次，间隔20秒休眠。如果GetTickCount值没有改变（即时间已经加速），恶意软件将终止自身。
• 连续两次调用GetCursorPos函数。如果鼠标在X轴上的位置发生了变化（即鼠标位置是随机生成的），恶意软件将终止自身。
• 调用GetGlobalMemoryStatusEx。如果实际物理内存的数量小于1.5GB，恶意软件将终止自身
• 只有左键（物理）鼠标按钮按下至少三次后（在无限循环中查询GetAsyncKeyState），负载才开始。

Ref：
ESET_Okrum_and_Ketrican.pdf

参考

1. https://www.cynet.com/attack-techniques-hands-on/malware-anti-vm-techniques/
2. https://www.ptsecurity.com/ww-en/analytics/antisandbox-techniques/
3. https://artemonsecurity.com/vmde.pdf
4. https://github.com/LordNoteworthy/al-khaser
5. https://github.com/a0rtega/pafish

Unicorn高级逆向与反混淆