CN104462971A - 根据应用程序声明特征识别恶意应用程序的方法和装置 - Google Patents

Abstract

本发明提供了一种根据应用程序声明特征识别恶意应用程序的方法和装置，涉及计算机技术领域，该方法通过获取应用程序的安装包中的清单文件，统计清单文件中记录的第一清单文件特征，根据应用程序的第一清单文件特征确定该应用程序是否为恶意应用程序，该种识别方法，根据恶意程序会在清单文件中声明其不应具有的特征进行恶意应用程序的识别，解决用户在不知情的情况下安装具有高权限的恶意应用程序的问题，识别时运算量小，速度快。

Description

根据应用程序声明特征识别恶意应用程序的方法和装置

技术领域

本发明涉及计算机技术领域，具体涉及一种根据应用程序声明特征识别恶意应用程序的方法和装置。

背景技术

目前，手机、平板电脑等移动终端应用越来越广。Android是一种基于开源协议的移动终端操作系统，经过多年的发展，它已经相当成熟并可提供诸多功能。

在Android发展的过程中，针对Android的恶意程序也越来越多。目前，对于恶意程序的识别方法主要通过提取应用程序的可执行代码特征，再通过杀毒引擎进行识别，但是仍然难免存在漏网之鱼。

为了提高用户的安全性，Android也提供了一些安全保护机制。例如，规定应用程序需要在其安装包中声明其需要使用操作系统中哪些权限、需要使用操作系统中的哪些服务，并交给用户确认。但是一般的用户在安装应用程序时，可能不会认真核对，且对于一般的用户来说，也难以理解这些声明信息。

而恶意的应用程序，也会利用这一机制，在操作系统中要求较高的权限，进而执行一些恶意行为。例如，有些恶意应用程序，其功能与发送短信无关，却会在操作系统中要求发送短信的权限，进而发现一些扣费短信，导致用户损失。

而在目前阶段，并不存在针对这一类恶意应用程序的识别方法。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种根据应用程序声明特征识别恶意应用程序的方法和相应地装置。

依据本发明的一个方面，提供了一种根据应用程序声明特征识别恶意应用程序的方法，包括：

获取应用程序的安装包中的清单文件；

统计所述清单文件中记录的第一清单文件特征；

根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序。

可选地，所述清单文件为manifest文件；

所述第一清单文件特征包括如下特征的至少一种：

包名、权限特征、服务特征、activity特征、provider特征、版本号、receiver特征。

可选地，所述应用程序声明的权限特征包括所述应用程序声明的权限以及权限数量；

所述应用程序声明的服务特征包括所述应用程序声明的服务以及服务数量；

所述activity特征包括所述应用程序声明的activity名称和activity数量；

所述provider特征包括provider名称和provider数量；

所述receiver特征包括receiver名称和数量。

可选地，所述统计所述清单文件中记录的第一清单文件特征，包括：

在所述manifest文件的第一字段处获取所述应用程序声明的包名；

在所述manifest文件的第二字段处获取所述应用程序声明的权限，并统计权限数量；

在所述manifest文件的第三字段处获取所述应用程序声明的服务，并统计服务数量；

在所述manifest文件的第四字段处获取所述应用程序声明的activity名称，并统计activity数量；

在所述manifest文件的第五字段处获取所述应用程序声明的provider名称，并统计provider数量；

在所述manifest文件的第六字段处获取所述应用程序声明的receiver名称，并统计receiver数量；

在所述manifest文件的第七字段处获取所述应用程序声明的版本号；

其中，所述第一字段为<package>，所述第二字段为<uses-permission>，所述第三字段为<service>，所述第四字段为<activity>，所述第五字段为<provider>，所述第六字段为<receiver>，所述第七字段为<version>。

可选地，所述根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序，包括：

在预置的特征库中查找与所述应用程序声明的包名对应的二清单文件特征的范围，并判断所述应用程序声明的第一清单文件特征是否与所述第二清单文件特征匹配；

当所述应用程序声明的第一清单文件特征与所述第二清单文件特征匹配时，判定所述应用程序为恶意应用程序；

当所述应用程序声明的第一清单文件特征与所述第二清单文件特征不匹配时，判定所述应用程序为非恶意程序。

可选地，所述根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序，包括：

通过在本地预置的安全识别库中查询是否存在与所述第一清单文件特征相匹配的记录确定所述应用程序是否为恶意应用程序。

可选地，确定所述应用程序是否为恶意应用程序之后，所述方法还包括：

提示用户所述应用程序为恶意应用程序，并禁止用户进行安装；

或，

清除所述应用程序。

依据本发明的一个方面，还提供了一种根据应用程序声明特征识别恶意应用程序的装置，包括：

文件获取模块，适于获取应用程序的安装包中的清单文件；

信息统计模块，适于统计所述清单文件中记录的第一清单文件特征；

识别模块，适于根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序。

可选地，所述清单文件为manifest文件；

