CN114091028B - 一种基于数据流的Android应用信息泄露检测方法 - Google Patents

Abstract

本发明涉及一种基于数据流的Android应用信息泄露检测方法，基于按需分析算法，在不改动现有Apk代码生命周期构建，不对检测流程有大改动下，通过识别第三方库和无效方法规则，去除CG图中无用的边，更新CG图，并结合CFG图，构建应用完整控制流程图，最后通过FlowDroid对此流程图的数据流分析过程中，寻找潜在的数据泄露，整个方案设计可以减少很多不必要的运算，并且经过试验分析得出，本发明设计可以有效减少分析APK时的时间占用和空间占用，在高精度的同时，保证高性能。

Description

一种基于数据流的Android应用信息泄露检测方法

技术领域

本发明涉及一种基于数据流的Android应用信息泄露检测方法，属于信息泄露检测技术领域。

背景技术

随着技术的发展，人们可以通过移动设备获取互联网上丰富的资源和完善的服务，越来越多的用户通过手机接入网络。根据中国互联网络信息中心发布的第46次《中国互联网发展状况统计报告》分析，截止2020年6月，互联网宽带接入端口数量达9.31亿个，网民规模达9.4亿个，其中，手机网民规模已达到9.32亿，占全体网民的99.2%。

数量巨大的移动智能设备数量极大地改变了人们的生活，而在当前智能手机的市场中，Android占据最大的比例。Android操作系统开源，本身具有开放和免费的优点，众多软件工程师都参与了应用的开发，基于Android操作系统的应用数量爆炸增长。根据IDC2020年发布的报告看，Android市场占有率为86.6%，拥有最大的用户群体。

Android应用的基数大导致恶意应用影响的人足够多，Android系统的开放性允许用户下载和安装来自第三方的恶意应用，而Android应用程序开发的低成本导致恶意应用开发难度降低。恶意应用可以盗窃用户的隐私信息，如短信信息、联系人与应用数据。这些隐私信息对于用户来说很宝贵，泄露的话会对用户造成安全威胁。恶意应用开发成本过低，很多恶意应用是用良性应用改造的，伪装很好，导致Android应用市场中恶意应用层出不穷且难以辨别。诸如隐私窃取、病毒感染等恶意行为给用户设备中的隐私信息、敏感数据和系统安全带来越来越多的威胁。识别Android应用信息泄露成为一个亟需解决的问题。

动态检测是指为Android应用程序提供运行环境，如模拟器或真机，使用一定的驱动策略使应用运行，记录应用行为，同时对产生的数据进行存储，根据以上特征判断应用是否为恶意。动态检测为了监听应用组件间信息与网络传输数据，需要修改系统内核或定制ROM。

静态检测是指不需要运行应用，而是通过分析静态文件来检测漏洞，输入为APK文件，通过反编译工具Dex2Jar和Jd-gui来将源代码转化为可阅读的Smali代码或者Java文件，配合APK文件内其他的配置文件对程序进行分析。静态检测的优点是不需要运行应用，没有环境限制，且不需要修改Android内核，在速度上比动态检测快，缺点是无法真实模拟应用运行的情况，分析结果有误差。

Steven Arzt等人根据数据流分析开发了工具FlowDroid，FlowDroid基于数据流分析，根据Android的生命周期构建主方法，可以正确的处理Android框架的回调方法。它基于上下文、流、类变量和对象敏感，减少了静态检测的误报数量。

2016年，Steven Arzt等人在FlowDroid的基础上改进了内存消耗的问题，提出了StubDroid。StubDroid对经常使用的类库生成摘要文件，对于已经分析过的类库不进行重复分析。在进行数据流运算时，可以避免无用的计算，极大地避免了内存浪费，加快了分析时间。StubDroid改进方向是系统类库，即静态检测必须依靠的Java核心库rt.jar和Android的系统库framework.jar。

2018年，FengGuo Wei等人提出了一种新的静态检测工具Amandroid。它同样是针对上下文敏感的数据流分析，Amandroid优化了三点。一是它计算了程序中所有对象及其字段指向的信息和调用上下文，为综合分析大型程序打下基础。二是它同时完成了上下文敏感和流敏感的静态检测，而Wala、FlowDroid都只能完成其中一个。三是它为每个组件创建了数据流图、数据依赖图和包含了组件间通信的摘要表，通过这些数据结构Amandroid完成了组件间的数据流分析。

