CN1696912B - 用于有效修补软件的方法和系统 - Google Patents

Abstract

描述了一种应用软件补丁的工具以克服传统修补软件的缺点。通过使用自动修补代理，该工具接收软件补丁。响应于接收到所述软件补丁，在没有用户干预的情况下，该工具执行下面的动作：首先，该工具识别当前加载并且所接收软件补丁所属的可执行模块的实例。其次，该工具将所接收的软件补丁应用到所识别的已加载可执行模块实例，来修改所识别的可执行模块实例的行为。

Description

用于有效修补软件的方法和系统

技术领域

本发明涉及更新所安装的计算机程序的操作的领域。

背景技术

修补是修改已安装程序的过程，这些程序包括应用程序、工具程序、操作系统和操作系统组件、设备驱动程序、等等。修补对于为多种目而修改程序是很有用的，包括纠正编程错误、减少或消除安全风险、或改善修改的程序所使用的逻辑。修补典型地是由最初提供该要修补的程序的公司或其它组织启动的。

安装的程序主要由可执行代码模块组成。作为一个例子，被设计成在华盛顿州雷蒙德市微软公司的WINDOWS XP操作系统上执行的多种程序主要由称作“DLL”的可执行代码模块组成。修补的一个常见方法是在构成要修补的安装程序的可执行代码模块中识别包含希望用补丁进行修改的程序代码的可执行代码模块；创建在其中可作出所需修改的已识别可执行代码模块的新版本；以及与安装程序一起将所识别的可执行代码模块的新版本分发给希望应用该补丁的用户。然后，每个用户确定他/她是否希望应用该补丁，如果是，就执行该安装程序，该安装程序用所识别的可执行代码模块的新版本代替所识别的可执行代码模块的原版本。

传统修补方法具有许多明显的缺点。这些缺点通常增加了与接收和应用补丁相关的负担。在某些情况下，这种增加的负担延迟了某些用户应用某些补丁，并甚至阻止了某些用户应用补丁。这种补丁应用中的延迟和阻止在某些情况下对用户会产生严重的负面影响，尤其是对被设计成减少或消除安全风险的补丁来说是这样。

传统修补方法的一个缺点在于，必须分布创建多个补丁以实施对单个程序的单个修改的普遍情况。在某些情况下，要修补的程序具有特定可执行代码模块的多个不同“特色(flavor)”，例如，程序被设计成在其上执行的每一操作系统或操作系统的版本和/或该程序的每种自然语言版本的不同特色。只要所识别可执行代码模块是这种可执行代码模块，则对于特色所识别的可执行代码模块的每种特色必须重复上述补丁创建和分发过程。然后，用户必须为所识别的可执行代码模块的合适特色选择并应用补丁。分类所产生的大量补丁并为每个用户的计算机系统上的应用程序选择正确的补丁集可能是非常繁重的，以致于这种状态有时被称作“补丁空洞(patch hell)”。在某些情况下，管理员必须维护识别安装在每个目标系统上的可执行模块版本集的编目(inventory)数据库，其用来为每种目标系统选择合适的传统补丁。

传统修补的另一个缺点和分发补丁的大尺寸有关。通常，可执行代码模块都具有以兆字节计的尺寸，从而使得单个补丁具有相当的尺寸，对某些用户来说，使得很难分配和存储，或者甚至不可能进行分配和存储。对于具有多种特色的补丁来说，该问题还会倍增。此外，由于每种传统补丁典型地包括整个可替代的可执行模块，所以应用传统补丁会产生代码混乱的问题。

传统修补方法又一缺点在于，某些用户在将补丁应用到产品计算机系统之前需要测试补丁。在某些情况下，在计算机系统上安装补丁会产生相反的结果，例如，包含在补丁中的已识别可执行代码模块的新版本引入新的编程错误，或引起新的、未预料的、与运行在其所应用的计算机系统上的另一个程序的交互。因此，对于维持其数据和操作是重要的产品系统，通常在向其应用补丁之前，用户首先将该补丁应用于测试系统，来估计该补丁应用于产品系统是否安全。补丁的这种分离测试增加了与修补相关的负担。此外，如果传统修补产生问题——例如，应用程序兼容性问题或被恶意利用的新弱点——在应用该补丁一段充分时间之后，可能很难将这些问题跟踪到该补丁。

传统修补方法的再一缺点与包括在补丁中的安装程序(installer)的操作有关。通常，为了替换作为执行程序一部分的可执行代码模块，安装程序必须首先终止这些程序的执行。而且，在某些情况下，这种替换在不重启计算机系统的情况下是不能完成的。这两个步骤在使用修补的计算机系统中都会引起实质上的破坏。

传统修补方法的还有一个缺点在于，有时试图修补某个可执行模块，而对于该可执行模块的“专用修理”(也称作“热修理”)先前已经被发布给该可执行模块的合适顾客子集。在这种情况下，由于在基于各用户是否应用了热修理将替代可执行代码模块的不同新版本的传统补丁分发给每个用户时遇到的困难，因此通常相反，分配替换可执行模块的单个新版本的简单的传统补丁，而不管用户是否应用了热修理。如果该新版本包含该热修理，那么该补丁就将热修理强加给不想接收它的客户。另一方面，如果新版本不包含该热修理，那么使得期望接收该热修理的客户不能得到该热修理。

