CN106951780A - 重打包恶意应用的静态检测方法和装置 - Google Patents

Abstract

本发明涉及一种重打包恶意应用的静态检测方法和装置，该方法包括：获取待检测应用程序的安装包的API调用序列及各个API调用序列所属的类之间的关联关系；构建基于类的函数调用关系图；对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；在恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；确定待检测应用程序是否为重打包的恶意应用程序。本发明不依赖于Android官方应用程序，且以类为单位进行提取恶意代码，所以针对变种的恶意代码，也能保证有较高的准确度。

Description

重打包恶意应用的静态检测方法和装置

技术领域

本发明涉及恶意代码检测技术领域，尤其是涉及一种重打包恶意应用的静态检测方法和装置。

背景技术

随着移动互联网的快速发展，由于智能终端(例如智能手机、平板等)的方便携带、性能出色、功能丰富(例如即时通讯、处理办公、网络游戏等)，智能终端的销售量迅速增长。目前，***互联网用户已超过8亿，2015年Google Play已经突破140万种应用，国内的各种第三方的应用市场也拥有大量的移动应用。这些应用给人们带来巨大便利的同时，也带来很大的信息安全隐患和风险。一项基于Android***的恶意应用程序分析的研究表明：在分析1260个恶意应用程序样本后，发现1083个(86％)恶意应用程序是经过合法版本与恶意应用程序经过重新打包生成的。

面对Android平台上恶意重打包应用程序泛滥的问题，国内外研究学者提出了不同的检测方法。其中DroidMOSS是典型的代表，该方法首先假设Android官方应用市场的Android应用程序是最初始的、未经过重新打包的并且是非恶意的，以检测第三方应用市场等其他来源的Android应用程序是否为重打包恶意应用程序。其中检测过程采用的是模糊哈希算法，基于指令序列生成Android应用程序的唯一签名，然后进行成对的比较，实现应用程序是否恶意的检测。

在上述检测方法中，假设Android官方应用市场的应用程序是原生的、非恶意的且未经过重新打包的，这种假设在某些方面过于乐观，无法检测出Android应用市场上的重打包应用程序。而且，对于变种恶意代码的检测能力都颇为有限，需要及时地更新恶意样本库。以上两点均使得DroidMOSS的检测准确度较低。

发明内容

针对以上缺陷，本发明提供一种打包恶意应用的静态检测方法和装置，可以提高检测准确度。

第一方面，本发明提供的重打包恶意应用的静态检测方法包括：

获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；

根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；

根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；

在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；

根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

可选的，所述获取待检测应用程序的安装包的API调用序列，包括：对所述安装包进行预处理，得到classes.dex文件；对所述classes.dex文件进行反编译，得到smali文件；从所述smali文件中提取出API调用序列。

可选的，所述对所述安装包进行预处理，得到classes.dex文件，包括：对所述安装包进行解压缩，在解压缩得到的文件中提取出classes.dex文件。

可选的，所述从所述smali文件中提取出API调用序列，包括：在所述smali文件中，从所述待检测应用程序的每个入口点的对应位置处开始进行搜索并回溯，以提取出所述API调用序列。

可选的，所述将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配，包括：将所提取出的每个类的敏感API调用序列与所述样本库中同类别恶意应用程序家族的家族特征进行相似度匹配；其中，所述恶意应用程序家族中包括多个相同类别的恶意应用程序；所述家族特征为所述恶意应用程序家族的特征序列，且包括所述恶意代码家族中各个恶意应用程序的敏感API调用序列样本。

可选的，所述方法还包括：若根据相似度匹配结果确定所述待检测应用程序为重打包的恶意应用程序，则将该待检测应用程序的敏感API调用序列添加至同类别恶意应用程序家族的家族特征中。

第二方面，本发明提供的重打包恶意应用的静态检测装置包括：

获取模块，用于获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；

构建模块，用于根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；

聚类模块，用于根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；

匹配模块，用于在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；

确定模块，用于根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

可选的，所述获取模块包括：

预处理单元，用于对所述安装包进行预处理，得到classes.dex文件；反编译单元，用于对所述classes.dex文件进行反编译，得到smali文件；提取单元，用于从所述smali文件中提取出API调用序列。

可选的，所述匹配模块具体用于：将所提取出的每个类的敏感API调用序列与所述样本库中同类别恶意应用程序家族的家族特征进行相似度匹配；其中，所述恶意应用程序家族中包括多个相同类别的恶意应用程序；所述家族特征为所述恶意应用程序家族的特征序列，且包括所述恶意代码家族中各个恶意应用程序的敏感API调用序列样本。

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

