CN101278260B - 使软件程序免于弱点和攻击的约束注入方法 - Google Patents

Abstract

将约束插入程序中以解决程序受到攻击的弱点。约束包括确定要求程序执行在正常操作下不会发生的“边界情况”的时间的代码段。约束代码可以访问检测器和补救器函数的库，以检测各种攻击和对于攻击进行补救。可选地，可以不用补救器地将检测器用于分析。如有必要，可以保存和恢复程序的环境，以便在进行了补救之后继续操作。约束可以包括描述符和机器指令或字节码，所述描述符指示如何使用约束。

Description

使软件程序免于弱点和攻击的约束注入方法

交叉参考相关申请 

本申请要求2005年6月7日提出、发明名称为“使软件程序免于弱点和攻击的约束注入(injection)系统”的美国临时专利申请第60/688,099号的权益，特此引用以供参考。 

环境技术 

计算机主机遭受各种各样的攻击，譬如，服务的拒绝、特权提升、目录遍历、缓冲器溢出、未授权远程或本地执行/访问、信息泄漏等。这样的攻击对像公司那样的企业、政府、和其它大型机构特别有害和代价昂贵。其结果是，发展出防止这样攻击的行业。例如，通过预测未来攻击，主动地(proactively)开发出保护软件。尽管主动地保护可以防止一大类攻击，但主机入侵防御不能只依靠主动地保护。存在许多其它可在系统上获得的可能攻击向量，并且没有主动系统可以保证100％覆盖地防止已知和未知攻击，包括那些还未开发的系统。当前的应用程序和操作系统对于任何入侵防御系统来说都过于复杂，无法精确识别所有可能攻击向量。因此，需要一种可以及时地对任何可能弱点或攻击作出反应的宽广和灵活系统。 

并且，反应性地处理弱点的当前最有效方法是修补系统。当发现弱点时，通常由独立软件销售商(ISV)创建一个补丁。典型的补丁替换可执行文件或动态链接库，需要重新启动应用程序或重新引导系统才能激活补丁。典型补丁进程包括修复代码中的故障，然后重新编译代码和发布带有必要模块的可执行文件。但是，补丁更新非常不利于软件升级：通常需要重新引导应用程序，其是对应用程序的单次整体改变并会改变正常操作行为，消除有问题补丁很麻烦，并且顾客看不见补丁的有效性。 

需要一种解决了上述和其它问题的软件保护技术。 

发明内容

这里粗略描述的技术提供了保护软件的约束注入系统和技术。 

该约束注入系统和技术精确地保护应用程序存储器中弱点本身的附近，而不是系统或网络周围的应用程序存储器的外部。约束通常是插入程序中的少数几个机器指令。约束也可以插入到存储器中程序指令驻留的激活应用程序中。该系统和技术提供了在保持关键业务连续性的同时，解决任何已知类型的软件缺陷的能力，所述软件缺陷包括允许诸如服务的拒绝、特权提升、目录遍历、缓冲器溢出、未授权远程或本地执行/访问、信息泄漏等攻击的那些。该系统和技术对传统修补作了补充，并且由于可以快速部署，缩短了使程序面临攻击的时间。 

新的约束可以不重新启动或重新引导地应用于正在运行的应用程序，和可以周期性地或在需要时提供更新。类似地，不需要升级硬件或其它程序。而且，约束注入技术可以以在启用约束之前精确指示用户/应用程序干扰的风险的直接方式运行，和以启用约束的保护方式运行。 

约束注入系统和技术还通过，例如，服务器、群体或操作系统启用细粒度管理控制。 

本发明提供了一种用于保护软件的计算机实现方法，包含：在补丁点处将约束代码插入计算机程序中，所述约束代码插入发生在计算机程序的运行时期间；当计算机程序的控制流到达补丁点时执行约束代码；其中，约束代码调用检测器和/或补救器函数的库，每个检测器函数检测在计算机程序中何时调用弱点而不改变计算机程序的状态，而每个补救器函数采取补救动作来修复弱点；和当计算机程序正在运行时，在检测计算机程序中的弱点的调用、但不采取补救动作的检测模式与检测计算机程序中的弱点的调用、并且响应于此而采取补救动作的保护模式之间动态地切换约束代码，其中，当计算机程序的控制流到达补丁点时执行约束代码包含：当约束代码已经动态地切换到检测模式时，调用库中的检测器函数而不调用库中的补救器函数；和当约束代码已经动态地切换到保护模式时，调用库中的检测器函数和库中的补救器函数。 

在一个实施例中，保护软件的计算机实现方法包括在计算机程序的指令之间的补丁点处将约束代码插入程序中，和当计算机程序的控制流到达补丁点时执行约束代码。约束代码可以包括，例如，汇编代码或机器指令。约束代码可以调用检测在计算机程序中是否调用了弱点的检测器，和响应检测器而调用补救器(remediator)以采取补救动作。在一种手段中，该插入包括将计算机程序的代码段复制到高速缓存，和将约束代码的至少一条指令插入高速缓存中计算机程序的指令之间的代码段中。在另一种手段中，该插入包括用约束代码的至少一条指令替换计算机程序的至少一条指令，和将至少一个替换指令存储在网关上，在这种情况下不需要高速缓存。 

在另一个实施例中，保护软件的计算机实现方法包括识别计算机程序中的弱点，开发消除弱点的约束，该约束包含在特定点处插入计算机程序中的代码，和向至少一个顾客发布约束。 

本发明还提供了相应系统和程序存储设备。 

附图简述 

图1例示了开发约束的进程； 

图2例示了部署约束的进程； 

图3例示了利用代码高速缓存在应用程序内部署约束的软件结构； 

图4a例示了约束注入系统的信息流； 

图4b例示了使用约束注入系统的网络环境(context)； 

图5例示了调用所部署约束时的控制流； 

图6例示了加载新约束或模块时采用的进程； 

图7例示了部署或移除补丁点时采用的进程； 

图8例示了创建新片段时采用的进程； 

图9提供了示范性约束代码的源代码(检测器和保护器函数)； 

图10提供了NTDLL.DLL，即，用于与Windows

内核交互的核心操作系统组件中的图9的源代码的反汇编； 

图11提供了生成和发送给顾客的带有约束代码的XML文件；和 

图12例示了不利用代码高速缓存地在应用程序内部署约束的软件结构。 

详细描述 

1.引言-弱点的解剖 

虽然约束注入系统可以应用于如在第3部分中所述的许多问题，但主要应用之一是保护计算机程序的弱点。大多数弱点是在软件的正常操作中决不应该发生的边界情况(corner case)。边界情况是在普通操作参数之外发生的问题或状况-尤其是当多个环境变量或条件同时处在极端水平上时表现的那一个。它们通常由开发者在写软件代码时未能考虑到那种情况引起。边界情况导致可以被利用以实施在程序的正常操作假设下应该不允许的动作的弱点。 

对于大多数弱点来说，在程序执行的正确点上执行的、像几个指令(例如，汇编指令)那样的简单检查足以检测边界情况。例如，这样的检查可以确定一个值是否在范围之外，或其中是否存在某些模式。这些检查不检测正常操作下的边界情况。当插在程序中的检查检测到调用了边界情况时，例如返回错误码、改变范围之外的数据值以便在范围内、删截字符串、或改变程序的控制流那样的简单补救足以避免对弱点的利用(exploitation)。在弱点的检查和补救中通常不需要像状态改变或数据结构改变那样的动态程序升级中的难题。 

2.约束注入系统 

我们将介绍可以免于程序弱点的技术。如前所述，通过将简单检查和补  救码插入现有应用程序中可以避免对弱点的使用。约束注入系统是允许为此目的将一个或多个代码段(约束)插入/注入应用程序中的系统。具体地说，约束可以包括确定调用边界情况的时间的检测器代码、和一旦检测到边界情况就采取补救动作的补救器代码。 

一般说来，约束具有指定应用程序，并且每个约束解决一种弱点。通常，约束以应用程序中的具体地址为插入的目标。这个位置由约束开发者指定。一旦注入，通过流过补丁点的控制来触发。 

在应用程序内，命名像库组件和可执行组件那样的特定组件。例如，对于Microsoft Windows

，命名动态链接库(DLL)和可执行(.EXE)文件。一般说来，可以提供任何类型的库和可执行组件供包括Unix等的任何系统使用。应用程序和组件通过版本号和散列数(hash)标识。过滤准则可以用于标识约束的可应用性。 

如下是一组出现在约束注入系统中的一些可能表现中的属性： 

2a.稳定 

约束注入系统本身是稳定的，该系统或该系统内的约束只将最少的中断引入系统中，有助于提高系统的整体可用性。 

2b.安全 

约束注入系统不将任何新的可利用攻击向量引入系统中。为了可靠起见，检查和验证所有通信和约束。 

2c.综合 

大多数约束实现提供了将任意一段代码注入应用程序代码中的任意点的能力。这是具有识别和修复程序中的大多数问题的能力的极为有力工具，因为对修改程序的能力没有什么限制。 

2d.动态 

在将约束注入应用程序存储器中的实现中，可以例如动态地将新约束插入正在运行的应用程序中。在大多数实现中，可以在应用程序正在运行的时候动态地打开和关闭约束。也可以像动态地在检测和保护模式之间切换那样，转换任何顾客可见的切换。 

2e.移除 

在大多数实现中，可以从正在运行的应用程序中移除约束。 

2f.最小 

可以创建解决单个弱点的约束。因此，典型约束应该对整个系统具有最小的影响。一批约束防止系统出现已知弱点。 

2g.顾客可见 

可以使顾客看见约束的状态和统计。例如，每个约束可以具有顾客友好的描述。可以将约束保存成顾客可见的数据库。而且，顾客可以控制各个约束，譬如，打开或关闭它们、和设置检测器或保护器模式。顾客可以观察激活约束的行为，譬如，检测器的调用次数、补救器的触发次数、错误个数、采取的补救动作、和例如打开或关闭、或者检测器或保护器模式的当前状态。还可以提供创建带有顾客可见调试设置的调试日志以便了解假阳性(falsepositive)和错误的能力。约束的状态可以指示其是打开还是关闭、是否可用在系统中、和主动还是被动。该系统也可以收集像调用约束多少次那样有关约束有效性的统计。 

