CN106570399A - 一种跨App组件间隐私泄露的检测方法 - Google Patents

Abstract

本发明公开了一种跨App组件间隐私泄露的检测方法，步骤为：提取待分析的应用程序中组件的属性信息，对待分析的应用程序按照是否能将隐私信息传递给第三方应用程序的判断方法对待分析的应用程序进行分类，得到潜在泄露隐私的应用程序的组合；分别生成潜在泄露隐私的组件子序列，并利用所述的子序列构建完整的潜在泄露隐私的组件序列，利用虚拟主函数和插桩技术解决由于代码不连续性造成无法进行静态污点分析的问题，并构建所述组件序列中组件的控制流程图；执行静态污点分析，并输出检测到的跨App组件间隐私泄露的路径。本发明解决了现有技术中存在的路径爆炸和代码的不连续性等问题，加快了跨App组件间隐私泄露的速度，提高了检测效率。

Description

一种跨App组件间隐私泄露的检测方法

技术领域

本发明属于Android应用程序内部的隐私泄露检测技术领域，具体涉及一种基于构件潜在泄露隐私的组件序列，并利用静态污点分析技术实现跨App组件间隐私泄露的自动检测方法。

背景技术

随着Android设备市场份额的不断扩大，更多的恶意攻击者将目标瞄向Android设备。研究发现，以泄漏用户隐私信息为目标的恶意软件占据比例很大，而且近年来国内移动设备用户信息泄漏事件频发。中国互联网协会2015年发布的《中国网民权益保护调查报告》称，78.2％的网民个人身份信息被泄漏过，63.4％的网民个人网上活动信息被泄漏过。2015年百度Wormhole漏洞影响许多用户量过亿的应用程序，带来大量用户隐私泄漏风险。面对移动用户隐私保护的严峻形势，隐私泄漏的检测颇受关注。

现有的隐私泄露检测主要针对Android应用程序内部的隐私泄漏，包括组件内隐私泄漏、组件间隐私泄漏、ICC漏洞检测(如Activity劫持的第三方App来达到隐私泄漏的目的)，而忽略Android中跨App组件间隐私泄漏的问题。跨App组件间的隐私泄露指恶意软件利用存在ICC漏洞(如Activity劫持的第三方App来达到隐私泄漏的目的)。研究表明，60％的应用程序至少存在1个以上的ICC漏洞，因此，利用ICC漏洞实现跨App组件间隐私泄漏非常容易。如：Android Application1中组件能获取位置信息；Android Application2中存在ICC漏洞的组件能将接收到的信息写入文件。Application1将位置信息通过ICC方法(inter-component communication)传递Application2，则Application2将位置信息写入文件，导致隐私信息泄漏。

恶意软件泄漏隐私的主要途径分为组件内隐私泄漏、组件间隐私泄漏和跨App组件间隐私泄漏等。其中对组件内部的隐私泄露检测技术已经达到很高的识别精度，但是对跨App组件间的隐私泄露检测研究较少。基于静态污点分析技术，以及基于函数调用关系实现检测隐私泄漏的方法，精确度很高，但是仅限于组件内隐私泄漏问题。跨App组件间隐私泄漏检测，与之相关的Epicc和ComDroid等ICC漏洞检测方法，仅能对ICC漏洞进行检测，并没有执行数据流分析，即只能检测组件是否可能泄漏隐私信息，不能判断是否有隐私信息通过此泄漏点泄漏隐私。所以，单纯以ICC漏洞的存在来判断隐私数据泄漏会造成极高的误报率。跨App组件间隐私泄漏的检测，由于App中组件数量庞大、依赖关系复杂，并存在很多与跨App组件间隐私泄漏无关的组件序列路径问题，如果直接利用现有的隐私泄漏检测技术，会导致在CFG的构建上引起空间爆炸，严重影响检测效率。而且，跨App组件间隐私泄漏涉及多个应用程序，由于App间代码不连续导致无法建立一个连续的CFG，导致不能执行静态污点分析，所以现有技术不能被直接利用解决此问题。

发明内容

针对上述现有技术中存在的问题，本发明的目的在于，提供一种跨App组件间隐私泄露的检测方法，以解决现有技术中存在的路径爆炸问题以及多种代码不连续性问题等。