但是在实际应用中，现有技术对Android应用的分析效率依旧很低，诸如应用中大多会存在无效的方法，这些方法不参与到数据的分析处理，因此此类方法在数据流分析过程中占据大量资源、以及消耗更多的时长。

发明内容

本发明所要解决的技术问题是提供一种基于数据流的Android应用信息泄露检测方法，通过串联Android组件的生命周期来创建主方法，实现按需分析，能够在高精度的同时，保证高性能，提高信息泄露检测的效率。

本发明为了解决上述技术问题采用以下技术方案：本发明设计了一种基于数据流的Android应用信息泄露检测方法，用于针对待测Android应用，实现应用信息泄露检测，包括如下步骤：

步骤A. 获得待测Android应用APK文件中的配置文件，并获得配置文件中对应预设各组件类型的各个组件信息，然后进入步骤B；

步骤B. 获得待测Android应用APK文件中的DEX文件，结合预设必要类类型，获得DEX文件中的各个类，构成类集合SootClass，然后进入步骤C；

步骤C. 针对类集合SootClass中的各个类，区分属于源程序的各个类、以及属于第三方类的各个类，并确定属于第三方的各个类分别属于有效类标签或无效类标签，然后进入步骤D；

步骤D. 获得待测Android应用APK文件中的XML文件，并对XML文件进行解析，获得应用的UI文件与应用分析的规则文件，且通过应用分析的规则文件，获得应用的数据分析入口与数据分析出口，然后进入步骤E；

步骤E. 基于所获各个组件信息、类集合SootClass中各个类、应用的UI文件、以及应用的数据分析入口与数据分析出口，以各组件信息、以及属于有效类标签各个类分别所对应方法为节点，构建各节点分别对应所涉及各基本块的CFG图，并构建该各节点分别所对应方法间调用关系的CG图，结合属于无效类标签的各个类分别作为各个节点，构成应用完整控制流程图，然后进入步骤F；

步骤F. 以跳过无效类标签各类所对应节点数据流分析的方式，针对应用完整控制流程图执行数据流分析，实现应用信息泄露检测。

作为本发明的一种优选技术方案：所述步骤A中预设各组件类型包括Activity类型组件、Service类型组件、Content Provider类型组件、Broadcast Receiver类型组件。

作为本发明的一种优选技术方案：所述步骤B中预设必要类类型包括Java的原生类库rt.jar与Android的框架库framework.jar。

作为本发明的一种优选技术方案：所述步骤C包括如下步骤C1至步骤C3；

步骤C1. 分别判断类集合SootClass中的各个类，判断类的程序是否经过混淆，待完成对类集合SootClass中所有类的判断后，进入步骤C2；

步骤C2. 分别针对程序经过混淆的各个类，通过聚合静态特征识别方法，判断类是否属于第三方类，是则即该类属于第三方类；否则判定该类属于源程序；

同时，分别针对程序未经过混淆的各个类，应用类的类名与预设第三方类名库进行匹配，若匹配成功，则判定该类属于第三方类；否则判定该类属于源程序；然后进入步骤C3；

步骤C3. 分别针对属于第三方的各个类，判断类属于有效类标签或无效类标签，然后进入步骤D。

作为本发明的一种优选技术方案：所述步骤C1中，分别针对类集合SootClass中的各个类，执行如下步骤C1-1至步骤C1-3，判断类的程序是否经过混淆，待完成对类集合SootClass中所有类的判断后，进入步骤C2；

步骤C1-1. 获得类的类名，并判断该类名的命名规则是否为驼峰命名法、帕斯卡命名法或匈牙利命名法的一种，是则进入步骤C1-2；否则进入步骤C1-3；

步骤C1-2. 针对该类名进行字符串分割，并判断分割所获字符串是否为单词，是则进入步骤C1-3；否则判定该类的程序经过混淆；

步骤C1-3. 针对类存储位置下各层级包名组成的全限定名进行分割，获得各个分割结果组成的数组，并判断数组中是否存在单个字符的分割结果或者全数字的分割结果，是则判定该类的程序经过混淆；否则判定该类的程序未经过混淆。

作为本发明的一种优选技术方案：所述步骤C2中按如下方法，分别针对程序经过混淆的各个类，通过聚合静态特征识别方法，判断类是否属于第三方类；

分别针对程序经过混淆的各个类，首先分别提取类中各层级分别对应预设各类型特征的特征值，并由该各个特征值构成该类所对应的特征向量，然后应用以类中各层级分别对应预设各类型特征的特征值组成的特征向量为输入，以类对应第三方库标签或非第三方库标签为输出的第三方类识别模型，判断该类是否属于第三方类。