3.通过约束注入解决的问题 

约束注入系统是不局限于解决程序弱点问题的灵活系统。这个部分将描述约束注入系统的这种和其它可能应用。 

3a.修补弱点 

约束注入系统的最基本目的是防止软件系统出现已知弱点。由于这些弱点在针对它们的大多数攻击被发布(release)之前是已知的，及时地防止出现弱点提供了主动入侵防御系统(IPS)。 

3b.防止攻击 

与修补弱点一样，可以创建防止已知攻击的约束。具体地说，通过分析攻击以便了解它如何背离正常程序行为，可以精巧地制作检查和停止那种背离的约束。 

3c.修复程序故障 

由于约束具有改变应用程序中的任何一段代码的能力，可以将它用于修复未导致弱点的许多其它类别的故障。 

3d.过滤内容 

约束可以监视应用程序内的数据流动并搜索和过滤数据。这可以通过插入随数据的移动执行的约束来实现。 

3e.加强安全策略 

约束可以加强应用程序中的安全策略，譬如，通过限制应用程序的现有  功能。约束可以插入限制、绕过或禁用特定特征的代码。 

3f.扩展应用程序功能性 

作为加强安全策略的必然结果，可以将约束用于扩展和加强应用程序的功能性。 

3g.监视应用程序行为 

通过插入对与某程序行为有关的控制流路径的检查，和将相关结果报告给程序外部的监视系统，可以将约束用于监视那种行为。这也可以用于监视系统和应用程序性能、稳定性和可用性。 

4.约束注入系统综述 

约束注入系统可以跨越(span)三个域：创建、管理、和部署。大多数约束在约束销售商、入侵防御系统(IPS)销售商、独立软件销售商(ISV)、开发受到保护的应用程序的原始设备制造者(OEM)销售商、或第三方安全专家的安全实验室中创建。约束可以由约束注入系统的顾客的企业网络运行中心(NOC)管理和支配。NOC通常是管理、监视和监督大型通信网络的物理空间。最后，将约束部署在企业中的主机上。 

约束的基本类型包括：1)以已知弱点、攻击或程序故障为目标的约束；2)可以解决多种多样的问题或加强防范禁闭(lockdown)或其它策略的通用约束(这些约束可能需要配置、调整或训练)；和3)保护出现已知弱点和加强所接受策略的、利用约束注入系统传送的内置约束。通过如下的描述可以进一步了解约束注入系统的功能。 

图1例示了开发约束的进程。一种途径从例如研究人员发布概念证明的利用开始(步骤105)。概念证明的利用提供了在软件中存在具体弱点的依据，并且证明利用是可行的。但是，概念证明可以被攻击者用作构建攻击的路线图。在步骤110中，获取利用代码，譬如，通过安全实验室，和使用工具跟踪利用活动(步骤115)，以便在攻击期间分析利用和它的表现。跟踪是计算机程序执行的步骤的详细记录。随后，识别弱点(步骤135)。 

在第二种可能途径中，发布安全补丁(步骤120)。例如，像微软公司那样的OEM软件销售商响应于发现的弱点，周期性地发布安全补丁。该补丁与原始模块不同，以标识修改码(步骤S125)。然后，安全实验室确定如何强迫程序执行修改码，例如，通过应用正确输入序列或其它适当工具(步骤S130)。随后，识别弱点(步骤135)。 

在第三种途径中，当发布攻击时(步骤160)，获取攻击(步骤S165)，并且在攻击受控时通过观察其对有弱点系统做了什么，跟踪它的活动(步骤170)。随后，识别弱点(步骤135)。通常，当发布攻击时，发布的消息被顾客、软件销售商、软件安全行业协会、和(有时)普通新闻媒体公布，作为对其它人的警告。在其它情况下，顾客可以选择秘密地处理攻击，以避免负面的公布。 

因此，在所有三种途径中，在进行分析之后，识别弱点(步骤135)，并且可以开发约束以检测弱点和对其进行补救(步骤140)。可以将约束代码移植到修补的模块的不同版本(步骤145)。也就是说，在部署时可以存在相同软件的多个版本。这些差异的一些是顾客看不见的(例如，是否应用了较早的补丁)。每种版本通常含有一个或两个稍有不同的文件。因此，应该将补丁移植到可能在顾客机器中运行的文件的所有版本。例如，在向顾客发布之前广泛地测试约束(步骤150)。 

图2例示了部署约束的进程。多种商业模型可以用于向顾客240提供约束注入软件以及约束，以保护顾客的软件。约束注入软件为使用约束提供了框架。在一种手段中，安全实验室210开发出约束注入软件220并且将它直接传送给顾客240。在另一种手段中，安全实验室210开发出约束注入软件220并且将它提供给开发顾客240使用的软件的OEM软件销售商215。OEM软件销售商215转而将约束注入软件220传送给顾客240。 

例如以库的形式传送约束235也可以采取多种途径。例如，安全实验室210可以将约束直接传送给顾客204。或者，安全实验室210可以将约束传送给OEM软件销售商215，OEM软件销售商215转而将约束传送给顾客240。在另一种手段中，安全实验室可以为开发和向OEM软件销售商215或向约束开发者230传送约束225提供工具。这些实体的每一个都可以使用工具来准备约束235并且将它们作为服务传送给顾客240。安全实验室210可选地在约束创建的多个阶段使用弱点信息提供者205的帮助来开发约束。弱点信息提供者205可以是逆向设计程序和/或跟踪和分析有关弱点的信息以帮助约束开发者230创建约束的个体或公司。约束创建的多个阶段一般指图1的步骤110、115或125、130或165、和170。有时，弱点信息提供者205也可以执行步骤135和步骤140的一部分，以减轻约束开发者230的一些约束创建负担。 

在另一种手段中，如果拥有可用资源，顾客自己开发约束和/或约束注入软件。 

图3例示了利用代码高速缓存在应用程序内部署约束的软件结构。还参照图4a，可以与正常企业软件系统一样分发和安装约束注入软件。在顾客站点安装作为中央管理控制台的中央控制器420。中央控制器420生成用于所有节点的安装器，其在每个节点上安装节点管理器430。节点管理器430将像DLL那样的约束库安装到受保护的所有应用程序中。可以以在反病毒系统中布置签名(或DAT文件)的方式部署约束。图3标识了单个应用程序内的组件(例如，应用程序核心440)。预定支持函数库350代表与(例如)部署反病毒系统的签名的方式相似地部署的新约束。管理程序执行引擎(MPEE)305管理代码高速缓存的创建和维护并保证程序执行的所有指令都发生在代码高速缓存内。注意，MPEE的功能性可以用于实现超出约束部署的许多其它能力。约束特定软件用约束管理引擎330、约束网关340、预定支持函数库350、和管理约束360的外部接口表示。预定支持函数库350供应将由约束使用的公共函数库，因此那些函数不必与每个约束一起下载。 

接收约束的原始未修改程序包括例如代码段321，代码段321含有大量指令，例如，指令A 322、指令B 324、指令C 326和指令D 328。原始程序指的是在注入约束防止攻击之前存在的程序。管理程序执行引擎(MPEE)305控制安全代码高速缓存310的创建和管理。有关安全代码高速缓存310的可能实现的进一步细节可以在2005年1月13日公布、名称为“利用代码高速缓存安全执行计算机程序(Secure Execution Of A Computer Program Using aCode Cache)”的美国专利申请公布第2005/0010804号(代理案号ARAK-01000US0)中找到，该专利申请特此引用以供参考。 

MPEE 305从原始代码段321中创建修改代码段311。具体地说，修改代码段311包括插在指令B 324和指令C 326之间的补丁点处的保存环境指令312、改变堆栈指令313、调用网关指令314、返回状态指令315、和恢复环境指令316。这里，我们假设约束是利用单个检测器/补救器函数插入单个位置中的单个单元。但是，也可以利用补丁点的集合提供约束，其中每个补丁点拥有它自己的插入点、检测器和/或补救器函数(参见图7)。一般说来，可以将约束插入应用程序中的任何位置。这些位置不需要预定。插入约束的特定位置由约束开发者指定。保存环境指令312的功能是保存应用程序环境，  改变堆栈指令313的功能是将堆栈从当前堆栈改变成MPEE堆栈，返回状态指令315的功能是将检测器的状态返回给用户，调用网关指令314的功能是调用约束网关340，以及恢复环境指令316的功能是恢复应用程序环境。有关进一步的细节请参见图5。环境主要通过寄存器表示。每个环境将含有它自己的堆栈。但是，当前堆栈通过堆栈指针寄存器标识，因此，改变寄存器将改变堆栈。 

约束管理引擎(CME)330与MPEE 305协调，以便当原始代码段321从原始程序位置320复制到安全代码高速缓存310时，它被正确修改，以反映修改的代码段311。当控制流调用约束时，它调用约束网关340。具体地说，当控制流经过修改段311时，调用网关指令314调用约束网关340。约束网关340利用约束管理系统330给出的部署状态，调用约束库370中的一个或多个适当约束。可以将不止一个约束附在同一指令上。约束库370包括检测器372和补救器374，其转而又可以从预定函数库350中调用一组预定函数。请参见第19部分。预定函数可以包括，例如，多个约束可以使用的字符串复制、字符串比较、和其它函数。约束库370还包括如下面第9部分讨论的约束描述符376。约束网关340随后使调用返回到代码段311，譬如，返回到返回状态指令315。 

检测器372确定修改段311是否试图调用弱点，在这种情况下，报告该事实和调用补救器374。检测器372应该对程序没有负面影响，譬如，改变程序状态。也就是说，检测器代码不应该修改任何程序可见存储器或程序寄存器，获取程序可见的资源，修改程序控制流，或破坏和挂起系统。应该捕获异常条件，并应该无限循环地作出检查。如果遇到问题，可以从约束退出。为了重现问题，可以禁用约束。 