更新模块，用于在根据相似度匹配结果确定所述待检测应用程序为重打包的恶意应用程序时，将该待检测应用程序的敏感API调用序列添加至同类别恶意应用程序家族的家族特征中。

本发明提供的重打包恶意应用的静态检测方法和装置，各个步骤中并没有假设Android官方应用市场上的应用程序是原生态的、非恶意的且未经过重新打包的，即不依赖于Android官方应用程序，可以进一步提高检测准确度，还能实现对Android官方应用程序的检测。而且，在S3中，根据各个类调用关系的强弱程度，对各个类进行聚类划分，以提取出恶意代码部分，由于这一过程是以类为单位进行的，即使恶意程序的开发者对注入部分做了修改，也能根据相似性判断，得到比较准确的检测结果，所以针对变种的恶意代码，也能保证有较高的准确度。而且，在检测过程中，通过聚类划分的方式提出恶意代码部分，对应用程序正常代码部分的修改、删除等操作不影响检测结果，进一步提高检测准确度。

附图说明

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些图获得其他的附图。

图1示出了本发明一实施例中重打包恶意应用的静态检测方法的流程示意图；

图2示出了本发明一实施例中S1中获取的API调用序列的示意图；

图3示出了本发明一实施例中应用程序的结构示意图；

图4示出了本发明一实施例中S2中构建的函数调用关系图的示意图；

图5示出了本发明一实施例中S4中聚类分析后得到的各个簇的示意图；

图6示出了本发明一实施例中电子设备的结构框图。

具体实施方式

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

第一方面，本发明提供一种重打包恶意应用的静态检测方法，该方法可实现对重打包的恶意应用程序进行检测，适用于Android官方应用市场、第三方应用市场或其他来源的Android应用程序。如图1所示，该方法包括：

S1、获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；

可理解的是，API，即Application Programming Interface，是指操作***留给应用程序的调用接口，应用程序通过调用操作***的API而使操作***去执行应用程序的命令或动作。在该步骤中获取的API调用序列可参考图2。

可理解的是，所谓的类与类之间的关联关系可以包括：继承关系、引用、函数调用关系等。

S2、根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；

可理解的是，应用程序在开发过程中主要以类和包的形式进行组织，如图3所示，在APK(即Android Package)这个包下，有n个类即class，而每个类下有多个调用函数，每个调用函数下有多个API调用序列。可见，开发者在开发过程中是将具有一定关联的代码放在一个类中，进而组织到一个包下，因此类和包具有特定的语义信息。据此，将各个API调用序列进行分类，即基于类进行聚合，从而构建函数调用关系图，构建的函数调用关系图可参考图4。

S3、根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；

可理解的是，根据类与类调用关系的强弱程序，进行聚类划分，也就是说，调用关系较强的类划分在一起，调用关系较弱的类划分在一起，具体的强弱程度，可以根据实际需要进行设置，将调用关系强于某特定程度，则认为是调用关系较强，否则认为调用关系较弱。根据对Android平台恶意应用程序隐藏技术的研究，恶意应用程序的开发者将恶意应用程序使用重打包技术嵌入正常应用程序后，重打包的恶意应用程序将包含恶意应用程序是所有组件和指令。在重打包过程中，为了保证应用程序功能的正常执行，大部分重打包的恶意应用程序采用注入独立的组件来执行恶意行为，例如，注入一个独立的广播***，以用于监听手机的开机启动时间。在手机重启后，该广播器便被触发执行恶意行为。由于执行恶意行为的组件的独立性，使得恶意代码部分与正常应用的代码部分之间在函数调用关系上联系较弱。因此，这里通过各个类调用关系的强弱程度进行聚类划分可以从应用程序的APK文件中提取出恶意代码部分。在该步骤中，聚类分析后得到的各个簇可参考图5。

需要注意的是，本发明中提到的重打包的恶意应用程序和恶意应用程序的含义不同，恶意应用程序仅是指执行恶意行为的所有组件和指令，而重打包的恶意应用程序中包含恶意应用程序和正常代码部分，是将恶意应用程序注入正常应用程序后重打包形成的。

S4、在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；

可理解的是，恶意代码簇是由不同的类聚合在一起构成的，恶意代码簇的特征标记由每个类的敏感API序列特征标记共同构成。

可理解的是，所谓的敏感API调用序列，是指敏感API的调用序列，如表1所示，敏感API有短信类的、设备信息类的、地理信息类的、广播类的、数据库类的、网络类的、录音类的、其他类的。重打包的恶意应用程序为了实现其恶意行为，必然会存在对敏感API的调用，因此将敏感API调用序列作为该待检测应用程序的特征序列。这里，将敏感API调用序列提取出来，与样本库中恶意应用程序的特征序列样本进行相似度匹配，便于后续待检测应用程序是否为重打包的恶意应用程序的确定。

