CN101046836A - 一种清除rootkit的系统及方法 - Google Patents

Abstract

本发明公开了一种清除ROOTKIT的系统及方法。其中，该系统包括：虚拟机监视器(3)，以及运行在虚拟机监视器(3)上的服务操作系统(2)和至少一个客户操作系统(1)，其中：客户操作系统(1)包括检测工具代理模块(22’)，用于在客户操作系统(1)运行时，收集客户操作系统(1)中信息；服务操作系统(2)包括检测工具(22)，用于在虚拟机监视器(3)中收集客户操作系统(1)运行时的信息，并将收集的信息与所述检测工具代理模块(22’)收集的信息相比较，判断是否存在ROOTKIT，并依照检测工具代理模块(22’)中收集的信息，将被ROOTKIT修改的信息替换。根据本发明的清除ROOTKIT的系统及方法，在操作系统实时运行时，可靠地清除未知ROOTKIT，且安全性高。

Description

一种清除ROOTKIT的系统及方法

技术领域

本发明涉及清除病毒的系统及方法，尤其涉及一种清除ROOTKIT的系统及方法。

背景技术

随着商业用户对个人计算机(PC)依赖性的不断加大，用户在PC上主要的检查病毒与木马的工具是防(杀)病毒及防(杀)木马工具软件，这些工具工作原理是在系统运行时，扫描系统内存中的进程及硬盘上保存的系统文件，并匹配相关特征文件，从而发现病毒及木马。

操作系统是由内核(Kernel)和外壳(Shell)两部分组成的，其中：内核负责一切实际的工作，包括CPU任务调度、内存分配管理、设备管理、文件操作等；外壳是基于内核提供的交互功能而存在的界面，它负责指令传递和解释。一般的进程查看工具和杀毒软件也不例外，能看到的进程其实是内核“看到”并通过相关接口指令(API)反馈到应用程序的，这样就不可避免的存在一条数据通道。简单而言，ROOTKIT设法让自己达到和内核一样的运行级别，甚至进入内核空间，这样它就拥有了和内核一样的访问权限，因而可以对内核指令进行修改，最常见的是修改内核枚举进程的API，让它们返回的数据始终“遗漏”ROOTKIT自身进程的信息，一般的进程工具自然就“看”不到ROOTKIT了。更高级的ROOTKIT还篡改更多API，这样，用户就看不到进程(进程API被拦截)，看不到文件(文件读写API被拦截)，看不到被打开的端口(网络组件SOCK API被拦截)，更拦截不到相关的网络数据包(网络组件NDIS API被拦截)了，这样ROOTKIT通过监听系统的功能、用合法的数值取代返回的数据。ROOTKIT其它的秘密活动包括掩盖网络活动和修改WINDOWS注册表，达到了隐藏其代码不被发现的目标。

当病毒或者木马采用ROOTKIT技术时，其病毒本身内存中进程和硬盘保存的文件被隐藏起来，则不会被防病毒、防木马工具软件发现，更不会与特征文件进行匹配，因此采用ROOTKIT技术的病毒与木马不会被采用现有技术的防病毒与防木马的工具软件发现。

系统中隐藏的病毒及木马，轻则破坏系统，重则盗取用户合同、银行帐号等敏感数据，给用户带来严重地损失。

目前，最可靠地检测ROOTKIT的办法是关闭操作系统(OFFLINE OS)检测。例如，系统自身启动，然后列出所有的文件、REGISTRY项等等。然后用WINPE从CD启动，再列出所有的文件、REGISTRY项。这时，对比两个列表，在正常情况下，两个列表中所列内容应该是一样的，如果出现不一样的地方，就可以发现那些在用自身系统启动的情况下看不到的文件。

该方法的主要缺点是：

1)该方法只能检测硬盘中文件，对于可能通过网络或方式进入系统或系统中运行态的进程无法检查；

2)关闭系统会给用户带来不便，特别是对于某些24小时不能停机的重要系统(例如，银行的授权系统等)，关闭系统的方法是不现实的；

3)由于ROOTKIT是未知的，不仅查找ROOTKIT存在困难，而且ROOTKIT如何替换系统核心文件和API是未知的，清除未知ROOTKIT存在技术问题。