补救器374具有改变应用程序以修复弱点的能力，譬如，通过改变任何应用程序可见存储器位置，或改变程序的控制流，例如，通过从当前应用程序函数返回或跳过跳跃程序之后的少数几条应用程序指令。跳跃程序是在运行时创建的一小段代码，主要在堆栈中。生成这个代码是为了帮助从一个地方到另一个地方的程序转移控制。原始代码使控制转移到跳跃程序代码，然后跳跃程序代码使控制转移到目的地。对于跳跃程序来说，存在许多种用法。例如，当目的地在编译时未知时，跳跃程序可以不修补二进制(binary)地进行控制转移。当分支的类型未知(短或长)时，跳跃程序可以帮助插入大小可  变指令。跳跃程序还可以用于处理长分支。 

也可以采取允许程序级别补救动作，譬如，杀死线程和/或进程和抛出异常。补救器代码应该只在停止攻击所需的最低程度上改变程序行为。 

约束管理引擎330通过外部接口与外界协调，以便管理约束360，例如，设置约束的部署状态，以及加载新约束库。例如，外部接口360可以通过节点管理器430与中央控制器420通信。 

在一种可能实现中，约束系统可以在Microsoft因特网安全和加速(ISA)服务器上实现。 

图4a例示了约束注入系统的信息流。约束可以由，例如，授权的安全实验室410开发。具体地说，可以开发一起构成约束(例如，图2中的约束235)的独立约束412和约束信息文件414。有关约束的附加细节将在下面作进一步讨论。当需要新约束时，开发它并且使它对于用户可用。安全实验室410可以通过例如将约束下载到顾客站点的中央控制器420，将约束传送给顾客的企业网络运行中心(NOC)。中央控制器420管理约束和将它们部署在企业的端点，譬如，服务器、用户台式机或其它计算机上。通常，企业拥有使企业用户能够运行受约束保护的应用程序的大量服务器和主计算机，例如台式计算机、膝上型计算机、移动设备等。服务器加强相关应用程序中的约束。在一种手段中，为了达到这个目的，服务器可以使用像可从Determina公司(Determina Corp.，Redwood City，California)获得的Memory Firewall^TM (SecureCore)那样的基础设施。 

服务器也可以将有关稳定性和可能假阳性的信息提供给中央控制器420，从而使部署简便和提高整体可用性。当触发一个事件时，服务器节点可以利用智能将安全事件与假阳性区分开，并且还在中央控制器420上汇集信息以提高精度和通知系统管理人员。而且，每个服务器或其它端点还可以拥有起中央控制器420与每个独立应用程序内的应用程序核心440之间的中介作用的节点管理器430。 

中央控制器420将约束存储在约束存储器422中，并且在约束信息模块424中收集有关约束的当前状态的信息。部署设置和状态模块426使管理人员能够管理约束的部署和将当前状态通知管理人员。统计模块428收集有关约束的统计数据。有关进一步的信息请参见下面第12部分。 

此外，在图4a中，在节点管理器430和核心440之间，记号“只读存储  器”表示通过在两个进程之间共享存储页面将约束信息从节点管理器430传递到应用程序440的机制，记号“约束库加载”表示节点管理器430将信息从图3的库350和370加载到应用程序440中，和记号“通知”表示通知应用程序440新信息可用的机制(例如，这可以利用中断型或轮询型机制实现)。在通知中还可以提供例如打开、关闭、检测或保护等，用户对约束部署的偏好。记号“只读存储器”表示将当前操作特性从应用程序440传送到节点管理器430的共享存储页面。例如，可以提供与约束部署有关的状态信息和统计。最后，记号“事件日志”表示可以将核心440生成的事件日志记录在节点管理器430中。 

图4b例示了使用约束注入系统的网络环境。在一种可能手段中，安全实验室460通过因特网470或其它WAN(广域网)或LAN(局域网)将约束注入软件和约束提供给像企业475那样的一个或多个企业。企业475中的控制器服务器480将约束注入软件和约束提供给企业中的一个或多个服务器和/或主机，例如示例性服务器482和示例性主机490。控制器服务器480提供图4a中的中央控制器420的功能。服务器482和主机490上的节点管理器484和492分别提供图4a的节点管理器430的功能。服务器483可以是运行一个或多个应用程序486或其它计算机应用程序的应用程序服务器，而主机490可以是台式计算机、膝上型计算机、PDA(个人数字助理)、蜂窝式电话或运行一个或多个应用程序494或其它计算机应用程序的其它设备。应用程序486和494可以分别完全在服务器482或主机490本地运行，或可以是分布式应用程序的服务器方一部分和客户机方一部分，在这种情况下，主机490是服务器492的客户主机。应用程序486和494提供图4a的应用程序核心440的功能。 

图5例示了调用所部署约束时的控制流。该控制流被划分成指示是否涉及安全代码高速缓存、约束网关、或约束库的三个部分。在安全代码高速缓存上，当程序计数器到达补丁点时，执行修改段(311，图3)(步骤502)。安全代码高速缓存中的插入代码保存应用程序环境(步骤504)，将堆栈改变成MPEE堆栈(步骤506)，和调用约束网关以便使控制转移到网关(步骤507)。 

约束网关识别执行的约束(步骤522)。如果激活和选择了约束(判定块524)，则调用约束库中的检测器(步骤542)。如果当前约束未处在保护模式下，则将检测器状态返回给用户(步骤508)，并且在恢复应用程序环境之后(步骤510)继续执行应用程序代码(步骤514)。因此，即使在保护模式下  未部署约束，也可以报告状态信息、统计等。如果当前约束处在保护模式下(判定块526)，和如果来自检测器的返回码指示有必要补救(判定块528)，那么，调用补救器(步骤544)。取决于补救器的返回码(判定块530)，可以采取不同途径。在一种途径中，终止当前线程和/或进程(步骤532)。在第二种途径中，使控制流改变到不同应用程序地址，在这种情况下，找出或创建来自跳转目标的片段(步骤512)，恢复修改的应用程序环境(步骤516)，和执行该片段(步骤518)。在第三种途径中，从调用约束的点开始继续执行程序，在这种情况下，恢复可能修改过的应用程序环境(步骤510)，和继续执行该片段(步骤514)。 

图6例示了加载新约束或模块时采取的进程。注意，模块是应用程序的单元，和应用程序由多个模块建成。可执行文件和每个库都是模块。图6涉及应用程序加载新库，以及约束系统获取新约束。还参照图3，指令312、313、314、315和316由MPEE 305/CME 330插入。它们不是约束或应用程序(模块)的一部分。指令322、324、326和328来自应用程序(模块)。 

当加载新约束时(步骤605)，记录有关约束的信息(步骤610)。接着，针对列在约束中的所有受影响的应用程序和应用程序内的模块(步骤615)，系统进行检查，看看应用程序当前是否正在运行和当前是否加载了模块(判定块620)。注意，步骤620被步骤615调用多次-每个模块一次。如果加载了模块，则进行附加检查。例如，可以针对提供的版本检查存储器中的模块的版本(判定块625)。具体地说，当将新模块装入存储器中时(步骤655)，针对每个约束(步骤660)，查询所有激活的约束，看看它们的任何一个是否都包括部署的约束(判定块665)。因此，在判定块625，可以将提供的模块的版本与存储器中的模块的版本相比较。如果所有检查都通过了，则针对模块中的每个补丁点(步骤630)，执行补丁点选择逻辑(判定块635)。补丁点选择逻辑与匹配约束应用程序策略有关(下面第11部分)。如果补丁点选择逻辑选择部署，则计算补丁点附近的程序位的散列值，并且将它与散列检查的提供的散列值相比较(判定块640)。如果散列检查指示匹配，部署补丁点(步骤650)。 

当未加载模块(判定块620)，模块版本不匹配(判定块625)，补丁点选择逻辑未选择部署(判定块635)，或散列检查未指示匹配(判定块640)时，完成该进程(步骤645)。 

图7例示了当部署补丁点(步骤705)或移除补丁点(步骤710)时采取的进程。通常，约束可以拥有补丁点的集合。每个补丁点拥有它自己的插入点、检测器、和补救器函数。正如前面所讨论的那样，约束也可以只涉及到一个补丁点。在任一种情况下，即部署或移除补丁点，如果包括补丁点的代码段当前处在安全代码高速缓存中(判定块715)，则从安全代码高速缓存中清除(flush)那个片段(步骤720)，并且在需要时重建它。否则，在步骤725中结束该进程。在部署新补丁点的情况下，用在代码高速缓存中重建新片段时含有必要标注(callout)的新片段替换安全代码高速缓存中没有对约束网关的标注的原始代码段。在移除补丁点的情况下，清除含有标注的片段，并用在代码高速缓存中重建时没有必要标注的新片段替换它。 

图8例示了当创建新片段(例如图3中的片段311)时采取的进程。具体地说，该图描述了创建新片段时(步骤805)MPEE和CME采取的动作。针对所有激活/部署的补丁点(步骤810)，进行检查以确定补丁地址是否在片段的地址范围内(判定块815)。如果找到补丁点，那么，当创建/复制片段指令时，检查每条指令(步骤820)，以确定它的地址是否是补丁地址(判定块825)。在补丁地址的指令上，将代码插入片段中，以保存和恢复应用程序环境和调用网关(830)。然后，更新网关用于标识补丁的数据结构(步骤835)，和继续创建片段(步骤840)。如果在判定块815中未找到补丁点，则继续创建片段(步骤840)。 

5.约束类别 

约束可以通过它们与企业中的终端用户或系统管理员的交互来分类。5a.黑盒约束 

约束开发者拥有将约束提供成黑盒约束的选项。黑盒约束不允许顾客拥有任何约束前配置。顾客拥有的唯一选项是判定部署约束的地方。但是，约束注入系统可以为所有约束提供通用选项，譬如，以侵入检测系统(IDS)或入侵防御系统(IPS)模式部署的能力。在IDS模式或检测模式下，检测侵入，但不采取预防性动作，而在IPS模式或保护模式下，除了检测之外，还采取预防性动作。因此，IDS模式可以指示启用约束之前用户/应用程序干扰的风险。针对弱点、攻击和故障的大多数约束在提供为黑盒约束时在使复杂性最小化的同时可以满足顾客的需要。 

5b.参数暴露(parameter-exposed)约束 