所述第一清单文件特征包括如下特征的至少一种：

包名、权限特征、服务特征、activity特征、provider特征、版本号、receiver特征。

可选地，所述应用程序声明的权限特征包括所述应用程序声明的权限以及权限数量；

所述应用程序声明的服务特征包括所述应用程序声明的服务以及服务数量；

所述activity特征包括所述应用程序声明的activity名称和activity数量；

所述provider特征包括provider名称和provider数量；

所述receiver特征包括receiver名称和数量。

可选地，所述信息统计模块，包括：

第一统计单元，适于在所述manifest文件的第一字段处获取所述应用程序声明的包名；

第二统计单元，适于在所述manifest文件的第二字段处获取所述应用程序声明的权限，并统计权限数量；

第三统计单元，适于在所述manifest文件的第三字段处获取所述应用程序声明的服务，并统计服务数量；

第四统计单元，适于在所述manifest文件的第四字段处获取所述应用程序声明的activity名称，并统计activity数量；

第五统计单元，适于在所述manifest文件的第五字段处获取所述应用程序声明的provider名称，并统计provider数量；

第六统计单元，适于在所述manifest文件的第六字段处获取所述应用程序声明的receiver名称，并统计receiver数量；

第七统计单元，适于在所述manifest文件的第七字段处获取所述应用程序声明的版本号；

其中，所述第一字段为<package>，所述第二字段为<uses-permission>，所述第三字段为<service>，所述第四字段为<activity>，所述第五字段为<provider>，所述第六字段为<receiver>，所述第七字段为<version>。

可选地，所述识别模块，包括：

识别单元，适于在预置的特征库中查找与所述应用程序声明的包名对应的二清单文件特征的范围，并判断所述应用程序声明的第一清单文件特征是否与所述第二清单文件特征匹配；

第一判定单元，适于当所述应用程序声明的第一清单文件特征与所述第二清单文件特征匹配时，判定所述应用程序为恶意应用程序；

第二判定单元，适于当所述应用程序声明的第一清单文件特征与所述第二清单文件特征不匹配时，判定所述应用程序为非恶意程序。

可选地，所述识别模块还具体适于按照如下方式根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序：

通过在本地预置的安全识别库中查询是否存在与所述第一清单文件特征相匹配的记录确定所述应用程序是否为恶意应用程序。

可选地，所述装置还包括：

查杀模块，适于提示用户所述应用程序为恶意应用程序，并禁止用户进行安装；

或，

清除所述应用程序。

本发明提供了一种根据应用程序声明特征识别恶意应用程序的方法和装置，通过获取应用程序的安装包中的清单文件，统计清单文件中记录的第一清单文件特征，根据应用程序的第一清单文件特征确定该应用程序是否为恶意应用程序，该种识别方法，根据恶意程序会在清单文件中声明其不应具有的特征进行恶意应用程序的识别，解决用户在不知情的情况下安装具有高权限的恶意应用程序的问题，识别时运算量小，速度快。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。

附图说明

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

图1是本发明一个实施例提供的一种根据应用程序声明特征识别恶意应用程序的方法流程图；

图2是本发明一个实施例提供的一种根据应用程序声明特征识别恶意应用程序的具体方法流程图；

图3是本发明一个实施例提供的一种根据应用程序声明特征识别恶意应用程序的装置结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应该被这里阐述的实施例所限制。相反，提供这些实施例是为了能够透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一

本发明实施例提供了一种根据应用程序声明特征识别恶意应用程序的方法。其可以通过对在终端设备上安装的恶意程序查杀工具进行改进来实现。例如，本实施例中的终端设备可以为PC(Personal Computer，个人计算机)，手机，平板、手持电脑等用户移动终端设备。

图1是本实施例提供的一种根据应用程序声明特征识别恶意应用程序的方法流程图。该方法具体包括步骤S102至步骤S106。

S102：获取应用程序的安装包中的清单文件。

S104：统计清单文件中记录的第一清单文件特征。

S106：根据上述应用程序的第一清单文件特征确定该应用程序是否为恶意应用程序。

本发明提供了一种根据应用程序声明特征识别恶意应用程序的方法，通过获取应用程序的安装包中的清单文件，统计清单文件中记录的第一清单文件特征，根据应用程序的第一清单文件特征确定该应用程序是否为恶意应用程序，该种识别方法，根据恶意程序会在清单文件中声明其不应具有的特征进行恶意应用程序的识别，解决用户在不知情的情况下安装具有高权限的恶意应用程序的问题，识别时运算量小，速度快。

实施例二

本实施例为上述实施例一的一种具体应用场景，通过本实施例，能够更加清楚、具体地阐述本发明所提供的方法。

本实施例所提供的恶意应用程序的识别方法，可通过在移动终端中安装的恶意程序查杀软件实现。通过恶意查杀软件对移动终端下载、即将安装或已经安装的应用程序进行识别，以提高移动终端的安全性。