表1敏感AP1的所属类说明

S5、根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

可理解的是，若相似度匹配程度较高，则可以认定为待检测应用程序为重打包的恶意应用程序。若有多个类的敏感API调用序列，而其中一个类的敏感API调用序列与样本库的相似度匹配程度较高，则也认为该待检测应用程序为重打包的恶意应用程序。

本发明提供的检测方法，各个步骤中并没有假设Android官方应用市场上的应用程序是原生态的、非恶意的且未经过重新打包的，即不依赖于Android官方应用程序，可以进一步提高检测准确度，还能实现对Android官方应用程序的检测。而且，在S3中，根据各个类调用关系的强弱程度，对各个类进行聚类划分，以提取出恶意代码部分，由于这一过程是以类为单位进行的，即使恶意程序的开发者对注入部分做了修改，也能根据相似性判断，得到比较准确的检测结果，所以针对变种的恶意代码，也能保证有较高的准确度。而且，在检测过程中，通过聚类划分的方式提出恶意代码部分，对应用程序正常代码部分的修改、删除等操作不影响检测结果，进一步提高检测准确度。

在具体实施时，S1的具体过程可以包括：

S11、对所述安装包进行预处理，得到classes.dex文件；

可理解的是，安装包的基本结构包括：

META-INF\Jar，这个文件中常可以看到；

res\，是用于存放资源文件的目录；

AndroidManifest.xml，是程序全局配置文件；

classes.dex，是Dalvik字节码；

resources.arsc，是编译后的二进制资源文件。

从以上结构中可以看出，安装包中包括classes.dex文件，。由于应用程序安装包的本质是zip格式的压缩文件，因此可以利用对所述安装包进行解压缩的方式，从解压缩得到的文件中提取出classes.dex文件。

S12、对所述classes.dex文件进行反编译，得到smali文件；

可理解的是，上述反编译实际上是一种逆向分析技术，通过对classes.dex文件的反编译得到的smali文件，是细粒度的smali代码，便于后续获取更加精确的函数序列或函数调用关系。

S13、从所述smali文件中提取出API调用序列。

在具体实施时，可以采用以下方式从smali文件中提取出API调用序列：在所述smali文件中，从所述待检测应用程序的每个入口点的对应位置处开始进行搜索并回溯，以提取出所述API调用序列。还可以将调用函数的返回值和参数作为附加信息进行提取，进而构建信息更为丰富的函数调用关系图。

以上，提供了一种获取安装包的API调用序列的方式，当然还可以采用其他的方式获取API调用序列，对此本发明不做限定。

在具体实施时，S4中所述将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配，可以包括：

将所提取出的每个类的敏感API调用序列与所述样本库中同类别恶意应用程序家族的家族特征进行相似度匹配；

所述恶意应用程序家族中包括多个相同类别的恶意应用程序；所述家族特征为所述恶意应用程序家族的特征序列，且包括所述恶意代码家族中各个恶意应用程序的敏感API调用序列样本。

这里，预先根据多个已知的恶意应用程序执行恶意行为的类别，对各个恶意应用程序进行家族分类，在本次提取出敏感API调用序列后，将敏感API调用序列与相同类别的恶意应用程序家族的家族特征进行相似性匹配，实现家族性检测，不需要与所有的恶意应用程序的特征序列进行对比，提高了检测效率。

在具体实施时，若根据相似度匹配结果确定所述待检测应用程序为重打包的恶意应用程序，还可以将该待检测应用程序的敏感API调用序列添加至同类别恶意应用程序家族的家族特征中，以对样本库进行更新，以样本库能够满足检测需求。

实际上，经对1009个公开的Android恶意重打包应用程序进行测试，其检测正确率高达93％，可见，本发明提供的检测方法在准确性和可用性上都有良好的表现，可应用于实际中的检测工作。

第二方面，本发明还提供一种重打包恶意应用的静态检测装置，该装置包括：

获取模块，用于获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；

构建模块，用于根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；

聚类模块，用于根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；

匹配模块，用于在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；

确定模块，用于根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

可选的，所述获取模块包括：

预处理单元，用于对所述安装包进行预处理，得到classes.dex文件；

反编译单元，用于对所述classes.dex文件进行反编译，得到smali文件；

提取单元，用于从所述smali文件中提取出API调用序列。

可选的，所述匹配模块具体用于：将所提取出的每个类的敏感API调用序列与所述样本库中同类别恶意应用程序家族的家族特征进行相似度匹配；其中，所述恶意应用程序家族中包括多个相同类别的恶意应用程序；所述家族特征为所述恶意应用程序家族的特征序列，且包括所述恶意代码家族中各个恶意应用程序的敏感API调用序列样本。

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