用户可以将一组变元(或参数)应用于约束以调整该约束。并且，约束可以检查普遍的或一般的问题。这样的约束可能需要调整成与每个应用程序和部署情形匹配。因此，该约束可以向顾客暴露约束前接口。大多数策略加强约束适合这个类别。 

5c.GUI暴露约束 

参数暴露约束的高级形式含有与之相关联的图形用户界面(GUI)部件。这可以利用简单GUI创建语言、伴随Java或Active-X部件，或任何其它GUI技术实现。 

5d.顾客开发约束 

最终，可以向顾客暴露用于约束开发的应用程序编程接口(API)。 

6.约束范围 

约束的范围在其插入任意代码的能力方面可以不受限制，或限制为适合诸如API拦截的程序修改的特定方法。API拦截(interception)指的是在API级别上捕获应用程序与操作系统之间的交互。这个部分描述了一组可能的范围限制，以及检测器和补救器模型。 

6a.任意代码块注入 

约束注入系统具有以小块汇编代码的形式将约束插入程序中的能力。这向约束提供了最高权力，因为它提供了没有限制地监视或改变程序的行为的能力。 

6b.限制的代码块注入 

可以根据一个或多个应用程序二进制接口(ABI)限制汇编代码注入。ABI是检测器和补救器中的代码必须遵守的一组规则。用于检测器和补救器的ABI规则是不同的。ABI描述应用程序与操作系统之间、应用程序与它的库之间、或应用程序的组成部分之间的低级接口。ABI允许编译的目标代码利用兼容ABI不对系统进行任何改变地起作用。ABI可以定制成在不允许可以负面影响应用程序的额外权力的同时支持所有必要功能。例如，用于数据纠正的约束的ABI将不允许对应用程序状态的任何修改或任何应用程序控制转移。 

6c.检测器和补救器代码块注入 

用于弱点的约束可以在检测器/补救器范例内开发，因为大多数弱点是由在正常操作下决不应该发生的边界情况引起的。正如前面讨论的那样，检测  器检查边界情况的发生，并且当检测到边界情况时，补救器采取必要的补救动作。因此，检测器可以遵从非常严格的ABI，从而它可以提供不改变正常程序行为的强有力保证。这可以通过限制检测器以使它不能改变正常程序状态来实现，包括： 

●不能修改任何程序可见存储器或程序寄存器； 

●不能获取程序可见资源； 

●不能修改程序的控制流； 

●不能破坏或挂起程序； 

-这可以通过捕获任何异常状况和通过检查无限循环来实现。 

当在检测模式下运行约束时，它不影响正常程序操作。这很重要，因为一些约束可以生成假阳性，并且作为这些假阳性的结果采取的补救动作可以影响正常程序行为。在这种模式下，顾客可以不影响应用程序地观察和测试假阳性的约束。 

补救器具有修改程序状态和改变程序的控制流的能力。但是，用于补救器的ABI也可以通过向其提供接口以便作出补救动作来限制。 

简单约束(指检测器和补救器两者)是无状态的。但是，可以扩展约束注入系统，以便约束可以捕获、存储、修改和自始至终或与其它约束共享内部状态。约束-状态信息应该与程序状态分开。 

6d.API拦截的确认(validation)例程 

由于API是程序中公众可见的、并因此稳定和已知的点，它们为拦截提供良好机会。确认例程可以确认在API调用中传递的变元。由于所有系统调用都实现成API，API拦截是系统调用拦截的扩展集。 

API确认器(一种约束类型)也是一小块汇编代码。但是，这个块必须遵守甚至比通用约束所遵守的更严格的ABI形式。例如，这个代码只能访问作为API的输入数据结构的一部分的存储器。API确认器ABI将向API提供对每个变元的访问。确认各个API的变元的数据类型，因此使允许的访问更精确和更严格。 

API确认器还可以扩展到容纳与输入过滤相似的简单拦截，其中，对于给定API和变元，提供规则表达式以确认变元。 

6e.输入过滤的规则表达式 

典型的输入过滤器是规则表达式。对照规则表达式检查到应用程序的所  有输入(输入的类型通过策略给出)。用于构建规则表达式的字母可以包括ASCII(美国信息交换标准代码)和Unicode(统一字符编码)字符、存储器地址和通过API定义的一组特殊项。如果需要，可以开发出功能更强大的语法来表达输入过滤器。 

分析每个应用程序以找出适当的过滤点。如表1所示，过滤器和过滤点被标记成属于一个或多个类别。对于未分析和标记的应用程序，可以使用一组通用规则来标识过滤什么和每个过滤点与什么类别相联系。表1提供了可能的输入点类别的局部列表。 

表1 

名称：	类别：	描述
			EI	外部输入	来自外部源的所有输入
EIR	处理前的外部输入	照原样输入(可能加密或未扩展)
			EIO	处理后的外部输入	扩展、解密和重新组装之后的输入
EO	外部输出	发送到系统以外的数据
			FN	文件名	文件的名称
FNR	文件名-读取	要读取的文件的名称
			FNW	文件名-写入	要写入的文件的名称
FNC	文件名-创建	将创建的文件的名称
			FC	文件内容	从文件读取/写入文件中的数据
FCR	文件内容-读取	从文件读取的数据
			FCW	文件内容-写入	写入文件中的数据
CS	命令串	执行的外壳命令

可以使用两种类型的监视器用于输入选择： 

1.通用监视器-利用例如Microsoft Windows

，可以创建特殊API拦截器，作为可以应用于任何程序的通用选择器。 

2.定制监视器-全面了解给定程序，可以对输入过滤监视特定拦截点。 

7.约束补丁点识别 

精确描述将约束插入应用程序代码中的什么地方是重要的。在执行应用  程序代码时，当控制流经过补丁点时，调用约束。这个部分描述约束的可能补丁点。 

7a.地址偏移 

当将约束插入已知模块(例如，可执行文件或库)中时，可以提供相对于模块的开始地址的偏移以指示补丁点。 

7b.绝对地址 

如果保证模块不被加载器重新定位，则可以使用绝对地址描述补丁点。 

7c.符号偏移 

为了支持可能稍有不同的模块的多种版本，可以提供具有偏移的符号地址来描述补丁点。约束注入系统可以解析符号地址和加入偏移以确定实际插入点。 

7d.API拦截钩子(interception hook) 

为了描述操作系统或公共库提供的API函数上的约束，可以使用函数的名称。因此，约束可应用于库的多个主要和次要版本。而且，可以不访问应用程序地创建约束。 

7e.系统调用钩子 

可以在系统调用之前和/或之后插入约束。系统调用可以通过进行内核转移的特殊机器指令标识。像Microsoft Windows

那样的一些操作系统在版本之间重新编号系统调用，在这种情况下，根据操作系统(OS)版本将系统调用映射到调用号的表格可以用于允许系统调用标识适用于多个OS版本。 

7f.代码模式匹配钩子 

取代识别位置，约束注入系统可以检查一批具体指令，以识别插入约束的地方。简单搜索涉及到匹配确切代码序列。但是，这种搜索可以是复杂的。例如，可以使用规则表达式匹配。 

7g.多模式 

多模式系统使用例如符号偏移或系统调用的准则识别一般区域，然后搜索那个区域找出代码模式以定位确切的补丁点。对于多模式选择，存在其它可能组合。地址计算也可以包括更复杂的算法。 

8.约束注入方法 

约束注入系统的一个重要方面是用于将约束注入应用程序代码中的方法。一些注入方法只提供约束注入系统的所需属性的分集。这个部分描述少  数几种可能注入方法。 

8a.跳跃程序(trampoline)方法 

约束可以通过将跳跃程序，或较短片段的代码插入应用程序模块的存储图像的给定位置来调用。由于这个插入应该与其它激活线程同时发生，跳跃程序插入必须是原子的。而且，它可以覆盖有效指令边界上的指令。这些限制对可以安装跳跃程序的地方和可以插入的指令的类型施加了限制。在将控制转移到约束代码块之前必须短跳转到附近位置。 

8b.代码高速缓存方法 

前面结合图3讨论的这种方法涉及到创建原始程序的指令块的高速缓存和执行高速缓存当中的指令的系统。可从Determina公司(Determina Corp.，Redwood City，California)获得的Memory Firewall^TM是创建指令高速缓存的系统的例子。但是，也可以使用其它手段。由于指令高速缓存重新映射地址空间和提供从原始地址到高速缓存地址的应用程序透明翻译，可以改变指令块的形状。因此，可以通过扩展高速缓存中的块将多个指令插入程序指令块中。而且，提供高速缓存管理系统的MPEE305(图3)可以提供多个线程之间的同步，以便代码插入无需是原子的，允许多个指令插入。这为约束注入提供了灵活框架。当将代码块复制到代码高速缓存时，约束注入系统可以进行检查，看看激活约束是否被指定为插入那个块中。如果如此指定了激活约束，约束注入系统可以利用约束代码重写该块或将调用插入约束块中。如果新约束在应用程序正在运行的时候到达和插入点已经在代码高速缓存中，则可以清除高速缓存块并用插入的约束重新创建高速缓存块。重新创建可以在程序计数器下一次传送到那个块时马上或缓慢地发生。 

8c.二进制重写(binary rewrite)方法 

在这种方法中，可以离线修改可执行文件或库，以便通过，例如，插入跳跃程序或重新安排代码插入约束。约束可以是内嵌的，或可以将约束函数加入模块中。注意，这种方法不能提供约束的动态注入。 

8d.目标代码重写方法 

在这种方法中，修改发生在程序开发工具链中。这可以发生在任何点上，譬如，在编译器、汇编器、或链接器上。 

8e.字节码修改方法 

这种方法在将程序发布成字节码的时候应用，和可以通过加载器重写字  节码以包括约束，在解释器中执行约束，或在字节代码被翻译成机器代码时将约束插入即时(Just In-Time)编译器中。 

8f.应用程序/系统定义的拦截点方法 

操作系统和复杂应用程序为插入监视或改变应用程序行为的功能提供API。在这种方法中，可以利用应用程序或OS提供的这些API之一创建应用程序或操作系统专用约束注入系统。当底层应用程序或操作系统调用API时将调用约束。但是，这样的系统不支持在应用程序中任意点上的插入。 

