CN104008340B - 病毒查杀方法及装置 - Google Patents

Abstract

本发明是关于一种病毒查杀方法及装置。其中，所述方法包括：接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件；检测加载的文件中是否包含有病毒文件；若包含有病毒文件，则调用预设的程序，以可写的方式重新加载所述引导分区中的文件；将重新加载的文件中的病毒文件删除；若存在有所述病毒文件对应的进程，则将所述病毒文件对应的进程删除。本发明提供的技术方案使得写入引导分区的病毒或恶意程序在每次手机开机或重启时，加载的病毒或恶意程序的文件及对应的进程均被删除，避免了开机或重启后病毒或恶意程序再次复活，提高了用户的使用安全性。

Description

病毒查杀方法及装置

技术领域

本发明涉及一种计算机领域，特别是涉及一种病毒查杀方法及装置。

背景技术

Android是一种以Linux为基础的开放源码操作***，主要使用于手机等移动终端，目前尚未有统一中文名称。Android平台由操作***、中间件、用户界面和应用软件组成，Android应用程序即指Android平台下的应用软件。

随着Android智能手机的普及，逐渐形成了一条针对Android***的恶意软件的产业链。这些恶意软件通常伪装成正常的应用软件或者游戏欺骗用户安装，一旦进入用户手机，就在后台悄悄定制SP服务或拨打付费电话吸取用户话费，或者收集用户的隐私，或者窃取用户的网银和第三方支付密码以实施进一步的盗窃。

目前，安卓***(Andriod)手机上出现了一种新型的木马病毒，该木马病毒与以往所有木马病毒不同的是，该木马被写入手机磁盘引导分区，会偷偷下载大量未知软件，消耗话费和/或流量。这种木马病毒被称为“不死木马”(英文命名为oldboot)。

Oldboot通过物理接触或磁盘操作，将自身写入引导分区(***启动文件映射boot.img文件所在分区)，并改写引导配置文件inti.rc，恶意代码可以获得及早地启动优先级和最高的运行权限，有效避免被杀毒软件清除并隐藏自身。手机安全软件，即使可暂时报读和清除恶意代码，在手机重启后，“不死木马”会再次“复活”。这种不断复活的木马病毒，会给用户带来极大的危害。

发明内容

鉴于上述问题，提出了本发明以便于提供一种克服上述问题或者至少部分地解决上述问题的病毒查杀方法及装置，以避免开机或重启后木马病毒再次复活，提高使用安全性。

依据本发明的一个方面，提供了一种病毒查杀方法，包括：

接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件；

检测加载的文件中是否包含有病毒文件；

若包含有病毒文件，则调用预设的程序，以可写的方式重新加载所述引导分区中的文件；

将重新加载的文件中的病毒文件删除；

若存在有所述病毒文件对应的进程，则将所述病毒文件对应的进程删除。

可选的，前述的病毒查杀方法，其中，所述检测加载的文件中是否包含有病毒文件，包括：

扫描所述引导分区中的文件，获取所述引导分区中文件的特征码；

查询预设病毒数据库中是否包含有所述特征码；

若有，则所述引导分区中包含有病毒文件，且所述特征码对应的文件为病毒文件。

可选的，前述的病毒查杀方法，其中，所述引导分区中的文件包括：***启动文件映射boot.img，所述boot.img包括：内核kernel及根目录；

其中，所述根目录下包含有服务目录及引导配置文件inti.rc，所述服务目录下包含有服务文件。

可选的，前述的病毒查杀方法，其中，

所述接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件，包括：

接收到开机或重启触发指令后，以只读的方式加载引导分区中的所述boot.img；

通过所述boot.img的kernel读取所述根目录下的inti.rc中的配置信息，所述配置信息包括各服务文件的启动顺序；

根据预设库文件，按照所述配置信息中包含的所述启动顺序依次启动服务目录下对应的服务文件；

相应的，所述检测加载的文件中是否包含有病毒文件，具体为：

依次检测启动的服务文件是否为病毒文件；

其中，所述预设库文件为通过在所述服务文件启动所需调用的原库文件的可执行连接文件格式elf结构中添加设定文件后构成的库文件；或者，所述预设库文件为替换所述服务文件启动所需调用的原库文件的新库文件。

可选的，前述的病毒查杀方法，其中，所述调用预设的程序，以可写的方式重新加载所述引导分区中的文件，具体为：

调用预设的程序，以可写的方式重新加载所述根目录。