同时，还可以结合AVE引擎、AVM引擎、云查杀引擎、机器学习引擎等对手机上已经安装的应用程序进行扫描。

可以通过多个杀毒引擎进行病毒检测，驱动多个病毒引擎联合进行病毒检测；将opcode序列与多个病毒引擎的病毒库文件中的记录进行匹配，如果匹配成功则判断opcode序列包含病毒，多个病毒引擎包括：AVE引擎、AVM引擎、云查杀引擎、机器学习引擎等等。

病毒引擎可以包括：服务端和客户端，例如，云查杀引擎等等包括服务器端查杀工具和客户端查杀工具。服务端通过将opcode序列与病毒库文件中的记录匹配进行病毒检测，将病毒检测结果下发到客户端，并提供修复方案，修复方案包括：文件类型、与文件类型对应的查杀方法等等，客户端可以根据修复方案进行查杀病毒。客户端可以安装在手机、PC、PAD等上，通过手机端等上的客户端查杀引擎，或者是手机端等上的应用分发平台等工具，为用户提供可靠的移动互联网安全服务。

图2是本发明一个实施例提供的一种根据应用程序声明特征识别恶意应用程序的方法流程图，该方法包括步骤S201至S207。

在步骤S201中，当检测到预设事件发生时，触发对于预设应用程序的恶意程序查杀操作。

其中，上述预设事件可以包括，但不限于：

当恶意程序查杀软件的查杀功能或者扫描功能被触发时。

例如，可以是用户手动激活恶意程序查杀软件的查杀功能，希望对移动终端中的恶意应用程序进行查杀或扫描时，开始执行本发明所提供的恶意程序的识别方法。

或者，预设事件还可以是：当移动终端下载某一个应用程序的安装包完成时。

例如，恶意程序查杀软件可以设置为，当检测到有任意文件下载完成时，均对其进行恶意程序的扫描，以保证移动终端的操作系统的安全性。

又或者，预设事件还可以是：当操作系统中发生异常时，触发对于恶意程序的查杀操作。

例如，当用户的移动终端中频繁的出现广告弹窗或联系人信息被恶意读取，则说明操作系统中有恶意程序产生了恶意行为，对用户造成困扰，这时需要触发恶意程序查杀工具的查杀功能。

其中，对于识别应用程序是否为恶意应用程序，触发的可以为对一个特定应用程序的识别，也可以是对多个应用程序的识别。对于每个应用程序的识别方式相同，本实施例以对其中任意一个应用程序进行识别的操作。

在查杀操作被触发后，即开始执行恶意应用程序的识别操作，执行步骤S202，按照应用程序的安装包的压缩格式对该安装包进行解压。

需要说明的是，在安卓操作系统中，对于应用程序的管理均是以apk的形式，在apk中包含该应用程序的全部信息，下面对apk进行说明：

在本发明的实施例中，安装包会包括如下信息：应用程序的安装包的包名、版本号、开发者签名、Android组件receiver的特征，Android组件service的特征，provider特征，Android组件activity的特征，可执行文件中的指令或字符串，安装包目录下各文件的MD5值，其中，所述可执行文件包括Dex文件，和/或，ELF文件；所述Dex文件包括classes.dex文件，扩展名为.jar的文件，以及，Dex格式的文件。

其中，在本实施例中，第一清单文件特征可以包括上述特征中的：

安装包的包名、版本号、Android组件receiver的特征，Android组件service的特征，provider特征，Android组件activity的特征。

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文件的开发者签名也可以作为识别山寨应用程序的一个特征。

上述应用程序的开发者签名，也可称为代码签名，是在应用程序上附加一个防伪和防篡改的开发者签名来保护应用程序不被恶意修改。如果已安装的应用程序的开发者签名与应用程序的官方的开发者签名不一致，则可以认为已安装的应用程序可能被恶意修改过，该应用程序是山寨应用程序。在提取开发者签名时，对于安卓应用而言，可以从程序安装包中的元信息(META-INF)目录下提取，META-INF目录用于存储包和扩展的配置数据，例如安全性信息和版本信息，其中开发者签名就存储于此。META-INF目录如下表所示：

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

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

4)Dex文件和ELF文件

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

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

在对应用程序的安装包解压缩后，执行步骤S203，获取安装包中的manifest文件。

其中，manifest文件也即AndroidManifest.xml。

如在步骤S202中所述，在按照谷歌规定的解压格式对其进行解压后，可以得到多个文件：

META-INF文件夹、res文件夹、AndroidManifest.xml文件、classes.dex文件、resources.arsc文件。

其中，

META-INF文件夹里面存放的是证书文件，软件修改后需要将里面的证书文件删除，否则软件无法安装。并且，在该文件夹中还存在一个MANIFEST.MF文件，在该文件中记录了apk的众多配置信息，例如：manifest文件的版本、该文件的生成者、定义jar文件的签名版本、应用程序或者类装载器使用该值来构建内部的类搜索路径等。