8g.加载器重写方法 

当将模块加载到存储空间时，加载器可以扫描模块和插入任何可应用的约束。这可以通过插入跳跃程序或通过重新排列模块中的代码内嵌约束来完成。但是，加载器方法不支持加载库或可执行文件之后的动态插入。 

8h.系统调用薄片(system call shim)方法 

在这种方法中，可以利用来自用户空间或内核空间的系统调用薄片来实现允许监视系统调用的约束的受限形式。 

9.约束描述符 

约束描述符376(图3)提供帮助约束注入系统判定何时、何地和如何应用约束的、与每个约束相联系的描述。约束描述符存在许多可能变型。下面提供约束描述符的两个示范性实例。具体地说，表2提供了基本约束描述符，而表3提供了扩展约束描述符。 

9a.基本约束描述符 

表2描绘了每个约束提供的描述符的实例。该例子适合与MicrosoftWindows

一起使用，但也可普遍使用。一种可能的表示使用了可扩展标记语言(XML)文件。在一种手段中，约束可以使用这种描述符。 

表2 

描述符	定义/注释：
		xml_file_version	XML文件版本
xml_file_timestamp	创建XML文件的时间戳
		xml_file_signature	利用私钥生成的签名；用于在顾客站点通过管理控制台验证XML完整性。
constraint_injection_engine_version+	约束注入系统的版本

 

policy+	顾客可见的单元大小。这是顾客配置和观看结果的级别。策略为单个弱点通知(例如，安全公告)，比如说，Microsoft的MS-2004-0120定义属性和约束。但是，这样的通知可以修复不止一个要排除的弱点，因此，一个策略可以解决不止一个弱点。
		policy_id	标识策略的唯一正整数。如果发布新版本替换旧版本，则是相同的。
Name	策略的字符串名。顾客可见。
		Description	描述策略的注释字符串。顾客可见。
external_id	Common Vulnerabilities andExposures(CVE )#、像Microsoft CAN#那样的Candidate(CAN)CVE#、或通过外部源识别补丁的其它东西。
		Version	主要用于管理控制台以过滤相同约束的不同版本和只将最近版本发送到核心。
policy_class	如下之一：VULNERABILITY-防止已知弱点。通常从检测模式开始。ATTACK-防止已知攻击。最好直接进入保护模式。LOCKDOWN-加强系统防范禁闭。由于这是可选的和需要顾客交互，默认时应该处在关闭或检测模式下。MONITOR-监视应用程序中的指定活动。这可以用于帮助外部事件相关器(correlator)。这里，补救器(remediator)应该具有检测器的特性，即，不修改应用程序。它应该发出可以被事件相关器

 

	汇集的消息，因此，开始可以以关闭或保护模式开始。
		constraint_all	约束DLL或其它没有路径的库的基本名称。核心假设所有DLL将在中央控制器管理的DLL高速缓存中，例如，在单个目录中。
constraint_dll_hash	核心用来验证“constraint_dll”未被窜改的散列值。
		os_major*(“*”指示该项出现零次、一次或多次)	指定策略可应用的操作系统，例如，Windows 2000、2003或XP。只用于通过管理控制台的过滤和顾客可见性；不用于核心。
os_servicepatck*	操作系统的服务包编号
		os_patch*	操作系统的补丁级别
executable_list*	可执行文件名的列表，没有路径；只用于通过管理控制台和节点管理器的过滤，和用于顾客可见性；不供核心使用；空意味着可应用于利用所涉及的DLL的任何可执行文件
		Timestamp	为策略创建时间戳
Mode	针对这种策略的应用程序的默认模式。可以是检测、保护或关闭。
		constaint_reset_function	在注入、清除和异常-中断时将被调用以便初始化/重置状态的“constraint_dll”中的函数的符号或相对于基地址的偏移。
vulnerability+(“+”指示该项将出现一次或多次)	每个“vulnerability”为策略中的一个弱点定义约束。如果“策略”打算处理多于一个弱点，那么，对于每一个弱点应该有“vulnerability”。这是顾客看不见的，只有“external_id”可见；其用于内部跟

 

	踪。顾客看不见的原因是他们只看见，例如，MS-####-####，不是它修复的所有弱点。
		vulnerability_id	标识弱点的唯一正整数。
Description	描述“部件”和对它的约束的注释字符串。
		set+	每个“set”定义受弱点和相应约束影响的所有模块。“sets”用于处理可能具有需要修补的相同弱点的一个或多个模块的不同版本。这是通过为需要补丁的每组模块版本定义不同“set”完成的。对于给定进程，应该只有一个“set”可以应用，即“set”是相互排斥的。
module+	定义要修补的模块、它的特性、补丁点和约束代码。
		pe_name	用于标识要修补的模块。即使它是“”，也必须指定一个值。
pe_checksum	同上。即使是零，例如，无论在可移植可执行文件(PE)中还是在其它可执行文件中，都必须指定。
		pe_timestamp	同上。
pe_size	同上。
		hash+	一组散列定义，每个补丁点一个，用于验证每个补丁点是正确的。即使一个不匹配，也拒绝PE文件。
start_addr	将从中计算散列值的、相对于基地址的偏移。
		Length	要用在散列值计算中的字节数
hash_value	要对照检验的散列值。
		patch_point+	定义要修补的偏移和用于它的约束代码。

 

offset	要修补的模块的符号或相对于基地址的偏移。
		detector_fn	指定检测器代码以便调用的约束DLL的符号或相对于基地址的偏移。
remediator_fn	与上面相同，但用于补救器。
		return_addr	如果补救器请求，在执行了补救器代码之后控制应该转到的待修补模块的符号或相对于基地址的偏移。这使补救器可以改变应用程序执行的流向。
precedence	如果在相同“offset”上必须注入两个约束代码，决定首先注入哪个约束代码的全局排序。

9b.扩展约束描述符 

如下的字段(表3)可以用于补充或替换基本描述符(表2)中的字段，以提供约束描述符的更广泛形式。 

表3 

名称	类型	描述
			Unique ID	Num1.Num2.Num3	Num1-原创者的唯一编号；Num2-原创者唯一指定编号；Num3-年度
Type	POL	策略约束
			GEN	防止一类攻击的通用约束
VUL	防止已知弱点的约束
			ATT	防止已知攻击的约束
ConstraintType	CODEBLK	具有代码块的通用约束
			SYSCALL	API拦截器
INPTFIL	输入过滤器

 

	INPTMONC	拦截已知特定输入点和为输入过滤提取输入的监视器代码。与运行时系统连接。
			INPTMONG	使用API拦截为输入过滤拦截通用输入点的监视器代码。与运行时系统连接。
Originator-Major	短字符串	约束的原创者/创建者的名字
			Originator-Minor	短字符串(可选)	有关组织内的原创者的一些描述性信息
Confidence	0到15之间的数字	提供原创者对没有假阳性的置信度0-可以存在假阳性15-不能存在肯定
			Importance	0到15之间的数字	原创者对于这个约束有多重要的评估0-可选约束，不那么重要15-关键约束，极其重要
Invalidates	唯一ID的列表(可选)	被这个约束取代的约束
			Requires	唯一ID的列表(可选)	部署这个约束所需的约束
Applies to	<nm.，ver.，info>的列表	Nm.-可执行文件或DLL的名称Ver.-版本号，在版本字段中可以包括“*”以标识所有次要处理Info.-不同约束类型的特定信息
				CODEBLK	要插入检查的、相对于代码段开头的偏移

 

	INFO	SYSCALL	要监视的、系统调用的名称或编号
				INPTFIL	要过滤的、输入的类型
INPTMONG	可用于过滤的输入的类型和API名称
				INPTMONC	可用于过滤的输入的类型和用于插入检查的、相对于代码段开头的偏移

10.约束语言 

约束注入系统可能要求每个约束一起提供机器指令和约束描述符。这可以是任意指令块或遵守一组给定规则，例如，严格ABI的指令块。当约束注入系统调用约束时，可以执行这个代码块。约束注入系统可以支持这些语言的混合。注意，在基于检测器和补救器的解决方案中，每个约束可以携带两个代码块，一个用于检测器和另一个用于补救器。约束可以利用如下技术实现。 

10a.库中的函数 

当注入约束时，像DLL那样的库文件可以提供约束的代码。这个库可以具有约束注入系统调用的约束的输出函数。每个库可以具有多个约束的函数。约束注入系统可以支持具有所有约束的单个综合库，或每一个只具有新约束的多个库。 

10b.机器指令函数对象 

取代依赖于加载器加载约束函数库，约束注入系统可以直接提供约束函数的机器码。这个信息由约束注入系统复制到程序的存储器。但是，约束注入系统必须解析符号和进行链接。所需的链接功能很简单，因为约束函数具有非常有限的ABI。而且，不向应用程序暴露约束函数使约束注入系统更透明。另一个问题是代码的重新定位。约束注入系统可以执行重新定位或需求位置独立代码。 

10c.机器指令代码块插入 

当构建代码高速缓存时，可以在适当位置直接将作为代码块提供的约束代码内嵌到应用程序代码中。当执行约束时，这可以导致更好的性能。 

10d.机器指令代码块替换 

这与机器指令代码块插入非常相似，其中，取代插入代码块，替换现有代码块。 

10e.字节码 

取代提供机器指令，可以使用字节码来描述约束。当约束代码必须遵从受限ABI时，字节码提供加强那个ABI的简单方式。字节码应该具有到机器指令的简单映射。 

表4提供了简单约束字节码格式的例子。字节码可以是约束描述符的一部分或独立文件。SP表示空隔。 

表4 

字节码	机器指令/注释：
		constraint_code	“[”[SP]<globals>SP<all_cons>[SP]“]”
		globals	“(”[SP]<num_glob>_SP<glob_list[SP]“)”
num_glob	glob_list中的数据单元的计数
		glob_list	<glob_list>[SP]<data>|<data>|e
data	“<”[SP]<num_bytes>[SP]“>”|“<”[SP]<num_bytes>SP<init_string>[SP]“>”
		num_bytes	要分配的字节数的数值
Init_string	十六进制字节字符串。字符串中的字节数应该小于或等于num_bytes
all_cons	<num_cons>[SP]<cons_list>
		num_cons	cons_list中的计数约束单元