为了实现上述任务，本发明采用以下技术方案：

一种跨App组件间隐私泄露的检测方法，包括以下步骤：

提取待分析的应用程序中组件的属性信息，利用属性信息对待分析的应用程序按照是否能将隐私信息传递给第三方应用程序的判断方法对待分析的应用程序进行分类，根据分类结果得到潜在泄露隐私的应用程序的组合；

根据所述组合中的应用程序，分别生成潜在泄露隐私的组件子序列，并利用所述的子序列构建完整的潜在泄露隐私的组件序列，在此基础上，利用虚拟主函数和插桩技术解决由于代码不连续性造成无法进行静态污点分析的问题，并构建所述组件序列中组件的控制流程图；在所述的控制流程图上执行静态污点分析，并输出检测到的跨App组件间隐私泄露的路径。

进一步地，所述的提取待分析的应用程序中组件的属性信息的具体内容包括：

利用数据流分析工具Epicc提取待分析的应用程序中Dex和AndroidManifest文件中的以下信息：

声明的组件列表、每个组件的intent-filter标签、每个组件的exported属性值、每个组件的intent参数值。

进一步地，所述的利用属性信息对待分析的应用程序按照是否能将隐私信息传递给第三方应用程序的判断方法对待分析的应用程序进行分类的具体过程包括：

根据组件的intent参数值来判断组件能否将隐私信息传递给第三方应用程序，若当前组件能将隐私信息传递给第三方应用程序，则将当前组件所在的应用程序归类为Source App；若当前组件能被第三方应用程序调用，则将当前组件所在的应用程序归类为Sink App；若应用程序同时满足Source App和Sink App的条件，则将该应用程序归类为Source Or Sink；

则根据分类结果得到潜在泄露隐私的应用程序的组合有以下几种：

(Source App，Sink App)、(Source App，Source Or Sink)、(Source Or Sink，Sink App)、(Source Or Sink，Source Or Sink)。

进一步地，所述的生成潜在泄露隐私的组件子序列的具体方法为：

根据应用程序中intent参数值与intent-filter标签，利用组件间的匹配规则生成组件调用关系，根据组件调用关系生成应用程序运行时可能出现的组件执行序列，然后判断组件执行序列中是否存在能够构建完整的潜在泄露隐私的组件序列的子组件序列，如果存在，则将该子组件序列输出。

进一步地，所述的利用虚拟主函数和插桩技术的具体过程包括：

对于生命周期方法在代码上的不连续性：

在生成的潜在泄露隐私的组件序列基础上，为序列中的每个组件生成虚拟主函数dummyMain，按照Android开发文档中生命周期的调用顺序，在dummyMain中生成调用生命周期方法的语句，从而解决生命周期方法在代码上的不连续性问题；

对于回调函数在代码上的不连续性：

利用FlowDroid收集回调函数，判断当前组件是否包含回调函数，如果包含，则在组件的dummyMain方法的调用onResume与onPause语句之间，生成调用回调函数的语句，从而解决回调函数在代码上的不连续性问题；

对于组件间的代码不连续性：

利用Soot生成Jimple中间语言，采用插桩技术修改所述的潜在泄漏隐私的组件序列中组件的ICC方法，从而解决组件间的代码不连续性问题。

本发明提出了一种采用静态污点分析的手段检测跨App组件间隐私泄露的方法，解决了现有技术中存在的问题，为跨App组件间隐私泄露问题提供了一种新的研究思路；本发明与现有技术相比具有以下技术特点：

1.本发明在保证覆盖泄漏隐私信息路径的情况下提出生成潜在泄漏隐私的组件序列的方法，精简与跨App组件间隐私泄漏无关的组件序列，解决了路径爆炸问题；

2.针对App间代码不连续造成无法构建完整CFG，从而导致不能执行数据流分析的问题，通过移植IccTA中的插桩方法进行了有效解决；

3.通过生成虚拟主函数的方法和插桩技术，解决了跨App组件间隐私泄漏中的多种代码不连续性问题；

4.构建精简的控制流图加快了跨App组件间隐私泄露的速度，提高了检测效率。

