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

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安装包中提取而出；在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；将查找到的特征记录对应的安全级别包含在所述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安装包，并从所述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系统中的所有文件进行扫描，而是通过扫描Android安装包来进行安全检测。由于Android上的病毒、木马和其他恶意软件想要进入用户的手机，需要打包成Android安装包的形式。反过来说，如果不是一个合法的Android安装包，它就无法安装到用户手机上，也就不会对用户产生危害。基于这一点，杀毒引擎可以把查杀的目标集中到对Android安装包的扫描上，从而大大提高扫描的效率。 

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

再次，本申请将客户端检测与服务器检测相结合，不仅可以在客户端本地对Android应用程序进行安全检测，还可以将提取的特征上传到服务器检测。由于服务器设置的安全识别库时常保持更新，无论哪个客户端或人工识别出新的或变种的病毒、木马等特征，都会立即更新到该库中，所以该库中的特征更大、更全，可以检测出客户端本地检测不到的特征，因此对各种恶意软件的变种识别能力大大增强。 

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

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

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

附图说明

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

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

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

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

图5是本申请另一实施例所述一种针对Android应用程序的服务器侧的安全检测流程图； 

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

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

图8是本申请实施例所述一种设在客户端针对Android应用程序的安全检测系统的结构图； 

图9是本申请另一实施例所述一种设在客户端针对Android应用程序的安全检测系统的结构图； 

图10是本申请另一实施例所述一种设在客户端针对Android应用程序的安全检测系统的结构图； 

图11是本申请实施例所述一种设在服务器针对Android应用程序的安 全检测系统的结构图； 

图12是本申请另一实施例所述一种设在服务器针对Android应用程序的安全检测系统的结构图。 

具体实施方式

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

分析现有技术中的各种杀毒引擎，由于移植自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应用程序的安全检测方法流程图。 

本实施例中，客户端(如手机)直接从本地的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应用程序的检测不局限于传统的查毒检测，而是可以为用户提供安全、危险、谨慎等更多的提示。 

基于以上内容，下面通过实施例说明优先在本地检测，然后再上传服务器检测的情况。 

此时，本申请实施例又提供了两种情况：一种是本地优先检测完后，无论检测结果如何，都上传到服务器重新检测，然后将两种检测结果合并，具体如图3实施例所述；另一种是本地优先检测，如果对提取的特征全部检测出结果，则无需上传服务器再检测，但如果本地有无法识别的特征，则再上传服务器检测，最后将两种检测结果合并，具体如图4实施例所述。 

下面分别详细说明。 

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

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

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

步骤303，客户端将本地查找到的特征记录对应的安全级别包含在所 述Android安装包的本地安全检测结果中； 

步骤304，客户端将所述指定的特征信息上传到服务器，在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述服务器预置的安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合； 

其中，客户端通常将全部的指定特征都上传到服务器进行再次检测； 

步骤305，客户端接收服务器返回的针对所述Android安装包的安全检测结果，所述安全检测结果中包含服务器查找到的特征记录对应的安全级别； 

步骤306，客户端将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后在客户端用户界面显示。 

其中，所述合并是指：将服务器返回的安全检测结果与本地安全检测结果逐条对比，如果两者相同，则合并成一条结果；如果两者不同，则以服务器的安全检测结果为准。 

需要说明的是，上述客户端本地预置的安全识别库与上述服务器预置的安全识别库类似，因此对本地预置的安全识别库的介绍可参照上述服务器预置的安全识别库的说明。 

但是，两者的不同之处在于：服务器设置的安全识别库时常保持更新，无论哪个客户端或人工识别出新或变种的病毒、木马等特征，都会立即更新到该库中，所以该库中的特征更大、更全，可以检测出客户端本地检测不到的特征，因此对各种恶意软件的变种识别能力大大增强。这也是在本地检测完之后，再次上传到服务器进行检测的主要原因，可以避免客户端本地漏检。 

而且，还需要说明的是，上述过程中，步骤302、303既可以与步骤304、305先后执行，也可以同时并行执行。 

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

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

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

其中，客户端可能查找到与所有指定的单个特征信息或其组合相匹配的特征记录，也可能只查找到与部分指定的单个特征信息或其组合相匹配的特征记录； 

步骤43，客户端将本地查找到的特征记录对应的安全级别包含在所述Android安装包的本地安全检测结果中； 

