CN102779257B

CN102779257B - 一种Android应用程序的安全检测方法及系统

Info

Publication number: CN102779257B
Application number: CN201210221959.9A
Authority: CN
Inventors: 李涛; 张旭
Original assignee: Beijing Qihoo Technology Co Ltd; Qizhi Software Beijing Co Ltd
Current assignee: 3600 Technology Group Co ltd
Priority date: 2012-06-28
Filing date: 2012-06-28
Publication date: 2015-10-07
Anticipated expiration: 2032-06-28
Also published as: CN102779257A

Abstract

本申请提供了一种Android应用程序的安全检测方法及系统，以解决现有的Android平台的杀毒方法扫描速度慢、误报率高的问题。所述方法包括：扫描Android安装包，并从所述Android安装包中提取出指定的特征信息；在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中显示。本申请扫描速度快、查杀准确率高。

Description

一种Android应用程序的安全检测方法及系统

技术领域

本申请涉及软件安全技术领域，特别是涉及一种Android应用程序的安全检测方法及系统。

背景技术

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

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

针对这些众多的Android恶意软件，各个致力于软件杀毒的公司相继推出了Android平台的杀毒软件。但是，它们的杀毒引擎主要移植自PC上的杀毒引擎，采用传统PC杀毒的思路，按照文件进行查杀，甚至对在Android手机上根本无法运行的文件都会进行扫描，导致扫描速度慢、扫描效率低的问题；而且，扫描算法采用提取文件片段计算CRC(Cyclic Redundancy Check，循环冗余校验码)和MD5(Message Digest Algorithm，消息摘要算法第五版)再在本地数据库中查找的方法，通用性不高，容易导致误报，误报率较高。

发明内容

本申请提供了一种Android应用程序的安全检测方法及系统，以解决现有的Android平台的杀毒方法扫描速度慢、误报率高的问题。

为了解决上述问题，本申请公开了一种Android应用程序的安全检测方法，包括：扫描Android安装包，并从所述Android安装包中提取出指定的特征信息；在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中显示。

优选地，所述从Android安装包中提取出的指定的特征信息包括以下中的一种或几种组合：Android安装包的包名，版本号，数字签名，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征，可执行文件中的指令或字符串，Android安装包目录下各文件的MD5值；其中，所述可执行文件包括Dex文件，和/或，ELF文件；所述Dex文件包括classes.dex文件，扩展名为.jar的文件，以及，Dex格式的文件。

优选地，所述安全识别库中的特征信息包括以下中的一种或几种组合：各种样本Android安装包的包名，版本号，数字签名，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征，可执行文件中的指令或字符串，Android安装包目录下各文件的MD5值；其中，所述可执行文件包括Dex文件，和/或，ELF文件；所述Dex文件包括classes.dex文件，扩展名为.jar的文件，以及，Dex格式的文件；其中，所述样本Android安装包包括各种安全级别下的Android安装包。

优选地，所述在安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录，包括：将所述指定的特征信息进行组合，得到至少包含两个特征的各项特征组合；从包含最多特征的特征组合开始，在所述安全识别库中查找与所述特征组合相匹配的特征记录，如果未查找到，则逐个减少特征组合中的特征个数，针对减少了特征个数的特征组合，继续在所述安全识别库中查找与所述特征组合相匹配的特征记录，如果未查找到，则在所述安全识别库中查找与单个特征信息相匹配的特征记录。

优选地，在查找过程中，针对特征个数相同的多项特征组合，按照预先设定的先后顺序进行查找；针对单个特征信息，按照预先设定的先后顺序进行查找。

优选地，所述从Android安装包中提取出指定的特征信息，包括：从所述Android安装包的AndroidManifest.xml文件中提取出以下中的一种或几种组合：包名，版本号，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征；和/或，从所述Android安装包的META-INF\目录下的.RSA文件中提取出所述Android安装包的数字签名；和/或，从所述Android安装包的classes.dex文件中提取出可执行指令；和/或，从所述Android安装包的lib\目录下提取出ELF文件的指令或字符串。

优选地，所述安全级别包括安全、危险、谨慎和木马四个级别。

优选地，所述安全检测结果还包括以下至少一项：行为描述信息，软件描述信息，时间戳信息。

本申请还提供了一种Android应用的安全检测系统，包括：特征提取模块，用于扫描Android安装包，并从所述Android安装包中提取出指定的特征信息；检测模块，用于在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；显示模块，用于将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中显示。

优选地，所述检测模块包括：特征组合子模块，用于将所述指定的特征信息进行组合，得到至少包含两个特征的各项特征组合；第一查找子模块，用于从包含最多特征的特征组合开始，在所述安全识别库中查找与所述特征组合相匹配的特征记录；第二查找子模块，用于当第一查找子模块未查找到时，逐个减少特征组合中的特征个数，针对减少了特征个数的特征组合，继续在所述安全识别库中查找与所述特征组合相匹配的特征记录；第三查找子模块，用于当第二查找子模块未查找到时，在所述安全识别库中查找与单个特征信息相匹配的特征记录。

优选地，所述第二查找子模块在查找过程中，针对特征个数相同的多项特征组合，按照预先设定的先后顺序进行查找；所述第三查找子模块针对单个特征信息，按照预先设定的先后顺序进行查找。

优选地，所述特征提取模块包括：第一提取子模块，用于从所述Android安装包的AndroidManifest.xml文件中提取出以下中的一种或几种组合：包名，版本号，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征；和/或，第二提取子模块，用于从所述Android安装包的META-INF\目录下的.RSA文件中提取出所述Android安装包的数字签名；和/或，第三提取子模块，用于从所述Android安装包的classes.dex文件中提取出可执行指令；和/或，第四提取子模块，用于从所述Android安装包的lib\目录下提取出ELF文件的指令或字符串。

与现有技术相比，本申请包括以下优点：

首先，本申请提供的针对Android应用程序的安全检测，并不是对Android系统中的所有文件进行扫描，而是通过扫描Android安装包来进行安全检测。由于Android上的病毒、木马和其他恶意软件想要进入用户的手机，需要打包成Android安装包的形式。反过来说，如果不是一个合法的Android安装包，它就无法安装到用户手机上，也就不会对用户产生危害。基于这一点，杀毒引擎可以把查杀的目标集中到对Android安装包的扫描上，从而大大提高扫描的效率。