res文件夹里存放的大部分是软件所需的资源及布局文件，部分需要汉化的单词、语句会在这些***.xml文件里。

AndroidManifest.xml是每个应用都必须定义和包含的，它描述了应用的名字、版本、权限、引用的库文件等等信息。

classes.dex文件是Java源码编译后的代码文件。

resources.arsc文件是编译后的资源文件。

在本实施例所提供的方法中，需要获取的即为其中的AndroidManifest.xml。

在获取得到manifest文件后，执行步骤S204，统计manifest文件中应用程序的第一清单文件特征。

第一清单文件特征，也即在被扫描的应用程序的安装包中提取得到的如下特征的任意一种：

安装包的包名、版本号、Android组件receiver的特征，Android组件service的特征，provider特征，Android组件activity的特征。

其中，

应用程序声明的权限特征包括应用程序声明的权限以及权限数量；

应用程序声明的服务特征包括应用程序声明的服务以及服务数量；

activity特征包括应用程序声明的activity名称和activity数量；

provider特征包括provider名称和provider数量；

receiver特征包括receiver名称和数量。

其中，包名因为是应用程序的唯一标识，因此也可以称作为标识ID。

具体地，统计manifest文件中记录的应用程序声明的包名和第一清单文件特征的方法可以包括：

在manifest文件的第一字段处获取应用程序声明的ID；

在manifest文件的第二字段处获取应用程序声明的权限，并统计权限数量；

在manifest文件的第三字段处获取应用程序声明的服务，并统计服务数量；

在manifest文件的第四字段处获取应用程序声明的activity名称，并统计activity数量；

在manifest文件的第五字段处获取应用程序声明的provider名称，并统计provider数量；

在manifest文件的第六字段处获取应用程序声明的receiver名称，并统计receiver数量；

在manifest文件的第七字段处获取应用程序声明的版本号；

其中，第一字段为<package>，第二字段为<uses-permission>，第三字段为<service>，第四字段为<activity>，第五字段为<provider>，第六字段为<receiver>，第七字段为<version>。

下面对从manifest文件中提取得到包名、权限特征和服务特征的方法进行举例说明：

manifest文件为一个xml文件，因此，在其文件中以xml的格式规定了每一种特征，并通过各个字段名对其进行标识，并且，xml格式对于数据的标识，采取了分层的数据结构。

在本实施例中，仅仅介绍对于包名、权限特征和服务特征的相关部分：

(1)包名的识别：

应用程序的包名通过package进行标识，package处于manifest文件中的第一层中，例如：

<manifest xmlns:android＝"http://schemas.android.com/apk/res/android"

package＝"com.woody.test"

android:sharedUserId＝"string"

android:sharedUserLabel＝"string resource"

android:versionCode＝"integer"

android:versionName＝"string"

android:installLocation＝["auto"|"internalOnly"|"preferExternal"]>

</manifest>

其中，由package＝"com.woody.test"可知，该应用程序对应的包名为“com.woody.test”。

(2)权限特征的识别：

在manifest文件中，应用程序的权限特征一般以字段<uses-permission>进行标识，但是也包括其他字段，例如：

<permission>、<permission-tree/>、<permission-group/>。

其中，权限特征定义了该应用程序在安卓操作系统中，可以使用的权限，例如：是否可以拨打电话、是否可以获取联系人信息、是否可以监控来电等，这些权限信息均与操作系统的安全程度相关。

应用程序的行为权限在AndroidManifest.xml文件中的声明形式如下：

<uses-permission android:name＝“使用权限”/>

作为可选实施例，可以使用Java中的可扩展标记语言(XML，ExtensibleMarkup Language)文件解析器，解析AndroidManifest.xml文件中的权限描述部分，以获取应用程序申请的行为权限列表。当然，也可以使用其他XML解析器，或者，使用其他编程语言，例如C/C++、python等编程语言开发XML解析器，对AndroidManifest.xml文件进行解析，以获得相应的应用程序所申请的行为权限列表。

下面举例示出了一个权限信息的声明为例：

<uses-permission

android:name＝"android.permission.READ_PHONE_STATE"/>

其中，在上述标签中即定义了应用程序要求具有获取通话状态的权限，也即“android.permission.READ_PHONE_STATE”，也即获取通话状态的权限。对于操作系统中的权限，可以包括多种，为了便于说明，列举部分如下：

android.permission.CALL_PHONE//允许一个程序初始化一个电话拨号，不需通过拨号用户界面需要用户确认

android.permission.CALL_PRIVILEGED//允许一个程序拨打任何号码，包含紧急号码无需通过拨号用户界面需要用户确认

android.permission.CAMERA//请求访问使用照相设备

android.permission.CHANGE_NETWORK_STATE//允许程序改变网络连接状态

android.permission.CHANGE_WIFI_STATE//允许程序改变Wi-Fi连接状态