其中，所述本地安全检测结果中包含所有能够查找到的特征记录对应的安全级别； 

步骤441，如果客户端在本地预置的安全识别库中查找到与所有指定的单个特征信息或其组合相匹配的特征记录，则取消将所述指定的特征信息上传到服务器，并将所述本地安全检测结果在客户端用户界面显示，流程结束。 

换而言之，如果所有的指定特征，无论以单个特征的形式，还是以组合的形式，都能在客户端本地的安全识别库中找到相匹配的特征记录，那么将结束流程，不再上传到服务器检测； 

步骤442，如果客户端在本地预置的安全识别库中查找到与部分指定的单个特征信息或其组合相匹配的特征记录，则将全部或剩余部分的指定的特征信息上传到服务器查找，其中，所述剩余部分的指定的特征信息为未在本地查找到相匹配的特征记录的特征信息； 

换而言之，如果客户端在本地的安全识别库中查找后还存在不能识别的单个特征或特征组合，即本地不能最终确认所述Android安装包的安全性，此时需要上传到服务器进行检测；上传时，可以将剩余部分的指定特征(即不能识别的特征)上传，也可以将全部的指定特征上传，这样 可以对本地识别出的特征在服务器上进行复查； 

具体的，指定特征上传后，在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述服务器预置的安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合； 

步骤452，客户端接收服务器返回的针对所述Android安装包的安全检测结果，所述安全检测结果中包含服务器查找到的特征记录对应的安全级别； 

步骤462，客户端将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后在客户端用户界面显示。 

基于上述图2、图3和图4实施例的内容，下面通过本申请提供的另一实施例，说明上述各实施例的应用场景。具体如下： 

客户端在本地预置的安全识别库中查找之前，还可包括以下处理步骤： 

依据预设的配置信息，确定直接将所述指定的特征信息上传到服务器查找，或者直接在本地查找，或者提示用户选择在本地查找还是上传到服务器查找。 

其中，所述预设的配置信息可包括以下几种： 

1)当所述配置信息表示不允许提供本地预置的安全识别库时，确定直接将所述指定的特征信息上传到服务器查找； 

根据实际应用的需要，可能存在不允许在客户端设置安全识别库的情况，此时，客户端提取出特征信息后，可以直接上传到服务器检测。 

2)当所述配置信息表示优先在本地查找时，确定直接在本地查找； 

这种情况下，客户端提取特征信息后，会自动在本地查找。这是一种实际应用中普遍使用的模式，因为客户端通常会从服务器下载或从PC机安装安全识别库，所以可以优先使用本地安全识别库进行查找。 

进一步地，客户端还可以在配置信息中设置两种情况： 

其一，如图3实施例所述，本地查找完后，全部上传服务器再次复查； 

其二，如图4实施例所述，本地查找完后，依据本地查找结果确定是否需要上传服务器查找。 

实际应用中，一款手机中可能安装上百个软件应用程序，但是由于客户端本地容量有限，一般只能识别出20个左右的应用程序，对于剩余的将近80款软件应用程序未能识别，此时的配置可以是在本地查找完后，全部上传服务器再次复查，也可以配置成将本地未能识别的特征上传服务器继续查找。实际情况下，将全部特征都上传复查是一种比较简便、能够保证识别准确度的方式。 

3)当所述配置信息表示优先由用户选择时，确定提示用户选择在本地查找还是上传到服务器查找。 

这种情况下，需要由用户参与选择，客户端提取出特征信息后，在客户端用户界面显示提示信息，提示用户选择在本地查找还是上传到服务器查找。通常，如果用户手机有包月的上网流量，则可以选择上传服务器查找，因为这样查找的准确率更高；如果上网流量用完，又不想额外耗费更多流量，则可以选择仅在本地查找，或者优先在本地查找，如果本地查找结果不全，再将剩余未识别的特征上传服务器查找。 

总之，实际应用中的很多场景下，都可灵活选择以上任意一种或几种实现方式的组合，本申请不再一一列举。 

而无论上述的哪种应用情况，上传到服务器的安全检测过程都可参照下图5所示的流程。 

参照图5，其示出了本申请另一实施例所述一种针对Android应用程序的服务器侧的安全检测流程图。 

