模板
教程
环境
性能
功能
管理
反病毒引擎设计之虚拟机查毒篇
编者按：绪论《反病毒引擎设计之绪论篇》我们介绍了病毒技术的发展状况和一些病毒的特点和感染机制。下面我们重点对虚拟机查毒进行阐述。
目录
2.1虚拟机概论
2.2加密变形病毒
2.3虚拟机实现技术详解
2.4虚拟机代码剖析
2.4.1不依赖标志寄存器指令模拟函数的分析
2.4.2依赖标志寄存器指令模拟函数的分析
2.5反虚拟机技术
2．虚拟机查毒
近些年,虚拟机，在反病毒界也被称为通用解密器，已经成为反病毒软件中最引人注目的部分，尽管反病毒者对于它的运用还远没有达到一个完美的程度，但虚拟机以其诸如"病毒指令码模拟器"和"Stryker"等多变的名称为反病毒产品的市场销售带来了光明的前景。以下的讨论将把我们带入一个精彩的虚拟技术的世界中。
首先要谈及的是虚拟机的概念和它与诸如Vmware（美国VMWARE公司生产的一款虚拟机，它支持在WINNT/2000环境下运行如Linux等其它操作系统）和WIN9X下的VDM（DOS虚拟机，它用来在32位保护模式环境中运行16实模式代码）的区别。其实这些虚拟机的设计思想是有渊源可寻的，早在上个世纪60年代IBM就开发了一套名为VM/370的操作系统。VM/370在不同的程序之间提供抢先式多任务，作法是在单一实际的硬件上模式出多部虚拟机器。典型的VM/370会话，使用者坐在电缆连接的远程终端前，经由控制程序的一个IPL命令，模拟真实机器的初始化程序装载操作，于是 一套完整的操作系统被载入虚拟机器中，并开始为使用者着手创建一个会话。这套模拟系统是如此的完备，系统程序员甚至可以运行它的一个虚拟副本，来对新版本进行除错。Vmware与此非常相似，它作为原操作系统下的一个应用程序可以为运行于其上的目标操作系统创建出一部虚拟的机器，目标操作系统就象运行在单独一台真正机器上，丝毫察觉不到自己处于Vmware的控制之下。当在Vmware中按下电源键（Power On）时，窗口里出现了机器自检画面，接着是操作系统的载入，一切都和真的一样。而WIN9X为了让多个程序共享CPU和其它硬件资源决定使用VMs（所有Win32应用程序运行在一部系统虚拟机上；而每个16位DOS程序拥有一部DOS虚拟机）。VM是一个完全由软件虚构出来的东西，以和真实电脑完全相同的方式来回应应用程序所提出的需求。从某种角度来看，你可以将一部标准的PC的结构视为一套API。这套API的元素包括硬件I/O系统，和以中断为基础的BIOS和MS-DOS。WIN9X常常以它自己的软件来代理这些传统的API元素，以便能够对珍贵的硬件多重发讯。在VM上运行的应用程序认为自己独占整个机器，它们相信自己是从真正的键盘和鼠标获得输入，并从真正的屏幕上输出。稍被加一点限制，它们甚至可以认为自己完全拥有CPU和全部内存。实现虚拟技术关键在于软件虚拟化和硬件虚拟化，下面简要介绍WIN9X下的DOS虚拟机的实现。
当Windows移往保护模式后，保护模式程序无法直接调用实模式的MS-DOS处理例程，也不能直接调用实模式的BIOS。软件虚拟化就是用来描述保护模式Windows部件是如何能够和实模式MS-DOS和BIOS彼此互动。软件虚拟化要求操作系统能够拦截企图跨越保护模式和实模式边界的调用，并且调整适当的参数寄存器后，改变CPU模式。WIN9X使用虚拟设备驱动（VXD）拦截来自保护模式的中断，通过实模式中断向量表（IVT），将之转换为实模式中断调用。做为转换的一部分，VXD必须使用置于保护模式扩展内存中的参数，生成出适当的参数，并将之放在实模式（V86）操作系统可以存取的地方。服务结束后，VXD在把结果交给扩展内存中保护模式调用端。16位DOS程序中大量的21H和13H中断调用就此解决，但其中还存在不少直接端口I/O操作，这就需要引入硬件虚拟化来解决。虚拟硬件的出现是为了在硬件中断请求线上产生中断请求，为了回应IN和OUT指令，改变特殊内存映射位置等原因。硬件虚拟化依赖于Intel 80386+的几个特性。其中一个是I/O许可掩码，使操作系统可能诱捕（Trap）对任何一个端口的所有IN/OUT指令。另一个特性是：由硬件辅助的分页机制，使操作系统能够提供虚拟内存，并拦截对内存地址的存取操作，将Video RAM虚拟化是此很好的例证。最后一个必要的特性是CPU的虚拟8086（V86）模式 ，让DOS程序象在实模式中那样地执行。
我们下面讨论用于查毒的虚拟机并不是象某些人想象的：如Vmware一样为待查可执行程序创建一个虚拟的执行环境，提供它可能用到的一切元素，包括硬盘，端口等，让它在其上自由发挥，最后根据其行为来判定是否为病毒。当然这是个不错的构想，但考虑到其设计难度过大（需模拟元素过多且行为分析要借助人工智能理论），因而只能作为以后发展的方向。我设计的虚拟机严格的说不能称之为虚拟机器，而叫做虚拟CPU，通用解密器等更为合适一些，但由于反病毒界习惯称之为虚拟机，所以在下面的讨论中我还将延续这个名称。查毒的虚拟机是一个软件模拟的CPU，它可以象真正CPU一样取指，译码，执行，它可以模拟一段代码在真正CPU上运行得到的结果。给定一组机器码序列，虚拟机会自动从中取出第一条指令操作码部分，判断操作码类型和寻址方式以确定该指令长度，然后在相应的函数中执行该指令，并根据执行后的结果确定下条指令的位置，如此循环反复直到某个特定情况发生以结束工作，这就是虚拟机的基本工作原理和简单流程。设计虚拟机查毒的目的是为了对付加密变形病毒，虚拟机首先从文件中确定并读取病毒入口处代码，然后以上述工作步骤解释执行病毒头部的解密段（decryptor），最后在执行完的结果（解密后的病毒体明文）中查找病毒的特征码。这里所谓的“虚拟”，并非是创建了什么虚拟环境，而是指染毒文件并没有实际执行，只不过是虚拟机模拟了其真实执行时的效果。这就是虚拟机查毒基本原理，具体介绍请参看后面的相关章节。
当然，虚拟执行技术使用范围远不止自动脱壳（虚拟机查毒实际上是自动跟踪病毒入口的解密子将加密的病毒体按其解密算法进行解密），它还可以应用在跨平台高级语言解释器，恶意代码分析，调试器。如刘涛涛设计的国产调试器Trdos就是完全利用虚拟技术解释执行被调试程序的每条指令，这种调试器比较起传统的断点式调试器（Debug,Softice等）具有诸多优势，如不易被被调试者察觉，断点个数没有限制等。
前面提到过设计虚拟机查毒的目的是为了对付加密变形病毒。这一章就重点介绍加密变形技术。
早期病毒没有使用任何复杂的反检测技术，如果拿反汇编工具打开病毒体代码看到的将是真正的机器码。因而可以由病毒体内某处一段机器代码和此处距离病毒入口（注意不是文件头）偏移值来唯一确定一种病毒。查毒时只需简单的确定病毒入口并在指定偏移处扫描特定代码串。这种静态扫描技术对付普通病毒是万无一失的。
随着病毒技术的发展，出现了一类加密病毒。这类病毒的特点是：其入口处具有解密子（decryptor），而病毒主体代码被加了密。运行时首先得到控制权的解密代码将对病毒主体进行循环解密，完成后将控制交给病毒主体运行，病毒主体感染文件时会将解密子，用随机密钥加密过的病毒主体，和保存在病毒体内或嵌入解密子中的密钥一同写入被感染文件。由于同一种病毒的不同传染实例的病毒主体是用不同的密钥进行加密，因而不可能在其中找到唯一的一段代码串和偏移来代表此病毒的特征，似乎静态扫描技术对此即将失效。但仔细想想，不同传染实例的解密子仍保持不变机器码明文（从理论上讲任何加密程序中都存在未加密的机器码，否则程序无法执行），所以将特征码选于此处虽然会冒一定的误报风险（解密子中代码缺少病毒特性，同样的特征码也会出现在正常程序中），但仍不失为一种有效的方法。
由于加密病毒还没有能够完全逃脱静态特征码扫描，所以病毒写作者在加密病毒的基础之上进行改进，使解密子的代码对不同传染实例呈现出多样性，这就出现了加密变形病毒。它和加密病毒非常类似，唯一的改进在于病毒主体在感染不同文件会构造出一个功能相同但代码不同的解密子，也就是不同传染实例的解密子具有相同的解密功能但代码却截然不同。比如原本一条指令完全可以拆成几条来完成，中间可能会被插入无用的垃圾代码。这样，由于无法找到不变的特征码，静态扫描技术就彻底失效了。下面先举两个例子说明加密变形病毒解密子构造，然后再讨论怎样用虚拟执行技术检测加密变形病毒。
著名多形病毒Marburg的变形解密子：
以上的代码看上去绝对不会是用编译器编译出来，或是编程者手工写出来的，因为其中充斥了大量的乱数和垃圾。代码中没有注释部分均可认为是垃圾代码，有用部分完成的功能仅是循环向加密过的病毒体的每个双字加上或异或一个固定值。这只是变形病毒传染实例的其中一个，别的实例的解密子和病毒体将不会如此，极度变形以至让人无法辩识。至于变形病毒的实现技术由于涉及复杂的算法和控制，因此不在我们讨论范围内。
这种加密变形病毒的检测用传统的静态特征码扫描技术显然已经不行了。为此我们采取的方法是动态特征码扫描技术，所谓“动态特征码扫描”指先在虚拟机的配合下对病毒进行解密，接着在解密后病毒体明文中寻找特征码。我们知道解密后病毒体明文是稳定不变的，只要能够得到解密后的病毒体就可以使用特征码扫描了。要得到病毒体明文首先必须利用虚拟机对病毒的解密子进行解释执行，当跟踪并确定其循环解密完成或达到规定次数后，整个病毒体明文或部分已被保存到一个内部缓冲区中了。虚拟机之所以又被称为通用解密器在于它不用事先知道病毒体的加密算法，而是通过跟踪病毒自身的解密过程来对其进行解密。至于虚拟机怎样解释指令执行，怎样确定可执行代码有无循环解密段等细节将在下一节中介绍。
有了前面关于加密变形病毒的介绍，现在我们知道动态特征码扫描技术的关键就在于必须得到病毒体解密后的明文，而得到明文产生的时机就是病毒自身解密代码解密的完毕。目前有两种方法可以跟踪控制病毒的每一步执行，并能够在病毒循环解密结束后从内存中读出病毒体明文。一种是单步和断点跟踪法，和目前一些程序调试器相类似；另一种方法当然就是虚拟执行法。下面分别分析单步和断点跟踪法和虚拟执行法的技术细节。
单步跟踪和断点是实现传统调试器的最根本技术。单步的工作原理很简单：当CPU在执行一条指令之前会先检查标志寄存器，如果发现其中的陷阱标志被设置则会在指令执行结束后引发一个单步陷阱INT1H。至于断点的设置有软硬之分，软件断点是指调试器用一个通常是单字节的断点指令（CC，即INT3H）替换掉欲触发指令的首字节，当程序执行至断点指令处，默认的调试异常处理代码将被调用，此时保存在栈中的段/偏移地址就是断点指令后一字节的地址；而硬件断点的设置则利用了处理器本身的调试支持，在调试寄存器（DR0--DR4）中设置触发指令的线形地址并设置调试控制寄存器（DR7）中相关的控制位，CPU会在预设指令执行时自动引发调试异常。而Windows本身又提供了一套调试API，使得调试跟踪一个程序变得非常简单：调试器本身不用接挂默认的调试异常处理代码，而只须调用WaitForDebugEvent等待系统发来的调试事件；调试器可利用GetThreadContext挂起被调试线程获取其上下文，并设置上下文中的标志寄存器中的陷阱标志位，最后通过SetThreadContext使设置生效来进行单步调试；调试器还可通过调用两个功能强大的调试API--ReadProcessMemory和WriteProcessMemory来向被调试线程的地址空间中注入断点指令。根据我逆向后的分析结果，VC++的调试器就是直接利用这套调试API写成的。使用以上的调试技术既然可以写出像VC++那样功能齐全的调试器，那么没有理由不能将之运用于病毒代码的自动解密上。最简单的最法：创建待查可执行文件为调试器的调试子进程，然后用上述方法对其进行单步跟踪，每当收到具有EXCEPTION_SINGLE_STEP异常代码的事件时就可以分析该条以单步模式执行的指令，最后当判断病毒的整个解密过程结束后即可调用ReadProcessMemory读出病毒体明文。
用单步和断点跟踪法的唯一一点好处就在于它不用处理每条指令的执行--这意味着它无需编写大量的特定指令处理函数，因为所有的解密代码都交由CPU去执行，调试器不过是在代码被单步中断的间隙得到控制权而已。但这种方法的缺点也是相当明显的：其一容易被病毒觉察到，病毒只须进行简单的堆栈检查，或直接调用IsDebugerPresent就可确定自己正处于被调试状态；其二由于没有相应的机器码分析模块，指令的译码，执行完全依赖于CPU，所以将导致无法准确地获取指令执行细节并对其进行有效的控制。；其三单步和断点跟踪法要求待查可执行文件真实执行，即其将做为系统中一个真实的进程在自己的地址空间中运行，这当然是病毒扫描所不能允许的。很显然，单步和断点跟踪法可以应用在调试器，自动脱壳等方面，但对于查毒却是不合适的。
而使用虚拟执行法的唯一一点缺点就在于它必须在内部处理所有指令的执行--这意味着它需要编写大量的特定指令处理函数来模拟每种指令的执行效果，这里根本不存在何时得到控制权的问题，因为控制权将永远掌握在虚拟机手中。用软件方法模拟CPU并非易事，需要对其机制有足够的了解，否则模拟效果将与真实执行相去甚远。举两个例子：一个是病毒常用的乘法后ASCII调整指令AAM，这条指令因为存在未公开的行为从而常常被病毒用来考验虚拟机设计的优劣。通常情况下AAM是双字节指令，操作码为D4 0A（其实0A隐含代表了操作数10）；但也可作为单字节指令明确地指定第二字节除数为任意8位立即数，此时操作码仅为D4。虚拟机必需考虑到后一种指定除数的情况来保证模拟结果的正确性；还有一个例子是关于处理器响应中断的方式，即CPU在刚打开中断后将不会马上响应中断，而必须隔一个指令周期。如果虚拟机没有考虑到该机制则很可能虚拟执行流程会与真实情况不符。但虚拟执行的优点也是很明显的，同时它正好填补了单步和断点跟踪法所力不能及的方面：首先是不可能被病毒觉察到，因为虚拟机将在其内部缓冲区中为被虚拟执行代码设立专用的堆栈，所以堆栈检查结果与实际执行无二（不会向堆栈中压入单步和断点中断时的返回地址）；其次由于虚拟机自身完成指令的解码和地址的计算，所以能够获取每条指令的执行细节并加以控制；最后，最为关键的一条在于虚拟执行确实做到了“虚拟”执行，系统中不会产生代表被执行者的进程，因为被执行者的寄存器组和堆栈等执行要素均在虚拟机内部实现，因而可以认为它在虚拟机地址空间中执行。鉴于虚拟执行法诸多的优点，所以将其运用于通用病毒体解密上是再好不过的了。
通常，虚拟机的设计方案可以采取以下三种之一：自含代码虚拟机（SCCE），缓冲代码虚拟机（BCE），有限代码虚拟机（LCE）。
自含代码虚拟机工作起来象一个真正的CPU。一条指令取自内存，由SCCE解码，并被传送到相应的模拟这条指令的例程，下一条指令则继续这个循环。虚拟机会包含一个例程来对内存/寄存器寻址操作数进行解码，然后还会包括一个用于模拟每个可能在CPU上执行的指令的例程集。正如你所想到的，SCCE的代码会变的无比的巨大而且速度也会很慢。然而SCCE对于一个先进的反病毒软件是很有用的。所有指令都在内部被处理，虚拟机可以对每条指令的动作做出非常详细的报告，这些报告和启发式数据以及通用清除模块将相互参照形成一个有效的反毒系统。同时，反病毒程序能够最精确地控制内存和端口的访问，因为它自己处理地址的解码和计算。
缓冲代码虚拟机是SCCE的一个缩略版,因为相对于SCCE它具有较小的尺寸和更快的执行速度。在BCE中，一条指令是从内存中取得的，并和一个特殊指令表相比较。如果不是特殊指令，则它被进行简单的解码以求得指令的长度，随后所有这样的指令会被导入到一个可以通用地模拟所有非特殊指令的小过程中。而特殊指令，只占整个指令集的一小部分，则在特定的小处理程序中进行模拟。BCE通过将所有非特殊指令用一个小的通用的处理程序模拟来减少它必须特殊处理的指令条数，这样一来它削减了自身的大小并提高了执行速度。但这意味着它将不能真正限制对某个内存区域，端口或其他类似东西的访问，同时它也不可能生成如SCCE提供的同样全面的报告。
有限代码虚拟机有点象用于通用解密的虚拟系统所处的级别。LCE实际上并非一个虚拟机，因为它并不真正的模拟指令，它只简单地跟踪一段代码的寄存器内容，也许会提供一个小的被改动的内存地址表，或是调用过的中断之类的东西。选择使用LCE而非更大更复杂的系统的原因，在于即使只对极少数指令的支持便可以在解密原始加密病毒的路上走很远，因为病毒仅仅使用了INTEL指令集的一小部分来加密其主体。使用LCE，原本处理整个INTEL指令集时的大量花费没有了，带来的是速度的巨大增长。当然，这是以不能处理复杂解密程序段为代价的。当需要进行快速文件扫描时LCE就变的有用起来，因为一个小型但象样的LCE可以用来快速检查执行文件的可疑行为，反之对每个文件都使用SCCE算法将会导致无法忍受的缓慢。当然，如果一个文件看起来可疑，LCE还可以启动某个SCCE代码对文件进行全面检查。
下面开始介绍32位自含代码虚拟机w32encode（w32encode.cpp，Tw32asm.h，Tw32asm.cpp做为查毒引擎的一部分和其它搜索清除模块联编为Rsengine.dll）的程序结构和流程。由于这是一个设计完备且复杂的大型商用虚拟机，其中不可避免地包含了对某些特定病毒的特定处理，为了使虚拟机模型的结构清晰脉络分明，分析时我将做适当的简化。
w32encode的工作原理很简单：它首先设置模拟寄存器组（用一个DWORD全局变量模拟真实CPU内部的一个寄存器，如ENEAX）的初始值，初始化执行堆栈指针（虚拟机用内部的一个数组static int STACK[0x20]来模拟堆栈）。然后进入一个循环，解释执行指令缓冲区ProgBuffer中的头256条指令，如果循环退出时仍未发现病毒的解密循环则可由此判定非加密变形病毒，若发现了解密循环则调用EncodeInst函数重复执行循环解密过程，将病毒体明文解密到DataSeg1或DataSeg2中。相关部分代码如下：
W32Encode0中总体流程控制部分代码：
parse中虚拟执行每条指令的过程较复杂一些：通常parse会从取得指令缓冲区ProgBuffer中取得当前指令的头两个字节（包括了全部操作码）并根据它们的值调用相应的指令处理函数。例如当第一个字节等于0F并且第二个字节位与BE后等于BE时，可判定此指令为movszx并同时调用movszx进行处理。当执行进入特定指令的处理函数中时，首先要通过判断寻址方式（调用modregrm或modregrm1）确定指令长度并将控制权交给saveinst函数。saveinst在保存该指令的相关信息后会调用真正指令执行函数W32ExecuteInst。这个函数和parse非常相似，它从SaveInstBuf1中取得当前指令的头两个字节并根据它们的值调用相应的指令模拟函数以完成一条指令的执行。相关部分代码如下：
总体流程控制和分遣部分的相关代码，在上一章中都已分析过了。下面分析具体的特定指令模拟函数，这才是虚拟机的精华之所在。我将指令分成不依赖标志寄存器和依赖标志寄存器两大类分别介绍：
push和pop指令的模拟：
CW32Asm类中cmp指令的模拟：
任何一个事物都不是尽善尽美，无懈可击的，虚拟机也不例外。由于反虚拟执行技术的出现，使得虚拟机查毒受到了一定的挑战。这里介绍几个比较典型的反虚拟执行技术：
首先是插入特殊指令技术，即在病毒的解密代码部分人为插入诸如浮点，3DNOW，MMX等特殊指令以达到反虚拟执行的目的。尽管虚拟机使用软件技术模拟真正CPU的工作过程，它毕竟不是真正的CPU，由于精力有限，虚拟机的编码者可能实现对整个Intel指令集的支持，因而当虚拟机遇到其不认识的指令时将会立刻停止工作。但通过对这类病毒代码的分析和统计，我们发现通常这些特殊指令对于病毒的解密本身没有发生任何影响，它们的插入仅仅是为了干扰虚拟机的工作，换句话说就是病毒根本不会利用这条随机的垃圾指令的运算结果。这样一来，我们可以仅构造一张所有特殊指令对应于不同寻址方式的指令长度表，而不必为每个特殊指令编写一个专用的模拟函数。有了这张表后，当虚拟机遇到不认识的指令时可以用指令的操作码索引表格以求得指令的长度，然后将当前模拟的指令指针（EIP）加上指令长度来跳过这条垃圾指令。当然，还有一个更为保险的办法那就是：得到指令长度后，可以将这条我们不认识的指令放到一个充满空操作指令（NOP）的缓冲区中，接着我们将跳到缓冲区中去执行，这等于让真正的CPU帮我们来执行这条指令，最后一步当然是将执行后真实寄存器中的结果放回我们的模拟寄存器中。这虚拟执行和真实执行参半方法的好处在于：即便在特殊指令对于病毒是有意义的，即病毒依赖其返回结果的情况下，虚拟机仍可保证虚拟执行结果的正确。
其次是结构化异常处理技术，即病毒的解密代码首先设置自己的异常处理函数，然后故意引发一个异常而使程序流程转向预先设立的异常处理函数。这种流程转移是CPU和操作系统相互配合的结果，并且在很大程度上，操作系统在其中起了很大的作用。由于目前的虚拟机仅仅模拟了没有保护检查的CPU的工作过程，而对于系统机制没有进行处理。所以面对引发异常的指令会有两种结果：其一是某些设计有缺陷的虚拟机无法判断被模拟指令的合法性，所以模拟这样的指令将使虚拟机自身执行非法操作而退出；其二虚拟机判断出被模拟指令属于非法指令，如试图向只读页面写入的指令，则立刻停止虚拟执行。通常病毒使用该技术的目的在于将真正循环解密代码放到异常处理函数后，如此虚拟机将在进入异常处理函数前就停止了工作，从而使解密子有机会逃避虚拟执行。因而一个好的虚拟机应该具备发现和记录病毒安装异常过滤函数的操作并在其引发异常时自动将控制转向异常处理函数的能力。
再次是入口点模糊（EPO）技术，即病毒在不修改宿主原入口点的前提下，通过在宿主代码体内某处插入跳转指令来使病毒获得控制权。通过前面的分析，我们知道虚拟机扫描病毒时出于效率考虑不可能虚拟执行待查文件的所有代码，通常的做法是：扫描待查文件代码入口，假如在规定步数中没有发现解密循环，则由此判定该文件没有携带加密变形病毒。这种技术之所以能起到反虚拟执行的作用在于它正好利用了虚拟机的这个假设：由于病毒是从宿主执行到一半时获得控制权的，所以虚拟机首先解释执行的是宿主入口的正常程序，当然在规定步数中不可能发现解密循环，因而产生了漏报。如果虚拟机能增加规定步数的大小，则很有可能随着病毒插入的跳转指令跟踪进入病毒的解密子，但确定规定步数大小实在是件难事：太大则将无谓增加正常程序的检测时间；太小则容易产生漏报。但我们对此也不必过于担心，这类病毒由于其编写技术难度较大所以为数不多。在没有反汇编和虚拟执行引擎的帮助下，病毒很难在宿主体内定位一条完整指令的开始处来插入跳转，同时很难保证插入的跳转指令的深度大于虚拟机的规定步数，并且没有把握插入的跳转指令一定会被执行到。
另外还有多线程技术，即病毒在解密部分入口主线程中又启动了额外的工作线程，并且将真正的循环解密代码放置于工作线程中运行。由于多线程间切换调度由操作系统负责管理，所以我们的虚拟机只能在假定被执行线程独占处理器时间，即保证永远不被抢先，的前提下进行。如此一来，虚拟机对于模拟启用多线程工作的代码将很难做到与真实效果一致。多线程和结构化异常处理两种技术都利用了特定的操作系统机制来达到反虚拟执行的目的，所以在虚拟CPU中加入对特定操作系统机制的支持将是我们今后改进的目标。
最后是元多形技术（MetaPolymorphy）,即病毒中并非是多形的解密子加加密的病毒体结构，而整体均采用变形技术。这种病毒整体都在变，没有所谓“病毒体明文”。当然，其编写难度是很大的。如果说前几种反虚拟机技术是利用了虚拟机设计上的缺陷，可以通过代码改进来弥补的话，那么这种元多形技术却使虚拟机配合的动态特征码扫描法彻底失效了，我们必须寻求如行为分析等更先进的方法来解决。【未完待续】
查阅下一篇：《反病毒引擎设计之实时监控篇》
主要参考文献
David A. Solomon, Mark Russinovich 《Inside Microsoft Windows 2000》September 2000
David A. Solomon 《Inside Windows NT》 May 1998
Prasad Dabak，Sandeep Phadke，Milind Borate 《Undocumented Windows NT》October 1999
Matt Pietrek 《Windows 95 System Programming Secrets》 March 1996
Walter Oney 《System Programming for Windows 95》 March 1996
Walter Oney 《Programming the Windows Driver Model》 1999
陆麟 《WINDOWS9X文件读写Internal》2001
(责任编辑：赵纪雷)