附图说明

图1为在360应用市场上统计的81个App中组件数量示意图；

图2为一个获取隐私信息的应用程序的代码示意图；

图3为一个隐私泄露信息的应用程序的代码示意图；

图4为本发明方法的整体流程图；

图5为App组合序列中元素1的组件泄漏子序列生成过程示意图；

图6为App组合序列中元素2的组件泄漏子序列生成过程示意图；

图7为startActivity的修改方法示意图；

图8为360应用市场上81个应用的分类结果示意图。

具体实施方式

图1是在360应用市场上统计的81个App中组件数量示意图，统计结果显示，81个应用程序中包含9321个Activity组件、806个Service组件和688个Broadcast Receiver组件，平均每个应用程序包含134个组件。

图2和图3给出了两个示例，分别为获取隐私信息的Application1和泄露隐私信息的Application2示意图，用以展示App组件间隐私泄露的问题。在图2中，Application1中组件Activity1(1-12)通过getDeviceId(8行)得到设备的ID值，则表示为且Application1不存在泄露隐私信息的表征函数，则表示为lp(Application1)＝false。在图3中，Application2中组件Activity2不能获取隐私信息，则表示为且Activity2可以泄露隐私信息，则表示为lp(Application2)＝true；在Application1存在关联Application2的R函数startActivity，将DeviceID传递给Application2，则综上所述，Application1和Application2满足跨App组件间隐私泄露的定义，则Application1和Application2可能存在跨App组件间隐私泄露的路径。

本发明提出了一种跨App组件间隐私泄露的检测方法，具体步骤介绍如下：

步骤1，提取待分析的应用程序中组件的属性信息

如图4所示，对于可能存在组件间隐私泄露的待分析应用程序，本发明中利用数据流分析工具Epicc提取待分析的应用程序中Dex和AndroidManifest文件中的以下信息：

(1)声明的组件列表；

(2)每个组件的intent-filter标签；

(3)每个组件的exported属性值；

(4)每个组件的intent参数值(如：action)。

通过(1)得到应用程序中声明的组件列表，当组件exported属性值为true时，则允许第三方App访问当前组件；反之拒绝任何来自第三方App访问。通过(2)和(4)得到组件的Intent参数值和intent-filter属性值，用于组件间的匹配。

组件exported的属性值存在显式声明和默认值，所以本发明方法采用算法1计算组件的exported属性值：

步骤2，利用属性信息对待分析的应用程序按照是否能将隐私信息传递给第三方应用程序的判断方法对待分析的应用程序进行分类，根据分类结果得到潜在泄露隐私的应用程序的组合，具体过程如下：

根据步骤1中得到的组件的intent参数值来判断组件能否将隐私信息传递给第三方应用程序，若当前组件能将隐私信息传递给第三方应用程序，则将当前组件所在的应用程序归类为Source App；若当前组件能被第三方应用程序调用，则将当前组件所在的应用程序归类为Sink App；若应用程序同时满足Source App和Sink App的条件，则将该应用程序归类为Source Or Sink。根据上述分类方法，一个应用程序可以归属为一个以上的类别。

因此，本发明方法将待分析的应用程序分为以下几类：

(1)Source App：能够获取隐私信息并将隐私信息传递给第三方应用程序的App集合；

(2)Sink App：能够从第三方应用程序得到隐私信息并泄漏的App集合；

(3)Source Or Sink：同时满足Source App和Sink App条件的应用程序集合。

则最终得到的潜在泄露隐私的应用程序的组合有以下几种：

(Source App，Sink App)、(Source App，Source Or Sink)、(Source Or Sink，Sink App)、(Source Or Sink，Source Or Sink)。其中，括号中的元素表示集合中的应用程序。不用分析类似(Sink App，Source App)等不能泄漏隐私的App组合。

之所以进行App分类的原因如下：

跨App组件间隐私泄漏是由两个App组合完成的，但是，任意两个App组合不一定能够达到泄漏隐私的目的。为了删除不可能达到泄漏隐私的App组合，提出一种对App分类的思想：