无论客户端本地是否对提取的特征进行检测，只要客户端将特征上传到服务器，服务器就会按照以下流程进行检测： 

步骤501，服务器接收客户端上传的指定的特征信息，所述指定的特征信息是客户端从Android安装包中提取而出； 

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

步骤503，服务器将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中发送给对应的客户端。 

优选地，当在服务器预置的安全识别库中未查找到相匹配的特征记录时，还可以包括以下步骤： 

识别所述指定的特征信息，并根据识别结果确定与所述指定的单个特征信息或其组合相匹配的特征记录及特征记录对应的安全级别； 

将所述特征记录及特征记录对应的安全级别更新到所述服务器预置的安全识别库中。 

其中，所述识别过程中可以介入人工识别，帮助准确定位识别结果。例如，目前的病毒、木马和其他恶意软件都是产业化运作，甚至有商业公司参与其中，它们制作、发布恶意软件形成了正规化、流程化的链条，其中一个环节就是“杀毒软件免杀测试”。 

简单地说，就是这些专业的制作者，在散发自己的恶意软件之前，都会先用几大杀毒软件公司的杀毒软件更新到最新的病毒库之后扫描一遍，如果被杀毒软件报告为病毒，那么它们就会尝试去修改自己的恶意软件，直到杀毒软件最终扫不出来为止。 

理论上讲，如果只考虑一对一的情况，无论设计什么样的查杀逻辑，终归能被对手分析出规律，从而找出绕过的方法。一般地查杀，对于某个应用，如果本地查杀引擎穷举所有的特征记录之后，仍没有匹配的记录，那么扫描就结束了。 

而本申请实施例中服务器查杀的优势就在于：穷举已知的所有特征记录都没有匹配，那么就将该应用的特征信息归档，交给检测中心分析处理。检测中心通过人工介入分析之后，鉴定是安全或者恶意软件，都会更新服务器的安全识别库，这样，下一次服务器杀查询相同的应用特征 的时候，就能即时返回结果。因此，即便恶意软件的制作者暂时找到了绕过当前查杀的方法，通过了“免杀”的测试，但等这个恶意软件真正发布到市场上之后，还是很快会被服务器查杀识别定位。 

综上所述，上述各实施例中，针对Android应用程序的安全检测既可以在客户端本地完成，也可以在服务器完成，还可以将本地检测与服务器检测相结合。无论哪种检测模式，都可通过下面的详细过程实现。 

在查询安全识别库的过程中，本申请实施例提供了一种优化的查询方法，这种查询采用对各项特征进行组合查询的方式，可进一步提高检测效率和检测的准确率。其中，所述安全识别库可以是客户端本地设置的安全识别库，也可以是服务器设置的安全识别库。 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上述流程中，需要注意的是，匹配的特征记录不一定是恶意软件的记录，也可以是正常软件的记录。例如，某安全产品的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_l_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是其它的值，如“危险”、“谨慎”，则按照上述方式依此类推。 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于此，一个待检测的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.AdServiceReceiver。 

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

<service android:enabled＝″true″android:name＝″com.geinimi.custom.GoogleKeyboard″...(中间略)/> 

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

下文把这条特征写成： 

service＝com.geinimi.custom.GoogleKeyboard。 

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

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

下文把这条特征写成： 

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:42 CST 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 SECTION LOCAL DEFAULT 7 

2:00001140 0 SECTION LOCAL 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 7 Java_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平台的移动终端的应用检测中，其实施原理与上述实施例相似，故不再赘述。 

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

基于上述方法实施例的说明，本申请还提供了相应的系统实施例，包括设置在客户端的安全检测系统(如图8至图10所示)，以及设置在服务器的安全检测系统(如图11、图12所示)。下面分别详细说明。 

参照图8，其示出了本申请实施例所述一种设在客户端针对Android应用程序的安全检测系统的结构图。 

所述针对Android应用程序的安全检测系统设置在客户端，可以包括以下模块： 

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

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

显示模块83，用于接收服务器返回的针对所述Android安装包的安全检测结果，并在客户端用户界面显示，所述安全检测结果中包含服务器查找到的特征记录对应的安全级别。 

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

优选地，在本申请的另一实施例中，如图9所示，所述设在客户端的安全检测系统除包括特征提取模块81、上传模块82和显示模块83外，还可以包括： 

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

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

优选地，所述系统还可以包括： 