可选的，前述的病毒查杀方法，其中，所述将重新加载的文件中的病毒文件删除，包括：

获取所述病毒文件的特征码；

根据所述根目录，进入所述服务目录；

在所述服务目录下查找所述特征码对应的文件，所述文件即为所述病毒文件；

将所述病毒文件从所述服务目录中删除。

可选的，前述的病毒查杀方法，还包括：

检测***分区中是否包含有病毒文件；

若包含有病毒文件，则将所述病毒文件从所述***分区中删除。

可选的，前述的病毒查杀方法，还包括：

根据删除所述病毒文件后的引导分区，引导进入操作***，展现开机界面。

依据本发明的另一个方面，提供了一种病毒查杀装置，包括：

加载模块，用于在接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件；

检测模块，用于检测加载的文件中是否包含有病毒文件；

重加载模块，用于当所述引导分区中的文件存在有病毒文件时，调用预设的程序，以可写的方式重新加载所述引导分区中的文件；

文件删除模块，用于将重新加载的文件中的病毒文件删除；

进程删除模块，用于当存在有所述病毒文件对应的进程时，将所述病毒文件对应的进程删除。

可选的，前述的病毒查杀装置，其中，所述检测模块，包括：

扫描单元，用于扫描所述引导分区中的文件，获取所述引导分区中文件的特征码；

查询单元，用于查询预设病毒数据库中是否包含有所述特征码；若有，则所述引导分区中包含有病毒文件，且所述特征码对应的文件为病毒文件。

可选的，前述的病毒查杀装置，其中，所述引导分区中的文件包括：***启动文件映射boot.img，所述boot.img包括：内核kernel及根目录；所述根目录下包含有服务目录及引导配置文件inti.rc，所述服务目录下包含有服务文件；

所述加载模块，包括：

加载单元，用于在接收到开机或重启触发指令后，以只读的方式加载引导分区中的所述boot.img；

第一启动单元，用于通过所述boot.img的kernel读取所述根目录下的inti.rc中的配置信息，所述配置信息包括各服务文件的启动顺序；

第二启动单元，用于根据预设库文件，按照所述配置信息中包含的所述启动顺序依次启动服务目录下对应的服务文件；

相应的，所述检测模块，具体用于依次检测启动的服务文件是为病毒文件；

其中，所述预设库文件为通过在所述服务文件启动所需调用的原库文件的可执行连接文件格式elf结构中添加设定文件后构成的库文件；或者，所述预设库文件为替换所述服务文件启动所需调用的原库文件的新库文件。

可选的，前述的病毒查杀装置，其中，所述重加载模块，具体用于调用预设的程序，以可写的方式重新加载所述根目录。

可选的，前述的病毒查杀装置，其中，所述文件删除模块，包括：

获取单元，用于获取所述病毒文件的特征码；

查找单元，用于根据所述根目录，进入所述服务目录，在所述服务目录下查找所述特征码对应的文件，所述文件即为所述病毒文件；

删除单元，用于将所述病毒文件从所述服务目录中删除。

可选的，前述的病毒查杀装置，其中，

所述检测模块，还用于检测***分区中是否包含有病毒文件；

所述文件删除模块，还用于当所述***分区中的文件存在有病毒文件时，将所述病毒文件从所述***分区中删除。

可选的，前述的病毒查杀装置，还包括：

引导执行模块，用于根据删除所述病毒文件后的引导分区，引导进入操作***，展现开机界面。

借由上述技术方案，本发明实施例提供的技术方案至少具有下列优点：

本发明提供的技术方案通过在接收到开机或重启触发指令后，检测引导分区中是否有病毒文件，若引导分区中存在有病毒文件，则以可写的方式重新加载引导分区中的文件，再将重新加载的文件中的病毒文件删除，若存在该病毒文件对应的进程，则将该病毒文件对应的进程也进行删除，使得写入引导分区的病毒或恶意程序在每次手机开机或重启时，加载的病毒或恶意程序的文件及对应的进程均被删除，避免了开机或重启后病毒或恶意程序再次复活，提高了用户的使用安全性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例一提供的病毒查杀方法的一种实现的流程示意图；

图2示出了本发明实施例一提供的病毒查杀方法的另一种实现的流程示意图；

图3示出了本发明实施例二提供的病毒查杀装置的一种实现的结构示意图；