发明内容

本发明的目的在于，提供一种清除ROOTKIT的系统。

本发明的另一目的在于，提供一种清除ROOTKIT的方法。

本发明的清除ROOTKIT的系统，包括虚拟机监视器，以及运行在虚拟机监视器上的服务操作系统和至少一个客户操作系统，其中：

所述客户操作系统包括检测工具代理模块，用于在客户操作系统运行时，收集客户操作系统中信息；

所述服务操作系统包括检测工具；

所述检测工具，用于在虚拟机监视器中收集客户操作系统运行时的信息，并将收集的信息与所述检测工具代理模块收集的信息相比较，判断是否存在ROOTKIT，并依照检测工具代理模块中收集的信息，将被ROOTKIT修改的信息替换。

所述服务操作系统还可以包括原始系统文件参照模块，用于在客户操作系统最初运行时，保存初始系统信息。

所述收集的信息为文件列表信息或者系统内存状态信息。

所述系统内存状态信息为系统API接口地址信息及API对应的程序代码。

本发明的清除ROOTKIT的方法，包括以下步骤：

步骤A)检测工具代理模块收集用户在客户操作系统中的信息；

步骤B)运行于虚拟机监视器上的服务操作系统检查运行于虚拟机监视器3上的客户操作系统中是否存在被ROOTKIT修改的信息；

步骤C)如果存在ROOTKIT，则依照检测工具代理模块收集的信息，将被ROOTKIT修改的信息替换，清除ROOTKIT。

所述步骤B)可以包括下列步骤：

步骤B1)检测工具在虚拟机监视器中收集客户操作系统打开的信息；

步骤B2)客户操作系统中的检测工具代理模块收集在客户操作系统1中打开的信息，并将收集的信息传输给服务操作系统的检测工具；

步骤B3)将所述步骤B1)中检测工具收集的信息与步骤B2)中检测工具代理模块收集的信息进行比较，判断是否存在差异信息；

步骤B4)如果没有差异信息，则客户操作系统中没有ROOTKIT，检查过程结束；如果有差异信息，则客户操作系统中存在ROOTKIT。

所述步骤C)还可以包括下列步骤：

检测工具，用步骤B2)中检测工具代理模块收集的信息，替换被ROOTKIT修改的差异信息，清除ROOTKIT。

本发明的查杀ROOTKIT的方法，还可以包括以下步骤：

服务操作系统中原始系统文件参照模块对客户操作系统中初始系统信息进行保存；

针对差异信息，检测工具用原始系统文件参照模块中保存的初始系统信息替换硬盘保存的实际被ROOTKIT修改的信息。

所述收集的信息为文件列表信息或者系统内存状态信息。

所述系统内存状态信息为API接口地址信息和API对应的程序代码。

本发明的有益效果是：根据本发明的清除ROOTKIT的系统及方法，在操作系统实时运行时，可靠地清除未知ROOTKIT，且本发明的检测工具以及原始系统文件参考模块运行于操作系统之外的VMM控制的服务操作系统内存区域，攻击操作系统安全软件的病毒及木马无法攻击到VMM以及服务操作系统，因此检测工具以及原始系统文件参考模块不会受到攻击，安全性高。

附图说明

图1为本发明一实施例的清除ROOTKIT的系统结构示意图；

图2为本发明一实施例的清除ROOTKIT的方法流程图；

图3为本发明另一实施例的清除ROOTKIT的系统结构示意图；

图4为本发明另一实施例的清除ROOTKIT的方法流程图。

具体实施方式

以下将结合附图1～4详细说明本发明的清除ROOTKIT的系统及方法。

实施例1

图1为本发明一实施例的清除ROOTKIT的系统结构示意图。

如图1所示，本实施例的清除ROOTKIT的系统包括：至少一个客户操作系统(客户OS)1、服务操作系统2、虚拟机监视器(Virtual Machine Monitor，VMM)3。