合并模块85，用于将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后通过所述显示模块83在客户端用户界面显示。 

优选地，所述本地检测模块84具体可以包括以下子模块： 

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

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

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

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

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

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

优选地，在本申请的另一实施例中，如图10所示，所述设在客户端的安全检测系统除包括特征提取模块81、上传模块82、显示模块83和本地检测模块84外，还可以包括： 

取消上传模块86，用于当所述本地检测模块84在本地预置的安全识别库中查找到与所有指定的单个特征信息或其组合相匹配的特征记录时，取消将所述指定的特征信息上传到服务器，并通过所述显示模块83将所述本地安全检测结果在客户端用户界面显示。 

优选地，当所述本地检测模块84在本地预置的安全识别库中查找到与部分指定的单个特征信息或其组合相匹配的特征记录，则所述上传模块82将全部或剩余部分的指定的特征信息上传到服务器查找，其中，所述剩余部分的指定的特征信息为未在本地查找到相匹配的特征记录的特征信息； 

所述合并模块85将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后通过所述显示模块83在客户端用户界面显示。 

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

优选地，在本申请的另一实施例中，基于图8、图9、图10各实施例的内容，所述设在客户端的安全检测系统还可以包括： 

模式选择模块，用于所述本地检测模块84在本地预置的安全识别库中查找之前，依据预设的配置信息，确定直接将所述指定的特征信息上传到服务器查找，或者直接在本地查找，或者提示用户选择在本地查找还是上传到服务器查找。 

其中， 

当所述配置信息表示不允许提供本地预置的安全识别库时，确定直接将所述指定的特征信息上传到服务器查找； 

当所述配置信息表示优先在本地查找时，确定直接在本地查找； 

当所述配置信息表示优先由用户选择时，确定提示用户选择在本地查找还是上传到服务器查找。 

参照图11，其示出了本申请实施例所述一种设在服务器针对Android应用程序的安全检测系统的结构图。 

所述针对Android应用程序的安全检测系统设置在服务器上，可以包括以下模块： 

接收模块91，用于接收上传的指定的特征信息，所述指定的特征信息是从Android安装包中提取而出； 

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

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

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

优选地，在本申请的另一实施例中，如图12所示，所述设在客户端的安全检测系统除包括接收模块91、网络检测模块92和发送模块93外，还可以包括： 

特征识别模块94，用于当所述网络检测模块在预置的安全识别库中未查找到相匹配的特征记录时，识别所述指定的特征信息，并根据识别结果确定与所述指定的单个特征信息或其组合相匹配的特征记录及特征记录对应的安全级别； 

更新模块95，用于将所述特征记录及特征记录对应的安全级别更新到所述安全识别库中。 

优选地，在本申请的另一实施例中，基于图11和图12所示的各实施例，其中的网络检测模块93具体可以包括以下子模块： 

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

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

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

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

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

优选地，所述上传的指定的特征信息包括以下中的一种或几种组合： 

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安装包。 

对于上述系统装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见图6、图7所示方法实施例的部分说明即可。 

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

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

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

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

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

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

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

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

Claims (28)

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

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

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

接收服务器返回的针对所述Android安装包的安全检测结果，并在客户端用户界面显示，所述安全检测结果中包含服务器查找到的特征记录对应的安全级别。

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

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

将本地查找到的特征记录对应的安全级别包含在所述Android安装包的本地安全检测结果中。

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

将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后在客户端用户界面显示。

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

如果在本地预置的安全识别库中查找到与所有指定的单个特征信息或其组合相匹配的特征记录，则还包括：

取消将所述指定的特征信息上传到服务器，并将所述本地安全检测结果在客户端用户界面显示。

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

如果在本地预置的安全识别库中查找到与部分指定的单个特征信息或其组合相匹配的特征记录，则将全部或剩余部分的指定的特征信息上传到服务器奎找，其中，所述剩余部分的指定的特征信息为未在本地查找到相匹配的特征记录的特征信息；

将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后在客户端用户界面显示。

6.根据权利要求2所述的方法，其特征在于，所述在本地预置的安全识别库中查找之前，还包括：

依据预设的配置信息，确定直接将所述指定的特征信息上传到服务器查找，或者直接在本地查找，或者提示用户选择在本地查找还是上传到服务器查找。

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