cons_list	<cons_list>[SP]<constraint>|<constraint>
constraint	“(”[SP]<offset>SP<num_inject>[SP]<inject_list>[SP]“)”
		offset	开始注入地址是DLL或其它库的基地址加上偏移

 

num_inject	inject_list中的注入单元的计数。注入单元的数目必须小于256。
		关于如下条目，注入列表的注入单元，例如，约束代码段将被依次插入程序中。因此，流过注入单元的最后指令的控制将到达下一个单元的第一指令。在执行了最后注入单元中的最后指令之后，将执行基本块的第一指令，即在偏移所指的地址上的指令。注意，不指定指令的地址，而是通过MPEE重新定位指令。
inject_list	<inject_list>[SP]“<”<inject>“>”|“<”<inject>“>”
		inject	<instr_string>|<branch_instr>|<library_call>|<lea>|<frame_in>|<frame_out>
如下条目提供了指令的字节串。可以按小尾方式(little endian)或大尾方式(big endian)标准化。
		instr_string	“X”<instr_pack>
instr_pack	非控制转移指令列表的十六进制字节串。列表中没有列出使用PC偏移的指令
		branch_instr	“B”<jump short>|“B”<jump absolute>|“B”<return>
jump_short	<js_opcode><js_num>
		js_opcode	Jcc(如果满足条件就跳转)指令的操作码的十六进制字。只支持跳转短指令。有效操作码是：JO     70    JS     78JB     72    JNS    79JNO    71    JP     7AJC     72    JPE    7AJNAE   72    JNP    7BJAE    73    JPO    7BJNB    73    JL     7CJNC    73    JNGE   7CJE     74    JGE    7DJZ     74    JNL    7DJNE    75    JLE    7E

 

	JNZ    75    JNG    7E JBE    76    JG     7F JNA    76    JNLE   7F JA     77    JCXZ   E3 JNBE   77    JECXZ  E3
		js_num	十六进制格式的两个字节。整数标识来自cons_list的约束。约束按照它们在约束列表中的顺序隐含地从0开始向上编号。这个编号被翻译成正确的相对地址，以便分支采用到那个约束的开头的控制。
jump_absolute	具有以操作数给出的绝对地址的JMP(跳转)指令的字节串。有效指令是：JMP ptr16：16  EA cdJMP ptr16：32  EA cp
		return	返回指令之一的字节串：RET  C3RET  C2XXRET  CAXX
如下的条目提供了加载全局数据项的地址的机制。注意，调用全局将需要使用这种受限格式来获得地址。
		lea	“L”r32data_num
r32	选择32位寄存器之一的一个字节整数值。EAX  0ECX  1EDX  2EBX  3
		data_num	十六进制格式的两个字节。整数标识来自glob_list的数据项。数据按照它们在glob_list中的顺序隐含地从0开始向上编号。这个编号被翻译成正确相对地址，以便加载有效地址将加载数据的指定位置的

 

	开始地址。
		如下两个伪指令为约束指令创建新框架以使用和恢复应用框架。“frame in”将堆栈切换到内部DR堆栈和保存原始寄存器和算术标志(不是浮点环境)。“frame out”恢复原始应用框架，和将寄存器和算术标志恢复成调用frame_in时的状态。在约束内只能发出单个frame_in。当发出frame_in时，在给出返回到应用程序的控制之前需要单次调用fram_out。注意，由于库调用需要可用堆栈，这不能作为库调用完成。
frame_in	“FI”
		frame_out	“FO”
如下指令调用来自约束注入支持库的库例程。调用框架建立和破坏与正常C调用惯例类似。因此，为了调用库函数，需要给出新框架。
		library_call	“C”library_num
library_num	十六进制格式的两个字节。整数标识要调用的库例程。

11.约束应用策略 

将在约束描述符中提供的信息与当前机器状态(例如，OS的版本、应用程序、加载的库等)、当前威胁情景、有关其它相关约束的信息和用户指令相结合，约束注入系统可以决定应该将约束注入哪些应用程序中、和在什么时候完成那个任务。给定应用程序的约束的过滤可以利用如下信息/准则进行： 

●OS版本； 

●在应用程序中存在给定模块； 

●可执行文件和模块的文件名。例如，可执行文件可以是Microsoft Win-dows

可移植可执行文件(诸如EXE、DLL、ActiveX控制、和几种其它Windows

可执行格式)； 

●可执行文件和模块的可执行版本； 

●可执行文件和模块的可执行检查和； 

●可执行文件和模块的可执行时间戳； 

●可执行文件和模块的可执行大小； 

●有关在哪里部署约束的用户输入； 

●由例如信号、异常或任何反常行为那样的内部应用事件触发 

●由例如资源过度使用的外部可见应用事件触发 

●由例如用户登录或网络连接开始的系统事件触发 

●在预定时间窗或例如系统引导期间的系统特有时间窗内 

●存在替代约束 

●存在冲突约束 

12.约束管理 

正如前面结合图2讨论的那样，约束可以由适当销售商创建。像结合图4a讨论的那样，想部署约束的用户利用中央管理控制台下载约束并管理它们。控制器420与每个服务器上的节点管理器交互。节点管理器转而与在受保护应用程序上运行的核心约束注入系统连接。利用控制器，用户具有以约束为粒度管理系统和获取有关每个约束的状态和有效性的信息的能力。正如前面讨论的那样，用户能够动态地打开和关闭约束，和将约束放置在检测或保护模式下。还将有关每个约束的部署状态和统计提供给用户。这个反馈信息可以包括： 

●状态 

-Off-用户关闭； 

-Forced off-由过多错误或异常引起的关闭； 

-Not active-未找到匹配组； 

-Detect-在检测模式下，至少一个组激活，例如，注入约束； 

-Protect-与上面相同，但在保护模式下； 

-In transition-状态正在改变；可以处在注入中途或在找到匹配组之后正在等待注入。 

●统计 

-检测到弱点的次数； 

-未检测到弱点的次数； 

-检测器返回错误的次数； 

-保护弱点的次数； 

-保护器返回错误的次数； 

-保护器请求杀死当前线程的次数； 

-保护器请求杀死当前进程的次数； 

-保护器请求引发异常的次数 

-保护器请求改变应用程序控制流的次数 

-保护器返回静寂状态(silent status)，例如不想用日志记录事件的次数； 

-由于例如异常或无限循环的错误，约束系统中止检测器或保护器的次数。 

由约束检测的每次违规(violation)或由约束注入系统检测的错误可以生成事件到事件日志。也可以生成辩论(forensics)文件供进一步分析用。 

13.约束注入和清除 

一旦识别出补丁点，就发生注入。注入的代码可以保存应用程序堆栈，切换到约束堆栈，使所有应用程序寄存器进栈和开始执行约束。在执行了约束之后，恢复应用程序寄存器和堆栈，并且控制流在补丁点处的实际指令重新开始。在完成了注入之后，和在执行约束之前，调用“constraint_reset_function”以便建立约束要求的状态。 

可以针对每个约束完成诸如状态、统计、违规报告等的簿记(bookkeeping)，从而约束执行可以隐藏在沙盒(sandbox)中。这可以利用，例如，网关函数或序言-尾声函数(prologue-epilogue function)对完成。利用网关的优点是在调用处可以只注入对网关的调用。但是，这意味着可以利用约束注入系统内被认为是安全冒险的函数指针调用约束(补救器和检测器两者)。这个问题可以利用序言-尾声函数对克服。也就是说，在调用地点，如有需要，沿着控制流逻辑，注入对序言函数的调用，然后注入对检测器的调用，然后调用注入补救器，和然后调用尾声函数。但是，一个缺点是，对于给定补丁点，必须注入大量代码。如果可以解决网关模型的安全问题(将写保护用于核心文本或在调用之前进行目标确认)，那个模型应该较为有利。 

如果在一个点上需要应用不止一个约束，则使用“先后次序(precedence)”(表2)确定注入顺序。注意，每个约束不会获得一组新的干净的应用程序寄存器。只有一组。如果以前的约束修改了它，那么，随后的约束可以看见变化。否则，以前的约束提供的补救将丢失。可以将约束设计成处理这种状况。 

注入的原子性可以在“弱点”级别上，而不是在“策略”级别上，例如，如果“弱点”中的至少一“组”要求的所有模块都满足，那么，即使相同“策略”下的其它“弱点”未准备好，也注入它的约束。如果注入不是在这个级别上完成，  那么，可以暴露“弱点”，直到在其“策略”下的其它弱点作好修补准备，这违背了约束注入的目的。 

当库是DLL时，原子性的另一个尺度是当每个DLL匹配时注入约束还是等到对于给定“弱点”所需的所有DLL都匹配。当对于给定“弱点”所有DLL都匹配时注入从原子性的观点来看是合乎逻辑的。但是，如果以前加载了一个DLL并且匹配，并且以后在执行时加载了另一个DLL，则在加载第二DLL之前不修补第一DLL中的安全漏洞。这可以通过创建相同策略但不同“组”的另一个“弱点”来处理。因此，在你加载时注入和全部加载后注入手段各有优缺点。 

与注入不同，清除只发生在“策略”级别上。清除指的是移除策略提供的修复，这意味着针对它的所有“弱点”。“策略”可以在如下环境之一清除： 

●当读入新策略信息时，在启动时或在推进(例如，图4a，通知)期间； 

●当读入模式改变时，在启动时或在推进期间； 

●当卸载库时。这种情况下的清除已经由核心注意。不需要对库加载做任何事情。 

●当约束返回错误或由于异常中止约束的次数达到某个阈值时。 

在清除之后马上调用“constraint_reset_function”，以便整理约束状态。 

14.约束信息验证 

由于约束信息从约束开发者发送到顾客站点，最终发送到应用程序的核心，在顾客站点验证信息的完整性是防止由窜改引起的问题的关键。 

首先，应该由CME 330验证发送的XML文件，例如，描述符文件。签名的证书可以用于与，例如，约束开发者的网站通信，以便下载XML文件。一旦获得了文件，就可以利用“xml_file_signature”(表2)验证它。 