android.permission.CLEAR_APP_USER_DATA//许一个程序清除用户数据

android.permission.DISABLE_KEYGUARD//允许程序禁用键盘锁

由此可见，manifest文件中规定的权限信息与操作系统的安全息息相关，例如，如果一个恶意应用程序获取到了“允许一个程序清除用户数据”的权限，则对用户数据具有极大威胁。

其中，在本实施例中，统计权限信息时，除了统计权限包括的类型，还可以包括统计该应用程序所要求的权限的数量。

(3)服务特征的识别：

在manifest文件中，应用程序的服务特征一般以字段<service>进行标识，该字段中标识了该应用程序对操作系统所要求的服务，例如：当程序退出时，在后台运行的服务，比如听音乐，网络下载数据等。

例如如下对于service的定义：

其中，上述标签中定义了服务，该服务所指向的类为“newservice.action”，“newservice.action”中即为该应用程序所提出的服务。

其中，在本实施例中，统计服务特征时，除了统计服务包括的类型，还可以包括统计该应用程序所要求的服务的数量。

在统计得到应用程序的包名第一清单文件特征后，执行步骤S205，判断预置的特征库中与该包名对应的第二清单文件特征是否匹配。

其中，特征库中保存有恶意应用程序的特征，在本实施例中称为第二清单文件特征，该第二清单文件特征与第一清单文件特征的类型相同，例如可以为：

应用程序的包名、权限特征、服务特征等。

例如：

某一恶意应用程序，其名称为“读书软件”，包名为“com.test.1”，但是与其功能不符，其包括了在“后台发送短信”、“读取用户的联系人信息”限2个，“在后台下载数据”的服务1个。

由观察可知，该“读书软件”要求了与其功能不符的权限和服务，因此具有恶意程序的可能，将其包名、权限信息和服务信息保存到特征库中，以后再有用户扫描时发现符合该特征的程序应用，则可将其定义为恶意应用程序。

进一步地，在进行匹配前，还包括：

根据应用程序的包名查找与该应用程序对应的第二清单文件特征。

为了防止恶意应用程序对自身包名进行改动而导致无法查找到其对应的第二清单文件特征，本步骤还可以具体的为：

根据应用程序的包名中的关键字进行第二清单文件特征的查找。

例如：包名为“ABC”，则可以根据其中的一个关键字“B”进行第二清单文件的查找。

在进行第一清单文件特征和第二清单文件特征的匹配时，匹配规则可以设定多种，且方式灵活，例如：

第一种，可以将第二清单文件特征中的权限特征设定一个范围，当第一清单文件特征中的权限特征数量在该范围内时，即认为匹配成功。

第二种，将第一清单文件特征中的任意一种与第二清单文件特征中该类型的特征进行比较。

例如，只对第一清单文件特征中的服务特征与第二清单文件特征中的服务特征进行匹配，如果匹配成功，即认为第一清单文件特征和第二清单文件特征成功。

需要说明的是，上述两种方法可以同时使用。

除了上述通过第一清单文件与第二清单文件特征进行匹配的方式，还可以采用如下方式对恶意应用程序进行识别：

在本地预置的安全识别库中查询是否存在与第一清单文件特征相匹配的记录。

优选地，在此步骤之前，还包括对安全识别库的完善，具体的方法可以为：

将恶意应用程序的清单文件特征记录到安全识别库中，以供查杀引擎进行恶意应用程序深度扫描。

深度安全扫描包括但不限于木马病毒扫描、广告插件扫描、漏洞扫描。例如，对于木马病毒扫描，可以通过将应用程序文件包与预存储的恶意程序库内的特征进行匹配，当应用程序文件包与恶意程序库内的特征相匹配时，提示该应用程序文件包为恶意程序，并建议用户禁止对该应用程序的安装。这样，在安装应用程序前，通过对待安装应用程序文件包进行深度安全扫描，可以识别出恶意应用程序，极大降低用户误安装恶意应用程序的概率。

进一步地，在进行恶意应用程序的扫描后，除了可以识别恶意应用程序，还可以包括对应用程序的风险识别，例如可以为：

安全、危险、谨慎、木马等四种状态。

通过上述方法，本发明结合多个杀毒引擎，在具体的病毒检测的过程中，可以完成服务器端和客户端的同步，本申请实施例列举出安全、危险、谨慎和木马四个安全级别。其中，各种安全级别的定义如下：

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

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

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

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

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

当第一清单文件特征与第二清单文件特征匹配成功时，执行步骤S206，即将该应用程序判定为恶意应用程序。

进一步地，在将应用程序判定为恶意应用程序时，还可以包括：

清除该恶意应用程序；

或，

将该恶意应用程序的特征加入到病毒库中，以帮助杀毒引擎对恶意应用程序进行识别。

除此之外，还可以包括：

提示用户该应用程序为恶意应用程序，并禁止用户进行安装。