其中，虚拟机监视器3，运行在支持虚拟计算指令的硬件平台上，并在其上运行现有的各种操作系统(包括本发明的客户操作系统1以及服务操作系统2)；服务操作系统2，其运行于虚拟机监视器3上，包括检测工具22，用于在虚拟机监视器3中直接收集客户操作系统1运行时的信息(例如，打开的文件集、进程集以及API接口地址等信息)，其在客户操作系统1中设置有检测工具代理模块22’，用于收集在客户操作系统1中用户打开的信息(例如，打开的文件集、进程集以及API接口地址等信息)；客户操作系统1，包括所述服务操作系统2中检测工具代理模块22’，用于收集在客户操作系统1中用户打开的信息，并将收集的信息传输至检测工具22。

以上，检测工具22及检测工具代理模块22’所收集到的信息包括：1)文件列表信息：存储在存储设备上的文件清单；2)系统内存状态信息，包括系统API接口地址以及API接口相应的程序代码等。

可以理解的是，如果客户操作系统1中存在ROOTKIT，由于ROOTKIT会隐藏其自身以及被其修改的文件或者系统API接口等信息，因此检测工具代理模块22’中显示的收集到的信息则是为未被ROOTKIT修改的原始信息(例如，原始系统文件、原始API接口等信息)。

具体的，当客户操作系统1最初运行时，检测工具22开始运行于虚拟机监视器3上，用于在虚拟机监视器3中直接收集客户操作系统1运行时的信息(包括文件集、进程集、API接口地址以及API相应的程序代码等)，并与从检测工具代理模块22’传输来的在客户操作系统1中收集的信息进行比较，如果发现某些文件或者进程只存在于检测工具22收集的集合中，而检测工具代理模块22’中未收集到，则差异文件有可能是ROOTKIT；如果检测工具22收集的API接口地址与检测工具代理模块22’收集的API接口地址不一致时，则差异API接口地址为ROOTKIT替换的API接口。此时，检测工具22将依照检测工具代理模块22’中收集的信息，即未被ROOTKIT修改的原始信息，包括原始系统文件、原始API接口地址及相应的程序代码，替换硬盘保存的实际被ROOTKIT修改的系统文件、API接口地址及相应的程序代码，从而清除未知的ROOTKIT。

以下，参照图2介绍本发明的清除ROOTKIT的方法，包括以下步骤：

步骤101)服务操作系统2中检测工具22开始在虚拟机监视器3上运行，并通过虚拟机监视器3收集用户在客户操作系统1中打开的信息(例如，打开的文件集、进程集以及API接口地址等信息)，并通知客户操作系统1中检测工具代理模块22’收集用户在客户操作系统1中打开的信息(包括文件集、进程集以及API接口地址等)；

步骤102)客户操作系统1中的检测工具代理模块22’将其在客户操作系统1中收集的信息传输至服务操作系统2中的检测工具22；

步骤103)检测工具22将步骤101)中检测工具22收集的信息与步骤102)中检测工具代理模块22’收集的信息进行比较，判断是否存在差异信息(例如，差异文件、差异进程以及差异API接口地址等)，如果不存在差异信息，则客户操作系统1中没有ROOTKIT，则向客户操作系统1提示后结束检查过程，否则，执行步骤104)：

步骤104)针对差异信息，检测工具22用检测工具代理模块22’中收集的相应信息，替换硬盘保存的实际被ROOTKIT修改的信息(例如，系统文件、API接口地址以及API相应的程序代码等)，从而清除未知的ROOTKIT。

下面，结合一个具体的例子来说明本发明的方法在实际系统中的应用：

服务操作系统2中检测工具22在虚拟机监视器3上运行，并基于虚拟机监视器3收集在客户操作系统1运行时打开的文件为1、2、3和4；客户操作系统1中检测工具代理模块22’收集直接在客户操作系统1中打开的文件为1和2，且该文件1的内容与检测工具22收集的文件1的内容有差异，在检测工具22收集的文件1的内容是abc，而检测工具代理模块22’收集的文件1的内容是def。

上述收集过程说明：

1)文件3和4是ROOTKIT在硬盘上生成的新文件；

2)文件1的内容在ROOTKIT侵入前是def，而受ROOTKIT侵入后被修改为abc。