其次，本申请从Android安装包中提取出指定的特征进行检测，如将包名、版本号、数字签名、Android组件receiver、service、activity中的信息等作为指定的特征，这些指定的特征对于检测最具代表性，因此与移植自PC上的传统杀毒引擎相比，本申请准确抓住了Android平台下应用的几大关键特征，使得扫描速度快、查杀准确率高。

再次，本申请进行的检测提供了安全、危险、谨慎和木马四个安全级别，不仅可以检测出病毒、木马和其他恶意软件，还可以将正常的应用、存在安全风险的应用和虽然正常但存在一些问题的应用全部检测出来。因此，本申请对Android应用程序的检测不局限于传统的查毒检测，而是可以为用户提供安全、危险、谨慎等更多的提示。

最后，本申请对提取出的各项特征进行安全检测时，采用对各项特征进行组合查询的方式，进一步提高了检测效率和检测的准确率。

当然，实施本申请的任一产品不一定需要同时达到以上所述的所有优点。

附图说明

图1是本申请实施例中Android系统的架构设计图；

图2是本申请实施例所述一种Android应用程序的安全检测方法流程图；

图3是本申请实施例所述在安全识别库中进行查找的流程图；

图4是本申请另一实施例所述在安全识别库中进行查找的流程图；

图5是本申请实施例所述一种Android应用程序的安全检测系统的结构图；

图6是本申请实施例所述的安全检测系统中检测模块的结构图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

分析现有技术中的各种杀毒引擎，由于移植自PC上的杀毒引擎，主要针对的是PC系统的特性而设计，而PC系统与Android系统既有相同的特性，也有不同的特性，但现有技术并没有深入理解Android系统本身的特点，因此并不完全适合于Android系统的杀毒，存在着扫描速度慢、误报率高的问题。

基于此，本申请结合Android系统本身的特点，提出一种专门针对Android系统特性而设计的杀毒方法，下面先介绍设计思路。

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

表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都要包含数字签名(digital signature)。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系统的架构设计中，Android应用与整个系统平台之间的关系如图1所示。Android应用通常是用Java语言开发的，它用Android开发工具编译之后变成了二进制的字节码(byte code)，这些字节码被打包成classes.dex文件，由Android平台的Dalvik虚拟机来解释执行。为了能够调用Android系统功能，Android系统提供了一套运行环境(Android Framework)，Android应用调用系统各功能都是通过调用Android Framework 的库来实现的。

另一方面，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值等信息，也可以作为识别恶意软件的重要特征。其中，上述的恶意软件包括病毒、木马和其他恶意软件。

本申请实施例综合了以上各个重要特征，提出一种针对Android应用程序的安全检测方法，可以对APK的上述各项特征进行扫描、鉴定，最终识别出各种恶意软件(包括病毒、木马和其他恶意软件)。而且，本申请实施例的安全检测方法，识别结果不局限于此，还可以将正常的应用、存在安全风险的应用和虽然正常但存在一些问题的应用全部检测出来，以提示用户。

下面通过实施例对本申请所述方法的实现流程进行详细说明。

参照图2，其示出了本申请实施例所述一种Android应用程序的安全检测方法流程图。

步骤201，扫描Android安装包，并从所述Android安装包中提取出指定的特征信息；

所述指定的特征信息即指上述列举的各项重要特征，如包名、版本号、数字签名、AndroidManifest.xml中列出的各模块的入口信息、Dex文件和ELF文件、Android安装包目录下各文件的MD5值等。这些指定的特征信息对于安全检测最具代表性，因此也是用于检测的关键特征。

其中，AndroidManifest.xml中列出的各模块的入口信息包括Android组件中的特征。Android开发的四大组件分别是：活动(Activity)，用于表现功能；服务(Service)，后台运行服务，不提供界面呈现；广播接收器(Broadcas tReceiver)，用于接收广播；内容提供商(Content Provider)，支持在多个应用中存储和读取数据，相当于数据库。

因此，所述从Android安装包中提取出的指定的特征信息可以包括：

Android安装包的包名，和/或，版本号，和/或，数字签名，和/或，Android组件receiver的特征，和/或，Android组件service的特征，和/或，Android组件activity的特征，和/或，可执行文件中的指令或字符串，和/或，Android安装包目录下各文件的MD5值；

需要说明的是，所述“和/或”是指从Android安装包中可以单独提取出其中任意一项特征信息用作安全检测，也可以提取出多项特征信息的组合用作安全检测。当然，同时提取多项特征进行检测的效果要明显优于单项特征，这在后面图3所示的实施例中将进行详细说明，所以此处略。

其中，所述可执行文件包括Dex文件，和/或，ELF文件；所述Dex文件包括classes.dex文件，扩展名为.jar的文件，以及，Dex格式的文件。

具体地，在本申请的一种优选实施列中，所述可执行文件包括Dex文件，Dex文件主要是APK中的classes.dex文件，即Dalvik Executable(Dalvik虚拟机可执行文件)。公知的是，Dalvik是用于Android平台的Java虚拟机。Dalvik虚拟机(Dalvik VM)是Android移动设备平台的核心组成部分之一。它可以支持已转换为.dex(即Dalvik Executable)格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik应用作为一个独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

更为优选的是，所述可执行文件还可以包括扩展名为.jar的文件。 Android安装包中的JAR文件其实就是Dex文件，只不过其扩展名为.jar，对于APK中除classes.dex之外的其他文件，只要判定其为Dex文件即可决定是否进行扫描。

在实际应用中，所述Dex文件还可以包括其它Dex格式的文件。

此外，上述Android安装包目录下各文件的MD5值可以是数字签名的MD5值，也可以是表1中res\、assets\、lib\等目录下各文件的MD5值。

基于以上列举的指定特征，可通过以下方式从Android安装包中提取出各项指定的特征信息，参照表1可知：

从所述Android安装包的AndroidManifest.xml文件中提取出以下信息中的一种或几种组合：：包名，版本号，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征；

和/或，

从所述Android安装包的META-INF\目录下的.RSA文件中提取出所述Android安装包的数字签名；

和/或，

从所述Android安装包的classes.dex文件中提取出可执行指令；

和/或，

从所述Android安装包的lib\目录下提取出ELF文件的指令或字符串。

其中，所述“和/或”的理解与上相同，即可以从Android安装包中单独提取出其中任意一项特征信息用作安全检测，也可以提取出多项特征信息都用作安全检测。

关于具体的特征提取方法，将在后面的举例说明中进行解释。

步骤202，在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；

步骤203，将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中显示。