第一清单文件特征与第二清单文件特征匹配不成功时，执行步骤S207，即将该应用程序判定为正常应用程序。

本发明实施例提供的根据应用程序声明特征识别恶意应用程序的识别方法，通过获取应用程序的安装包中的清单文件，统计清单文件中记录的第一清单文件特征，根据应用程序的第一清单文件特征确定该应用程序是否为恶意应用程序，该种识别方法，根据恶意程序会在清单文件中声明其不应具有的特征进行恶意应用程序的识别，解决用户在不知情的情况下安装具有高权限的恶意应用程序的问题，识别时运算量小，速度快。

实施例三

图3是本发明一个实施例提供的一种根据应用程序声明特征识别恶意应用程序的装置结构框图，该装置300包括：

文件获取模块310，适于获取应用程序的安装包中的清单文件；

信息统计模块320，适于统计清单文件中记录的第一清单文件特征；

识别模块330，适于根据应用程序的第一清单文件特征确定应用程序是否为恶意应用程序。

优选地，上述清单文件为manifest文件；

上述第一清单文件特征包括如下特征的至少一种：

包名、权限特征、服务特征、activity特征、provider特征、版本号、receiver特征。

优选地，上述应用程序声明的权限特征包括上述应用程序声明的权限以及权限数量；

上述应用程序声明的服务特征包括上述应用程序声明的服务以及服务数量；

上述activity特征包括上述应用程序声明的activity名称和activity数量；

上述provider特征包括provider名称和provider数量；

上述receiver特征包括receiver名称和数量。

优选地，所述信息统计模块320，包括：

第一统计单元321，适于在上述manifest文件的第一字段处获取上述应用程序声明的包名；

第二统计单元322，适于在上述manifest文件的第二字段处获取上述应用程序声明的权限，并统计权限数量；

第三统计单元323，适于在上述manifest文件的第三字段处获取上述应用程序声明的服务，并统计服务数量；

第四统计单元324，适于在上述manifest文件的第四字段处获取上述应用程序声明的activity名称，并统计activity数量；

第五统计单元325，适于在上述manifest文件的第五字段处获取上述应用程序声明的provider名称，并统计provider数量；

第六统计单元326，适于在上述manifest文件的第六字段处获取上述应用程序声明的receiver名称，并统计receiver数量；

第七统计单元327，适于在上述manifest文件的第七字段处获取上述应用程序声明的版本号；

其中，第一字段为<package>，第二字段为<uses-permission>，第三字段为<service>，第四字段为<activity>，第五字段为<provider>，第六字段为<receiver>，第七字段为<version>。

优选地，所述识别模块330，包括：

识别单元331，适于在预置的特征库中查找与应用程序声明的包名对应的二清单文件特征的范围，并判断应用程序声明的第一清单文件特征是否与第二清单文件特征匹配；

第一判定单元332，适于当应用程序声明的第一清单文件特征与第二清单文件特征匹配时，判定应用程序为恶意应用程序；

第二判定单元333，适于当应用程序声明的第一清单文件特征与第二清单文件特征不匹配时，判定应用程序为非恶意程序。

可选地，识别模块330还具体适于按照如下方式根据应用程序的第一清单文件特征确定应用程序是否为恶意应用程序：

通过在本地预置的安全识别库中查询是否存在与第一清单文件特征相匹配的记录确定应用程序是否为恶意应用程序。

可选地，该装置300还包括：

查杀模块340；

查杀模块340适于提示用户应用程序为恶意应用程序，并禁止用户进行安装；

或，

清除该应用程序。

本发明提供了一种根据应用程序声明特征识别恶意应用程序的装置，通过获取应用程序的安装包中的清单文件，统计清单文件中记录的第一清单文件特征，根据应用程序的第一清单文件特征确定该应用程序是否为恶意应用程序，该种识别方法，根据恶意程序会在清单文件中声明其不应具有的特征进行恶意应用程序的识别，解决用户在不知情的情况下安装具有高权限的恶意应用程序的问题，识别时运算量小，速度快。

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

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

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

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

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

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

至此，本领域技术人员应认识到，虽然本文已详尽示出和描述了本发明的多个示例性实施例，但是，在不脱离本发明精神和范围的情况下，仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此，本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。

本发明实施例提供了A1.一种根据应用程序声明特征识别恶意应用程序的方法，包括：获取应用程序的安装包中的清单文件；统计所述清单文件中记录的第一清单文件特征；根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序。A2.根据A1所述的方法，其中，所述清单文件为manifest文件；所述第一清单文件特征包括如下特征的至少一种：包名、权限特征、服务特征、activity特征、provider特征、版本号、receiver特征。A3.根据A2所述的方法，其中，所述应用程序声明的权限特征包括所述应用程序声明的权限以及权限数量；所述应用程序声明的服务特征包括所述应用程序声明的服务以及服务数量；所述activity特征包括所述应用程序声明的activity名称和activity数量；所述provider特征包括provider名称和provider数量；