作为本发明的一种优选技术方案：所述步骤C3中，分别针对属于第三方的各个类，执行如下步骤C3-1至步骤C3-2，判断类属于有效类标签或无效类标签，然后进入步骤D；

步骤C3-1. 若类中存在对应数据出口sink方法的API，则进入步骤C3-2；若类中存在对应数据入口source方法的API，则判定该类属于有效类标签；

步骤C3-2. 针对该类中的所有接口方法进行数据流分析，判断由该类的入口处数据是否无法传递到数据出口sink方法，是则判定该类属于无效类标签；否则判定该类属于有效类标签。

作为本发明的一种优选技术方案：所述步骤F中，以无效类标签各类分别所对应节点作为普通指令，结合普通指令通过IFDS参与数据流分析的方式，针对应用完整控制流程图执行数据流分析，实现应用信息泄露检测。

作为本发明的一种优选技术方案：所述步骤F中，以无效类标签各类分别所对应节点作为普通指令，结合普通指令通过IFDS参与数据流分析的方式，应用FlowDroid，针对应用完整控制流程图执行数据流分析，实现应用信息泄露检测。

本发明所述一种基于数据流的Android应用信息泄露检测方法，采用以上技术方案与现有技术相比，具有以下技术效果：

（1）本发明所设计基于数据流的Android应用信息泄露检测方法，基于按需分析算法，在不改动现有Apk代码生命周期构建，不对检测流程有大改动下，通过识别第三方库和无效方法规则，去除CG图中无用的边，更新CG图，并结合CFG图，构建应用完整控制流程图，最后通过FlowDroid对此流程图的数据流分析过程中，寻找潜在的数据泄露，整个方案设计可以减少很多不必要的运算，并且经过试验分析得出，本发明设计可以有效减少分析APK时的时间占用和空间占用，在高精度的同时，保证高性能。

附图说明

图1是本发明所设计基于数据流的Android应用信息泄露检测方法的流程示意图；

图2是jar包class文件的层级示意图；

图3是方法返回值为void的代码示例图；

图4是方法返回值为非void的代码示例图；

图5是本发明所设计基于数据流的Android应用信息泄露检测方法的系统架构示意图。

具体实施方式

下面结合说明书附图对本发明的具体实施方式作进一步详细的说明。

从代码和实际分析用例两个方面，发现FlowDroid在构建CG与进行数据流计算时，存在着高额的内存占用与耗时过大的问题，因此，本发明所设计一种基于数据流的Android应用信息泄露检测方法，用于针对待测Android应用，实现应用信息泄露检测，如图1所示，实际执行如下步骤A至步骤F。

步骤A. 获得待测Android应用APK文件中的配置文件，并获得配置文件中对应诸如Activity类型组件、Service类型组件、Content Provider类型组件、BroadcastReceiver类型组件的预设各组件类型的各个组件信息，然后进入步骤B。

步骤B. 获得待测Android应用APK文件中的DEX文件，结合诸如包括Java的原生类库rt.jar与Android的框架库framework.jar的预设必要类类型，获得DEX文件中的各个类，构成类集合SootClass，然后进入步骤C；rt.jar与framework.jar用于模拟Android运行环境。

步骤C. 针对类集合SootClass中的各个类，区分属于源程序的各个类、以及属于第三方类的各个类，并确定属于第三方的各个类分别属于有效类标签或无效类标签，然后进入步骤D。

在Java中，所有的类都有它的全限定名，如图2所示，ApacheData类的全限定名为org.apache.jcp.xml.dsig.internal.dom.ApacheData。在JVM的类加载器加载类时，对于全限定名相同的类只能加载一个。全限定名可以显示该类的包名层级，因此可以通过全限定名获取该类所属的类库。AndroidManifest.xml文件中声明了应用的主包名，因此应用主体代码的包名可直接得到。

实际应用当中，上述步骤C具体执行如下步骤C1至步骤C3。

步骤C1. 分别判断类集合SootClass中的各个类，判断类的程序是否经过混淆，待完成对类集合SootClass中所有类的判断后，进入步骤C2。

目前，许多开发者会使用混淆工具来对应用进行混淆。在分清混淆应用前，先介绍混淆常使用的技术。混淆可以通过缩短应用程序的类、方法和字段的名称来减小应用程序的大小与增大应用程序被逆向分析的难度。混淆的技术主要有字符串混淆、代码删除、代码隐藏与反射。上述的几种混淆策略都可以通过人工来检验，如以通过变量名是否是无意义的字符串来判断。但是Android市场上每天增加的应用量数以万计，需要以代码的方式检测。在手动分析一些混淆过后的应用后，概括出几种规律如下。