所述安全识别库通常需要预先设置在客户端本地，如手机文件系统中，安全识别库中预置了多条特征记录，其中，单个特征信息可以构成一条特征记录，多个特征信息的组合也可以构成一条特征记录。例如，一个安全识别库中预置了几十条特征记录，其中，第一条特征记录中列出了某种病毒的Android安装包包名，第二条特征记录中列出了某个正常应用的Android安装包版本号及其数字签名的MD5值，第三条特征记录中列出了某个正常应用的Android安装包包名及其receiver特征，第四条特征记录中列出了某种木马的Android安装包包名、版本号及其ELF文件中的特定字符串，等等。

总之，安全识别库中既收集了识别病毒、木马等各种恶意软件的特征信息，也收集了识别正常应用的特征信息，而不同于很多仅仅用于识别恶意软件的数据库。

因此，所述安全识别库中收集的特征信息可以包括以下列举的：

各种样本Android安装包的包名，和/或，版本号，和/或，数字签名，和/或，Android组件receiver的特征，和/或，Android组件service的特征，和/或，Android组件activity的特征，和/或，可执行文件中的指令或字符串，和/或，Android安装包目录下各文件的MD5值；

如前所述，所述“和/或”也是指从各种样本的Android安装包中可以单独提取出其中任意一项特征信息用作安全检测，也可以提取出多项特征信息的组合用作安全检测。

其中，所述可执行文件包括Dex文件，和/或，ELF文件；所述Dex文件包括classes.dex文件，扩展名为.jar的文件，以及，Dex格式的文件；

其中，所述样本Android安装包包括各种安全级别下的Android安装包。

本申请实施例列举出安全、危险、谨慎和木马四个安全级别。其中，各种安全级别的定义如下：

安全：该应用是一个正常的应用，没有任何威胁用户手机安全的行为；

危险：该应用存在安全风险，有可能该应用本身就是恶意软件；也有可能该应用本来是正规公司发布的正常软件，但是因为存在安全漏洞，导致用户的隐私、手机安全受到威胁；

谨慎：该应用是一个正常的应用，但是存在一些问题，例如会让用户不小心被扣费，或者有不友好的广告遭到投诉等；当发现这类应用之后，会提示用户谨慎使用并告知该应用可能的行为，但是由用户自行决定是否清除该应用；

木马：该应用是病毒、木马或者其他恶意软件，此处为了简单统称为木马，但并不表示该应用仅仅是木马。

所以，在设置安全识别库时，可以将安全、危险、谨慎和木马四个级别下的Android安装包都作为样本Android安装包，从而由样本中的单个特征或特征组合得到的特征记录可分别对应着一种安全级别及相关的行为和描述等信息。

例如，上述的第一条特征记录和第四条特征记录分别对应的安全级别均为木马级别，上述的第二条特征记录和第三条特征记录分别对应的安全级别均为安全级别。

当然，安全识别库中还可以设置一条特征记录，列出某种木马的Android安装包版本号及其数字签名的MD5值，虽然这条特征记录使用的特征组合与上述第二条特征记录相同，都使用了版本号与数字签名MD5值的组合，但是这条特征记录对应的安全级别则为“木马”。

所以，安全级别并不与某一种特定的特征或特征组合相对应，而是与具体的特征或特征组合的取值相对应。因此，如上所述，对于相同的特征或特征组合，具体取值不同，对应的安全级别也是不同的。

而且，上述安全、危险、谨慎和木马四个级别的定义仅作为举例说明，根据实际应用，当然也可以有其他的安全级别分类及定义，本申请的保护范围并不限定于此。

那么，所述在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录，并将查找到的特征记录对应的安全级别包含在所述 Android安装包的安全检测结果的步骤，可以理解为：

在安全识别库中查找特征记录，如果提取出的指定单个特征与第一条特征记录相匹配，则可以判定当前的Android安装包为木马级别；如果提取出的指定特征进行组合后与第二条特征记录或者第三条特征记录相匹配，则可以判定当前的Android安装包为安全级别；如果提取出的指定特征进行组合后与第四条特征记录相匹配，则可以判定当前的Android安装包也为木马级别。

所以，针对某个Android安装包的安全检测结果可以是包含安全、危险、谨慎或木马四个表示安全级别的信息，此外所述安全检测结果中还可以包括与安全级别相关的行为描述、软件描述、时间戳等至少一项提示信息，如对应“谨慎”级别的提示信息可以是“可能造成扣费，是否选择删除该应用”。

更具体地，在一优选实施例中，所述安全检测结果可以包含安全级别、行为描述信息、软件描述信息和时间戳信息。其中：

安全级别：可以用32位整数表示，可表示安全、危险、谨慎或木马四个安全级别，每个安全级别的定义如上所述。

行为描述信息：也可以用32位(0～31)整数表示，可以表示出各个安全级别的软件行为描述。其中，可以选取一位表示标志位，标志位为0表示没有恶意行为，如果有恶意行为，则可以定义：第1位代表“后台偷偷下载”，第2位代表“私自发送短信”，第3位代表“包含广告”，等等。即，每一位都可以单独表示一种软件的行为描述。

例如，对于检测为“木马级别”的Android应用程序，如果恶意行为＝3，翻译成二进制就是11，第1位＝1，第2位＝1，表示的恶意行为是：同时具有后台偷偷下载和私自发送短信的行为。

再例如，对于检测为“谨慎级别”的Android应用程序，如果行为描述＝4，翻译成二进制就是100，第1位＝0，第2位＝0，第2位＝1，表示的行为是：包含广告。由于这个广告可能是用户允许的，也可能是用户不允许的，所以会提示用户谨慎使用，由用户自行决定是否清除。

软件描述信息：通常表示为字符串，是对Android应用程序的说明，如发布者、发布时间等信息。

时间戳信息：表明Android应用程序的特征信息(如正常特征、木马特征等)是什么时候入库的。

实际应用中，客户端用户界面显示安全检测结果时，可以先弹出安全级别信息，如果用户点击“查看详情”按钮，再为用户展示行为描述信息、软件描述信息和时间戳信息。

综上所述，上述图2实施例提供的针对Android应用程序的安全检测方法，首先，该方法并不是对Android系统中的所有文件进行扫描，而是通过扫描Android安装包来进行安全检测。这种把查杀的目标集中到Android安装包扫描的方式，可以大大提高扫描的效率。

其次，该方法从Android安装包中提取出指定的特征进行检测，如将包名、版本号、数字签名、等作为指定的特征，这些指定的特征对于检测最具代表性，因此与移植自PC上的传统杀毒引擎相比，该方法能够准确抓住Android平台下应用的几大关键特征，使得扫描速度快、查杀准确率高。