传统修补方法的另一个缺点涉及这样的事实，依赖于特定可执行模块(例如特定动态链接库)的软件产品的安装程序通常通过将特定可执行模块存储在目标计算机系统的文件系统中的非标准位置中，来“隐藏”该可执行模块。因此，有时很难或不可能确定特定目标系统是否包含要修补的可执行模块的复本，并且，如果包含了副本，很难确定它驻留在目标计算机系统的文件系统中的何处。而且，某些软件产品维护了已经由其安装程序安装的可执行模块版本的“目录”。软件产品可依赖于在特定可执行模块版本目录中的指示的正确性。当传统补丁使用可执行模块的新版本替换在目标中识别的可执行模块的版本而不更新该目录的情况下，这种依赖就不再可靠了。

传统修补方法的另一个缺点源自于这样的事实，即，在要修补的可执行模块被安装于目标计算机系统之前，这种修补方法不可能被应用。因此，如果在接收了要修补的可执行模块的传统补丁之后该可执行模块才被安装在目标计算机系统中，那么就不可能再将该补丁应用于该可执行模块。

传统修补方法的另一个缺点在于它们通常只能由登录到目标计算机系统的用户使用具有自由修改权限的管理帐户应用。为此目的登录到管理帐户会使得的目标计算机系统易于感染病毒，这些病毒存在于目标计算机系统中，试图修改该目标计算机系统的各方面并需要自由权限来做这些。

传统修补方法的另一个缺点在于传统补丁很难或不可能被禁用，从而需要例如倒转可执行模块的替换或倒转对系统注册表的一个或多个修改等步骤。

因此，克服上述传统修补方法的某些或全部缺点的新修补方法将具有明显的实用性。

发明内容

根据本发明的一种在计算系统中应用软件补丁的方法，包括，使用自动修补代理以便：接收所述软件补丁；以及响应于接收到所述软件补丁，在没有用户干预的情况下，识别所接收软件补丁所属的在系统存储器中当前加载的可执行模块实例，并且响应于识别出当前加载的可执行模块实例，将所接收的软件补丁应用于所识别的当前加载的可执行模块实例，来修改所识别的当前加载的可执行模块实例的一部分，从而使得所识别的当前加载的可执行模块实例的行为被改变。

根据本发明的一种用自动修补代理来应用软件补丁的系统，包括：用于接收所述软件补丁的装置；以及用于响应于接收到该软件补丁，在没有用户干预的情况下，识别所接收的软件补丁所属的在系统存储器中当前加载的可执行模块实例，并且响应于识别出当前加载的可执行模块实例，将所接收的软件补丁应用于所识别的当前加载的可执行模块实例，来修改所识别的当前加载的可执行模块实例的一部分，从而使得所识别的当前加载的可执行模块实例的行为被改变的装置。

根据本发明的一种用于应用软件补丁的计算系统，包括：自动接收所述软件补丁的接收器；识别子系统，其响应于接收器接收到所述软件补丁，在没有用户干预的情况下，识别所接收的软件补丁所属的在系统存储器中当前加载的可执行模块实例；以及补丁应用子系统，其响应于由所述识别子系统识别出所接收的软件补丁所属的当前加载的可执行模块，在没有用户干预的情况下，将所接收的软件补丁应用到所识别的当前加载的可执行模块实例，来修改所识别的当前加载的可执行模块实例的一部分，从而使得所识别的当前加载的可执行模块实例的行为被改变。

附图说明

图1显示了在其中可以实现该工具的合适计算系统环境的例子。

图2是显示根据该工具在计算机系统之间的典型数据交换的数据流程图。

图3是显示通常由该工具执行来接收和处理新补丁的步骤的流程图。

图4是显示由该工具使用的典型示例补丁表格的数据结构图。

图5是显示通常由工具执行来更新特定补丁的配置指令的步骤的流程图。

图6是显示通常由工具执行来执行由补丁指定的参数确认的步骤的流程图。

具体实施方式

提供了一种用于修补所安装的计算机程序代码的软件工具(“工具”)。在某些实施例中，该工具向所安装的功能添加了参数测试和测试结果处理。在其它实施例中，该工具对所安装的功能增加了各种其它的功能(在某些情况下，在所安装的功能的执行流程的任意位置增加这些功能)。