此时，需要将文件3和4删除，并将文件1的内容abc改为def就能把系统恢复成未被ROOTKIT破坏的系统，因此，检测工具22需用检测工具代理模块22’收集的文件1(其内容为def)替换硬盘中的保存的文件1(其内容为abc)、3和4，即可清除未知ROOTKIT。恢复被ROOTKIT修改的系统API接口地址与恢复被ROOTKIT修改的系统文件的过程相类似，在此不再举例说明。

综上所述，依照本发明实施例1的清除ROOTKIT的系统，通过在硬件平台上运行VMM软件，然后在VMM上运行客户操作系统1以及服务操作系统2，并在服务操作系统2上设置检测工具22，在客户操作系统1中设置检测工具代理模块22’，用于收集直接在客户操作系统1上打开的信息，检测工具22，用于在虚拟机监视器3中直接收集客户操作系统1运行时打开的信息，并与检测工具代理模块22’中收集的信息相比较，显示出差异信息，从而可靠地检查出未知的ROOTKIT，然后，检测工具22针对差异信息，用检测工具代理模块22’收集的相应信息替代硬盘中实际被ROOTKIT修改的信息，从而清除ROOTKIT。本发明的检测工具22运行于操作系统之外的VMM控制的内存区域，由于攻击操作系统的病毒及木马无法攻击到VMM上，因此，检测工具以及原始系统文件参考模块不会受到攻击，安全性高。

实施例2

如图3所示，为本实施例的清除ROOTKIT的系统结构示意图。本实施例的清除ROOTKIT的系统与本发明实施例1的清除ROOTKIT的系统的结构大体相同，包括：至少一个客户操作系统1、服务操作系统2’、虚拟机监视器3。不同之处在于，本实施例的服务操作系统2’，包括检测工具22以及原始系统文件参照模块21。

其中，原始系统文件参照模块21，用于在客户操作系统1最初运行时，对初始系统信息(包括文件集、进程集、API接口地址以及相应的程序代码等信息)进行镜像或者备份。其他单元与本发明实施例1中的结构和功能大体相同，在此不再复述。

此外，需要对客户操作系统1中最初运行时的系统信息进行镜像或备份的目的是：当检测到被ROOTKIT感染的系统文件和API接口时，依照检测工具代理模块22’中收集的未被ROOTKIT感染的原始信息，检测模块22用原始系统文件参照模块21中相应的初始系统信息替换硬盘保存的实际被ROOTKIT修改的信息，从而清除未知ROOTKIT。

具体的，当客户操作系统1最初运行时，原始系统文件参照模块21对初始系统信息进行镜像或者备份；检测工具22开始运行于虚拟机监视器3上，用于在虚拟机监视器3中直接收集客户操作系统1运行时打开的文件集、进程集、API接口地址等信息，并与检测工具代理模块22’中收集的文件集、进程集、API接口地址等信息进行比较，如果发现某些文件或进程只存在于检测工具22收集的集合中，而检测工具代理模块22’中未收集到，则差异文件有可能是ROOTKIT；如果检测工具22收集的API接口地址与检测工具代理模块22’收集的API接口地址不一致时，则差异API接口地址为ROOTKIT替换的API接口。此时，依照差异信息，检测工具22用原始系统文件参照模块21中保存的相应信息，替换硬盘保存的实际被ROOTKIT修改的信息(例如，系统文件、API接口地址及相应的程序代码等)，从而清除未知的ROOTKIT。

以下，参照图4介绍本实施例的清除未知ROOTKIT的方法，包括以下步骤：

步骤201)服务操作系统2中原始系统文件参照模块21对客户操作系统1中初始系统信息进行镜像或备份；

步骤202)服务操作系统2中检测工具22开始在虚拟机监视器3上运行，并基于虚拟机监视器3收集用户在客户操作系统1中打开的文件集、进程集以及API接口地址等信息，并通知客户操作系统1中检测工具代理模块22’收集用户在客户操作系统1中打开的文件集、进程集以及API接口地址等信息；

步骤203)客户操作系统1中的检测工具代理模块22’将其收集的信息传输给服务操作系统2的检测工具22；