(1)如果当前App能获取隐私信息，但不能将隐私信息传递给第三方应用程序，则该App不能作为跨App组件间隐私泄漏中的一个App；

(2)如果当前App能泄漏隐私信息，但不能被第三方应用程序调用，则该App不能作为跨App组件间隐私泄漏中的一个App。

在本发明方法设计的过程中，主要面临以下两个问题：

第一，路径爆炸问题。CFG引入表示应用程序代码间关系的中间表示方法，它能够全面和真实的反映程序代码控制依赖关系，因而被广泛应用于隐私泄漏的路径检测。但是，在构建跨App的CFG时，由于待检测的多个独立的App包含组件数量庞大，使得存储空间和计算复杂度过高。如图1所示，如果要构造应用程序完整的CFG，过多的与跨App组件间隐私泄漏无关的组件依赖关系，会导致构造CFG出现路径爆炸的问题，从而降低跨App组件间隐私泄漏检测效率，甚至会增加跨App组件间隐私泄漏路径的误报率。

因为本发明方法检测隐私泄漏的准确率受到构建的CFG精确性的影响。所以，在保证覆盖跨App组件间可能存在的隐私泄漏路径的条件下，能够精简组件间的依赖关系，构造其真实存在并能引发隐私泄漏的组件依赖关系，是构建CFG必须解决的首要问题。

第二，代码的不连续性问题。Android应用程序在代码上的不连续性，将导致不能将分析的多个独立的App构建成一个完整的CFG，造成不能执行应用程序间静态污点分析，最终导致检测失败。

针对上述问题，本发明采用以下步骤来解决：

步骤3，根据所述组合中的应用程序，分别生成潜在泄露隐私的组件子序列，并利用所述的子序列构建完整的潜在泄露隐私的组件序列；

具体地，构建潜在泄露隐私的组件序列的方法是：

(1)根据潜在泄漏隐私的App组合中的两个应用程序，分别生成潜在泄漏隐私的组件子序列A、B；

(2)利用潜在泄漏隐私的组件子序列A、B，构建完整的潜在泄漏隐私的组件序列。

其中，上述的潜在泄露隐私的组件子序列的生成方法是：

根据步骤1中得到的应用程序中intent参数值与intent-filter标签，利用组件间的匹配规则生成如图5和图6所示的组件调用关系，根据组件调用关系生成应用程序运行时可能出现的组件执行序列，然后判断组件执行序列中是否存在能够构建完整的潜在泄露隐私的组件序列的子组件序列，如果存在，则将该子组件序列输出。

图5是App组合序列中元素1的组件泄漏子序列生成过程示意图；表示的是步骤2中App组合中第1个元素生成潜在泄漏隐私的组件子序列的过程，本发明方法根据组件调用关系生成两种组件执行序列：(1)A→B1→C；(2)A→B2。然后，本发明方法采用算法2判断(1)(2)中是否存在潜在泄漏隐私的组件子序列；

图6是App组合序列中元素2的组件泄漏子序列生成过程示意图，表示的是Step2中App组合中第2个元素生成潜在泄漏隐私的组件子序列的过程，本发明方法根据组件调用关系生成两种组件执行序列：(3)D→E→F1；(4)D→E→F2；

假定经过算法2和算法3生成的潜在泄漏隐私的组件子序列分别为：B→C、E→F2。那么生成的潜在泄漏隐私的组件序列为：B→C→E→F2。其中，序列中元素是与跨App组件间隐私泄漏问题相关的组件，同时也是需要构建控制流程图CFG的组件。

之所以生成潜在隐私泄露组件序列的原因如下：

在保证覆盖跨App组件间可能存在的隐私泄漏路径的条件下，精简组件间的依赖关系，构造真实存在并能引发隐私泄漏的组件依赖关系，是构建CFG必须解决的首要问题。因此，根据步骤2中得到的潜在泄漏隐私的App组合，提出了上述生成潜在泄漏隐私的组件序列的方法，这种方法可有效精简组件间的依赖关系，解决了路径爆炸的问题。

步骤4，利用虚拟主函数和插桩技术解决由于代码不连续性造成无法进行静态污点分析的问题，并构建所述组件序列中组件的控制流程图；