再次，该方法进行的检测提供了安全、危险、谨慎和木马四个安全级别，不仅可以检测出病毒、木马和其他恶意软件，还可以将正常的应用、存在安全风险的应用和虽然正常但存在一些问题的应用全部检测出来。因此，本申请对Android应用程序的检测不局限于传统的查毒检测，而是可以为用户提供安全、危险、谨慎等更多的提示。

基于上述内容，在查询安全识别库的过程中，本申请另一实施例还提供了一种优化的查询方法，这种查询采用对各项特征进行组合查询的方式，可进一步提高检测效率和检测的准确率。

所述查询的基本思路是：对提取的Android安装包的几项关键特征，在安全识别库中进行组合查询，当发现匹配的特征记录时，返回该特征记录所对应的安全信息。其中，所述安全信息可以包括安全级别的描述，以及与安全级别相对应的提示信息。

下面结合图3所示的流程，通过具体举例说明这种查询过程。

参照图3，其示出了本申请实施例所述在安全识别库中进行查找的流程图。

首先，假设安全识别库中采用了三种特征信息，分别是特征一、特征二和特征三。所述“特征一”、“特征二”和“特征三”并不特指某项特征，而是可根据实际情况来设定。当然，实际情况中采用的特征不限于三种，此处仅用作举例说明。

基于这三种特征，所述安全识别库中设定了由其中的单个特征和特征组合构成的特征记录，这些特征记录包括：

包含特征一、特征二、特征三的特征记录；

包含特征一、特征二的特征记录；

包含特征一、特征三的特征记录；

包含特征一的特征记录，是指仅包含特征一；

包含特征二的特征记录，是指仅包含特征二；

包含特征三的特征记录，是指仅包含特征三。

由于包含特征二、特征三的特征记录在实际应用中无法起到明显的检测作用，所以此处删除该条特征记录。当然，根据实际应用的需要，也可能将上述给出的某些特征记录省略。

基于上述设定的安全识别库，下面通过步骤301至步骤306来说明查询安全识别库的过程。具体如下：

步骤301，判断是否找到包含特征一、特征二、特征三的特征记录；

如果找到，则返回结果，所述结果包含了与该条特征记录相对应的安全级别信息；

如果未找到，继续步骤302；

步骤302，判断是否找到包含特征一、特征二的特征记录；

如果未找到，继续步骤303；

步骤303，判断是否找到包含特征一、特征三的特征记录；

如果未找到，继续步骤304；

步骤304，判断是否找到包含特征一的特征记录；

如果未找到，继续步骤305；

步骤305，判断是否找到包含特征二的特征记录；

如果未找到，继续步骤306；

步骤306，判断是否找到包含特征三的特征记录；

如果未找到，则扫描结束。

上述流程中，需要注意的是，匹配的特征记录不一定是恶意软件的记录，也可以是正常软件的记录。例如，某安全产品的APK数字签名的MD5特征值始终为dc6dbd6e49682a57a8b82889043b93a8，假设上图中的“特征一”就是指APK数字签名的MD5，那么当检索到MD5值＝dc6dbd6e49682a57a8b82889043b93a8的特征记录时，该特征记录对应的返回结果应该为“安全”，因而就不用进行下面的步骤了，直接识别为安全的软件。

下面通过一个具体的例子说明上述流程。

假设某手机上有3款应用(实际手机至少有几十款应用，此处为说明方便而简化了)：

1.手机系统自带的拨号键盘；

2.某款手机安全产品；

3.木马Pico。

首先分别提取所述3款应用的特征信息，具体如下：

1.手机系统自带的拨号键盘

特征一：APK包名，packageName＝com.android.phone；

特征二：APK版本号，versionCode＝8；

特征三：APK数字签名的MD5值，

sigHash＝8ddb342f2da5408402d7568af21e29f9；

2.某款手机安全产品

特征一：APK包名，packageName＝com.qihoo360.mobilesafe；

特征二：APK版本号，versionCode＝137；

特征三：APK数字签名的MD5值，

sigHash＝dc6dbd6e49682a57a8b82889043b93a8；

3.木马Pico

特征一：APK包名，packageName＝com.svox.pico；

特征二：APK版本号，versionCode＝1；

特征三：APK数字签名的MD5值，

sigHash＝e89b158e4bcf988ebd09eb83f5378e87。

假设安全识别库中有以下特征记录，特征记录以数据表的形式保存：

表1：特征一+特征二+特征三

Key——com.svox.pico_1_e89b158e4bcf988ebd09eb83f5378e87；

value——木马；

表2：特征一+特征二

空；

表3：特征一+特征三

Key——

com.qihoo360.mobilesafe_dc6dbd6e49682a57a8b82889043b93a8；

value——安全；

表4：特征一

空；

表5：特征二

空；

表6：特征三

Key——8ddb342f2da5408402d7568af21e29f9；

Value——安全。

需要说明的是，上述不为空的表1、表3和表6中，每个表都可能包含多条特征记录，而不仅仅是上述列举出来的情况。例如，表6中，还可以包括特征三的Key和Value为其他值的特征记录。

查询时，分别将3款应用的特征在安全识别库中按照表1-＞表2-＞...的顺序查询，得到以下查询结果：

对于应用1：手机系统自带的拨号键盘

表1：没有查询到；

表2：没有查询到；

表3：没有查询到；

表4：没有查询到；

表5：没有查询到；

表6：查询到了，结果是“安全”，查询结束，返回结果。

对于应用2：某款手机安全产品

表1：没有查询到

表2：没有查询到

表3：查询到了，结果是“安全”，查询结束，返回结果。

对于应用3：木马Pico

表1：查询到了，结果是“木马”，查询结束，返回结果。

假设有一款应用，表1～表6都没有查询到，那么返回结果为“未知”。

如果value是其它的值，如“危险”、“谨慎”，则按照上述方式依此类推。

上面图3所示的流程仅是举例说明，用于通过一个具体的例子使本领域技术人员方便了解查询过程，但由上面的例子可以总结出这种查询的本质过程，如图4所示。

参照图4，其示出了本申请另一实施例所述在安全识别库中进行查找的流程图。

步骤401，将所述指定的特征信息进行组合，得到至少包含两个特征的各项特征组合；

所述指定的特征信息是指从待检测的Android安装包中提取出的指定的特征信息。