步骤204)检测工具22将所述步骤202)中检测工具22收集的信息与步骤203)中检测工具代理模块22’收集的信息进行比较，判断是否存在差异信息(例如，差异文件、差异进程以及差异API接口地址等)，如果不存在差异信息，则客户操作系统1中没有ROOTKIT，则向客户操作系统1提示后结束检查过程，否则，执行步骤205)；

步骤205)针对差异信息，检测工具22用相应的在原始系统文件参照模块21中镜像或备份的初始系统信息替换硬盘保存的实际被ROOTKIT修改的信息(例如，系统文件、API接口以及相应的程序代码)，从而清除未知的ROOTKIT。

以下，结合一个具体的例子来说明本实施例的清除ROOTKIT的方法在实际系统中的应用：

服务操作系统2中的原始系统文件参照模块21对客户操作系统1在最初运行时的系统文件1和2进行镜像或备份得到文件1’和2’；检测工具22在虚拟机监视器3上运行收集在客户操作系统1运行时打开的文件为1、2、3和4；客户操作系统1中检测工具代理模块22’收集用户在客户操作系统1打开的文件为1和2，且文件1的内容与检测工具22收集的文件1的内容有差异，在检测工具22收集的文件1的内容是abc，而检测工具代理模块22’收集的文件1的内容是def。

上述收集过程说明：

1)文件3和4是ROOTKIT在硬盘上生成的新文件；

2)文件1的内容在ROOTKIT侵入前是def，而受ROOTKIT侵入后被其改为abc。

此时，需要将文件3和4删除，并将文件1的内容abc改为def就能把系统恢复成未被ROOTKIT破坏的系统，因此，检测工具22需用原始系统文件参照模块21保存的文件1’(其内容为def)替换硬盘中的保存的文件1(其内容为abc)、3和4，即可清除未知ROOTKIT。恢复被ROOTKIT修改的系统API接口地址与恢复被ROOTKIT修改的系统文件的过程相类似，在此不再举例说明。

在本实施例中，将原始系统文件参照模块21设置于服务操作系统2中是一种较佳方式，本发明并不局限于将原始系统文件参照模块21设置于服务操作系统2中，只要在客户操作系统1最初运行时，其完成对初始系统文件以及系统API接口地址等信息的镜像或备份即可。

综上所述，依照本实施例的清除ROOTKIT的系统，通过在硬件平台上运行VMM软件，然后在VMM上运行客户操作系统1以及服务操作系统2’，在客户操作系统1中设置检测工具代理模块22’，用于收集直接在客户操作系统1上打开的信息，并在服务操作系统2’上设置检测工具22，用于在虚拟机监视器3中直接收集客户操作系统1运行时打开的信息，并与检测工具代理模块22’中收集的信息相比较，显示出差异信息，从而可靠地检查出未知的ROOTKIT。通过增加原始系统文件参照模块21，保留初始系统信息，检测工具22针对差异信息，用原始系统文件参照模块21中收集的相应信息替代硬盘中实际被ROOTKIT修改的信息，从而清除ROOTKIT。本实施例的检测工具22以及原始系统文件参照模块21运行于操作系统之外的VMM控制的内存区域，由于攻击操作系统的病毒及木马无法攻击到VMM上，因此，检测工具22以及原始系统文件参考模块21’不会受到攻击，安全性高。

在上述本发明的实施例中，将检测工具代理模块设置于客户操作系统中只是一种较佳方式，本发明并不局限于将检测工具代理模块设置在客户操作系统中，检测工具代理模块可以通过各种其他方式实现，例如，当服务操作系统中的检测工具开始运行时，其通过自身复制，然后向客户操作系统中传输复制的检测工具作为检测工具代理模块，并在客户操作系统中运行并驻留该检测工具代理模块；或者服务操作系统中的检测工具向客户操作系统中传输检测工具代理模块，并在客户操作系统中运行并驻留检测工具代理模块，由于文件复制及传输为现有技术，本发明不再复述。

综上所述，依照本发明的清除ROOTKIT的系统及方法，在操作系统实时运行时，可以可靠地清除未知ROOTKIT，且本发明的检测工具以及原始系统文件参考模块运行于操作系统之外的VMM控制的服务操作系统内存区域，攻击操作系统安全软件的病毒及木马无法攻击到VMM以及服务操作系统，因此检测工具以及原始系统文件参考模块不会受到攻击，安全性高。