图4示出了本发明实施例二提供的病毒查杀装置的另一种实现的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，本发明实施例一提供的病毒查杀方法的流程示意图。本实施例所述方法可以使用在病毒引擎中，例如，手机安全卫士，手机查杀引擎等，即本实施例提供的所述方法的执行主体可以是安装在客户端的病毒查杀装置(亦或称病毒查杀引擎)。所述病毒查杀装置可以是专门针对Android***上的病毒、木马和其他恶意软件的查杀装置。所述病毒查杀装置可通过扫描Android安装包(APK文件)的包名、数字签名、AndroidManifest.xml中列出的各模块的入口信息、Dex文件和ELF文件、Android安装包的版本号、Android安装包目录下个文件的MD5值等中的一个或任意多个信息，作为识别各种恶意软件(病毒、木马和其他恶意软件)的特征。其中，上述各用于识别恶意软件的特征在下文中会详细介绍。

具体的，本实施例一提供的所述病毒查杀方法，包括：

步骤101、接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件。

具体的，所述引导分区中的文件包括：***启动文件映射boot.img，所述boot.img包括：内核kernel及根目录；其中，所述根目录下包含有服务目录及引导配置文件inti.rc，所述服务目录下包含有服务文件。其中，所述服务目录可包括有sbin目录。

本步骤可采用如下方法实现：

首先，接收到开机或重启触发指令后，以只读的方式加载引导分区中的所述boot.img。

然后，通过所述boot.img的kernel读取所述根目录下的inti.rc中的配置信息。

其中，所述配置信息包括各服务文件的启动顺序。

最后，根据预设库文件，按照所述配置信息中包含的所述启动顺序依次启动服务目录下对应的服务文件。

其中，所述预设库文件为通过在所述服务文件启动所需调用的原库文件的可执行连接文件格式elf结构中添加设定文件后构成的库文件；或者，所述预设库文件为替换所述服务文件启动所需调用的原库文件的新库文件。

这里需要说明的是：本步骤以只读的方式加载引导分区中的文件的实现过程与现有技术类同，不相同的步骤是：根据预设库文件，按照所述配置信息中包含的所述启动顺序依次启动服务目录下对应的服务文件。而现有技术中是根据服务文件启动所需调用的原库文件，来依次启动服务目录下对应的服务文件的。之所以本步骤将现有技术中的原库文件改为预设库文件，是为了使查杀代码在服务文件启动之前就被执行起来，以便于后续对各启动服务文件进行查杀。具体实现的过程有两种；

第一种，在原库文件的可执行连接文件格式(Executable and Linkable Format，简称elf)结构中添加设定文件构成所述预设库文件，即对现有库文件中的elf结构中的信息进行修改。

第二种，使用预先编辑好的新的库文件直接替换现有技术中的库文件。

步骤102、检测加载的文件中是否包含有病毒文件。

具体的，本步骤可通过病毒查杀装置通过扫描Android安装包(APK文件)的包名、数字签名、AndroidManifest.xml中列出的各模块的入口信息、Dex文件和ELF文件、Android安装包的版本号、Android安装包目录下个文件的MD5值等中的一个或任意多个信息，来识别加载的文件中是否包含有病毒文件。病毒查杀装置扫描上述特征即可识别出恶意文件的原理如下：

在Android***上，一个可以安装、运行的应用，需要打包成Android***的APK文件格式。APK是Android application package file的缩写，简称APK文件，即Android安装包，也可以理解为Android终端上安装的应用软件。APK文件其实是ZIP文件格式，但后缀名被修改为apk，通过Unzip等工具解压可以看到其内部的文件结构，如下表1所示：

表1

Android安装包(APK文件)一般通过Android应用市场下载、安装到手机上，也可以通过USB数据线等数据线接口或无线数据传输的方式从PC安装。Android上的病毒、木马和其他恶意软件想要进入用户的手机，也必须打包成APK的形式。反过来说，如果不是一个合法的APK文件，它就无法安装到用户手机上，也就不会对用户产生危害。基于这一点，杀毒引擎就可以把查杀的目标集中到对APK文件的扫描上，从而大大提高扫描的效率。

那么，Android安装包(APK文件)中的哪些信息可以作为扫描的重点，针对此问题本申请进行了分析，具体如下：

1)包名