在某些实施例中，对于每个补丁来说，所述工具向每一个要修补的计算机系统(即，每个“目标计算机系统”)分发：要执行测试的时点的指定、要执行的测试的身份、以及如何响应于一个或多个不同测试结果进行动作。在某些实施例中，该工具提供了一组标准的参数确认(validation)以及其用途可以在补丁中指定的其它测试。例如，补丁可以指定，对于特定的功能，如果该功能的特定参数不具有某一值，那么在主要执行开始之前该工具的调用将失败。另一补丁可指定，对于特定的功能，如果特定参数具有超过指定最大长度的长度，那么在允许继续执行该功能之前将该参数截断到指定的最大长度。多种安全性恶意利用依赖于促使用参数值调用功能，当这些参数值不在功能代码的原始版本中被阻断时，它们促使该功能创建或利用不安全的条件。在许多情况下，可以通过使用这些补丁来避免使用这些参数值执行该功能，从而防止这种恶意利用。在某些实施例中，补丁指定了对值(例如，从文件读取或由用户输入的值)的测试而非对功能参数的测试。

在某些实施例中，自动化修补代理自动接收每个补丁、确认它、并将它存储在可能应用程序的补丁表中。在某些实施例中，每个补丁被应用于要修补的可执行模块的任何实例，当接收到该补丁时，这些要修补的可执行模块已经加载到目标计算机系统上。这种方法在此称作“热修补”，并能使补丁一旦被接收能立即有效，并且不要求该工具能够确定要修补的可执行的模块是否被存储在磁盘上。在某些实施例中，每个接收的补丁被应用于要修补的可执行模块的磁盘映像，因此，当该磁盘映像在将来被加载时，所加载的磁盘映像包括该补丁。这种方法在此称作“冷修补”，并允许补丁跨多个会话被永久保存。在某些实施例中，该工具执行热修补和冷修补两者。在某些实施例中，每次当要修补的可执行模块被操作系统的加载程序加载时，将每个补丁应用到要修补的可执行模块。这种方法在此称作“加载时修补”。在某些实施例中，每次当调用要修补的功能时，将每个补丁应用到要修补的可执行模块。这种方法在此称作“调用截取修补”。加载时修补和调用截取修补都(1)不要求该功能能够确定要修补的可执行模块是否存储在磁盘上，(2)便于容易地倒转特定补丁，以及(3)不需要修改可执行模块的磁盘映像。

在某些实施例中，该工具允许用户或管理员配置已经应用的补丁的操作。作为例子，对于特定应用的补丁，这种配置可以包括：当执行到达对补丁指定的时点时是否执行由补丁指定的测试；是执行还是忽略由补丁指定的测试结果处理；和/或测试性能和/或其结果是否被记录、并显示于警告消息中，等等。在这些实施例中，该工具允许通过最初启用日志记录并禁用结果处理以在铲平计算机系统上测试补丁。在这些实施例中，该工具还允许在启用了其结果处理来有助于识别该补丁引起例如应用程序兼容性问题或其它IT问题的情况之后，以“冗长模式”将该补丁的操作记入日志。这些实施例也允许在发现该补丁引起问题时在应用之后快速禁用补丁。该工具的这些实施例还允许通过简单地从接收并存储在目标计算机系统中的补丁组中删除补丁来快速禁用补丁。

在某些实施例中，该工具使用一种“数据驱动”的修补方法，其中，补丁不包含代码，而是包含数据，例如较小的人类可读文本或XML文档，其指定了要执行测试的时点、要执行的测试的身份、以及如何响应于一个或多个不同测试结果来进行动作。在这些实施例中，修补代理接收数据驱动的补丁，并增加由补丁所指定的测试和测试处理。在某些实施例中，该工具使用一种“代码驱动”的修补方法，并且其中，每个补丁包含要增加给修补的可执行模块的短程序，它本身通过调用该工具的标准参数测试功能来执行测试，并且本身执行测试处理。通过使用数据驱动修补或代码驱动修补，有时可以使用单个补丁解决所有要修补可执行模块的特色。

在某些实施例中，该工具签署每个补丁来证明(1)该补丁来自于认证源，以及(2)该补丁的内容自从认证源创建该补丁时一直没有被修改。

在某些实施例中，该工具将每个补丁分发给每个目标计算机系统，并且目标计算机系统上的修补代理基于目标计算机系统的特性自动确定哪些补丁将应用于目标计算机系统，以及它们如何被应用。这就释放了用户和管理员许多传统上与选择和应用补丁相关的负担，以及维护准确和最新的编目数据库的负担。例如，这些特性可以包括要修补的可执行模块的哪一个版本被安装在目标计算机系统上。在这些实施例中，该工具可以通过分发对特定可执行模块的已热修理和未热修理特色指定不同的处理的补丁、消除牺牲特定可执行模块的热修理或当修补该可执行模块时使得该热修理普遍存在的任何需求，来克服通常由热修理所引起的问题。

在某些实施例中，修补代理存储目标系统中接收的每个补丁，而不管当接收特定补丁时要由该补丁所修补的可执行模块是否安装在目标系统上。由于在多种情况下该工具响应于对要修补的可执行模块的加载或对要修补的功能的调用来应用补丁，所以该工具可以在目标系统接收到补丁之后，将该补丁应用于安装在目标系统上的可执行模块。而且，补丁可以幸免于要修补的可执行模块的卸载和随后的重新安装。