所述组合是指各种可能的组合，例如，将上述从某个应用中提取出的特征一、特征二、特征三进行三个特征的组合和两两组合，可得到包含特征一、特征二、特征三的特征组合，包含特征一、特征二的特征组合，包含特征一、特征三的特征组合，以及包含特征二、特征三的特征组合，共四项特征组合。但是，上例中根据实际应用的需要没有使用包含特征

二、特征三的特征组合。

步骤402，从包含最多特征的特征组合开始，在所述安全识别库中查找与所述特征组合相匹配的特征记录，如果未查找到，则继续步骤403；

例如，从包含特征一、特征二、特征三的特征组合开始查询，针对上述的应用1和应用2，均没有在安全识别库中查找到相匹配的特征记录，则继续步骤403；但是对于应用3，则在表1中查询到了匹配的特征记录，则直接返回相应结果。

步骤403，逐个减少特征组合中的特征个数，针对减少了特征个数的特征组合，继续在所述安全识别库中查找与所述特征组合相匹配的特征记录，如果未查找到，则继续步骤404；

如果查找到，则返回相应结果。

例如，对于最多包含三个特征的特征组合，减少一个特征后的特征组合包含两个特征，那么对这些包含两个特征的特征组合进行查找。

在查找过程中，针对特征个数相同的多项特征组合，可以按照预先设定的先后顺序进行查找。

例如，图3所示流程中，包含两个特征的特征组合一共有3个，去除不使用的一个特征组合，剩下的两个特征组合的查找顺序是：先对包含特征一、特征二的特征组合进行查找，然后再对包含特征一、特征三的特征组合进行查找。

需要说明的是，所述预先设定的先后顺序需要根据实际情况下的特征定义、特征组合情况来设定，而不局限于某种设定情况。实际应用中，可能有很多种设定情况，在此不一一列举。

步骤404，在所述安全识别库中查找与单个特征信息相匹配的特征记录。

在查找过程中，针对单个特征信息，也可以按照预先设定的先后顺序进行查找。

例如，图3所示流程中，先查找包含特征一的特征记录，然后查找包含特征二的特征记录，最后查找包含特征三的特征记录。

如前所述，所述预先设定的先后顺序需要根据实际情况下的特征定义、特征组合情况来设定，而不局限于某种设定情况。实际应用中，可能有很多种设定情况，在此不一一列举。

图4所示的这种查找的先后顺序，具有以下特点：

第一，这种查找顺序是按照检测精度从高到低的顺序设置的，可以最大程度地避免恶意软件的漏检、错检；

如果包含最多特征的一项特征组合能够与安全识别库中包含最多特征的一条特征记录相匹配，那么得到的查找结果是精确的；

反之，按照流程从上到下的顺序，随着查找条件的放宽，检测精度也逐渐在降低。

基于此，一个待检测的Android应用程序可能同时匹配上安全识别库中的两条特征记录，但是它在检测精度较高的查找条件时就会被检测出来，因此该流程很好地保证了检测的准确度。

第二，这种查找顺序几乎可以对所有的Android应用程序进行检测；

换而言之，按照这个流程，一个木马可以被检测出来，一个安全软件通过检测也可以得到“安全”的识别结果。

第三，特征一、特征二、...的定义顺序会影响整个流程的查找顺序；

对每个特征的定义确定后(如“特征一”指APK包名，“特征二”指APK版本号，等等)，图4流程中查找的先后顺序也就确定了。如果将“特征二”定义为APK包名，将“特征一”定义为APK版本号，那么图4的流程中，“查找包含特征一、特征三的特征记录”修改为“查找包含特征二、特征三的特征记录”；并且，后面的流程中，查找特征一和查找特征二的先后顺序也要互换一下，即先查找特征二，再查找特征一，最后查找特征三。

综上所述，由以上几点可以看出，在实际设计安全识别库的时候，选取的特征信息不同，由这些特征组合出来的特征记录也会有很大差别，而且特征的组合还会影响特征个数相同的特征记录的先后查询顺序。由此设计出来的检测流程可能有很多种，但是，所有各种可能的流程都是基于上述图4所述的过程得出来的，因此均在本申请的保护范围之内。

基于上述内容，为了使本领域技术人员更加了解本申请的内容，下面将通过举例说明特征提取过程。

本例中提取的特征包括：

1)Android安装包包名：packageName

2)Android安装包版本号：versionCode

3)Android安装包的数字签名的MD5：signature[0]

4)Android组件receiver

5)classes.dex中的指令

6)ELF文件中的字符串

7)assets，res，lib等目录下各文件的MD5

8)Android组件service，activity

下面以几个恶意软件的实例，来说明上面几项特征的含义和检测的整个过程。

1、从Android安装包的AndroidManifest.xml文件中提取出包名，版本号，Android组件receiver、service、activity的特征；

按照Android系统的设计要求，所有的应用程序，包括木马，其模块(如receiver，service，activity等)要想被Android系统所执行，需要在AndroidManifest.xml文件中声明其模块的类名。特别是很多木马，都是把自己的代码模块嵌入到正常软件中，而显然，正常的软件的代码是不会主动去调用木马的代码模块的，那么木马要想让自己的代码被执行，就必须去修改正常软件的AndroidManifest.xml文件，在其中加入自己的类名，从而就暴露了自己的踪迹，可以作为识别的特征。

样本一：Android.Geinimi魔音

Android.Geinimi木马通常寄生在正常的Android应用里面，例如，在这个样本中，它是寄生在一款叫做“魔音”的应用中。解压缩样本的Android安装包，可以得到根目录下的AndroidManifest.xml文件。这个文件是Android Binary XML(AXML)格式的，可以用AXMLPrinter2工具解码成文本XML格式。

解码的结果如下：

1)其中，package＝″com.wbs″中的com.wbs就是该Android安装包的packageName，android：versionCode＝″1″中的“1”就是versionCode。

2)receiver的特征从下面这段提取：

这段代码的含义是，当Android系统android.intent.action.BOOT_COMPLETED(即手机开机启动)事件发生之后，调用名为com.geinimi.AdServiceReceiver的类。

下文把这条特征写成：

android.intent.action.BOOT_COMPLETED＝com.geinimi.AdServiceReceiv er。

3)service的特征从下面这段提取：

这段代码的含义是，本APK应用中提供了一个Android服务程序，名为com.geinimi.custom.GoogleKeyboard。

下文把这条特征写成：

service＝com.geinimi.custom.GoogleKeyboard。

4)activity的特征从下面这段提取：