Android操作***通过APK的包名(package name)对各个安装的APK进行管理。“包名”源自于Java的package的概念，按照Java的package的命名风格，例如某个Android安装包的包名是com.qihoo360.mobilesafe。Android***要求每个应用都声明一个唯一的包名。如果要安装的APK的包名和当前手机上某个已有的应用的包名重复了，那么Android***会拒绝安装。Android平台下的恶意软件也需要声明一个包名，因此，包名就可以作为识别恶意软件的一个重要特征。

2)数字签名

出于安全性的目的，Android***要求每个APK都要包含数字签名(digitalsignature)。Android***在安装APK文件的时候会检查APK内部各文件的数字签名是否与其预先设定的数字签名一致，如果不一致，或者没有数字签名，则认为文件已被篡改，拒绝该APK的安装和运行。Android平台下的恶意软件也不例外，所以APK文件的数字签名也可以作为识别恶意软件的一个重要特征。

3)AndroidManifest.xml中列出的各模块的入口信息

AndroidManifest.xml是每个APK文件所必需的全局描述文件，里面列出了Android安装包中应用的每个模块的入口信息。在Android***中，只有在AndroidManifest.xml中列出了的模块，才能够被***调用。Android平台下的木马，往往会伪装成正常的应用或游戏来诱骗用户安装，其中有很多木马就是寄生在一个正常的应用或游戏中，用户运行它的时候，看上去是原来的软件或游戏，但寄生在其中的木马模块在合适的时机就被激活，从而感染用户的手机。而因为Android***要求所有的模块都要在AndroidManifest.xml中列出，这就为寻找寄生的木马提高了重要线索。因此，AndroidManifest.xml中列出的各模块的信息，也是识别恶意软件的重要特征。

4)Dex文件和ELF文件

Android应用通常是用Java语言开发的，它用Android开发工具编译之后变成了二进制的字节码(byte code)，这些字节码被打包成classes.dex文件，由Android平台的Dalvik虚拟机来解释执行。为了能够调用Android***功能，Android***提供了一套运行环境(Android Framework)，Android应用调用***各功能都是通过调用AndroidFramework的库来实现的。

另一方面，Android***也支持应用程序通过JNI或者native executable直接运行。此时应用执行的是直接在CPU上运行的二进制机器码，不需要经过虚拟机解释，可以直接调用Android库如libc、WebKit、SQLite、OpenGL/ES等来调用***各功能。如果Android应用要通过JNI或者native executable运行，就需要将要执行的代码编译成ELF文件格式。ELF是Executable and Linkable Format的缩写，是Android/Linux操作***中可执行程序、共享库的文件格式。

Android上的恶意软件要想在Android***中运行起来，也要遵循上述架构规范。因此，在识别恶意软件的过程中，可以分别从Dex文件(即字节码文件)和ELF文件提取相应的特征。

此外，除上述列举之外，Android安装包的版本号、Android安装包目录下各文件的MD5值等信息，也可以作为识别恶意软件的重要特征。其中，上述的恶意软件包括病毒、木马和其他恶意软件。

当然，本步骤的实现方式不局限于此，还可以通过查询预设的病毒数据库来检测引导分区中是否包含有病毒文件。其中，所述预设的病毒数据库中包含有病毒文件的特征码。所述特征码可以是病毒文件的文件名，或其他标识信息等。例如，本步骤可采用如下方法实现：

首先，扫描所述引导分区中的文件，获取所述引导分区中文件的特征码。

然后，查询预设病毒数据库中是否包含有所述特征码。

若有，则所述引导分区中包含有病毒文件，且所述特征码对应的文件为病毒文件。

这里需要补充的是：所述加载的引导分区的文件可映射到内存之间或在映射到内存之后均可进行病毒文件的检测。本步骤可具体为：依次检测启动的服务文件是否为病毒文件。即上述步骤101中各服务文件按照inti.rc中的配置信息顺次启动后，可采用本步骤依次检测启动的服务文件是否为病毒文件。

步骤103、若包含有病毒文件，则调用预设的程序，以可写的方式重新加载所述引导分区中的文件。

具体的，调用的所述预设的程序可以是mount-o remount()程序。通过该mount-oremount()程序，可以将引导分区中的文件以可写的方式重新进行加载。这里需要说明的是：目前比较常见的“不死木马”oldboot通常情况下在引导分区的服务目录下，例如，在sbin目录下。因此，本步骤可通过调用所述预设的程序，以可写的方式重新加载所述引导分区中的根目录。即本步骤可具体为：

调用预设的程序，以可写的方式重新加载所述根目录。