在某些实施例中，修补代理在操作系统服务中实现。在这些实施例中，该工具给予修补代理应用补丁所需的任何权限。这些实施例减少了通常在应用传统补丁时所施加的安全风险，这是因为它们消除了用户使用具有较宽修改权限的管理帐户登录到目标计算机系统的需要，从而避免了给予在目标计算机系统上存在的任何病毒修改目标计算机系统的敏感方面的更多机会。

由于该工具所使用的补丁通常相对较小，因此，对传输和存储施加了适度的资源要求。而且，由于该工具所使用的补丁易于以小量恰当定义的方式来修改已修补软件的行为，所以该工具有助于减少代码混乱的问题。

图1示出了在其中实现该工具的合适计算系统环境100的例子。计算系统环境100仅仅是合适计算环境的例子，目的不在于暗示有关该工具使用范围或功能的任何限制。也不应该将计算环境100解释为对示例性操作环境100中示出的组件的任一个或其组合具有任何依赖或需求。

该程序可以用多种其它通用或专用计算系统环境或配置来运作。适合用于该工具的公知的计算系统、环境和/或配置的例子包括，但不限于：个人计算机、服务器计算机、手持或膝上型设备、图形输入板设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费者电子产品、网络PC、小型机、大型计算机、包括上述系统或设备的任何一个的分布式计算环境等等。

该工具可以在例如由计算机执行的程序模块等计算机可执行指令的通用环境中进行描述。通常，程序模块包括例程、程序、对象、组件、数据结构、等等，它们执行特定的任务或实现特定的抽象数据类型。该工具还可以在分布式计算环境中实施，在这种环境中，由通过通信网络连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储器设备的本地和/或远程计算机存储介质中。

参考图1，实现该工具的示例性系统包括计算机110形式的通用计算设备。计算机110的组件包括，但不限于，处理单元120、系统存储器130、以及用来将包括系统存储器在内的各种系统组件耦合到处理单元120的系统总线121。系统总线121可以是多种类型总线结构的任何一种，包括存储器总线或存储器控制器、外设总线、以及使用各种总线体系结构的任何一种的局部总线。作为例子，但不是限制，这些体系结构包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强ISA(EISA)总线、视频电子标准协会(VESA)局部总线、以及也称作Mezzanine总线的外围部件互连(PCI)总线。

计算机110通常包括多种计算机可读介质。计算机可读介质可以是能够由计算机110访问的任何可用介质，并包括易失和非易失介质、可移动和不可移动介质。作为例子，但不是限制，计算机可读介质可以包括计算机存储器介质和通信介质。计算机存储器介质包括易失和非易失，可移动和非可移动介质，这些介质以存储例如计算机可读指令、数据结构、程序模块或其它数据的任何方法或技术来实现。计算机存储器介质包括但不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁性存储设备、或可以用来存储所需信息并可以由计算机110访问的任何其它介质。通信介质通常在例如载波或其它传输机制等已调制数据信号中包含计算机可读指令、数据结构、程序模块或其它数据，并包括任何信息传送介质。术语“已调制数据信号”表示以在信号中的编码信息的方式设置或改变其一个或多个其特性的信号。作为例子，但不是限制，通信介质包括例如有线网络或直线连接的有线介质，以及例如声音、RF、红外和其它无线介质的无线介质。上述任何介质的组合也应该包括在计算机可读介质的范围内。

系统存储器130包括例如只读存储器(ROM)131和随机访问存储器(RAM)132的易失和/或非易失存储器形式的计算机存储介质。包含有助于例如在启动期间在计算机110的元件之间传送信息的基本线程的基本输入/输出系统133(BIOS)通常存储在ROM 131中。RAM 132通常包含可以由处理单元120立即访问和/或由处理单元120当前进行操作的数据和/或程序模块。作为例子，但不是限制，图1示出了操作系统134、应用程序135、其它程序模块136和程序数据137。

计算机110还可以包括其它可移动/非可移动、易失/非易失计算机存储器介质。仅仅作为例子，图1显示了用来对不可移动、非易失磁介质读取或写入的硬盘驱动器141，用来对可移动、非易失磁盘152读取或写入的磁盘驱动器151，以及用来对例如CD-ROM或其它光介质等可移动、非易失光盘156读取或写入的光盘驱动器155。其它可以用于示例性操作环境的可移动/不可移动、易失/非易失计算机存储器介质包括但不限于：磁带盒、闪存卡、数字多功能盘、数字视频带、固态RAM、固态ROM等。硬盘驱动器141通常通过例如接口140的不可移动存储器接口连接到系统总线121，磁盘驱动器151和光盘驱动器155通常通过例如接口150的可移动存储器接口连接到系统总线121。