当所述配置信息表示不允许提供本地预置的安全识别库时，确定直接将所述指定的特征信息上传到服务器查找；

当所述配置信息表示优先在本地查找时，确定直接在本地查找；

当所述配置信息表示优先由用户选择时，确定提示用户选择在本地查找还是上传到服务器查找。

8.根据权利要求2所述的方法，其特征在于，所述在本地预置的或服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录，包括：

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

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

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

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

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

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

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

接收上传的指定的特征信息，所述指定的特征信息是从Android安装包中提取而出；

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

将查找到的特征记录对应的安全级别包含在所述Android安装包的安全检测结果中发送。

11.根据权利要求10所述的方法，其特征在于，当在服务器预置的安全识别库中未查找到相匹配的特征记录时，还包括：

识别所述指定的特征信息，并根据识别结果确定与所述指定的单个特征信息或其组合相匹配的特征记录及特征记录对应的安全级别；

将所述特征记录及特征记录对应的安全级别更新到所述服务器预置的安全识别库中。

12.根据权利要求10所述的方法，其特征在于，所述在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录，包括：

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

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

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

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

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

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

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

14.根据权利要求10所述的方法，其特征在于，所述上传的指定的特征信息包括以下中的一种或几种组合：

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

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

15.根据权利要求10所述的方法，其特征在于，所述安全识别库中的特征信息包括以下中的一种或几种组合：

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

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

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

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

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

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

显示模块，用于接收服务器返回的针对所述Android安装包的安全检测结果，并在客户端用户界面显示，所述安全检测结果中包含服务器查找到的特征记录对应的安全级别。

17.根据权利要求16所述的系统，其特征在于，还包括：

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

还用于将本地查找到的特征记录对应的安全级别包含在所述Android安装包的本地安全检测结果中。

18.根据权利要求17所述的系统，其特征在于，还包括：

合并模块，用于将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后通过所述显示模块在客户端用户界面显示。

19.根据权利要求17所述的系统，其特征在于，还包括：

取消上传模块，用于当所述本地检测模块在本地预置的安全识别库中查找到与所有指定的单个特征信息或其组合相匹配的特征记录时，取消将所述指定的特征信息上传到服务器，并通过所述显示模块将所述本地安全检测结果在客户端用户界面显示。

20.根据权利要求18所述的系统，其特征在于，还包括：

当所述本地检测模块在本地预置的安全识别库中查找到与部分指定的单个特征信息或其组合相匹配的特征记录，则所述上传模块将全部或剩余部分的指定的特征信息上传到服务器查找，其中，所述剩余部分的指定的特征信息为未在本地查找到相匹配的特征记录的特征信息；

所述合并模块将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后通过所述显示模块在客户端用户界面显示。

21.根据权利要求17所述的系统，其特征在于，还包括：

模式选择模块，用于所述本地检测模块在本地预置的安全识别库中查找之前，依据预设的配置信息，确定直接将所述指定的特征信息上传到服务器查找，或者直接在本地查找，或者提示用户选择在本地查找还是上传到服务器查找。

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

当所述配置信息表示不允许提供本地预置的安全识别库时，确定直接将所述指定的特征信息上传到服务器查找；

当所述配置信息表示优先在本地查找时，确定直接在本地查找；

当所述配置信息表示优先由用户选择时，确定提示用户选择在本地查找还是上传到服务器查找。

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

接收模块，用于接收上传的指定的特征信息，所述指定的特征信息是从Android安装包中提取而出；

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

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

24.根据权利要求23所述的系统，其特征在于，还包括：

特征识别模块，用于当所述网络检测模块在服务器预置的安全识别库中未查找到相匹配的特征记录时，识别所述指定的特征信息，并根据识别结果确定与所述指定的单个特征信息或其组合相匹配的特征记录及特征记录对应的安全级别；

更新模块，用于将所述特征记录及特征记录对应的安全级别更新到所述服务器预置的安全识别库中。

25.根据权利要求23所述的系统，其特征在于，所述网络检测模块包括：

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

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

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

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

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

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

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

27.根据权利要求23所述的系统，其特征在于，所述上传的指定的特征信息包括以下中的一种或几种组合：

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

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

28.根据权利要求23所述的系统，其特征在于，所述安全识别库中的特征信息包括以下中的一种或几种组合：

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

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

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

Images