开发者开发的正常应用，类名与方法名通常由一个或多个有意义的单词通过命名法连接起来，如图2中的DOMCryptoBinary类，它由DOM、Crypto及Binary三个单词通过驼峰命名法连接；混淆的应用混淆的所有字符都是无意义的，比如单字符"a" 、b、c或单数字"1,2" ，或者是数字与字母的结合"1a23" 等。

因此，上述步骤C1中，分别判断类集合SootClass中的各个类，执行如下步骤C1-1至步骤C1-3，判断类的程序是否经过混淆。

步骤C1-1. 获得类的类名，并判断该类名的命名规则是否为驼峰命名法、帕斯卡命名法或匈牙利命名法的一种，是则进入步骤C1-2；否则进入步骤C1-3。

步骤C1-2. 针对该类名进行字符串分割，并判断分割所获字符串是否为单词，是则进入步骤C1-3；否则判定该类的程序经过混淆。

步骤C1-3. 针对类存储位置下各层级包名组成的全限定名进行分割，获得各个分割结果组成的数组，并判断数组中是否存在单个字符的分割结果或者全数字的分割结果，是则判定该类的程序经过混淆；否则判定该类的程序未经过混淆。

诸如"com/a/123" 分割为["com,a,123" ]，若数组中有元素为单个字符"a" 、b、c或者纯粹数字的，认为其为混淆。

步骤C2. 分别针对程序经过混淆的各个类，按如下方法，通过聚合静态特征识别方法，判断类是否属于第三方类，是则即该类属于第三方类；否则判定该类属于源程序。

分别针对程序经过混淆的各个类，首先分别提取类中各层级分别对应预设各类型特征的特征值，并由该各个特征值构成该类所对应的特征向量，然后应用以类中各层级分别对应预设各类型特征的特征值组成的特征向量为输入，以类对应第三方库标签或非第三方库标签为输出的第三方类识别模型，判断该类是否属于第三方类。

其中，采用Libradar方案对各类中各层级分别对应预设各类型特征的特征值进行提取，Libradar的阈值选择可以很好的保证识别出属于知名第三方类的类，虽然在这种情况下有些变种第三方类不会被识别出来，但是为了精确分析放弃掉这些潜在的第三方类。

与此同时，分别针对程序未经过混淆的各个类，应用类的类名与预设第三方类名库进行匹配，若匹配成功，则判定该类属于第三方类；否则判定该类属于源程序；然后进入步骤C3。

即在获取类的全限定名后，与预设第三方类名库的进行比对时，前缀名相同则证明该类属于匹配成功的库，匹配规则为最长前缀匹配，即选择匹配度最长的一条作为匹配项，预设第三方类名库中若同时存在org.apache与org.apache.jcp两个前缀时，认定ApacheData类属于org.apache.jcp类库。数据库的数据来源于Maven Repository，它是Maven的中央仓库，包含了绝大多数流行的开源Java构件。

区分类属于源程序或属于第三方类后，需要通过分析代码的应用层级来区分各属于第三方类的类的来源。首先，使用反编译工具Apktool[30]解析该类，可以得到Smali代码的集合；如果对于Smali语言不熟悉，可以使用dex2jar工具将解压得到的DEX文件转化为class文件，再使用jd-gui[31]工具查看程序，代码层级如图2所示。

在对属于第三方类的类进行筛选后，需要对属于第三方类的类进行无效类判断。一般情况下，静态分析中不会对应用程序进行舍弃，因为应用程序中的类的调用链并不清晰、且应用程序中的类是主要分析类。应用程序中的类多是互相调用的，如果删去了某个包下的所有类，可能导致数据流分析失败。而第三方库不同。第一，第三方库有着非常清晰的调用链，是被应用程序所调用的，多数并不调用应用程序的类；第二，它们往往只提供功能性需求，比如Apache Commons Lang的库，其中的StringUtils类可以对字符串进行一些判空或去除空白字符的处理；第三，第三方库可以在数据流分析前确定其来源，可以通过识别的方法获得包名，从而知道它的作用。因此，很适合从第三方库中选择无效类，从而找到它们中的无效方法。