上面讨论并在图1中示出的驱动器及其相关的计算机存储器介质为计算机110提供了计算机可读指令、数据结构、程序模块和其它数据的存储。在图1中，例如，示出硬盘驱动器141存储操作系统144、应用程序145、其它程序模块146和程序数据147。注意，这些组件可以与操作系统134、应用程序135、其它程序模块136和程序数据137相同，也可以不同。操作系统144、应用程序145、其它程序模块146和程序数据147在此被给予不同的标号以说明它们至少是不同的复本。用户可以通过例如图形输入板或电子数字化仪164、麦克风163、键盘162和通常称作鼠标、跟踪球或触摸板的定位设备161等输入设备将命令和信息输入到计算机110中。图1中没有示出的其它输入设备可以包括操纵杆、游戏垫、圆盘式卫星天线、扫描仪等等。这些和其它输入设备通常通过耦合到系统总线的用户输入接口160连接到处理单元120，但是也可以通过例如并行端口、游戏端口或通用串行总线(USB)的其它接口和总线结构来进行连接。监视器191或其它类型的显示设备也通过例如视频接口190的接口连接到系统总线121。监视器191还可以与触摸屏幕面板等集成在一起。注意，监视器和/或触摸屏幕面板可以物理地耦合到在其中包含计算设备110的外壳上，例如在图形输入板型的个人计算机中。此外，例如计算设备110的计算机还可以包括其它外围输入设备，例如扬声器195和打印机196，它们可以通过输出外围接口194等进行连接。

计算机110可以工作于使用到一个或多个例如远程计算机180的远程计算机的逻辑连接的网络化环境中。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其它通用网络节点，并通常包括与计算机110相关的多个或所有的上述单元，虽然图1中仅仅示出了存储器存储设备181。图1所描述的逻辑连接包括局域网(LAN)171和广域网(WAN)173，但是也可以包括其它网络。这种联网环境在办公室、企业范围的计算机网络、内联网和因特网中是普遍存在的。例如，在本工具中，计算机系统110可以包括从其转移数据的源机器，并且远程计算机180可以包括目标机器。然而应该注意，源和目标机器不需要通过网络或任何其它装置进行连接，相反，数据可以通过任何能够由源平台书写并由一个或多个目标平台读取的介质来进行转移。

当在LAN网络化环境中使用时，计算机110通过网络接口或适配器170连接到LAN 171。当在WAN网络化环境中使用时，计算机110通常包括用来通过例如因特网等WAN 173建立通信的调制解调器172或其它装置。调制解调器172可以是内置的也可以是外置的，并可以通过用户输入接口160或其它合适的机制连接到系统总线121。在网络化环境中，相对于计算机110描述的程序模块或其部分可以被存储在远程存储器设备中。作为例子，但不是限制，图1示出了远程应用程序185驻留在存储器设备181上。应该理解到，所示网络连接是示例性的，并且可以使用在计算机之间建立通信链路的其它装置。

虽然各种功能和数据在图1中被示出为驻留在以特定方式排列的特定计算机系统上，但是本领域的技术人员将理解，这些功能和数据可以用各种其它的方式分布于不同配置中的计算机系统上。虽然如上所述配置的计算机系统通常用来支持该工具的操作，但是本领域的普通技术人员将理解到，该工具可以使用不同类型和配置并具有不同组件的设备来实现。

图2是显示根据该工具在计算机系统之间的典型数据交换的数据流程图。图2所示的计算机系统(计算机系统210、220、221、222、230、231和232)通常具有结合图1示出并讨论的某些或全部组件。在补丁分发服务器处，该工具生成一个或多个补丁。这些补丁201从补丁分发服务器发送到一个或多个管理服务器，如管理服务器220和230。每个管理服务器进而将这些补丁转发到一个或多个目标计算机系统，如目标计算机系统221、222、231和232。在某些实施例中(没有示出)，补丁分发服务器直接将补丁发送到一个或多个目标计算机系统，或通过比通过单个管理服务器更间接的路线来发送。目标计算机系统接收的补丁在目标计算机系统中进行处理，这一点在下面将更加详细进行描述。管理服务器还可以将补丁配置命令202发送到一个或多个目标计算机系统，它们应用该补丁配置命令来重新配置特定补丁的操作。如下面将更详细讨论的那样，补丁可以被完全禁用；如果补丁不被禁用，那么其操作通知及其测试结果处理的每一个可被独立地启用或禁用。当操作通知被启用时，就可以显示通知，或可以将通知本地存储在目标计算机系统上，或作为通知203发送到合适的管理服务器。

图3是显示通常由该工具执行来接收和处理新补丁的步骤的流程图。在步骤301，该程序接收补丁。在步骤301接收的补丁可以是数据驱动补丁或代码驱动补丁。下面在表1中示出了示例的数据驱动补丁。

1    <Softpatch Patch＝″Q382429″>

2     <AffectedApplication AffectedExe＝″sqlservr.exe″>

3      <AffectedVersion Version＝″9.＊″>

4       <AffectedModules Name＝″SQLSORT.DLL″>

5        <Version″8.0.＊，9.＊″>

6                <Function Name＝″SsrpEnumCore″Address＝″0x0802E76B″

7                    Param＝″2″Paramtype＝″LPSTR″>