由于，现有技术中引导分区中的文件是以只读的方式加载的，即没有获得Root权限是不能对文件进行修改或其他操作的。因此，通过本步骤获取Root权限，以可写的方式重新加载所述引导分区的文件，即可对加载的引导分区中的文件进行删除操作，例如将加载的引导分区中的病毒删除。其中，获取Root权限可采用如下方式实现：在Root的手机上，会在“/system/bin”目录下存放一个名为su程序的文件，并且安装有SuperUser应用程序。其他应用程序想要以Root权限执行，就必须通过su程序执行shell命令，而此时，SuperUser就会弹出授权对话框，用户必须点击允许，命令才能成功被执行。点击允许时，如果没有选择“记住”选项，那么应用每次通过su程序执行shell命令时，都会弹出授权提醒的对话框；或者，通过chmod命令修改文件权限分类的所有者和所属分组为Root，例如，手机等移动设备从云端服务器下载的可执行程序文件存储至临时目录，例如/data/local/tem的目录下，通过chmod命令修改该可执行文件权限分类的所有者和所属分组为Root。当然，获取Root权限的方式不仅限于上述两种方式。另外，Root权限可分为临时Root权限和永久Root权限。而本实施例中获取的Root权限可以是临时Root权限。临时Root权限是指暂时性的Root权限。临时Root权限和永久Root权限的区别是：临时Root权限在移动设备重新启动后，临时Root权限会自动消失。而实际上，在临时Root权限下的操作权限与在永久Root权限下的操作权限相同，例如临时Root权限的操作至少包括以下任意一种：备份***、修改***的内部程序、将应用程序安装到SD卡上、获取文件目录、静默安装应用程序、卸载应用程序、以及卸载***预装应用程序。

步骤104、将重新加载的文件中的病毒文件删除。

具体的，本步骤可采用如下方法实现：

首先，获取所述病毒文件的特征码。

然后，根据所述根目录，进入所述服务目录。

随后，在所述服务目录下查找所述特征码对应的文件，所述文件即为所述病毒文件。

最后，将所述病毒文件从所述服务目录中删除。

以“不死木马”oldboot为例，通常oldboot在引导分区的sbin目录下，则本步骤可采用如下步骤实现：

首先，获取所述病毒文件的特征码。

然后，根据所述根目录，进入所述sbin目录。

随后，在所述sbin目录下查找所述特征码对应的文件，所述文件即为oldboot。

最后，将所述oldboot从所述sbin目录下中删除。

步骤105、若存在有所述病毒文件对应的进程，则将所述病毒文件对应的进程删除。

本步骤可采用查找病毒文件的标识来查找是否有该病毒文件对应的进程。

本实施例的技术方案通过在接收到开机或重启触发指令后，检测引导分区中是否有病毒文件，若引导分区中存在有病毒文件，则以可写的方式重新加载引导分区中的文件，再将重新加载的文件中的病毒文件删除，若存在该病毒文件对应的进程，则将该病毒文件对应的进程也进行删除，使得写入引导分区的病毒或恶意程序在每次手机开机或重启时，加载的病毒或恶意程序的文件及对应的进程均被删除，避免了开机或重启后病毒或恶意程序再次复活，提高了用户的使用安全性。

进一步的，上述实施例提供的所述方法，还可以包括如下步骤：

步骤201、检测***分区中是否包含有病毒文件。

步骤202、若包含有病毒文件，则将所述病毒文件从所述***分区中删除。

这里需要说明的是：目前比较常见的“不死木马”oldboot都是在引导分区中文件中。由于***分区的文件是可读写的，因此若在***分区中有木马病毒，则可直接将木马病毒从所述***分区中删除，无需采用上述步骤101～105。

再进一步的，上述实施例提供的所述方法，如图2所示，还包括如下步骤：

步骤301、根据删除所述病毒文件后的引导分区，引导进入操作***，展现开机界面。

其中，在展现的开机界面中可呈现出病毒查杀的相关信息，例如针对某个病毒文件的安全检测结果可以是包含安全、危险、谨慎或木马四个表示安全级别的信息，此外所述安全检测结果中还可以包括与安全级别相关的行为描述、软件描述、时间戳等至少一项提示信息。

需要说明的是：对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