关于属于第三方类的类是否为无效，可以将方法是否有返回值分为两类讨论，当调用的方法没有返回值时，代表该方法即使产生新的污染变量，也无法将该污染变量传递给上层调用者。因此，返回值为void类型的方法不会产生污点，只需要关心传入的形参是否有可能到达终点，即该方法体内有sink或者该方法调用、间接调用了有sink的方法。如图3，将污染变量传递给taint1和tanit2方法，taint1方法中有sink，taint2方法中没有sink。在这个例子中，taint1是有效方法，taint2是无效方法，可以省去对taint2方法的分析。当方法有返回值时，不仅需要考虑方法参数是否有可能传递到sink，也需要考虑方法的返回值是否是污染变量。如果方法返回值不是污染变量，即确定源头无污染，自然不需要判断会有信息泄露。如图4所示，taint1方法中有source，taint2方法中无source，taint1方法返回了污染值，在分析过程中不能省略该方法，则会产生误报，但是对于taint2方法并没有任何污染信息返回，是可以跨过分析的。

这两种例子是简化的，实际应用中的第三方类之间调用关系复杂，存在多个方法包含了上千指令，一个包中也可能有上千方法。采用人工分析对众多第三方库中的方法进行筛选并不现实，综合上述分析，提出一种规则来筛选第三方类中的无用无效类，即按如下步骤C3执行。

步骤C3. 分别针对属于第三方的各个类，执行如下步骤C3-1至步骤C3-2，判断类属于有效类标签或无效类标签，然后进入步骤D。

步骤C3-1. 若类中存在对应数据出口sink方法的API，则进入步骤C3-2；若类中存在对应数据入口source方法的API，则判定该类属于有效类标签，认为可能有污染。

步骤C3-2. 针对该类中的所有接口方法进行数据流分析，判断由该类的入口处数据是否无法传递到数据出口sink方法，是则判定该类属于无效类标签；否则判定该类属于有效类标签，认为可能有污染。

在静态检测中，一个第三方类是作为一个整体参与分析的。因此在认定无效类时，如果整个类有可能有风险，即在类中存在有效方法，在整体分析中就保留这个类。而存在上述两种问题时，则认为第三方类有风险，使该类正常参与数据流分析。这样做的原因是，对于静态检测来说，识别出泄露数量是第一位的，不能删去有可能存在的泄露路径。

步骤D. 获得待测Android应用APK文件中的XML文件，并对XML文件进行解析，获得应用的UI文件与应用分析的规则文件，且通过应用分析的规则文件，获得应用的数据分析入口与数据分析出口，然后进入步骤E。

FlowDroid可以很好的完成分析过程。但是它在内存优化与运算分析方面优化稍差，因此在分析大应用时会因内存耗尽出现Java程序堆溢出的问题。内存耗尽的原因是它在构建CG图时会消耗大量的内存资源，如下所示：

FlowDroid分析一个大小仅为100kb的DEX文件，需要计算3秒钟，在生成的CG图中有1980条边。而分析时应用的大小为数十兆时，不仅代码大小提升了百倍，方法之间关联数量迅速增长，CG图包含的边数过多，会造成内存爆炸的问题。这样的情况下，普通的PC机器因负载过高无法继续进行静态分析。

FlowDroid的CG构成方法。在程序分析中，单个方法的CFG反映了该方法执行流程中会遍历的所有基本块。如果该方法中调用了其他方法，则需要CG来表示方法之间的调用关系。一个完整程序的控制流图由CG和CFG组成，简称过程间控制流图（interproceduralcontrol flow graph, ICFG）。在FlowDroid的代码实现中，CG就是ICFG的一种实现，它包括了所有调用方法的程序基本块。因此，构建CG需要获取所有需要分析的方法，待分析的方法被称为可到达方法，FlowDroid会将这些方法的代码转化为Soot自定义的数据结构，并加入内存中。processReachables的代码示例如下：

该方法可以获取应用程序所有可能执行的方法。其中，worklist是一个存储Soot自定义变量MethodOrMethodContext的迭代器，MethodOrMethodContext是包含方法和方法所在上下文的结构，程序初始执行阶段worklist中只存储主方法及其所在上下文的一个变量。每次循环worklist均取出变量声明为momc，解析momc对应的方法m，将m的方法体转化为中间指令集。processNewMethod方法将遍历处理指令集，对于指令集中的每个指令，如果指令属于方法调用类，即invoke-static等，解析指令，获取指令的调用方法信息，将信息加入worklist。循环的终止条件为worklist为空集，代表所有可到达的方法都已获取。这样做可以保证程序所有的可达点，均能分析得到。在得到所有待分析的方法后，将这些方法包含的边加入CG。对于代码量较大的程序，就会导致CG中的边很多，存在内存占用过多的问题。