8                 <Filter MaxByteLength＝″60″/>

9                 <Resolution ActionType＝″BOOL″Action＝″FALSE″/>

10               </Function>

11       </Version>

12       <Version″10.＊，11.＊″>

13               <Function Name＝″SsrpEnumCore″Address＝″0x0802D283″

14                   Param＝″2″Paramtype＝″LPSTR″>

15                <Filter MaxByteLength＝″128″/>

16                <Resolution ActionType＝″BOOL″Action＝″FALSE″/>

17               </Function>

18       </Version>

19      </AffectedModules>

20     </AffectedVersion>

21    </AffectedApplication>

22

23    <Signature Hash＝″MD5″Signature＝″C509-64AA-9161-8C52-

24     9F6D-BF5A-AEF2-ECE1-0038-34D1″/>

25   </Softpatch>

表1

行1包含补丁的唯一标识符。行2标识由该补丁影响的应用程序。行3标识由该补丁影响的应用程序版本。行4标识由该补丁影响的可执行模块。行5标识了为其提供修补指导的所影响的可执行模块的两个版本——版本8.0*和9.*。行6-10包含可执行模块的这两个版本的修补指导。行6-7标识要修补的功能、其在可执行模块中的地址、由该补丁测试的其参数、以及要测试的参数类型。行8指示在行6-7中标识的参数应该被测试来判断其长度是否超过60字节。行9指示如果测试成功那么功能的调用就会失败。行12标识了向其提供修补指导的受影响的可执行模块的另外两个版本——版本10.*和11.*。行13-17包含可执行模块的这两个版本的修补方向。行13-14标识要修补的功能、其在可执行模块中的地址、由该补丁测试的其参数、以及要测试的参数类型。可以看出，在行13-14中为版本10.*和11.*标识的要修补功能在可执行模块中的地址不同于在行6-7中为版本8.0*和9.*标识的要修补功能的地址。行15指示在行13-14中标识的参数应该被测试来判断其长度是否超过128字节。行16指示如果测试成功那么该功能的调用就失败。该补丁可以指定多种结果处理动作类型，包括使所修补功能的调用失败、引发异常、终止执行所修补可执行模块的进程，或校正损坏的值(例如，通过截短过长的字符串)。行23-25包含补丁的签名，它标识了该补丁的来源并验证了该补丁自从离开其来源就没有被改变。

下表2包含在上面表1中示出的补丁的代码驱动版本。

1  00411A7E  push    3Ch

2  00411A80  mov     eax，dword ptr[str]

3  00411A83  push    eax

4  00411A84  call    ValidateStringLength(411082h)

5  00411A89  add     esp，8

6  00411A8C  movzx   ecx，al

7  00411A8F  test    ecx，ecx

8  00411A91  je      411A9Ah

9  00411A93  jmp     foo+2(411AD2h)

10 00411A9A  xor     eax，eax

11 00411A9C  ret

表2

行1-3将用于测试功能的参数放入栈中。行4调用测试功能。行5-8分支到测试功能的返回代码。如果测试功能成功，行9就跳转回来以开始执行修补的功能的主体。如果测试功能失败，行10-11就将失败的结果代码放入栈中，并从修补的功能返回到修补功能的颜色(color)。为了可读性，表2省略了在某些代码驱动补丁中存在的某些细节，包括可验证的签名、测试补丁配置标志当前值的指令、以及从修补功能的代码开始处重定位的指令。

在某些实施例中，两种类型的补丁可以包含附加的信息，对于要修补的可执行模块的一个或多个版本每一个来说，包括可以用来确认可执行模块的特定实例是该版本的正确复本的文件签名。这种文件签名可以是，例如，整个可执行模块版本的大小或校验和，或期望在可执行模块的特定点发生的代码，例如在将要修补可执行模块的偏移量处。

在步骤302，如果该补丁用有效签名来签署，那么该工具就继续到步骤303，否则该工具继续到步骤301来接收下一个补丁。在步骤303，该工具将该补丁添加到本地补丁表中。在步骤304，该工具初始化该补丁的初始配置，例如通过将其发送到默认配置。

图4是示出由该工具使用的典型示例补丁表的数据结构图。该补丁表400包含行，例如行401和402，其每一个被划分成以下列：补丁标识符列411，其包含从补丁中提取的补丁标识符；可执行模块列412，其包含识别要修补的可执行模块的信息，例如其名字；可执行模块版本列413，其标识列412标识的向其应用该补丁的可执行模块的所有版本；测试性能启用列414，其包含关于在每次调用修补的功能时是否应该执行由该补丁指定的测试的当前配置值；测试性能通知启用列415，其包含关于在每次执行该补丁的测试时是否应该生成通知的当前配置值；测试结果通知启用列416，其包含关于在每次补丁测试成功时是否生成通知的当前配置值；测试结果处理启用列417，其包含关于当补丁测试失败时是否应该实现补丁结果处理的当前配置值；以及补丁列418，其包含指向补丁自身的指针，指定了在每次测试失败时要执行的测试和测试结果处理。在某些实施例中，补丁列418不是如所示那样包含指向补丁的指针，而是直接包含每个补丁。特定补丁表可以包含或指向各种类型的补丁，例如所有的代码驱动补丁、所有的数据驱动补丁，或代码驱动和数据驱动补丁的组合。