其次，应该验证发送的约束库的完整性。对于每个“constraint_dll”，在“policy”中，存在“constraint_dll_hash”。利用这个散列值，核心可以确认约束库。验证失败将导致用日志记录的事件。 

15.约束库的ABI 

由于约束应该对应用程序和它的可用性影响最小，可以严格限制进入约束库的东西，以避免对动态应用程序(live application)产生负面影响。例如，可以利用ABI将如下限制或规则组施加在约束上： 

●不应该定义库初始化函数； 

●不应该覆盖应用程序或核心中的任何现有函数； 

●应该仅输出如XML文件描述的检测器、补救器和初始化函数； 

●不应该输入配备的接口外部的任何其它应用程序或核心函数； 

●不应该进行系统调用； 

●应该最小化静态链接函数的使用，尤其存在副作用的那些； 

●不应该访问或改变除了通过配备的接口之外的核心数据结构。 

16.检测器的ABI 

每个检测器可以用一个变元，即到环境结构的一个指针调用。可以将宏提供给约束写入器，以便利用这个指针读写应用程序的寄存器。每个检测器可以返回如下状态码之一： 

●检测到； 

●未检测到； 

●错误。 

可以利用ABI将如下附加限制或规则组施加在检测器上： 

●不应该修改应用程序寄存器； 

●不应该修改除为约束使用而分配的那个以外的其它存储器； 

●所有循环都应该具有可验证静态循环边界检查，由此防止无限循环； 

●应该使所有函数调用都在许可核心接口列表中或服从一组明确定义的特性； 

●在修改非本地存储器(全局的或通过变元指出的存储器)的所有函数中，存储器不应该是应用程序可见的； 

●对于修改存储器的所有函数，缓冲器应该足够大，和缓冲器尺寸和存储器修改的边界应该是可静态验证的； 

●不应该调用系统调用。 

在约束开发期间，程序分析工具可以用于检查和加强这些方针。但是，这些方针不是绝对规则。在没有其它选项可用的那些罕见场合下，可以忽略这些方针。但是，应该在许多考虑、得到监督团队的许可和许多质量保证之后作出。注意，基于字节码的约束可以使加强这些ABI限制的任务变得简单，并且使在约束注入系统中确认ABI成为可能。 

17.补救器的ABI 

每个补救器可以用两个变元调用。第一个与用于检测器的相同，它由补  救器用来读写应用程序寄存器(与只能读取的检测器不同)。第二个是到固定尺寸的缓冲器的指针，它可以由补救器用于提供可以写入事件日志中的信息。补救器可以执行如下之一或多个： 

●修改应用程序状态(存储器和/或寄存器)； 

●杀死当前线程； 

●杀死当前进程； 

●引发异常； 

●将控制流改变到在XML文件中规定的“return_addr”； 

●将控制流改变到计算的地址； 

●发送事件或消息； 

●指示错误。 

可以利用ABI将如下附加限制或规则组施加在补救器上： 

●所有循环都应该具有可验证静态循环边界检查，由此防止无限循环； 

●应该使所有函数调用都在许可核心接口列表中或服从一组明确定义的特性； 

●不应该调用系统调用。 

18.约束代码中的异常 

约束的执行可以导致无限循环或访问违规异常(由于间接调用NULL、无效和受保护存储器)。约束注入系统无需处置无限循环；取而代之，约束写入器可以在约束创建时处置它作为ABI限制。 

在访问违规的情况下，约束注入系统的异常处理器可以识别与约束有关的异常，终止约束执行和返回到具有适当状态代码的网关/序言-尾声函数，并且使清理和簿记的提醒由那个函数完成。 

19.约束调用的函数 

检测器和补救器ABI允许检测器和补救器分别调用包括属于如下类别的函数的一组预定支持函数： 

●报告； 

●字符串操纵； 

●同步； 

●错误处理； 

●冻结应用程序(为了原子更新应用程序)； 

●全局和线程专用存储器分配和解除分配； 

●有关线程创建和删除的通知。 

在函数改变应用程序可见状态时应予关注以避免程序崩溃。检测器调用的函数存在例如避免修改任何应用程序可见状态的进一步限制。 

20.使用管理程序执行核心 

可从Determina公司(Determina Corp.，Redwood City，California)获得的Memory Firewall^TM产品中的管理程序执行核心提供了实现约束注入系统的适当基底(substrate)。由于该核心创建代码高速缓存和通过高速缓存执行所有指令，可以在任意地址上插入任何指令序列。代码高速缓存创建进程考虑约束的原子插入和删除。它也为约束的沙盒执行提供基础。该核心还具有提供使应用程序可见度最低的输入-输出(I/O)和存储器管理函数的机制。但是，这种产品的使用只是一种示范性实现，因为其它实现也是可以的。 

21.支持的应用程序类别 

虽然并非不可能，但也难以为所有顾客使用的每个应用程序提供定制约束。这需要成千上万的安装和质量保证支持。而且，应用程序定制和多个版本可以使这个任务变得尤为艰难。为了简化这些东西，可以将应用程序划分成三个类别。 

21a.在约束开发实验室(例如，安全实验室)中可用的应用程序 

●约束开发者全面了解应用程序； 

-完整工作安装可用于所有受支持的版本； 

-质量保证框架可用于合理保证应用程序的质量； 

●约束被构建成修复应用程序中的特定弱点； 

●例子：Microsoft Windows

服务、因特网信息服务(IIS)(Microsoft

 万维网服务器)、和Oracle

数据库软件。 

21b.约束开发者可访问的应用程序 

●约束开发者将应用程序用于一次性分析； 

●通过分析应用程序构建确认/拦截点； 

-外部输入、局部输入、管理人员输入过滤点； 

-扩展的缓冲器拦截点； 

-到系统调用的路径的分类； 

●例子：PeopleSoft企业应用软件、Siebel商业应用软件、WinZip压缩  实用程序、和IIS version-1。 

21c.约束开发者决不会看见的应用程序 

●不了解应用程序； 

●只有通用API拦截或定制库； 

●例子：Foobar FTP服务器、定制应用程序。 

22.示范性约束代码 

下文为防止Micorsoft公司在它们的安全公告MS03-007中通知的弱点的约束提供了约束代码的例子。这是由于使用了长文件名可以导致IIS中的整体系统损坏的未检查缓冲器弱点。进一步的细节可以在http://www.microsoft.com/technet/security/bulletin/MS03-007.mspx中找到。在分析了弱点之后，约束开发者生成约束。图9提供了约束的源代码(检测器和保护器函数)。弱点与长文件名的使用有关。如图所指，补丁点正好在对函数RtlInitUnicode String的调用之前，函数RtlInitUnicodeString是将Unicode字符串长度删截成16位整数的函数。图10提供了应用约束的NTDLL.DLL中的代码的反汇编。NTDLL.DLL是用于与Windows

内核交互的核心操作系统组件。在这个代码中存在简单弱点。未对照文件名的最大可能长度检查变元的长度，造成了缓冲器溢出攻击的机会。因此，注入如上所述的约束，以便在调用函数RtlInitUnicodeString之前检查长度。图11提供了生成和发送给顾客的XML文件。XML文件提供识别约束的需要和将约束部署到顾客站点的中央控制器所需的信息。它提供了识别保护哪个弱点的顾客信息、有关何时何地部署约束的信息、和有关提供的检测器和保护器函数的信息。 

23.约束注入的独立框架 

约束注入的另一个实施例牵涉到使用不利用代码高速缓存地将约束直接加载和注入应用程序存储器中的独立框架。在这一手段中，当启动受保护应用程序时，加载特殊DLL或管理约束的其它库。这个库实现当发生了约束组改变或部署改变时约束管理引擎(CME)可以调用的例程。这可以通过两种方式完成。一种方法是将钩子(或回调)插入应用程序常规控制流中，以便当应用程序执行时，常规地调用DLL或其它库例程。另一种方法是使用特殊操作系统机制从来自CME的外部调用调用应用程序中的例程。 

当调用DLL或其它库的约束管理器例程时，利用CME检查哪些约束应该可应用于应用程序。这将在启动时或在CME提供存在变化的通知时或在加  载新库时发生。在启动时，扫描加载到存储器中的所有激活库，并且将那个版本信息与CME给出的约束的列表相匹配。当CME向列表提供变化的通知时，再次针对CME提供的更新约束列表检查那个激活库。新库的加载通过勾连加载进程来检测。当调用这个钩子时，将针对CME提供的约束列表检查新库。可以利用如下机制安装新约束或将激活约束去激活。 

首先，最好保证在地址空间中执行的所有线程处在允许修改存储图像的安全点处而不会造成竞争状况。一种加强方式是挂起所有线程和检查线程挂起的程序计数器位置。如果程序计数器处在不安全位置上，那么，使那个线程重新开始和允许它到达再次挂起的安全点。或者，可以将当前程序计数器重新定位到约束网关。由于加载器可能修改库的存储图像，希望保证这个进程相对于修改应用程序图像的加载器来说是安全的。这在名义上可以通过等待到加载器完成存储器的修改来完成。无需挂起所有线程地加强安全的可替代方法是保证对存储图像的修改可以与那个区域的执行共存。这可以通过例如下述方式来达到：如果插入的指令小则使用原子更新，或如果执行它们则首先原子地插入将造成错误的少数几个指令，然后自下而上地改变所需指令来达到。如果线程在其正在被修改的同时到达修改区，它将抛出可以捕获的异常。当捕获异常时，使线程停止直到注入完成。 

其次，如果还没有加载到存储图像中，可以将约束加载到存储器中。这可以通过利用加载器来完成，如果将约束作为常规DLL或其它给出，或可以通过利用定制加载器将约束指令复制到存储器中来完成。 

接着，检查每个补丁点，以保证它符合补丁点的规范。在这种情况下，在一种示范性实施例中，补丁点应该具有下面列出的如下八种附加限制。 

1.补丁点指定将约束注入应用程序代码中的地址。补丁点必须总是处在指令边界上。补丁点之后的五个字节叫做“补丁区”并将在约束注入期间将覆盖。在补丁区开始的指令采用的字节称为“扩展补丁区”。如果补丁区中的最后指令扩展到越过它的末端，则扩展补丁区将大于五个字节。例如： 