为了减少CG图的大小，其他依靠Soot分析Java程序的工具均对Java程序中的应用类与第三方类进行区分，对程序代码采取不同的解析标准。应用类与需要的第三方类均采取Application级的分析，而确定不需要的第三方类采取Library级的分析。在分析过程中不会转化为CFG，生成的CG会比不区分小一个数量级。虽然这样做会因为不分析第三方库带来一定的误差，但是因为大大减少了分析的代码数量，因此多数工具依然会使用这种区分方法。Soot中对程序分析可以开启全局模式，即所有的加载类均为Application级，在解析过程中会消耗最多的资源。FlowDroid默认开启全局模式，而且全局模式无法关闭，关闭全局模式会使某些方法无法获取代码信息，导致CG构建失败。因此，其他工具的方法无法在这里使用，FlowDroid的内存优化相对于其他依赖于Soot工具也是比较失败的。

虽然无法对类的层级进行区分，但是可以使某些方法无法加入CG，对对应无效标签的类删除后，可以大大缩减参与CG构建的方法。为了剔除这些无效方法，本专利在FlowDroid的CG构建算法的基础上提出一种新的算法，算法伪代码如下所示：

在原可达性算法的基础上，将CG的构建也一同合并进去。区别在于，在抽取SootMethod后，先需要进行一次判断，即判断类对应于有效标签或者无效标签，如果SootMethod代表的方法是不需要分析的方法，则跳出本次循环，不做进一步的处理，不进行下一步处理的方法体，可以省去两个步骤，一是CFG的构建，不需要解析该方法对应的基本块，将基本块对应的控制流加入CG，同时，也不会从这个方法中找它连接的其他方法。对于不需要分析的方法，可以同时减少分析该方法及该方法关联方法。

在数据流向statement代表的方法时，如果方法为无效方法，则不向下传递数据。虽然在CG算法中对于无效方法并没有进行CFG的相关运算，但是该statement还是保存下来，否则会导致程序无法分析下去。数据流在该方法下不进入分析，而是把该方法作为一个普通指令。普通指令如何参与数据流分析在IFDS算法里有很详细的解释，在这里不再赘述。新的数据流算法有效的避免了很多无用的计算，因此在FlowDroid同样很耗时的数据流计算中同样得到了优化。应用信息泄露需要依靠静态检测来完成，基于第三方类识别数据流分析的静态检测需要在不影响分析泄露数量的同时来完成对时间和内存的双重优化。

进而执行如下步骤E。

步骤E. 基于所获各个组件信息、类集合SootClass中各个类、应用的UI文件、以及应用的数据分析入口与数据分析出口，以各组件信息、以及属于有效类标签各个类分别所对应方法为节点，构建各节点分别对应所涉及各基本块的CFG图，并构建该各节点分别所对应方法间调用关系的CG图，结合属于无效类标签的各个类分别作为各个节点，构成应用完整控制流程图，然后进入步骤F。

即在实际代码执行应用中，按如下代码所示，删除CG图中无用的边。

最后执行步骤F，以无效类标签各类分别所对应节点作为普通指令，结合普通指令通过IFDS参与数据流分析的方式，应用FlowDroid，针对应用完整控制流程图执行数据流分析，实现应用信息泄露检测。

将本发明所设计基于数据流的Android应用信息泄露检测方法应用于试验当中，采取的评估指标为CG创建时间、CG边数、数据流内存占用与泄露数量。前两个分别代表了CG的时间占用和内存占用，在新的改进算法下，分析同一个应用应该同时降低在时间和内存上的耗费。数据流方面只考虑内存占用，因为数据流计算在FlowDroid中使用了多线程分析来加快分析速度。而泄露数量是最重要的，对于静态检测来说，不能在降低分析精度的情况下优化其他指标，准确的分析是首先需要做到的。

为了减小不同类别应用第三方库不同可能带来的误差，选取不同大小、不同类别的应用来进行实验。选取从Google应用市场下载游戏、社交、天气、小说和工具各100个应用，其大小与分类如图5所示。

在FlowDroid中，对于个别应用，数据流分析占用时长可能出现1小时之久。为了验证FlowDroid在时间上的优化，FlowDroid分析应用的时长设置为5分钟，超时分析则认为其未能完成检测。对500个APK进行分析，统计优化前后FlowDroid可以完成的APK数量，如下表1所示。

表1

类型	数量	平均时间
			优化前	227	4.53min
优化后	352	3.72min