对该技术领域的普通技术人员来说，根据以上实施例可以联想到其他的优点和变形。因此，本发明并不局限于上述具体实施例，其仅仅作为例子对本发明进行详细、示范性的说明。在不背离本发明宗旨的范围内，本领域普通技术人员可以根据上述具体实施例通过各种等同替换所得到的技术方案，但是这些技术方案均应该包含在本发明的权利要求的范围及其等同的范围之内。

Claims (10)

1.一种清除ROOTKIT的系统，其特征在于，包括虚拟机监视器(3)，以及运行在虚拟机监视器(3)上的服务操作系统(2)和至少一个客户操作系统(1)，其特征在于：

所述客户操作系统(1)包括检测工具代理模块(22’)，用于在客户操作系统(1)运行时，收集客户操作系统(1)中信息；

所述服务操作系统(2)包括检测工具(22)；

所述检测工具(22)，用于在虚拟机监视器(3)中收集客户操作系统(1)运行时的信息，并将收集的信息与所述检测工具代理模块(22’)收集的信息相比较，判断是否存在ROOTKIT，并依照检测工具代理模块(22’)中收集的信息，将被ROOTKIT修改的信息替换。

2.如权利要求1所述的清除ROOTKIT的系统，其特征在于，所述服务操作系统(2)还包括原始系统文件参照模块(21)，用于在客户操作系统(1)最初运行时，保存初始系统信息。

3.如权利要求1所述的清除ROOTKIT的系统，其特征在于，所述收集的信息为文件列表信息或者系统内存状态信息。

4.如权利要求3所述的清除ROOTKIT的系统，其特征在于，所述系统内存状态信息为系统API接口地址信息及API对应的程序代码。

5.一种清除ROOTKIT的方法，其特征在于，包括以下步骤：

步骤A)检测工具代理模块(22’)收集用户在客户操作系统(1)中的信息；

步骤B)运行于虚拟机监视器(3)上的服务操作系统(2)检查运行于虚拟机监视器(3)上的客户操作系统(1)中是否存在被ROOTKIT修改的信息；

步骤C)如果存在ROOTKIT，则依照检测工具代理模块(22’)收集的信息，将被ROOTKIT修改的信息替换，清除ROOTKIT。

6.如权利要求5所述的清除ROOTKIT的方法，其特征在于，所述步骤B)包括下列步骤：

步骤B1)检测工具(22)在虚拟机监视器(3)中收集客户操作系统(1)打开的信息；

步骤B2)客户操作系统(1)中的检测工具代理模块(22’)收集在客户操作系统(1)中打开的信息，并将收集的信息传输给服务操作系统(2)的检测工具(22)；

步骤B3)将所述步骤B1)中检测工具(22)收集的信息与步骤B2)中检测工具代理模块(22’)收集的信息进行比较，判断是否存在差异信息；

步骤B4)如果没有差异信息，则客户操作系统(1)中没有ROOTKIT，检查过程结束；如果有差异信息，则客户操作系统(1)中存在ROOTKIT。

7.如权利要求6所述的清除ROOTKIT的方法，其特征在于，所述步骤C)还包括下列步骤：

检测工具(22)用步骤B2)中检测工具代理模块(22’)收集的信息，替换被ROOTKIT修改的差异信息，清除ROOTKIT。

8.如权利要求5所述的查杀ROOTKIT的方法，其特征在于，还包括以下步骤：

服务操作系统(2)中原始系统文件参照模块(21)对客户操作系统(1)中初始系统信息进行保存；

针对差异信息，检测工具(22)用原始系统文件参照模块(21)中保存的初始系统信息替换硬盘保存的实际被ROOTKIT修改的信息。

9.如权利要求5所述的查杀ROOTKIT的方法，其特征在于，所述收集的信息为文件列表信息或者系统内存状态信息。

10.如权利要求9所述的查杀ROOTKIT的方法，其特征在于，所述系统内存状态信息为API接口地址信息和API对应的程序代码。

Images