text：767A6E1C 50               push  eax 

text：767A6E1D 6489250000000    mov   large 

fs：0，esp 

text：767A6E2451                push  ecx 

如果补丁点是767A6E1C，补丁点将覆盖从地址767A6E1C到767A6E21  的五个字节。扩展补丁区将覆盖从地址767A6E1C到767A6E23的八个字节。 

2.补丁区中的字节没有一个可以在程序中的任何地方成为控制转移指令的目标。 

3.结束在补丁区的前四个字节中的指令没有一个可以是CALL或无条件JMP指令。CALL或JMP指令结束在补丁区的最后字节上是可接受的。 

4.补丁区中的字节没有一个可以在程序中的任何地方读取。 

5.扩展补丁区中的字节没有一个可以在程序中的任何地方写入。 

6.在补丁区开始的指令没有一个可以是INT或INT3指令。 

7.作为限制#4的后果，扩展补丁区必须不包括任何重新定位。 

8.补丁区必须不与三十二字节高速缓存行边界相交(只有在使用原子注入时才需要)。 

在继续进行注入之前，我们通过计算补丁点附近的指令的散列函数计算补丁点的有效性。但是，如果在附近注入另一个约束，那么，散列函数的计算需要利用移动到约束网关的原始指令。 

接着，修改应用程序存储器中的补丁点，以便将控制转移指令插入约束网关中。在发生修改之前，将补丁点处的应用程序指令复制到约束网关，因此，它们将在执行约束之前(或之后)被执行。但是，如果复制过的指令是具有相对寻址的控制转移指令，则必须修改地址。这可能需要扩大相对地址大小。 

如果正在注入的约束请求控制流转移到另一个位置作为其补救动作之一，和如果已经利用不同约束修补了那个位置，那么，将控制流转移修改成直接到那个约束。而且，如果任何其它激活约束请求控制流转移到当前约束的补丁点，则也将这些转移修改成直接到该约束。 

该系统还拦截任何存储器保护，以便使只读页面变成可写的。移除约束，并且当再次使页面变成可执行的时，再次执行注入进程。 

图12例示了不利用安全代码高速缓存而在应用程序内部署约束的软件结构。除了不存在MPEE或代码高速缓存之外，提供的结构与图3的类似。该结构描绘了插入约束之前的原始程序1100、和存储器1120中的修改程序。原始程序1100和修改程序1120存在于不同时间，因为修改程序未与原始程序分开存储。也就是说，对原始程序作了修改，而不是复制原始程序。原始程序1100包括，例如含有许多指令的代码段1101，所述指令例如，指令A  1102、指令B 1103、指令C 1104和指令D 1105。代码段1110代表原始程序中的公共执行路径，例如指令，并且包括指令X 1111、指令Y 1112和指令Z1113。修改的程序1120包括通过用到网关指令1122替换指令C 1104来修改原始代码段1101而获得的修改代码段1121。另外，通过用到网关指令1126替换指令Y 1112来修改原始代码段1110而获得修改代码段1125。因此，在指令1103和1105之间、和在指令1111和1113之间提供了约束代码的补丁点。 

可以通过代码段1121和1125提供的跳跃程序从修改程序1120调用两个网关。调用CME 1130的网关包括具有保存环境指令1132、调用CME指令1133、恢复环境指令1134、指令Y 1112和返回程序指令1135的代码段1131。指令Y 1112可以在指令1133之前或之后执行。控制流在指令1133处从网关1130转移到CME 1150。控制流从CME 1150返回到网关1130以便执行，例如，恢复环境指令1134。用于补丁点1140的网关包括具有保存环境指令1142、调用检测器和补救器指令1143、恢复环境指令1144、指令C 1104、和返回到程序指令1145的代码段1141。控制流在指令1143处从网关1140转移到库1170。控制流从库1170返回到网关1140以便执行，例如，恢复环境指令1144。 

CME 1150、管理约束的外部接口1160、包括检测器1172、补救器1174和描述符1176的约束库1170、和预定支持函数库1180与如前所述图3中的它们的同名物相当。 

在补丁点处，重写代码段1101的指令，以便通过到网关指令1122将包括调用的代码段1121提供给用于补丁点的定制网关1140。在用于补丁点的网关1140上进行保存和恢复。具体地说，在指令1142保存应用程序环境。在指令1143上调用检测器1172和补救器1174的库。使控制流返回到网关1140，以便在指令1144恢复应用程序环境。指令C 1104也在指令1143之前或之后调用。控制流然后在指令1145返回到程序。具体地说，控制流可以返回到，例如，修改程序1120的指令D 1105。 

注意，覆盖的指令被复制到网关。具体地说，被到网关指令1122覆盖的指令C 1104移动到用于补丁点1140的网关，以及被到网关指令1126覆盖的指令Y 1112被复制到调用CME的网关1130。为了将控制流改变到CME 1150，如代码段1125所指示的，将跳跃程序插入公共执行路径1110中。管理约束的外部接口1160也可以调用CME 1150。因此，当程序的代码段1101被执行  时，控制流转移到调用约束库1170的网关1140。当代码段1110被执行时，控制流转移到网关1130，通过安装新约束、将激活的约束去激活、由计算机程序检测新库的加载、和确定哪些约束可应用于计算机程序，调用特殊DLL或管理约束的其它库的网关1130 

本发明可以利用硬件、软件、或硬件和软件两者的组合来实现。用于本发明的软件存储在包括硬盘驱动器、CD-ROM(只读光盘存储器)、DVD(数字多功能盘)、光盘、软盘、磁带驱动器、RAM(随机访问存储器)、ROM(只读存储器)、闪速存储器或其它适用存储设备的一个或多个处理器可读存储设备上。在可替代实施例中，可以用包括定制集成电路、门阵列、FPGA(现场可编程门阵列)、PLD(可编程逻辑器件)、和专用处理器的专用硬件替换一些或全部软件。在一个实施例中，实现本发明的软件用于编程一个或多个处理器。处理器可以与一个或多个存储设备、外围设备和/或通信接口通信。 

前面给出本发明技术的详细描述只是为了例示和描述的目的。它并不是为了穷举或使本技术局限于公开的确切形式。可以根据上面的教义作出许多修改和改变。选择所述实施例是为了最佳地说明本技术的原理和它的实际应用，从而使本领域的普通技术人员能够最佳地将本技术用在各种实施例中和像适合设想的具体使用那样与各种修改一起使用。意图通过所附权利要求书限定本技术的范围。 

Claims (17)

1.一种用于保护软件的计算机实现方法，包含：

在补丁点处将约束代码插入计算机程序中，所述约束代码插入发生在计算机程序的运行期间；

当计算机程序的控制流到达补丁点时执行约束代码；其中，约束代码调用检测器和/或补救器函数的库，每个检测器函数检测在计算机程序中何时调用弱点而不改变计算机程序的状态，而每个补救器函数采取补救动作来修复弱点；和

当计算机程序正在运行时，在检测计算机程序中的弱点的调用、但不采取补救动作的检测模式与检测计算机程序中的弱点的调用、并且响应于此而采取补救动作的保护模式之间动态地切换约束代码，

其中，当计算机程序的控制流到达补丁点时执行约束代码包含：

当约束代码已经动态地切换到检测模式时，调用库中的检测器函数而不调用库中的补救器函数；和

当约束代码已经动态地切换到保护模式时，调用库中的检测器函数和库中的补救器函数。

2.根据权利要求1所述的计算机实现方法，其中：

约束代码提供一个或多个功能，所述功能包括：消除计算机程序中的弱点、防止针对计算机程序的攻击、修复计算机程序中的故障、过滤计算机程序中的内容、加强计算机程序中的安全策略、扩展计算机程序的功能、监视计算机程序的行为、保存计算机程序的环境、调用检测器和/或补救器函数的库、或过滤到计算机程序的输入。

3.根据权利要求1所述的计算机实现方法，其中：

根据以下的一个或多个识别补丁点：从计算机程序的模块的开始地址的偏移、计算机程序的模块的绝对地址、从计算机程序的模块的符号地址的偏移、API拦截钩子、系统调用钩子、代码模式匹配 钩子、或多种识别模式。

4.根据权利要求1所述的计算机实现方法，其中：

通过扩展高速缓存中的一部分计算机程序将约束代码插入计算机程序中。

5.根据权利要求1所述的计算机实现方法，其中：

利用加载器重写将约束代码插入计算机程序中，其中所述加载器重写在将所述计算机程序的模块载入存储器中时插入约束。

6.根据权利要求1所述的计算机实现方法，其中：

约束代码遵守通过应用程序二进制接口定义的一组规则。

7.根据权利要求1所述的计算机实现方法，其中：

约束代码使用库函数。

8.根据权利要求1所述的计算机实现方法，其中：

提供约束代码作为替换计算机程序中的现有代码块的代码块。

9.根据权利要求1所述的计算机实现方法，进一步包含：

当满足弱点要求时，将约束代码的约束注入计算机程序中。

10.根据权利要求1所述的计算机实现方法，其中：

约束代码的至少一条指令调用网关，该网关调用检测器和/或补救器函数的库。

11.根据权利要求10所述的计算机实现方法，其中：

网关使控制流返回到代码段。

12.根据权利要求1所述的计算机实现方法，其中：

在存储包含有至少一条替换的指令的代码段的存储器中进行替换而无需将代码段复制到新位置。

13.根据权利要求1所述的计算机实现方法，其中：

约束代码的至少一条指令调用网关，该网关调用用于管理约束代码的例程，和执行至少一条替换的指令。

14.根据权利要求13所述的计算机实现方法，其中：

用于管理约束代码的例程确定哪些约束可应用于计算机程序。

15.根据权利要求14所述的计算机实现方法，其中： 

所述至少一条替换的指令是计算机程序的通常执行的指令。

16.根据权利要求1所述的计算机实现方法，进一步包含：

当计算机程序正在运行时动态地打开或关闭约束代码。

17.根据权利要求1所述的计算机实现方法，其中：

在多个补丁点处将约束代码插入计算机程序中，多个补丁点的每一个调用相应的检测器和/或补救器函数。 

Images