所述receiver特征包括receiver名称和数量。A4.根据A3所述的方法，其中，所述统计所述清单文件中记录的第一清单文件特征，包括：在所述manifest文件的第一字段处获取所述应用程序声明的包名；在所述manifest文件的第二字段处获取所述应用程序声明的权限，并统计权限数量；在所述manifest文件的第三字段处获取所述应用程序声明的服务，并统计服务数量；在所述manifest文件的第四字段处获取所述应用程序声明的activity名称，并统计activity数量；在所述manifest文件的第五字段处获取所述应用程序声明的provider名称，并统计provider数量；在所述manifest文件的第六字段处获取所述应用程序声明的receiver名称，并统计receiver数量；在所述manifest文件的第七字段处获取所述应用程序声明的版本号；其中，所述第一字段为<package>，所述第二字段为<uses-permission>，所述第三字段为<service>，所述第四字段为<activity>，所述第五字段为<provider>，所述第六字段为<receiver>，所述第七字段为<version>。A5.根据A4所述的方法，其中，所述根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序，包括：在预置的特征库中查找与所述应用程序声明的包名对应的二清单文件特征的范围，并判断所述应用程序声明的第一清单文件特征是否与所述第二清单文件特征匹配；当所述应用程序声明的第一清单文件特征与所述第二清单文件特征匹配时，判定所述应用程序为恶意应用程序；当所述应用程序声明的第一清单文件特征与所述第二清单文件特征不匹配时，判定所述应用程序为非恶意程序。A6.根据A1所述的方法，其中，所述根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序，包括：通过在本地预置的安全识别库中查询是否存在与所述第一清单文件特征相匹配的记录确定所述应用程序是否为恶意应用程序。A7.根据A1-A6任一项所述的方法，其中，在确定所述应用程序是否为恶意应用程序之后，所述方法还包括：提示用户所述应用程序为恶意应用程序，并禁止用户进行安装；或，清除所述应用程序。

本发明实施例提供了B8.一种根据应用程序声明特征识别恶意应用程序的装置，包括：文件获取模块，适于获取应用程序的安装包中的清单文件；信息统计模块，适于统计所述清单文件中记录的第一清单文件特征；识别模块，适于根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序。B9.根据B8所述的装置，其中，所述清单文件为manifest文件；所述第一清单文件特征包括如下特征的至少一种：包名、权限特征、服务特征、activity特征、provider特征、版本号、receiver特征。B10.根据B9所述的装置，其中，所述应用程序声明的权限特征包括所述应用程序声明的权限以及权限数量；所述应用程序声明的服务特征包括所述应用程序声明的服务以及服务数量；所述activity特征包括所述应用程序声明的activity名称和activity数量；所述provider特征包括provider名称和provider数量；所述receiver特征包括receiver名称和数量。B11.根据B10所述的装置，其中，所述信息统计模块，包括：第一统计单元，适于在所述manifest文件的第一字段处获取所述应用程序声明的包名；第二统计单元，适于在所述manifest文件的第二字段处获取所述应用程序声明的权限，并统计权限数量；第三统计单元，适于在所述manifest文件的第三字段处获取所述应用程序声明的服务，并统计服务数量；第四统计单元，适于在所述manifest文件的第四字段处获取所述应用程序声明的activity名称，并统计activity数量；第五统计单元，适于在所述manifest文件的第五字段处获取所述应用程序声明的provider名称，并统计provider数量；第六统计单元，适于在所述manifest文件的第六字段处获取所述应用程序声明的receiver名称，并统计receiver数量；第七统计单元，适于在所述manifest文件的第七字段处获取所述应用程序声明的版本号；其中，所述第一字段为<package>，所述第二字段为<uses-permission>，所述第三字段为<service>，所述第四字段为<activity>，所述第五字段为<provider>，所述第六字段为<receiver>，所述第七字段为<version>。B12.根据B11所述的装置，其中，所述识别模块，包括：识别单元，适于在预置的特征库中查找与所述应用程序声明的包名对应的二清单文件特征的范围，并判断所述应用程序声明的第一清单文件特征是否与所述第二清单文件特征匹配；第一判定单元，适于当所述应用程序声明的第一清单文件特征与所述第二清单文件特征匹配时，判定所述应用程序为恶意应用程序；第二判定单元，适于当所述应用程序声明的第一清单文件特征与所述第二清单文件特征不匹配时，判定所述应用程序为非恶意程序。B13.根据B8所述的装置，其中，所述识别模块还具体适于按照如下方式根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序：通过在本地预置的安全识别库中查询是否存在与所述第一清单文件特征相匹配的记录确定所述应用程序是否为恶意应用程序。B14.根据B8-B13任一项所述的装置，其中，所述装置还包括：查杀模块，适于提示用户所述应用程序为恶意应用程序，并禁止用户进行安装；或，清除所述应用程序。

Claims (10)