这段代码的含义是，用户在Android系统的应用列表界面点击“魔音”的图标的时候，调用名为com.geinimi.custom.Ad000_000000006的类。

下文把这条特征写成：

MAIN_LAUNCHER＝com.geinimi.custom.Ad0000_00000006.

此外，可以注意到前面的XML中，activity其实有两个，除了上面所述的以外，还有一个，如下：

其实，这才是真正的“魔音”应用的主程序入口。Android.Geinimi木马为了寄生到正常的应用中，采用了修改宿主应用的主程序入口指到自己，等木马被启动之后，再跳回宿主应用主程序入口的方法。不过本申请实施例所述的检测方法最初并不对此进行分析，而是先提取、记录特征，到最后统一判断。

所以这个activity也提取特征，下文记为：

LAUNCHER＝.MagicVoiceActivity

需要指出的是，上文为了便于理解，介绍的是“手工”从AndroidManifest.xml中提取特征的步骤。而实际应用中，为了提高特征提取的效率，可以通过调用Android Framework的相应API来完成的，例如，对于已经安装到手机上的APK文件，直接用PackageManager.getInstalledPackages()方法就可以查询到所有已安装的APK文件的packageName，versionCode等特征。显然，提取特征有多种办法，而整个检测逻辑不受具体的提取特征的方法的影响。

2、从Android安装包的META-INF\目录下的.RSA文件中提取出所述Android安装包的数字签名；

关于META-INF目录，里面有个.SF文件，内容类似为：

Signature-Version：1.0

SHA1-Digest-Manifest-Main-Attributes：zasvPbp2Pj22IZ986L4058c4i8Y＝

Created-By：1.6.0_22(Sun Microsystems Inc.)

SHA1-Digest-Manifest：yyKV+7zSDrmYPqgsQgY0uMvhXCQ＝

Name：res/drawable-hdpi/preview_bg.9.png

SHA1-Digest：EgbD5na0TDIzR7CYM+DPCmn9tjE＝

Name：res/drawable-hdpi/ic_home_arrows_5_focus.png

SHA1-Digest：BzYiVw5rVmyzw9MzKCKaA9QduEk＝

Name：res/raw/ic_menu_gallery.png

SHA1-Digest：d0vnA3rU6D1MuGhA3nzu5FtXaXQ＝

Name：res/drawable/pressed_application_background.9.png

SHA1-Digest：P84RuTx2USq2RIY2h01vEz9X4Ac＝

其中，每一项都是一个文件的校验信息，例如res/raw/ic_menu_gallery.png的校验信息是d0vnA3rU6D1MuGhA3nzu5FtXaXQ＝。如果文件被篡改，就会与校验信息不匹配，Android系统就能发现文件被篡改，从而拒绝安装。

所述校验信息的生成，是用数字证书的私钥生成的，所以无法伪造。META-INF目录下面有个公钥文件，扩展名为.RSA，Android系统用公钥来验证校验信息是否是伪造的。而提取特征，就是去检查.RSA文件的公钥信息，因为私钥和公钥是配对的，所以只要提取了公钥的特征，就能对应上唯一的私钥，而私钥是由应用的开发者自行保管的，所以可以用来区别木马和正常软件的开发者。

前文已经提到，Android系统要求每个APK都要包含数字签名。这个数字签名的信息可以通过Android的API来完成，例如，已安装到手机上的APK文件，可以通过PackageManager.getInstalledPackages()方法查询每个APK包含的数字签名。

一个Android安装包可以被多次签名，最终以最后一次签名为准。如果是通过API获取的数字签名，那么得到的是一个数组，变量名为signature，最后一次签名的数据是signature[0]。

此外，还有其它API也可以查询APK包中的数字签名，这里不一一列举。而且，手工提取signature[0]特征也可以，解压缩样本的Android安装包，在META-INF/目录下会看到CERT.RSA文件，这就是签名证书。用keytool-printcert-file CERT.RSA命令可以查看其中的详细信息，如下：

所有者：CN＝Android Debug，O＝Android，C＝US

签发人：CN＝Android Debug，O＝Android，C＝US

序列号：4ccd020e

有效期：Sun Oct 31 13:43:42 CST 2010至Mon Oct 31 13:43:42CST 2011

证书指纹：

MD5:29:4F:08:AE:04:30:7A:64:93:22:52:47:13:31:85:43

SHA1:E4:3F:46:1E:36:07:90:00:00:6C:35:FD:F5:21:42:55:0C:35:B8:A3

签名算法名称：SHA1withRSA

版本：3

3、从Android安装包的classes.dex文件中提取出可执行指令；

前文已经提到，大部分Android应用都主要是由Java语言编写，编译之后生成了Dalvik虚拟机的字节码(byte code)，打包成了classes.dex文件。解析classes.dex文件，反编译其字节码，就可以得到应用程序所要执行的指令。

可以挑选指令中能代表恶意软件特征的指令作为特征码，当发现classes.dex文件中包含这样的特征码时，就作为一个特征。例如， Android.Geinimi木马为了隐藏自己，将一些关键数据(如木马服务器信息)加密之后写入代码中，这些被加密的数据反而成为了检测识别它的特征。用dexdump工具分析classes.dex文件可看到输出中包含以下片段：

00d00c：0003 0100 1000 0000 5535 0234 8664 ...|02d4：array-data(12units)

00d024：0003 0100 1000 0000 1bea c301 eadf ...|02e0：array-data(12units)

上述片段就可以提取作为检测识别的特征。

当然，dexdump工具只是显示这些特征数据的手段之一，也可以通过其他方式自行实现解析、反编译和识别classes.dex文件的功能。

综上所述，样本一不包含ELF文件，所以没有提取到ELF特征。

从样本一中提取了上述特征之后，假设安全识别库中存在以下特征记录：

特征一：packageName＝com.wbs

特征二：无

特征三：MD5(signature[0])＝294f08ae04307a649322524713318543

特征一+特征三：安全级别为“木马”

当检测流程走到“找到包含特征一、特征三的木马？”时，找到记录，返回结果为“木马”。

4、从Android安装包的lib\目录下提取出ELF文件的指令或字符串。

样本二：Android.DroidKungFu功夫木马

功夫木马有数十种变种，它一般伪装成一个正常的应用(例如“图库锁”之类)，诱骗用户安装、运行之后，运行native executable文件，在用户手机上安装后门，使得木马制作者可以远程操纵用户手机。

对功夫木马各APK的packageName等特征的提取，与样本一一致，在此不再赘述。