更新模块，用于在根据相似度匹配结果确定所述待检测应用程序为重打包的恶意应用程序时，将该待检测应用程序的敏感API调用序列添加至同类别恶意应用程序家族的家族特征中。

可理解的是，本发明提供的静态检测装置为上述静态检测方法的功能架构模块，有关内容的解释、可选实施方式和有益效果等内容可以看出上述静态检测方法中的相应内容，在此不再赘述。

本发明还提供一种电子设备，参照图6，电子设备包括：处理器(processor)601、存储器(memory)602、通信接口(Communications Interface)603和总线604；其中，

所述处理器601、存储器602、通信接口603通过所述总线604完成相互间的通信；

所述通信接口603用于该电子设备与对应的通信设备之间的信息传输；

所述处理器601用于调用所述存储器602中的程序指令，以执行上述各方法实施例所提供的方法，例如包括：获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

本发明还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

本发明提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法，例如包括：获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所描述的显示装置的测试设备等实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上各实施例仅用以说明本发明的实施例的技术方案，而非对其限制；尽管参照前述各实施例对本发明的实施例进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明的实施例各实施例技术方案的范围。

Claims (10)

1.一种重打包恶意应用的静态检测方法，其特征在于，包括：

获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；

根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；

根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；

在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；

根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

2.根据权利要求1所述的方法，其特征在于，所述获取待检测应用程序的安装包的API调用序列，包括：

对所述安装包进行预处理，得到classes.dex文件；

对所述classes.dex文件进行反编译，得到smali文件；

从所述smali文件中提取出API调用序列。

3.根据权利要求2所述的方法，其特征在于，所述对所述安装包进行预处理，得到classes.dex文件，包括：

对所述安装包进行解压缩，在解压缩得到的文件中提取出classes.dex文件。

4.根据权利要求2所述的方法，其特征在于，所述从所述smali文件中提取出API调用序列，包括：

在所述smali文件中，从所述待检测应用程序的每个入口点的对应位置处开始进行搜索并回溯，以提取出所述API调用序列。

5.根据权利要求1所述的方法，其特征在于，所述将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配，包括：

将所提取出的每个类的敏感API调用序列与所述样本库中同类别恶意应用程序家族的家族特征进行相似度匹配；

所述恶意应用程序家族中包括多个相同类别的恶意应用程序；所述家族特征为所述恶意应用程序家族的特征序列，且包括所述恶意代码家族中各个恶意应用程序的敏感API调用序列样本。

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

若根据相似度匹配结果确定所述待检测应用程序为重打包的恶意应用程序，则将该待检测应用程序的敏感API调用序列添加至同类别恶意应用程序家族的家族特征中。

7.一种重打包恶意应用的静态检测装置，其特征在于，包括：

获取模块，用于获取待检测应用程序的安装包的API调用序列以及各个API调用序列所属的类之间的关联关系；

构建模块，用于根据类与类之间关联关系的强弱，构建基于类的函数调用关系图；所述函数调用关系图中的节点为类；

聚类模块，用于根据类与类之间关联关系的强弱程度，对各个类进行聚类划分，得到多个簇，并将各个簇中类与类之间关联关系最强的预设数量的簇去掉，得到恶意代码簇；

匹配模块，用于在所述恶意代码簇中的各个类的API调用序列中提取出敏感API调用序列，并将提取出的每个类的敏感API调用序列分别与预先建立的样本库中恶意应用程序的特征序列样本进行相似度匹配；

确定模块，用于根据相似度匹配结果，确定所述待检测应用程序是否为重打包的恶意应用程序。

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

预处理单元，用于对所述安装包进行预处理，得到classes.dex文件；

反编译单元，用于对所述classes.dex文件进行反编译，得到smali文件；

提取单元，用于从所述smali文件中提取出API调用序列。

9.根据权利要求7所述的装置，其特征在于，所述匹配模块具体用于：将所提取出的每个类的敏感API调用序列与所述样本库中同类别恶意应用程序家族的家族特征进行相似度匹配；其中，所述恶意应用程序家族中包括多个相同类别的恶意应用程序；所述家族特征为所述恶意应用程序家族的特征序列，且包括所述恶意代码家族中各个恶意应用程序的敏感API调用序列样本。

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

更新模块，用于在根据相似度匹配结果确定所述待检测应用程序为重打包的恶意应用程序时，将该待检测应用程序的敏感API调用序列添加至同类别恶意应用程序家族的家族特征中。