在步骤305，一旦该工具已经将所接收的补丁添加到补丁表并初始化其配置，那么该补丁就可以由该工具自动应用于可执行模块。在步骤305，该工具可以使用各种方法来应用该补丁，包括在通过引用结合的申请中描述的那些、以及实时功能调用截取、和/或对(1)已经加载的可执行模块、(2)可执行模块的一个或多个磁盘映像或(3)由操作系统的加载程序加载的可执行模块的实例的代码重写。在步骤305之后，该工具继续到步骤301来接收下一个补丁。

图5是示出通常由该工具执行来更新特定补丁的配置指令的步骤的流程图。在步骤501，该工具接收特定补丁的配置指令，例如从管理员接收。在某些实施例中，这种配置指令可以由管理员使用组政策来生成。在步骤502，该工具根据所接收的指令更新该补丁在补丁表中的配置。在步骤502之后，该工具继续到步骤501来接收下一个配置指令。

图6是显示通常由该工具执行来执行由补丁指定的参数确认的步骤的流程图。在步骤601，调用已修补的功能。在步骤602，如果对影响调用的功能的补丁启用了测试，那么该工具继续到步骤603，否则该工具继续到步骤601来处理对已修补功能的下一个调用。在步骤603，如果对该补丁启用了测试性能通知，那么该工具就继续到步骤604，否则该工具就继续到步骤605。在步骤604，该工具生成执行测试的通知。步骤604、608和610可以涉及将满足测试的指示在目标计算机系统上显示或存储，和/或将这种指示发送到远程计算机系统以进行显示或记入日志。

在步骤605，该工具执行由该补丁指定的确认测试。在某些实施例中，步骤605涉及调用由该工具进行测试所使用的一组标准例程的其中一个。在步骤606，如果在步骤605执行的测试得以满足，那么该工具就继续到步骤601，否则该工具就继续到步骤607。在步骤607，如果对该补丁启用了测试结果通知，那么该工具就继续到步骤608，否则该工具继续到步骤609。在步骤608，该工具生成测试没有被满足的通知。在步骤609，如果对该补丁启用了测试结果处理，那么该工具就继续到步骤610，否则该工具就继续到步骤601。在步骤610，该工具执行由该补丁指定的测试结果处理。在步骤610之后，该程序继续到步骤601。

本领域的技术人员应该理解，上述工具可以用多种方式直接应用或扩展。例如，该工具可用于为各种目的在多种类型的可执行模块中的多个位置处用各种方法来应用多种不同种类的补丁。而且，虽然在此所述的补丁包含指示当它们失败时的问题的值确认测试，但是该工具还可以使用指示当它们成功时的问题的值无效性测试来实现。在某些实施例中，每个测试伴随有其成功或失败是否指示问题的指示。虽然前述描述参考了优选实施例，但是本发明的范围仅由所附权利要求书及其中叙述的元素进行限定。

Claims (29)

1.一种在计算系统中应用软件补丁的方法，包括，使用自动修补代理以便：

接收所述软件补丁；

响应于接收到所述软件补丁，在没有用户干预的情况下，识别所接收软件补丁所属的在系统存储器中当前加载的可执行模块实例；以及

响应于识别出当前加载的可执行模块实例，在没有用户干预的情况下，将所接收的软件补丁应用于所识别的当前加载的可执行模块实例，来修改所识别的当前加载的可执行模块实例的一部分，从而使得所识别的当前加载的可执行模块实例的行为被改变。

2.根据权利要求1所述的方法，其特征在于，所识别的可执行模块是可独立执行的模块。

3.根据权利要求1所述的方法，其特征在于，所识别的可执行模块是库。

4.根据权利要求1所述的方法，其特征在于，所识别的可执行模块是脚本。

5.根据权利要求1所述的方法，其特征在于，所识别的可执行模块是受控代码模块。

6.根据权利要求1所述的方法，其特征在于，接收属于相同可执行模块实例的两个软件补丁，并且应用所接收的两个软件补丁来修改所述可执行模块实例的行为。

7.根据权利要求6所述的方法，其特征在于，所接收的两个补丁属于所述可执行模块实例中不同的位置。

8.根据权利要求6所述的方法，其特征在于，所接收的两个补丁属于所述可执行模块实例中的相同位置。

9.根据权利要求8所述的方法，其特征在于，应用所接收的两个补丁，使得由所述两个补丁指定的行为修改皆被所修补的可执行模块实例所展示。

10.根据权利要求8所述的方法，其特征在于，应用所接收的补丁，使得仅所接收的两个软件补丁中的主要软件补丁的行为修改被所述可执行模块实例所展示，其中所述主要软件补丁包含它将要控制一个或多个其它软件补丁的明确指示。