下面主要介绍ELF特征的提取：

在功夫木马的Android安装包的lib/armeabi目录下，有一个libxxx.so文件，文件名随着功夫木马各变种有所变化，例如libadv3.so，libd1.so等。这是一个Linux ELF文件，可以用readelf等工具读取其信息，下面是摘取的片段：

Symbol table′.dynsym′contains 44 entries：

Num：Value Size Type Bind Vis Ndx Name

0：00000000 0 NOTYPE LOCAL DEFAULT UND

1：0000089c 0 SECTIONLOCAL DEFAULT 7

2：00001140 0 SECTIONLOCAL DEFAULT 13

3：00000000 0 FUNC GLOBAL DEFAULT UND popen

4：0000089d 168 FUNC GLOBAL DEFAULT 7 init_predata

5：00000000 0 FUNC GLOBAL DEFAULT UND pclose

6：00000c0c 0 NOTYPE GLOBAL DEFAULT ABS_exidx_end

7：0000117c 10 OBJECT GLOBAL DEFAULT 13 PROP_RUNNING_ID

8：00000000 0 OBJECT GLOBAL DEFAULT UND_stack_chk_guard

9：00000000 0 FUNC GLOBAL DEFAULT UND_aeabi_unwind_cpp_pr0

10：00007b34 0 NOTYPE GLOBAL DEFAULT ABS_bss_end_

11：00001194 27037 OBJECT GLOBAL DEFAULT 13_bindata

12：00000945 616 FUNC GLOBAL DEFAULT 7Java_com_catsw_lockgaller

...(中间略)

40：00000000 0 FUNC GLOBAL DEFAULT UND open

41：00001140 5 OBJECT GLOBAL DEFAULT 13 DEFAULT_CHANNEL

42：00001140 0 NOTYPE GLOBAL DEFAULT 13_data_start

43：00000000 0 FUNC GLOBAL DEFAULT UND close

这个片段是libadv3.so文件导出的符号表，其中Type为OBJECT的符号是关注的重点，其中的_bindata实际是木马子包，所以可以提取出来作为特征。

当然，ELF文件是灵活多变的，恶意软件的ELF文件也不仅仅表现为这种形式，所以ELF文件的特征提取可以有多种方式，除了直接从符号表提取特征外，还可以提取代码段的片段、字符串等作为特征。

本实施例提取的特征记为：_bindata CONTAINS ELF chown unlink /system/bin；其含义是，在.so文件的符号表中查询_bindata的符号，其指向的数据中包含“ELF”、“chown”、“unlink”、“/system/bin”4组字符串。

假设这条特征在安全识别库中记录为：

特征四：_bindata CONTAINS ELF chown unlink/system/bin

安全级别：木马

当检测流程走到“找到包含特征四的木马？”时，找到记录，返回结果为“木马”。

上述实施例是以手机中的应用为例进行说明，但具体应用中也可以应用到等其他基于Android平台的移动终端的应用检测中，其实施原理与上述实施例相似，故不再赘述。

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

基于上述方法实施例的说明，本申请还提供了相应的系统实施例。

参照图5，其示出了本申请实施例所述一种Android应用程序的安全检测系统的结构图。

所述针对Android应用程序的安全检测系统可以包括：特征提取模块10，检测模块20，以及，结果返回模块30。其中，

特征提取模块10，用于扫描Android安装包，并从所述Android安装包中提取出指定的特征信息；

检测模块20，用于在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；

显示模块30，用于将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中显示。

所述从Android安装包中提取出的指定的特征信息可以包括以下信息中的一种或几种组合：

Android安装包的包名，版本号，数字签名，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征，可执行文件中的指令或字符串，Android安装包目录下各文件的MD5值。

所述安全识别库中的特征信息可以包括以下信息中的一种或几种组合：

各种样本Android安装包的包名，版本号，数字签名，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征，可执行文件中的指令或字符串，Android安装包目录下各文件的MD5值。

其中，所述安全级别包括安全、危险、谨慎和木马四个级别。

综上所述，上述实施例提供的针对Android应用程序的安全检测系统具有以下优点；

首先，本申请实施例提供的针对Android应用程序的安全检测，并不是对Android系统中的所有文件进行扫描，而是通过扫描Android安装包来进行安全检测。由于Android上的病毒、木马和其他恶意软件想要进入用户的手机，需要打包成Android安装包的形式。反过来说，如果不是一个合法的Android安装包，它就无法安装到用户手机上，也就不会对用户产生危害。基于这一点，可以把查杀的目标集中到对Android安装包的扫描上，从而大大提高扫描的效率。

其次，本申请实施例从Android安装包中提取出指定的特征进行检测，如将包名、版本号、数字签名、Android组件receiver、service、activity中的信息等作为指定的特征，这些指定的特征对于检测最具代表性，因此与移植自PC上的传统杀毒引擎相比，本申请实施例准确抓住了Android平台下应用的几大关键特征，使得扫描速度快、查杀准确率高。

再次，本申请实施例进行的检测提供了安全、危险、谨慎和木马四个安全级别，不仅可以检测出病毒、木马和其他恶意软件，还可以将正常的应用、存在安全风险的应用和虽然正常但存在一些问题的应用全部检测出来。因此，本申请实施例对Android应用程序的检测不局限于传统的查毒检测，而是可以为用户提供安全、危险、谨慎等更多的提示。

上述安全检测系统可以安装在手机等终端设备中，当用户需要安装一款Android应用程序时，所述安全检测系统可以对其进行检测，并给出相应的提示，提高终端使用的安全性。

基于以上系统实施例的内容，在本申请的另一优选实施例中，参照图6所示，所述检测模块20可以包括以下子模块：

特征组合子模块21，用于将所述指定的特征信息进行组合，得到至少包含两个特征的各项特征组合；

第一查找子模块22，用于从包含最多特征的特征组合开始，在所述安全识别库中查找与所述特征组合相匹配的特征记录；

第二查找子模块23，用于当第一查找子模块22未查找到时，逐个减少特征组合中的特征个数，针对减少了特征个数的特征组合，继续在所述安全识别库中查找与所述特征组合相匹配的特征记录；

第三查找子模块24，用于当第二查找子模块23未查找到时，在所述安全识别库中查找与单个特征信息相匹配的特征记录。

优选地，所述第二查找子模块23在查找过程中，针对特征个数相同的多项特征组合，按照预先设定的先后顺序进行查找；所述第三查找子模块24针对单个特征信息，按照预先设定的先后顺序进行查找。