1.一种根据应用程序声明特征识别恶意应用程序的方法，包括：

获取应用程序的安装包中的清单文件；

统计所述清单文件中记录的第一清单文件特征；

根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序。

2.根据权利要求1所述的方法，其中，

所述清单文件为manifest文件；

所述第一清单文件特征包括如下特征的至少一种：

包名、权限特征、服务特征、activity特征、provider特征、版本号、receiver特征。

3.根据权利要求2所述的方法，其中，所述应用程序声明的权限特征包括所述应用程序声明的权限以及权限数量；

所述应用程序声明的服务特征包括所述应用程序声明的服务以及服务数量；

所述activity特征包括所述应用程序声明的activity名称和activity数量；

所述provider特征包括provider名称和provider数量；

所述receiver特征包括receiver名称和数量。

4.根据权利要求3所述的方法，其中，所述统计所述清单文件中记录的第一清单文件特征，包括：

在所述manifest文件的第一字段处获取所述应用程序声明的包名；

在所述manifest文件的第二字段处获取所述应用程序声明的权限，并统计权限数量；

在所述manifest文件的第三字段处获取所述应用程序声明的服务，并统计服务数量；

在所述manifest文件的第四字段处获取所述应用程序声明的activity名称，并统计activity数量；

在所述manifest文件的第五字段处获取所述应用程序声明的provider名称，并统计provider数量；

在所述manifest文件的第六字段处获取所述应用程序声明的receiver名称，并统计receiver数量；

在所述manifest文件的第七字段处获取所述应用程序声明的版本号；

其中，所述第一字段为<package>，所述第二字段为<uses-permission>，所述第三字段为<service>，所述第四字段为<activity>，所述第五字段为<provider>，所述第六字段为<receiver>，所述第七字段为<version>。

5.根据权利要求4所述的方法，其中，所述根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序，包括：

在预置的特征库中查找与所述应用程序声明的包名对应的二清单文件特征的范围，并判断所述应用程序声明的第一清单文件特征是否与所述第二清单文件特征匹配；

当所述应用程序声明的第一清单文件特征与所述第二清单文件特征匹配时，判定所述应用程序为恶意应用程序；

当所述应用程序声明的第一清单文件特征与所述第二清单文件特征不匹配时，判定所述应用程序为非恶意程序。

6.一种根据应用程序声明特征识别恶意应用程序的装置，包括：

文件获取模块，适于获取应用程序的安装包中的清单文件；

信息统计模块，适于统计所述清单文件中记录的第一清单文件特征；

识别模块，适于根据所述应用程序的第一清单文件特征确定所述应用程序是否为恶意应用程序。

7.根据权利要求6所述的装置，其中，

所述清单文件为manifest文件；

所述第一清单文件特征包括如下特征的至少一种：

包名、权限特征、服务特征、activity特征、provider特征、版本号、receiver特征。

8.根据权利要求7所述的装置，其中，所述应用程序声明的权限特征包括所述应用程序声明的权限以及权限数量；

所述应用程序声明的服务特征包括所述应用程序声明的服务以及服务数量；

所述activity特征包括所述应用程序声明的activity名称和activity数量；

所述provider特征包括provider名称和provider数量；

所述receiver特征包括receiver名称和数量。

9.根据权利要求8所述的装置，其中，所述信息统计模块，包括：

第一统计单元，适于在所述manifest文件的第一字段处获取所述应用程序声明的包名；

第二统计单元，适于在所述manifest文件的第二字段处获取所述应用程序声明的权限，并统计权限数量；

第三统计单元，适于在所述manifest文件的第三字段处获取所述应用程序声明的服务，并统计服务数量；

第四统计单元，适于在所述manifest文件的第四字段处获取所述应用程序声明的activity名称，并统计activity数量；

第五统计单元，适于在所述manifest文件的第五字段处获取所述应用程序声明的provider名称，并统计provider数量；

第六统计单元，适于在所述manifest文件的第六字段处获取所述应用程序声明的receiver名称，并统计receiver数量；

第七统计单元，适于在所述manifest文件的第七字段处获取所述应用程序声明的版本号；

其中，所述第一字段为<package>，所述第二字段为<uses-permission>，所述第三字段为<service>，所述第四字段为<activity>，所述第五字段为<provider>，所述第六字段为<receiver>，所述第七字段为<version>。

10.根据权利要求9所述的装置，其中，所述识别模块，包括：

识别单元，适于在预置的特征库中查找与所述应用程序声明的包名对应的二清单文件特征的范围，并判断所述应用程序声明的第一清单文件特征是否与所述第二清单文件特征匹配；

第一判定单元，适于当所述应用程序声明的第一清单文件特征与所述第二清单文件特征匹配时，判定所述应用程序为恶意应用程序；

第二判定单元，适于当所述应用程序声明的第一清单文件特征与所述第二清单文件特征不匹配时，判定所述应用程序为非恶意程序。