如图3所示，本实施例二提供的病毒查杀装置的结构示意图。本实施例二提供的所述病毒查杀装置可实现上述实施例一提供的所述方法。其中，本实施例二提供的所述病毒查杀装置包括：加载模块1、检测模块2、重加载模块3、文件删除模块4及进程删除模块5。其中，所述加载模块1用于在接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件。所述检测模块2用于检测加载的文件中是否包含有病毒文件。所述重加载模块3用于当所述引导分区中的文件存在有病毒文件时，调用预设的程序，以可写的方式重新加载所述引导分区中的文件。所述文件删除模块4用于将重新加载的文件中的病毒文件删除。所述进程删除模块5用于当存在有所述病毒文件对应的进程时，将所述病毒文件对应的进程删除。

本实施例的技术方案通过在接收到开机或重启触发指令后，检测引导分区中是否有病毒文件，若引导分区中存在有病毒文件，则以可写的方式重新加载引导分区中的文件，再将重新加载的文件中的病毒文件删除，若存在该病毒文件对应的进程，则将该病毒文件对应的进程也进行删除，使得写入引导分区的病毒或恶意程序在每次手机开机或重启时，加载的病毒或恶意程序的文件及对应的进程均被删除，避免了开机或重启后病毒或恶意程序再次复活，提高了用户的使用安全性。

进一步的，上述实施例提供的所述装置中所述检测模块可采用如下的结构实现。所述检测模块，包括：扫描单元和查询单元。其中，所述扫描单元，用于扫描所述引导分区中的文件，获取所述引导分区中文件的特征码。所述查询单元，用于查询预设病毒数据库中是否包含有所述特征码；若有，则所述引导分区中包含有病毒文件，且所述特征码对应的文件为病毒文件。

再进一步的，上述实施例中所述的所述引导分区中的文件包括：***启动文件映射boot.img，所述boot.img包括：内核kernel及根目录；所述根目录下包含有服务目录及引导配置文件inti.rc，所述服务目录下包含有服务文件。所述加载模块可采用如下步骤实现。具体的，所述加载模块，包括：加载单元、第一启动单元和第二启动单元。其中，所述加载单元，用于在接收到开机或重启触发指令后，以只读的方式加载引导分区中的所述boot.img。所述第一启动单元，用于通过所述boot.img的kernel读取所述根目录下的inti.rc中的配置信息，所述配置信息包括各服务文件的启动顺序。所述第二启动单元，用于根据预设库文件，按照所述配置信息中包含的所述启动顺序依次启动服务目录下对应的服务文件。相应的，上述实施例中所述的检测模块具体用于依次检测启动的服务文件是为病毒文件。其中，所述预设库文件为通过在所述服务文件启动所需调用的原库文件的可执行连接文件格式elf结构中添加设定文件后构成的库文件；或者，所述预设库文件为替换所述服务文件启动所需调用的原库文件的新库文件。

进一步的，上述实施例中所述的重加载模块，具体用于调用预设的程序，以可写的方式重新加载所述根目录。

再进一步的，上述实施例中所述的文件删除模块包括：获取单元、查找单元和删除单元。其中，所述获取单元，用于获取所述病毒文件的特征码。查找单元，用于根据所述根目录，进入所述服务目录，在所述服务目录下查找所述特征码对应的文件，所述文件即为所述病毒文件。删除单元，用于将所述病毒文件从所述服务目录中删除。

进一步的，上述实施例中所述的所述检测模块，还用于检测***分区中是否包含有病毒文件。所述的文件删除模块，还用于当所述***分区中的文件存在有病毒文件时，将所述病毒文件从所述***分区中删除。

如图4所示，上述实施例所述的病毒查杀装置除包括图3所示的各模块外，还包括：引导执行模块6。其中，所述引导执行模块6用于根据删除所述病毒文件后的引导分区，引导进入操作***，展现开机界面。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及交换机中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述，构造这类***所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的病毒查杀装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (13)

1.一种病毒查杀方法，其特征在于，包括：

接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件；所述引导分区中的文件包括：***启动文件映射boot.img，所述boot.img包括：内核kernel及根目录；其中，所述根目录下包含有服务目录及引导配置文件inti.rc，所述服务目录下包含有服务文件；

检测加载的文件中是否包含有病毒文件；

若包含有病毒文件，则调用预设的程序，以可写的方式重新加载所述引导分区中的文件；

将重新加载的文件中的病毒文件删除；

若存在有所述病毒文件对应的进程，则将所述病毒文件对应的进程删除；

所述接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件，包括：

接收到开机或重启触发指令后，以只读的方式加载引导分区中的所述boot.img；