在生成潜在泄漏隐私的组件序列的基础上，利用虚拟主函数和插桩技术解决由于Android代码不连续性造成无法进行静态污点分析的问题，并构建基于精简组件(即通过前述方法构建的潜在泄露隐私的组件序列)的控制流程图CFG；通过利用插桩技术修改代码，并根据潜在泄漏隐私的组件序列，从组件序列的左侧向右侧开始，分别在前一个组件中实例化下一个组件，并调用helperIpc和dummyMain方法，如图7所示。

图7是startActivity的修改方法示意图，(A)表示Application1存在Activity1组件，(B)表示Application2存在Activity2组件。而Activity1和Activity2组件符合组件匹配规则，并能传递数据。分别修改(A)(B)的代码，使得Activity1和Activity2在代码上连续。如(B)所示，(B)中添加了helperIpc(Intent)方法，helperIpc方法将携带的Intent对象赋值给_intent_ipc；同时添加了getIntent方法，getIntent的返回值为_intent_ipc。helperIpc和getIntent实现显式传递Intent对象，从而替换由Android框架完成的Intent传递工作。而(B)中dummyMain方法实现了生命周期和回调函数的思想。如(A)所示，(A)删除了startActivity，并实例化Activity2，然后调用helperIpc方法传递Intent对象，以及调用Activity2中dummyMain方法解决由ICC引入的代码不连续问题。IccTA同样采用插桩技术来解决代码的不连续性。但是，IccTA局限于一个应用程序，并没有扩展到App间；而且，IccTA将应用程序内部所有的ICC方法都用插桩技术替换了，包括与泄漏隐私信息无关的组件中ICC方法，因此，容易造成路径爆炸，降低分析效率。

上述的虚拟主函数和插桩技术的具体实现过程介绍如下：

(1)对于生命周期方法在代码上的不连续性：

Android应用程序没有主函数，而是由组件生命周期组成的多个入口组成。Android框架为每个组件定义了完整的生命周期，根据用户事件或系统事件，调用组件的生命周期必须精确的模拟生命周期的调用顺序，才能保证下一步静态分析的正确性。在生成潜在泄漏隐私的组件序列基础上，为序列中的每个组件生成dummyMain(虚拟主函数)，按照Android开发文档中生命周期的调用顺序，在dummyMain中精确的模拟生命周期的执行顺序，即在dummyMain中生成调用生命周期方法的语句，从而解决生命周期方法在代码上的不连续性。FlowDroi同样采用生成dummyMain的方法模拟生命周期的执行顺序。但是，FlowDroid只为整个应用程序生成一个dummyMain，而本发明针对序列中的每个组件都生成了dummyMain。

(2)对于回调函数在代码上的不连续性：

Android应用程序开发基于Java，同时继承了回调函数导致的代码不连续性。本发明方法直接利用FlowDroid收集到的回调函数，判断当前组件是否包含回调函数，如果当前组件包含回调函数，则在组件的dummyMain方法的调用onResume与onPause语句之间，生成调用回调函数的语句，从而解决回调函数在代码上的不连续性问题。

(3)对于组件间的代码不连续性：

Android框架为组件间交互数据提供了ICC模型(如：startActivity)，但本质上是由Android框架实现了数据传递，而组件间在代码上是不连续的。因此，本发明方法利用Soot生成Jimple中间语言，并结合插桩技术修改步骤3生成的潜在泄漏隐私的组件序列中组件的ICC方法，从而解决组件间的代码不连续性。由于Android App间的数据交互同样是由ICC方法实现的，因此，本发明采用同样的方法解决App间代码的不连续性。

步骤5，在所述的控制流程图上执行静态污点分析，并输出检测到的跨App组件间隐私泄露的路径。

本方案中直接利用FlowDroid执行静态污点分析，检测跨App组件间隐私泄漏问题。FlowDroid是在Soot与Heros的基础上实现了一种精确的上下文敏感、流敏感、字段敏感、对象敏感的污点分析算法，并有效的解决了别名问题。利用SuSi工具获取敏感源和泄漏源集合，在步骤4中精确的CFG基础上执行应用程序间的静态污点分析，并输出检测到的跨App组件间隐私泄漏的路径，如图4所示。