11.根据权利要求1所述的方法，其特征在于，所识别的可执行模块实例在应用了所接收的软件补丁之后展示所修改的行为。

12.根据权利要求1所述的方法，其特征在于，还包括使用自动修补代理将所接收的软件补丁应用于所识别的可执行模块实例的磁盘映像。

13.根据权利要求1所述的方法，其特征在于，还包括当所识别的可执行模块实例在将来被重新加载时，使用自动修补代理将所接收的软件补丁应用于所识别的可执行模块实例。

14.根据权利要求1所述的方法，其特征在于，所述软件补丁所属的当前加载的可执行模块实例是从所述软件补丁所属的多个可执行模块实例中识别的，并且其中，使用包含在所接收的补丁中的已识别可执行模块实例的模块实例专用信息来应用所接收的软件补丁。

15.根据权利要求14所述的方法，其特征在于，所述多个可执行模块实例的每一个是相同可执行模块的不同版本。

16.根据权利要求14所述的方法，其特征在于，包含在所接收的补丁中的已识别可执行模块的模块实例专用信息指定了在已识别可执行模块内的一个偏移量，其中在所述偏移量处修改所识别的可执行模块的行为。

17.根据权利要求16所述的方法，其特征在于，包含在所接收的补丁中的已识别可执行模块的模块实例专用信息还指定了期望在应用所接收的软件补丁之前出现在指定偏移量处的已识别可执行模块实例的内容。

18.根据权利要求1所述的方法，其特征在于，还包括，使用所述自动修补代理以便：

接收属于当时不存在于所述计算系统中的可执行模块的第二软件补丁；以及

响应于接收到所述第二软件补丁，在没有用户干预的情况下，存储所接收的第二软件补丁，如果在计算系统中随后加载了所接收软件补丁所属的可执行模块实例，则所述存储的第二软件补丁可供将来应用。

19.根据权利要求1所述的方法，其特征在于，在应用之后，当所识别的可执行模块被卸载并随后被重新安装时，所述方法还包括，使用所述自动修补代理，在没有用户干预的情况下，将所接收的软件补丁重新应用到重新安装的已识别可执行模块实例，来修改重新安装的已识别可执行模块实例的行为。

20.根据权利要求1所述的方法，其特征在于，所接收的软件补丁包含指定如何修改所识别的可执行模块实例的行为的代码。

21.根据权利要求1所述的方法，其特征在于，所接收的软件补丁包含指定如何修改所识别的可执行模块实例的行为的数据。

22.根据权利要求1所述的方法，其特征在于，所接收的软件补丁指定，修改所识别的可执行模块实例的行为，以向所识别的可执行模块实例的指定部分添加参数测试和测试结果处理。

23.根据权利要求1所述的方法，其特征在于，所接收的软件补丁指定，修改所识别的可执行模块实例的行为，以向所识别的可执行模块实例中的指定部分添加一个参数确认功能。

24.根据权利要求1所述的方法，其特征在于，所接收的软件补丁指定，修改所识别的可执行模块实例的行为，从而通过标识一个标准的参数确认功能向所识别的可执行模块实例内的指定功能添加一个参数确认功能，其中所述标准的参数确认功能将要作为指定功能执行的一部分而被调用。

25.根据权利要求1所述的方法，其特征在于，所识别的可执行模块实例的已修改行为可以通过使用补丁配置接口来启用或禁用。

26.根据权利要求1所述的方法，其特征在于，对所识别的可执行模块实例的已修改行为的日志记录可以使用补丁配置接口来启用或禁用。

27.根据权利要求1所述的方法，其特征在于，所述软件补丁是通过允许所述软件补丁被复制到预定位置来接收的，并且其中，所述识别和应用是响应于所述软件补丁被复制到预定位置而自动执行的。

28.一种用自动修补代理来应用软件补丁的计算系统，包括：

用于接收所述软件补丁的装置；

用于响应于接收到该软件补丁，在没有用户干预的情况下，识别所接收的软件补丁所属的在系统存储器中当前加载的可执行模块实例的装置；以及

用于响应于识别出当前加载的可执行模块实例，在没有用户干预的情况下，将所接收的软件补丁应用于所识别的当前加载的可执行模块实例，来修改所识别的当前加载的可执行模块实例的一部分的装置，从而使得所识别的当前加载的可执行模块实例的行为被改变。

29.一种用于应用软件补丁的计算系统，包括：

自动接收所述软件补丁的接收器；

识别子系统，其响应于接收器接收到所述软件补丁，在没有用户干预的情况下，识别所接收的软件补丁所属的在系统存储器中当前加载的可执行模块实例；以及

补丁应用子系统，其响应于由所述识别子系统识别出所接收的软件补丁所属的当前加载的可执行模块，在没有用户干预的情况下，将所接收的软件补丁应用到所识别的当前加载的可执行模块实例，来修改所识别的当前加载的可执行模块实例的一部分，从而使得所识别的当前加载的可执行模块实例的行为被改变。

Images