可以看到本发明设计方法在短时间内完成分析的数量明显增多，平均分析时间也变短了。

上述技术方案所设计基于数据流的Android应用信息泄露检测方法，基于按需分析算法，在不改动现有Apk代码生命周期构建，不对检测流程有大改动下，通过识别第三方库和无效方法规则，去除CG图中无用的边，更新CG图，并结合CFG图，构建应用完整控制流程图，最后通过FlowDroid对此流程图的数据流分析过程中，寻找潜在的数据泄露，整个方案设计可以减少很多不必要的运算，并且经过试验分析得出，本发明设计可以有效减少分析APK时的时间占用和空间占用，在高精度的同时，保证高性能。

本发明所设计基于数据流的Android应用信息泄露检测方法，在实际应用当中，Android应用信息泄露检测平台采用微服务架构，按照需求分为三部分，如图5所示，分别是提供上传应用与展示应用情况功能的Android客户端、执行核心任务的业务模块、提供拆解任务与数据存储等基础功能的基础支持。

Android客户端为前端项目，后端项目为服务端，对应微服务群与协调服务群的基础支持。移动端与服务端采用C/S架构，客户端与服务端交互的方式为http，客户端用来提交任务与展示文件分析结果，同时对于已经得到的一些结果进行本地缓存，减少数据传输与服务端重复运算；服务端在接受任务后，将检测任务分为粒度更小的任务并提交至消息队列，最终将任务结果保存至数据库。

业务模块用来执行服务端提交的子任务，具体模块有静态检测模块、脱壳处理模块、动态检测模块、资源文件分析模块。每个业务模块的支持服务在本系统中都是最小粒度的，没有冗余代码。业务模块需要在系统中注册本模块的类型与分配的IP地址与物理端口，因此，业务模块的数量与类型都可以动态添加，拥有良好的水平扩展能力。业务模块与基础支持之间的交互使用的是消息队列，传输的信息为Json格式的字符串，业务模块解析Json字段配置相关任务，任务中的业务类型也可以自由修改，不需要担心一个字段的修改影响到其他模块，增加了容错性。每个业务模块是一个单独的微服务个体，可以运行在不同的主机上。

基础支持为传统的Web项目抽离了业务模块，主要是响应客户端请求和为业务模块提供支持。主要模块有任务分发模块、消息队列模块、服务注册模块与存储模块。

上述平台的设计，首先是对需求进行分析，将用户需求转化为客户端模块与服务端模块。其次，对系统架构进行设计，采用微服务的思想生成一个C/S的架构，这样的架构可以使模块达到低耦合、高内聚的效果。最后，对模块及其子模块进行详细的设计，包括任务下发、任务执行和结果展示等功能。根据上述设计实现平台，首先对该平台的运行环境进行介绍，包括模拟器环境与中间件的部署环境。其次，对客户端与服务端的子模块的实现进行介绍，客户端模块可以很好的实现展示功能，服务端模块则主要完成任务执行与任务分发的功能。

上面结合附图对本发明的实施方式作了详细说明，但是本发明并不限于上述实施方式，在本领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下做出各种变化。

Claims (8)

1.一种基于数据流的Android应用信息泄露检测方法，用于针对待测Android应用，实现应用信息泄露检测，其特征在于，包括如下步骤：

步骤A. 获得待测Android应用APK文件中的配置文件，并获得配置文件中对应预设各组件类型的各个组件信息，然后进入步骤B；

步骤B. 获得待测Android应用APK文件中的DEX文件，结合预设必要类类型，获得DEX文件中的各个类，构成类集合SootClass，然后进入步骤C；

步骤C. 针对类集合SootClass中的各个类，区分属于源程序的各个类、以及属于第三方类的各个类，并确定属于第三方的各个类分别属于有效类标签或无效类标签，然后进入步骤D；

其中，按如下操作，确定属于第三方的各个类分别属于有效类标签或无效类标签；

操作：若类中存在对应数据出口sink方法的API，则针对该类中的所有接口方法进行数据流分析，判断由该类的入口处数据是否无法传递到数据出口sink方法，是则判定该类属于无效类标签；否则判定该类属于有效类标签；若类中存在对应数据入口source方法的API，则判定该类属于有效类标签；

步骤D. 获得待测Android应用APK文件中的XML文件，并对XML文件进行解析，获得应用的UI文件与应用分析的规则文件，且通过应用分析的规则文件，获得应用的数据分析入口与数据分析出口，然后进入步骤E；