实验部分

实验一：仿真实验

为了验证本发明方法功能的有效性，构造了六组实现跨App组件间隐私泄漏的触发程序。触发程序中没有多余干扰检测的组件与路径，而且能够通过人工对比检测结果与预设的泄漏隐私路径，从而验证本发明方法功能的有效性。

在六组触发程序中，同组的2个App可以实现跨App组件间隐私泄漏。而不是同组的2个App不能泄漏隐私信息。如表1所示，六组触发程序分别是：(1，2)、(1，3)、(1，4)、(5，6)、(5，7)、(5，8)。经过分析本发明方法，得到六组触发程序的分类结果为：Source App＝{1，5}；Sink App＝{2，3，4，6，7，8}。根据分类结果，得到的潜在泄漏隐私的App组合序列共有12组，分别为：(1，2)、(1，3)、(1，4)、(1，6)、(1，7)、(1，8)、(5，2)、(5，3)、(5，4)、(5，6)、(5，7)、(5，8)。经过组件间的匹配，发现(1，6)、(1，7)、(1，8)、(5，2)、(5，3)、(5，4)等6组App组合不能达到泄漏隐私的目的。

表1测试样本图表

序号	测试用例	Activity	服务	广播	ICC方法	类别
							1	GetDeviceID1.apk	2	0	0	startActivity	SourceApk
2	LeakDeviceID1.apk	1	0	0		SinkApk
							3	LeakDeviceID2.apk	1	1	0	startService	SinkApk
4	LeakDeviceID3.apk	1	0	1	sendBroadcast	SinkApk
							5	GetDeviceID2.apk	2	0	0	startActivity	SourceApk
6	LeakDeviceID4.apk	1	0	0		SinkApk
							7	LeakDeviceID5.apk	1	1	0	startService	SinkApk
8	LeakDeviceID6.apk	1	0	1	sendBroadcast	SinkApk

最终，针对(1，2)、(1，3)、(1，4)、(5，6)、(5，7)、(5，8)等六组App组合输出泄漏隐私的路径。经过人工比较本发明方法的检测结果与预设的泄漏隐私的路径，两者路径一致，因此，本发明方法能够检测跨App组件间隐私泄漏的问题。

实验二：实例验证

为了进一步验证本发明方法对真实应用的检测效果，在360应用市场上随机选择81个真实应用。根据步骤2的分类规则，本发明得到的分类数据如图8所示，组件的exported属性值为true的数目为2301个，占组件总数10815的21.28％。其中，29个应用程序包含exported属性值为true的组件，即此29个App能被第三方应用程序调用；10个应用程序包含有隐式Intent或显示调用第三方应用程序的组件，即此10个App能够调用第三方应用程序；42个应用程序既包含exported属性为true的组件，同时能够调用第三方应用程序。

对获取隐私和泄漏隐私的API进行统计，结果显示，在获取隐私的API中，getLongitude和getLatitude被使用的次数最多，达到了1834次如表2所示；在泄漏隐私的API中，Log被使用的次数最多，达到66712次如表3所示。

表2获取隐私的API图表

API方法	次数	描述
			getLongitude()	1834	获取经度
getLatitude()	1834	获取纬度
			getCountry()	547	国家地区代码
getLastKnownLocation(String)	209	最近缓存地址
			getSSID()	89	SSID值

表3泄露隐私的API图表

API方法	次数	描述
			Log	66712	LogCat
putString/putBoolean/putInt/putLong	48959	数据存储
			write	890	写文件
sendTextMessage	252	发送短信
			MediaRecorder start()和setVideoSource	208	音频

通过本发明方法发现的一个具体实例

跨App组件间隐私泄漏的细节：检测发现com.pdswp.su.smartcalendar和com.xkfop.xhuioa能够合作实现跨App组件间隐私泄漏。com.pdswp.su.smartcalendar中用户输入的备忘录内容被com.xkfop.xhuioa劫持，导致备忘录内容被com.xkfop.xhuioa泄漏。首先，通过com.pdswp.su.smartcalendar.bean.NoteItemBean类中的方法getNote得到备忘录内容，并将备忘录内容赋给putExtra的参数android.intent.extra.TEXT；然后，通过startActivity传递出去，被com.xkfop.xhuioa中的类com.xkfop.sendService的getIntent方法得到参数android.intent.extra.TEXT的值，并通过sendTextMessage将备忘录内容泄漏。

