用于恶意软件检测的对应用的通用拆包的制作方法
【技术领域】
[0001] 本公开一般涉及用于拆包可执行二进制文件以使较少地依赖多个签名（例如，针 对每一个打包方法的一个签名）来标识潜在的恶意软件被保持在病毒签名DAT文件中的系 统和方法。更具体而言，但不作为限制，本公开涉及：在对经打包的可执行文件进行拆包时 使用硬件辅助的虚拟化来确定其原始的入口点，并且在执行该原始的入口点之前，一旦可 执行文件到达其完全扩展的形式就执行对其的正式扫描。
【背景技术】
[0002] 当代的应用代码的递送通常涉及其通过打包（pack)过程进行的压缩。通过使用 打包过程，二进制文件尺寸可以减小，并且多个文件可以被合并成一个文件。现代的打包过 程创建"自解压（self-extracting)可执行文件"，可执行其来对经打包的代码的内容进行 拆包（unpack)。也就是说，经打包的代码本身伴随着可执行代码段，当执行该可执行代码段 时，其导致使经打包的代码膨胀或解压缩。相应地，运行自解压可执行文件会导致经打包的 代码可执行文件被扩展在磁盘上、存储器中，或两者中。
[0003] 当对文件打包以创建自解压可执行文件时，可以采用许多不同类型的压缩算法以 及打包技术。这些技术中的某些是已知的并有文档记载的，而其他技术不是这样。对相同 文件采用不同的技术来创建自解压可执行文件将产生不同的文件一一由于不同的打包器 (packer)以及不同的压缩算法所产生的不同结果，打包代码（packing code)和经打包的 代码（packed code)两者都可能不同。此外，如果使用未知的或文档未记载的技术来将文 件打包为自解压可执行文件，则可能甚至难以确定打包代码和经打包的代码之间的区别。
[0004] 自解压可执行文件的这些特性常常被恶意软件开发者利用以对反病毒程序或恶 意软件检测程序隐藏恶意软件。检测恶意软件的一种常见的方法是签名扫描。利用签名 扫描，对文件进行扫描以发现已知或被怀疑与恶意软件相关联的位模式或签名。当文件中 的位模式匹配已知恶意软件的签名时，则可将该文件标识为恶意软件或标识为包含恶意软 件。然而，恶意可执行文件的签名可以被轻松地更改以力图误导可执行文件。当恶意软件 被打包时，可能避开检测，因为经拆包的恶意软件的已知签名将不会匹配经打包的恶意软 件文件的任何位模式。
[0005] 为了尝试克服隐藏恶意软件的这些企图，反病毒程序和恶意软件检测程序可以采 用多项技术。一项技术是在存储器中提取经打包的代码而不执行它，然后，尝试对经解压缩 的二进制文件扫描恶意软件签名。可以通过仿真经打包代码的执行来提取该经打包的代 码，或者如果打包算法是已知的，则由反病毒程序来执行提取。如果打包技术不是公知的或 未经文档记载，则在反病毒程序的控制下来提取经打包的代码可能无法是可能的。此外，许 多打包算法在检测到正在由调试器或通过执行仿真来执行拆包之后，使用反仿真和反调试 技术来简单地终止拆包过程。对代码流的诸部分标记时间戳是可用于判断代码正在被仿真 的标准方法。类似地，标识代码正在被调试可以通过查询操作系统来容易地确定。
[0006] 即使自解压可执行文件被允许执行或被仿真，反病毒程序也可能在确定执行的拆 包部分何时完成以及原始压缩的可执行文件何时开始执行时存在困难。在自解压可执行文 件中，拆包代码和经打包的可执行文件是相同的二进制文件的部分，并且在存储器中确定 这两者之间的区别可能是困难的。
[0007] 克服隐藏恶意软件的企图的另一技术是一旦标识了经打包的恶意软件的新签名， 就将包含恶意软件的已知的自解压可执行文件的签名添加到反病毒签名数据库中。此技术 的弱点在于，可以通过稍微更改打包器代码或打包技术从而产生不同的自解压可执行文件 并由此产生不同的签名来轻易地避开该技术。将导致打包技术中的这些变化的签名添加到 反病毒签名数据库中会导致增加签名数据库的尺寸。这导致签名的数量以及维持签名文件 的难度会相应地增大的问题。此外，由于可按不同的顺序，使用不同的打包算法来重复任意 次数的打包过程，从而创建将标识并维持的更大数量的签名，因此可能进一步挫败这些努 力。
【附图说明】
[0008] 图1是示出现有技术中已知的可执行文件101和经压缩的自解压可执行文件 102 (可能具有更小的尺寸）的简化结构的框图100。
[0009] 图2是示出能够被配置成促进一个或多个所公开的实施例的网络架构300的框 图。
[0010] 图3是示出具有可根据一个或多个所公开的实施例而配置的处理单元的计算机 的框图。
[0011] 图4是示出具有虚拟机监视器、访客操作系统和应用的计算机系统的软件栈的框 图。
[0012] 图5是示出根据一个或多个所公开的实施例的用于通用对可执行文件拆包直到 不要求进一步的拆包的技术的流程图。
[0013] 图6A是示出根据一个或多个所公开的实施例的用于在可执行文件的通用拆包以 及执行阶段期间设置存储器页面许可并解决存储器页面许可违规以控制对存储器的页面 的存储器访问的技术的流程图。
[0014] 图6B示出状态图650,其示出了可执行文件从其二进制加载时刻到其执行的终止 的受控执行的状态转换。
[0015] 图7是示出根据一个或多个所公开的实施例的在可执行文件的通用拆包和执行 阶段期间所看到的页面存储器许可的各阶段的框图。
【具体实施方式】
[0016] 如上文所解释的那样，不同的打包器的可用性以及可对可执行文件打包多次的事 实导致通过将经打包的恶意可执行文件与签名进行比较来标识它是困难的。经打包的恶意 可执行文件的每一个经标识的变体都可能需要在反病毒程序的病毒签名数据库中的其自 身的签名。这导致病毒签名数据库增长并增加了维护成本和精力一一签名文件更新必须被 传递到使用反病毒程序的最终用户计算机并由其下载。此外，这些相同的因素也使确定何 时应用签名检测算法复杂化。
[0017] 同样如上文所解释的那样，尝试对经打包的文件拆包以暴露原始的可执行文件也 呈现了诸多挑战。由于拆包代码与经打包的可执行文件组合，因此，标识拆包代码完成执行 且原始的二进制文件开始执行的时刻可能是困难的。为了避免对原始的可执行文件的执 行，反病毒程序可尝试对经打包的可执行文件拆包，而不是让拆包器代码执行。为了做到这 一点，反病毒程序必须配备有用于对可执行文件打包的拆包算法。然而，当使用了未知的或 未经文档记载的打包技术时，反病毒程序可能不能对该软件拆包。在这些类型的实例中，必 须通过包括拆包器算法来更新反病毒软件。由于拆包器算法可能时复杂的，因此，反病毒软 件开发者可能需要花费相当长的时间（数月或数年）来包括用于新发现的打包算法的解决 方案。此外，甚至通过对打包器算法的轻微的更改就会规避这些努力或使这些努力更费力。
[0018] 如下文中进一步解释的那样，公开了通过使用用于以受控方式来通用对经单次或 多次打包的应用拆包以检测恶意软件的系统和方法来解决这些及其他问题的技术。对经打 包的应用通用地拆包允许独立于对拆包算法的知晓并独立于对拆包存根（Stub)的实现的 知晓就可对应用拆包。可以使用与硬件辅助的虚拟化相关联的功能来帮助以受控方式通用 地对经打包的应用拆包。这些技术可以减少或消除为单个类型的恶意软件维持多个签名的 需求。
[0019] 参考图1，框图100示出两个文件（根据现有技术的可执行文件以及该文件的经打 包版本）之内的内部区段。通用可执行文件101表示扩展（即，运行时）形式的可执行二 进制文件。还示出了经打包的可执行文件102,其是通用可执行文件101通过打包过程被 修改的结果。通过由开发者对源代码、对象文件以及库执行编译以及链接过程已创建了可 执行文件101。可执行文件101可被组织成三个不同的区段。二进制头部105保存有关该 可执行二进制文件的其余部分（包括代码段110和数据段115)的组织的信息。二进制头 部105还包括对于文件中所包括的所有区段的存储器许可，当将可执行文件101加载到存 储器中时，由操作系统加载器实施这些存储器许可。当被加载到存储器中时，每一个区段都 开始于由操作系统定义的存储器页面的边界处。来自文件的区段并不必须仅包含一个存储 器页面一一相反，每一个区段都可以横跨整数数量的页面。
[0020] 程序执行从可执行二进制文件101中的代码段中的一个区段的某位置开始（即， 运行时），该位置通常被称为程序的"入口点"。取决于编译器/汇编器将"主"函数放在二 进制文件中的什么位置，该入口点可在代码段中的任何地方。入口点不需要在任何特定的 代码段的开始处开始，这还意味着入口点不一定开始于任何特定的存储器页面的开始处。
[0021] 打包器可以经由在本文中被称为打包过程的过程来对可执行文件101打包并压 缩以创建经打包的可执行文件102。典型的打包器可以执行复杂且唯一的操作，但是，如在 此所描述的那样，当从高层级来看时，几乎所有的打包器都执行相对简单操作集。在创建经 打包的可执行文件102时，打包器过程在这些区段上使用压缩算法来压缩可执行文件101 的代码段110和数据端115。这通常是主要为了减小可执行文件的文件尺寸而执行的，但 是，正如恶意软件的情况那样，它可以主要为了改变恶意软件的签名而执行。一旦压缩了这 些区段，可将它们置于经打包的可执行文件102中的新区段（经打包的代码和数据135)。 或者，打包器还可以将代码和数据打包到其中包含了拆包代码的相同区段中。如此，打包器 代码段130和经打包的代码和数据135可以在分开的区段中或在一个区段中。
[0022] 打包过程通常还创建具有当被执行时在存储器中将获取的预定尺寸的虚拟代码 段125。该尺寸通常被计算为大于或等于将在原始的可执行文件101中发现的经解压缩的 经打包代码和数据135的尺寸。由于虚拟代码段125是计划用于存储器中经解压缩的数据 的区段，因此，它不一定占据经打包的可执行文件102本身中的任何空间。相反，可将包含 经打包的可执行文件102的文件中的其尺寸反映为在对打包器代码的解压缩过程的执行 之前在存储器中所需的存储器页面的数量。由打包器转换代码在经更改的二进制头部120 中指定虚拟代码段125的细节。当将由操作系统将二进制可执行文件加载到存储器中时， 通常还在二进制头部（例如，105或120)中指定特定区段将在存储器中获取的存储器页面 的数量。因此，即使盘上可执行文件上的区段尺寸为零，该区段也可在由操作系统加载时在 存储器中获取一些空间。如此，打包过程通过压缩代码和数据已减小了整个二进制文件的 尺寸（即，盘尺寸和下载尺寸），但是准备了足够的存储器以便当在执行时拆包到存储器时 保存经解压缩的代码和数据。