图6所示的检测模块20对提取出的各项特征进行安全检测时，采用对各项特征进行组合查询的方式，进一步提高了检测效率和检测的准确率。

基于以上系统实施例的内容，在本申请的另一优选实施例中，所述特征提取模块10可以包括以下子模块：

第一提取子模块，用于从所述Android安装包的AndroidManifest.xml文件中提取出以下中的一种或几种组合：包名，版本号，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征；

和/或，

第二提取子模块，用于从所述Android安装包的META-INF\目录下的.RSA文件中提取出所述Android安装包的数字签名；

和/或，

第三提取子模块，用于从所述Android安装包的classes.dex文件中提取出可执行指令；

和/或，

第四提取子模块，用于从所述Android安装包的lib\目录下提取出ELF文件的指令或字符串。

对于上述安全检测系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见图2至图4所示方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域技术人员易于想到的是：上述各个实施例的任意组合应用都是可行的，故上述各个实施例之间的任意组合都是本申请的实施方案，但是由于篇幅限制，本说明书在此就不一一详述了。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”，不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括......”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

而且，上文中的“和/或”表示本文既包含了“和”的关系，也包含了“或”的关系，其中：如果方案A与方案B是“和”的关系，则表示某实施例中可以同时包括方案A和方案B；如果方案A与方案B是“或”的关系，则表示某实施例中可以单独包括方案A，或者单独包括方案B。

本申请实施例可以实施在任何支持图形处理、互联网内容撷取和渲染的装置(或多个装置)上。这些装置包括但不限于个人计算机、集群服务器、移动电话、工作站、嵌入式系统、游戏机、电视、机顶盒，或任何其它支持计算机图形和内容显示的计算装置。这些装置可以包括但不限于拥有执行和储存指令的一个或多个处理器和存储器的装置。这些装置可以包括软件、固件和硬件。软件可以包括一个或多个应用程序和操作系统。硬件可以包括但不限于处理器、存储器及显示器。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

以上对本申请所提供的一种Android应用程序的安全检测方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种Android应用程序的安全检测方法，其特征在于，包括：

扫描Android安装包，并从所述Android安装包中提取出指定的特征信息；其中，所述特征信息为所述Android安装包中存在的用于安全检测的特征信息；

在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；所述安全识别库中的特征信息包括以下中的一种或几种组合：各种样本Android安装包的包名，版本号，数字签名，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征，可执行文件中的指令或字符串，Android安装包目录下各文件的MD5值；

将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中显示；其中，所述安全检测结果包括：行为描述信息。

2.根据权利要求1所述的方法，其特征在于，所述从Android安装包中提取出的指定的特征信息包括以下中的一种或几种组合：

Android安装包的包名，版本号，数字签名，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征，可执行文件中的指令或字符串，Android安装包目录下各文件的MD5值；

3.根据权利要求1所述的方法，其特征在于，所述可执行文件包括Dex文件，和/或，ELF文件；所述Dex文件包括classes.dex文件，扩展名为.jar的文件，以及，Dex格式的文件；

4.根据权利要求1至3任一所述的方法，其特征在于，所述在安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录，包括：

将所述指定的特征信息进行组合，得到至少包含两个特征的各项特征组合；

从包含最多特征的特征组合开始，在所述安全识别库中查找与所述特征组合相匹配的特征记录，如果未查找到，则

逐个减少特征组合中的特征个数，针对减少了特征个数的特征组合，继续在所述安全识别库中查找与所述特征组合相匹配的特征记录，如果未查找到，则

在所述安全识别库中查找与单个特征信息相匹配的特征记录。

5.根据权利要求4所述的方法，其特征在于：

在查找过程中，针对特征个数相同的多项特征组合，按照预先设定的先后顺序进行查找；

针对单个特征信息，按照预先设定的先后顺序进行查找。

6.根据权利要求2所述的方法，其特征在于，所述从Android安装包中提取出指定的特征信息，包括：

从所述Android安装包的AndroidManifest.xml文件中提取出以下中的一种或几种组合：包名，版本号，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征；

和/或，

从所述Android安装包的classes.dex文件中提取出可执行指令；

和/或，

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

所述安全级别包括安全、危险、谨慎和木马四个级别。

8.根据权利要求1所述的方法，其特征在于，所述安全检测结果还包括以下至少一项：

软件描述信息，时间戳信息。

9.一种Android应用的安全检测系统，其特征在于，包括：

特征提取模块，用于扫描Android安装包，并从所述Android安装包中提取出指定的特征信息；其中，所述特征信息为所述Android安装包中存在的用于安全检测的特征信息；

检测模块，用于在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；所述安全识别库中的特征信息包括以下中的一种或几种组合：各种样本Android安装包的包名，版本号，数字签名，Android组件receiver的特征，Android组件service的特征，Android组件activity的特征，可执行文件中的指令或字符串，Android安装包目录下各文件的MD5值；

显示模块，用于将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中显示；其中，所述安全检测结果包括：行为描述信息。

10.根据权利要求9所述的系统，其特征在于，所述从Android安装包中提取出的指定的特征信息包括以下中的一种或几种组合：

11.根据权利要求9所述的系统，其特征在于，所述可执行文件包括Dex文件，和/或，ELF文件；所述Dex文件包括classes.dex文件，扩展名为.jar的文件，以及，Dex格式的文件；

12.根据权利要求9至11任一所述的系统，其特征在于，所述检测模块包括：

特征组合子模块，用于将所述指定的特征信息进行组合，得到至少包含两个特征的各项特征组合；

第一查找子模块，用于从包含最多特征的特征组合开始，在所述安全识别库中查找与所述特征组合相匹配的特征记录；

第二查找子模块，用于当第一查找子模块未查找到时，逐个减少特征组合中的特征个数，针对减少了特征个数的特征组合，继续在所述安全识别库中查找与所述特征组合相匹配的特征记录；

第三查找子模块，用于当第二查找子模块未查找到时，在所述安全识别库中查找与单个特征信息相匹配的特征记录。

13.根据权利要求12所述的系统，其特征在于：

所述第二查找子模块在查找过程中，针对特征个数相同的多项特征组合，按照预先设定的先后顺序进行查找；

所述第三查找子模块针对单个特征信息，按照预先设定的先后顺序进行查找。

14.根据权利要求10所述的系统，其特征在于，所述特征提取模块包括：

和/或，

15.根据权利要求9所述的系统，其特征在于：

所述安全级别包括安全、危险、谨慎和木马四个级别。