最后，通过实验统计发现在81个应用程序中的12组跨App组件间存在隐私泄漏问题。其中，应用程序间通过activity泄漏隐私信息的为4个，通过service泄漏隐私信息的为7个，通过Broadcast Receiver泄漏隐私信息的为1个。

最终结果表明，本发明方法在真实应用中是行之有效的。

Claims (5)

1.一种跨App组件间隐私泄露的检测方法，其特征在于，包括以下步骤：

提取待分析的应用程序中组件的属性信息，利用属性信息对待分析的应用程序按照是否能将隐私信息传递给第三方应用程序的判断方法对待分析的应用程序进行分类，根据分类结果得到潜在泄露隐私的应用程序的组合；

根据所述组合中的应用程序，分别生成潜在泄露隐私的组件子序列，并利用所述的子序列构建完整的潜在泄露隐私的组件序列，在此基础上，利用虚拟主函数和插桩技术解决由于代码不连续性造成无法进行静态污点分析的问题，并构建所述组件序列中组件的控制流程图；在所述的控制流程图上执行静态污点分析，并输出检测到的跨App组件间隐私泄露的路径。

2.如权利要求1所述的跨App组件间隐私泄露的检测方法，其特征在于，所述的提取待分析的应用程序中组件的属性信息的具体内容包括：

利用数据流分析工具Epicc提取待分析的应用程序中Dex和AndroidManifest文件中的以下信息：

声明的组件列表、每个组件的intent-filter标签、每个组件的exported属性值、每个组件的intent参数值。

3.如权利要求2所述的跨App组件间隐私泄露的检测方法方法，其特征在于，所述的利用属性信息对待分析的应用程序按照是否能将隐私信息传递给第三方应用程序的判断方法对待分析的应用程序进行分类的具体过程包括：

根据组件的intent参数值来判断组件能否将隐私信息传递给第三方应用程序，若当前组件能将隐私信息传递给第三方应用程序，则将当前组件所在的应用程序归类为SourceApp；若当前组件能被第三方应用程序调用，则将当前组件所在的应用程序归类为SinkApp；若应用程序同时满足Source App和Sink App的条件，则将该应用程序归类为SourceOr Sink；

则根据分类结果得到潜在泄露隐私的应用程序的组合有以下几种：

(Source App，Sink App)、(Source App，Source Or Sink)、(Source Or Sink，SinkApp)、(Source Or Sink，Source Or Sink)。

4.如权利要求2所述的跨App组件间隐私泄露的检测方法，其特征在于，所述的生成潜在泄露隐私的组件子序列的具体方法为：

根据应用程序中intent参数值与intent-filter标签，利用组件间的匹配规则生成组件调用关系，根据组件调用关系生成应用程序运行时可能出现的组件执行序列，然后判断组件执行序列中是否存在能够构建完整的潜在泄露隐私的组件序列的子组件序列，如果存在，则将该子组件序列输出。。

5.如权利要求1所述的跨App组件间隐私泄露的检测方法，其特征在于，所述的利用虚拟主函数和插桩技术的具体过程包括：

对于生命周期方法在代码上的不连续性：

在生成的潜在泄露隐私的组件序列基础上，为序列中的每个组件生成虚拟主函数dummyMain，按照Android开发文档中生命周期的调用顺序，在dummyMain中生成调用生命周期方法的语句，从而解决生命周期方法在代码上的不连续性问题；

对于回调函数在代码上的不连续性：

利用FlowDroid收集回调函数，判断当前组件是否包含回调函数，如果包含，则在组件的dummyMain方法的调用onResume与onPause语句之间，生成调用回调函数的语句，从而解决回调函数在代码上的不连续性问题；

对于组件间的代码不连续性：

利用Soot生成Jimple中间语言，采用插桩技术修改所述的潜在泄漏隐私的组件序列中组件的ICC方法，从而解决组件间的代码不连续性问题。