通过所述boot.img的kernel读取所述根目录下的inti.rc中的配置信息，所述配置信息包括各服务文件的启动顺序；

根据预设库文件，按照所述配置信息中包含的所述启动顺序依次启动服务目录下对应的服务文件。

2.根据权利要求1所述的方法，其特征在于，所述检测加载的文件中是否包含有病毒文件，包括：

扫描加载的文件，获取文件的特征码；

查询预设病毒数据库中是否包含有所述特征码；

若有，则所述加载的文件中包含有病毒文件，且所述特征码对应的文件为病毒文件。

3.根据权利要求1所述的方法，其特征在于，

所述检测加载的文件中是否包含有病毒文件，具体为：

依次检测启动的服务文件是否为病毒文件；

其中，所述预设库文件为通过在所述服务文件启动所需调用的原库文件的可执行连接文件格式elf结构中添加设定文件后构成的库文件；或者，所述预设库文件为替换所述服务文件启动所需调用的原库文件的新库文件。

4.根据权利要求1所述的方法，其特征在于，所述调用预设的程序，以可写的方式重新加载所述引导分区中的文件，具体为：

调用预设的程序，以可写的方式重新加载所述根目录。

5.根据权利要求4所述的方法，其特征在于，所述将重新加载的文件中的病毒文件删除，包括：

获取所述病毒文件的特征码；

根据所述根目录，进入所述服务目录；

在所述服务目录下查找所述特征码对应的文件，所述文件即为所述病毒文件；

将所述病毒文件从所述服务目录中删除。

6.根据权利要求1或2所述的方法，其特征在于，还包括：

检测***分区中是否包含有病毒文件；

若包含有病毒文件，则将所述病毒文件从所述***分区中删除。

7.根据权利要求1或2所述的方法，其特征在于，还包括：

根据删除所述病毒文件后的引导分区，引导进入操作***，展现开机界面。

8.一种病毒查杀装置，其特征在于，包括：

加载模块，用于在接收到开机或重启触发指令后，以只读的方式加载引导分区中的文件；所述引导分区中的文件包括：***启动文件映射boot.img，所述boot.img包括：内核kernel及根目录；所述根目录下包含有服务目录及引导配置文件inti.rc，所述服务目录下包含有服务文件；

检测模块，用于检测加载的文件中是否包含有病毒文件；

重加载模块，用于当所述引导分区中的文件存在有病毒文件时，调用预设的程序，以可写的方式重新加载所述引导分区中的文件；

文件删除模块，用于将重新加载的文件中的病毒文件删除；

进程删除模块，用于当存在有所述病毒文件对应的进程时，将所述病毒文件对应的进程删除；

所述加载模块，包括：

加载单元，用于在接收到开机或重启触发指令后，以只读的方式加载引导分区中的所述boot.img；

第一启动单元，用于通过所述boot.img的kernel读取所述根目录下的inti.rc中的配置信息，所述配置信息包括各服务文件的启动顺序；

第二启动单元，用于根据预设库文件，按照所述配置信息中包含的所述启动顺序依次启动服务目录下对应的服务文件。

9.根据权利要求8所述的装置，其特征在于，所述检测模块，包括：

扫描单元，用于扫描所述引导分区中的文件，获取所述引导分区中文件的特征码；

查询单元，用于查询预设病毒数据库中是否包含有所述特征码；若有，则所述引导分区中包含有病毒文件，且所述特征码对应的文件为病毒文件。

10.根据权利要求8所述的装置，其特征在于，所述重加载模块，具体用于调用预设的程序，以可写的方式重新加载所述根目录。

11.根据权利要求10所述的装置，其特征在于，所述文件删除模块，包括：

获取单元，用于获取所述病毒文件的特征码；

查找单元，用于根据所述根目录，进入所述服务目录，在所述服务目录下查找所述特征码对应的文件，所述文件即为所述病毒文件；

删除单元，用于将所述病毒文件从所述服务目录中删除。

12.根据权利要求8或9所述的装置，其特征在于，

所述检测模块，还用于检测***分区中是否包含有病毒文件；

所述文件删除模块，还用于当所述***分区中的文件存在有病毒文件时，将所述病毒文件从所述***分区中删除。

13.根据权利要求8或9所述的装置，其特征在于，还包括：

引导执行模块，用于根据删除所述病毒文件后的引导分区，引导进入操作***，展现开机界面。