步骤E. 基于所获各个组件信息、类集合SootClass中各个类、应用的UI文件、以及应用的数据分析入口与数据分析出口，以各组件信息、以及属于有效类标签各个类分别所对应方法为节点，构建各节点分别对应所涉及各基本块的CFG图，并构建该各节点分别所对应方法间调用关系的CG图，结合属于无效类标签的各个类分别作为各个节点，构成应用完整控制流程图，然后进入步骤F；

步骤F. 以无效类标签各类分别所对应节点作为无需进行内部方法分析的普通指令，结合普通指令通过IFDS参与数据流分析的方式，针对应用完整控制流程图执行数据流分析，实现应用信息泄露检测。

2.根据权利要求1所述一种基于数据流的Android应用信息泄露检测方法，其特征在于：所述步骤A中预设各组件类型包括Activity类型组件、Service类型组件、ContentProvider类型组件、Broadcast Receiver类型组件。

3.根据权利要求1所述一种基于数据流的Android应用信息泄露检测方法，其特征在于：所述步骤B中预设必要类类型包括Java的原生类库rt.jar与Android的框架库framework.jar。

4.根据权利要求1所述一种基于数据流的Android应用信息泄露检测方法，其特征在于：所述步骤C包括如下步骤C1至步骤C3；

步骤C1. 分别判断类集合SootClass中的各个类，判断类的程序是否经过混淆，待完成对类集合SootClass中所有类的判断后，进入步骤C2；

步骤C2. 分别针对程序经过混淆的各个类，通过聚合静态特征识别方法，判断类是否属于第三方类，是则该类属于第三方类；否则判定该类属于源程序；

同时，分别针对程序未经过混淆的各个类，应用类的类名与预设第三方类名库进行匹配，若匹配成功，则判定该类属于第三方类；否则判定该类属于源程序；然后进入步骤C3；

步骤C3. 分别针对属于第三方的各个类，判断类属于有效类标签或无效类标签，然后进入步骤D。

5.根据权利要求4所述一种基于数据流的Android应用信息泄露检测方法，其特征在于：所述步骤C1中，分别针对类集合SootClass中的各个类，执行如下步骤C1-1至步骤C1-3，判断类的程序是否经过混淆，待完成对类集合SootClass中所有类的判断后，进入步骤C2；

步骤C1-1. 获得类的类名，并判断该类名的命名规则是否为驼峰命名法、帕斯卡命名法或匈牙利命名法的一种，是则进入步骤C1-2；否则进入步骤C1-3；

步骤C1-2. 针对该类名进行字符串分割，并判断分割所获字符串是否为单词，是则进入步骤C1-3；否则判定该类的程序经过混淆；

步骤C1-3. 针对类存储位置下各层级包名组成的全限定名进行分割，获得各个分割结果组成的数组，并判断数组中是否存在单个字符的分割结果或者全数字的分割结果，是则判定该类的程序经过混淆；否则判定该类的程序未经过混淆。

6.根据权利要求4所述一种基于数据流的Android应用信息泄露检测方法，其特征在于：所述步骤C2中按如下方法，分别针对程序经过混淆的各个类，通过聚合静态特征识别方法，判断类是否属于第三方类；

分别针对程序经过混淆的各个类，首先分别提取类中各层级分别对应预设各类型特征的特征值，并由该各个特征值构成该类所对应的特征向量，然后应用以类中各层级分别对应预设各类型特征的特征值组成的特征向量为输入，以类对应第三方库标签或非第三方库标签为输出的第三方类识别模型，判断该类是否属于第三方类。

7.根据权利要求4所述一种基于数据流的Android应用信息泄露检测方法，其特征在于：所述步骤C3中，分别针对属于第三方的各个类，执行如下步骤C3-1至步骤C3-2，判断类属于有效类标签或无效类标签，然后进入步骤D；

步骤C3-1. 若类中存在对应数据出口sink方法的API，则进入步骤C3-2；若类中存在对应数据入口source方法的API，则判定该类属于有效类标签；

步骤C3-2. 针对该类中的所有接口方法进行数据流分析，判断由该类的入口处数据是否无法传递到数据出口sink方法，是则判定该类属于无效类标签；否则判定该类属于有效类标签。

8.根据权利要求1所述一种基于数据流的Android应用信息泄露检测方法，其特征在于：所述步骤F中，以无效类标签各类分别所对应节点作为无需进行内部方法分析的普通指令，结合普通指令通过IFDS参与数据流分析的方式，应用FlowDroid，针对应用完整控制流程图执行数据流分析，实现应用信息泄露检测。

Images