随着Android移动市场份额的不断扩大，越来越多的恶意攻击者将目标瞄向Android设备.腾讯社会研究中心最新一期发布的互联网安全报告[1]显示：在所选取的852个Android APP(Android application)中，约有98.5%的APP都需要获取用户隐私权限.Felt等人[2]研究发现，以获取并泄露用户隐私信息为目标的恶意软件占据很大的比例，这一结果很好地解释了近年来国内外个人信息泄露事件频发的问题.
学术界和工业界一般将隐私权限等级划分为高危隐私权限、核心隐私权限、重要隐私权限和普通隐私权限[3-4].不同层面的权限滥用会对用户造成不同程度的影响，如何在权限安全控制和用户的体验之间抉择是一个相互制约的话题，使用权限定义复杂的控制手段能够在一定程度上保护用户隐私数据，但却以牺牲用户体验为代价.为了娱乐性和实用性，目前移动设备仅使用粗粒度的访问权限控制手段.Android系统自身实现了一套用于保护敏感信息资源安全性的应用程序编程接口(application programming interface, API)访问权限控制机制，用于保护敏感信息资源的安全性.其要求在程序安装时向用户显式地申请使用权限.然而中国互联网数据中心[4](Data Center of China Internet, DCCI)调研发现，有72%的用户不清楚APP获取隐私权限的用途.所以大多数用户为了追求良好的用户体验，不惜将该程序自身功能不必需的隐私权限授权给该APP，因此这种API权限控制机制并不能有效控制第三方应用程序对隐私数据的访问和使用.
软件泄露隐私的主要途径分为组件内隐私泄露、组件间隐私泄露和跨APP组件间隐私泄露.组件内隐私泄露是指在Android APP内部，某组件能够独立完成隐私的获取和泄露[5]；而组件间隐私泄露是指Android APP内部的2个组件通过合作完成获取和泄露隐私[6]；跨APP组件间隐私泄露是指某个恶意软件利用存在组件间通信(inter-component communication, ICC)漏洞[7-8]通过第三方APP来泄露隐私；据ComDroid[8]研究表明，60%的应用程序至少存在1个以上的ICC漏洞.因此，跨APP组件间隐私泄露普遍存在并且不容忽视.
虽然目前存在很多隐私检测的研究[9-16]，但是针对跨APP组件间隐私泄露问题的研究涉及较少.FlowDroid[5]提出一种新型按需算法的静态污点分析技术检测隐私泄露问题；LeakMiner[17]结合Android自身特有的安全机制以及编程模型，基于函数调用关系实现了对程序中隐私信息的识别、跟踪和泄露检测.上述隐私泄露检测方法的精确度很高，但仅限于组件内隐私泄露问题；IccTA[6]和Amandroid[18]等方法针对组件间隐私泄露检测.其中，IccTA结合Epicc[7]与FlowDroid方法，通过跟踪组件间的隐私信息传播达到检测的目的.
跨APP组件间隐私泄露检测的实现存在很大的挑战.原因在于APP中组件数量庞大、依赖关系复杂，存在很多与跨APP组件间隐私泄露无关的组件序列路径.因此，直接利用现有的隐私泄露检测技术，会在构建控制流图(control flow graph, CFG)时引发空间爆炸，严重影响检测效率.而且，由于跨APP组件间隐私泄露往往涉及到多个应用程序的集合，APP间代码不连续将导致在分析隐私泄露路径时无法建立一个连续的CFG，而现有工作不能解决此问题.
因此，本文提出了一种检测跨APP组件间隐私泄露的方法PLDetect.PLDetect提出生成潜在泄露隐私的组件序列，精简与跨APP组件间隐私泄露无关的组件序列的方法，有效地解决了在生成CFG时路径爆炸问题；进一步地，PLDetect通过将生成虚拟主函数和插桩技术有效结合，解决跨APP组件间隐私泄露中的多种代码不连续性问题；最后，生成基于精简组件的控制流图，并执行应用程序间静态污点分析，输出跨APP组件间隐私泄露的路径.
Fig. 1 The example of privacy leakage across application components
图1 跨APP组件间隐私泄露实例
本文的主要贡献有3个方面:
1) 设计并实现1个采用静态污点分析方法检测跨APP组件间隐私泄露的系统PLDetect；
2) 在保证PLDetect覆盖泄露隐私信息路径的情况下，提出生成潜在泄露隐私的组件序列的方法，用以提高检测效率；
3) 针对APP间代码不连续造成无法构建完整的CFG，从而导致不能执行数据流分析的问题，通过移植改进IccTA中的插桩方法对此问题进行了有效解决.
1 跨APP组件间隐私泄露的攻击模型
为了准确描述跨APP组件间隐私泄露攻击模型，首先给出跨APP组件间隐私泄露的相关定义.
假定Appi为Android Market中应用程序，SandBoxi为其对应的运行沙箱环境，则表示为Appiin SandBoxi.假定fp为隐私信息获取通道表征函数，Privacyi为App1能获取的隐私信息，则表示为Privacyi=fp(Appi).假定lp为隐私信息泄露通道表征函数，若Appi不能泄露隐私信息，则表示为lp(App1)=false，否则，lp(App1)=true.
在App1in SandBox1& App2in SandBox2且SandBox1∩SandBox2=∅的条件下，如果App1满足Privacy1=fp(App1)≠∅且lp(App1)=false,App2满足 Privacy2=fp(App2)≠∅且 lp(App1)=true,并且存在一种关联关系函数R，使得Privacy2=fp(R(App2,App1))≠∅且 Privacy2∈Privacy1，那么App1和App2可能存在跨APP组件间隐私泄露的路径.
根据定义，对跨APP组件间隐私泄露的攻击模型进行实例化描述.
在图1中，App1是获取隐私信息的良性Android应用程序，App2是泄露隐私信息的恶意Android应用程序.App1中的组件A通过授权的API权限得到设备ID值(getDeviceId)，并通过ICC方法(startActivity)将ID值传递给App2中的组件B，并由B将ID值泄露.图1右侧的代码分别是App1中组件A与App2中组件B的关键代码简略描述.另外，在实际用户使用环境中，不排除2个恶意程序通过合作互通的形式更复杂更隐蔽地达到泄露隐私的目的.在上述实例中，App1可以利用恶意攻击者所规定的某种数据拆分格式,如图像格式或自定义文件等形式，将设备ID发送至App2，随后由App2将接收到的信息经过一系列数据重组以及信息转换手段写出，最终以非授权分发方式发送至攻击者.
上述中不论隐私信息以哪种形式组织，App1满足Privacy1=fp(App1)≠∅且lp(App1)=false，App2满足Privacy2=fp(App2)≠∅且lp(App2)=true.而且App1与App2存在关联关系R函数(startActivity)，使得Privacy2=fp(R(App2, App1))≠∅,因此，App1和App2间可能存在跨APP组件间隐私泄露的路径.
2 PLDetect系统实现
PLDetect由5个执行步骤组成，如图2所示，在Step1中，利用Epicc提取输入中每个APP的组件属性；在Step2中，利用Step1的组件属性对待分析的多个APP进行分类；在Step3中，利用分类结果精简与跨APP组件间隐私泄露无关的组件，生成潜在泄露隐私的组件序列，从而解决由于组件间依赖关系复杂而造成的路径爆炸问题；在Step4中，在潜在泄露隐私组件的基础上，利用虚拟主函数和插桩技术解决由于Android代码不连续性造成无法进行静态污点分析的问题，并构建基于精简组件的CFG；在Step5中，PLDetect利用SuSi[19](一种采用机器学习方法收集Android 敏感API的工具)收集到的敏感源和泄露点，在CFG上执行应用程序间的静态污点分析，最终输出检测到的跨APP组件间隐私泄露的路径.
Fig. 2 Overall framework of PLDetect
图2 PLDetect系统整体框架
2.1 组件属性提取
在图2的Step1，PLDetect利用Epicc提取Dex和AndroidManifest文件中的相关信息.Epicc是一个基于Soot编译框架[20]和Heros数据流分析工具[21]的ICC拓扑工具，能够提取组件属性、ICC方法和参数.
PLDetect提取组件属性为:
1) 声明的组件列表；
2) 每个组件的intent_filter标签；
3) 每个组件的exported属性值；
4) 每个组件的intent参数值.
算法1. 计算组件的exported值.
输入：Android应用程序的组件;
输出：true或false.
if explicitExported(component)=true then
*判断当前Activity是否可以被另一个Application的组件启动*
return getTheValue(“exported”)；
end if
if componentType(component)=ContentProvider
*componentType方法返回类的组件类型*
then
if SDKversion≤16 then
return true;
else
return false;
end if
end if
if ComContainIntentFilter(component)=true
*判断IntentFilter中是否包含该组件*
then
return true;
else
return false;
end if
通过属性1得到应用程序中声明的组件列表.当组件exported属性值为true时，则表示允许第三方APP访问当前组件；反之则拒绝任何来自第三方APP访问.因此，PLDetect采用算法1计算组件的exported属性值，并通过属性2和属性4得到组件的intent参数值和intent_filter属性值，用于组件间的匹配.
2.2 APP分类
跨APP组件间隐私泄露是由2个APP组合完成的，但是，任意2个APP组合不一定能够达到泄露隐私的目的.因此，针对所有的APP进行分类及相应的筛选处理是非常必要的.
1) 根据跨APP组件间隐私泄露的条件，PLDetect认为2种APP是良性的:
① 如果当前APP拥有获取隐私信息的权限，并能够获取隐私信息，则不能将隐私信息传递给第三方应用程序.
② 如果当前APP拥有泄露隐私信息的权限，并能够泄露隐私信息，则不能被第三方应用程序调用.
上述2种APP不能作为跨APP组件间隐私泄露集合中的APP.所以PLDetect对具有以上条件的APP进行剪枝，从而避免不必要的分析时间.
2) Android组件中是否拥有隐式intent决定该APP是否能够调用第三方APP，因此，假设当前APP拥有隐式intent的组件，则将该APP归类为SourceApp.Android组件的exported属性值决定组件能否被第三方应用程序调用，假设当前APP拥有exported的值为true，则将该APP分为SinkApp类.假设应用程序同时满足上述SourceApp和SinkApp的条件，则将该APP分为SourceOrSink类.
3) 根据2)中分类结果，本文得到可能实现跨APP组件间泄露隐私信息的APP组合有4种形式：(SourceApp,SinkApp),(SourceApp,SourceOrSink),(SourceOrSink,SinkApp),(SourceOrSink,Source-OrSink).
2.3 生成潜在泄露隐私的组件序列
为了能够有效精简组件间的依赖关系，构造真实存在的并能引发隐私泄露的组件序列，PLDetect根据2.2节中得到的潜在泄露隐私的APP组合，提出一种生成潜在泄露隐私的组件序列的方法，从而解决路径爆炸的问题.PLDetect生成潜在泄露隐私的组件序列的方法步骤为
Step1. 根据潜在泄露隐私的APP组合中的2个应用程序，分别生成潜在泄露隐私的组件子序列SeqA，SeqB.
Step2. 利用潜在泄露隐私的组件子序列SeqA，SeqB，构建完整的潜在泄露隐私的组件序列.
生成潜在泄露隐私的组件子序列的具体方法是：首先，根据2.1节中得到的intent参数与intent_filter标签，并利用组件间匹配规则生成图3和图4中的组件调用关系；然后，根据组件调用关系，生成应用程序运行时可能出现的组件执行序列；最后，PLDetect判断组件执行序列中是否存在能够构建完整的潜在泄露隐私的组件序列的组件子序列.
Fig. 3 Generation process of leakage sequence for element 1 in an APP combination
图3 APP组合中元素1泄露序列生成过程
Fig. 4 Generation process of leakage sequence for element 2 in an APP combination
图4 APP组合中元素2泄露序列生成过程
图3表示的是2.2节中APP组合中第1个元素生成潜在泄露隐私的组件子序列的过程描述，PLDetect根据组件调用关系生成了2种组件执行序列：1)A→B1→C；2)A→B2.然后，PLDetect采用算法2判断1), 2)中是否存在潜在泄露隐私的组件子序列.类似地，图4表示的是2.2节中APP组合中第2个元素生成潜在泄露隐私的组件子序列的全过程.
因此，假定经过算法2处理之后生成的潜在泄露隐私的组件子序列分别为B1→C，E→F1.那么，最终由PLDetect生成的潜在泄露隐私的组件序列为B1→C→E→F1.其中，本序列中各个元素是与跨APP组件间隐私泄露问题的相关组件，同时也是需要构建CFG的组件.
算法2. 判断APP组合序列中第i个元素的执行序列是否存在潜在泄露隐私的组件子序列.
输入：应用程序的执行序列;
输出：潜在泄露隐私的组件子序列.
if findLefttoRight(component_sequence)=false then *findLefttoRight方法在执行序列中寻找获取隐私信息的组件*
return false;
else
component_first←findLefttoRight
(component_sequence);
end if
if findRighttoLeft(component_sequence)=false then *findRighttoLeft方法在执行序列中寻找能够调用第三方APP的组件*
return false;
else
component_second←findRighttoLeft
(component_sequence);
end if
m←component_sequence.indexOf(component_first);
*判断组件component_first在执行序列中的位置*
n←component_sequence.indexOf(component_second);
if m>n then
return false;
else
return component_sequence.substring(m,n+1);
end if
2.4 生成精确的控制流图
Android的代码不连续性将导致不能把多个独立的APP构建成一个完整的CFG，因此，本节将详细介绍如何解决由Android中生命周期、回调函数以及ICC方法而引入的代码不连续性问题.
2.4.1 生命周期
Android应用程序没有主函数，而是由组件生命周期函数组成的多个入口，即Android应用程序可以根据用户事件或系统事件，调用组件的每个生命周期函数.如当Activity组件处于onPause状态时，如果该Activity被重新启动，则该Activity直接进入onResume状态，而非onCreate状态；如果该Activity由于内存不足被杀死而后重新启动时，则该Activity进入onCreate状态.因此，由于Android框架为每个组件定义了完整的生命周期，从而造成Android应用程序多入口的问题，只有通过精确的模拟生命周期的变化，才能保证下一步静态分析时得到的隐私泄露路径的精确性.
为了解决由于生命周期引入而带来的的不连续性问题，根据2.3节中生成的潜在泄露隐私的组件序列，PLDetect为序列中的每个组件生成dummy-Main(虚拟主函数).按照Android开发文档中生命周期的调用顺序，PLDetect在dummyMain中精确地模拟生命周期的执行顺序，即在dummyMain中插入调用生命周期函数的语句.
2.4.2 回调函数
Android操作系统允许注册回调函数.如Button的监听器，用户触发该按钮的点击事件后，由Android框架来自动调用onClick后的具体内容.PLDetect使用 FlowDroid处理回调函数的方法，在dummyMain中模拟回调函数的调用.然而，回调函数被调用的顺序无法预测，只有当回调函数所在的组件运行时，回调函数才可能被调用执行.因此，为了考虑模拟的精确性，PLDetect建立了回调函数与组件间的对应关系，并利用FlowDroid收集的回调函数集合，判断潜在泄露隐私组件序列中的每个组件是否存在回调函数，如若存在回调函数，则在dummyMain中模拟回调函数.即：在组件的dummyMain函数中的onResume与onPause调用语句之间，生成调用回调函数的语句，使得回调函数在dummyMain中可达，从而解决代码不连续性问题.
2.4.3 ICC方法
Android应用程序中组件交互数据是通过Bundle对象和intent对象传递的，即ICC模型.但是，通过intent对象实现的代码并没有直接调用对应组件，在代码层，2个组件是独立的、不连续的.它是由Android框架通过匹配intent与intent_filter的参数，从而实现组件间的匹配以及数据传递.
因此，本文利用Soot[13]生成Jimple中间语言，并结合插桩技术修改潜在泄露隐私的组件序列中组件间的ICC方法，从而解决ICC带来的组件间代码的不连续性问题.
PLDetect的具体思路是：基于Jimple中间语言利用插桩技术修改ICC代码，从潜在泄露隐私的组件序列的左侧第1个组件开始，分别在前一个组件中实例化下一个组件，并调用helperIpc和dummyMain方法.如图5所示:
Fig. 5 The modification method of startActivity
图5 startActivity的修改方法
在图5中，以startActivity的修改方法为例对利用插桩技术解决ICC带来的代码不连续性问题进行说明.其中，图5(a)表示App1中的Activity1组件，图5(b)表示App2中的Activity2组件.而Activity1和Activity2组件符合组件匹配规则并能传递数据.PLDetect通过修改图5中的代码，使得Activity1和Activity2在代码层上可达.
在图5(b)中，PLDetect生成helperIpc(intent)和getIntent()方法.helperIpc方法将携带的intent对象赋值给_intent_ipc；getIntent的返回值为_intent_ipc.helperIpc和getIntent实现intent对象的传递过程，从而替换由Android框架完成的工作.其中，图5(b)中dummyMain方法实现了2.4.1节和2.4.2节的思想.
在图5(a)中，删除了startActivity方法，并实例化Activity2对象，然后调用helperIpc方法传递intent对象，将intent对象的信息传递到Activity2对象，并且通过调用Activity2中dummyMain方法，使得Activity1和Activity2在代码层彻底链接起来.
因此，在潜在泄露隐私的组件序列中，任意2个相邻的组件都会采用上述相同的方法.
在Android系统中，Implicit Intent没有以一个指定的组件命名，而是声明需要执行的操作，该操作允许第三方应用程序的组件去处理它.例如：如果在地图上展示用户的位置，可以使用1个Implicit Intent去请求第三方应用程序在地图上展示指定的位置.因此，基于跨APP组件间隐私泄露的问题，应用程序间的数据传递本质上是使用intent对象携带、ICC方法(如startActivity等)传递实现的，所以，针对APP间代码的不连续性，本文采用上述方法处理.基于潜在泄露隐私组件序列的插桩技术，一方面有效解决了IccTA等方法存在的路径爆炸、工作量庞大、分析效率低的问题，另一方面克服了现有方法作用域为单独应用程序内部组件的局限性.
最后，在解决代码不连续性问题后，PLDetect将这些APP之间与隐私泄露相关的组件构建成1个完整的CFG.并且利用SuSi收集Android API中的敏感源和泄露点方法集合，在构建的CFG上执行应用程序间的静态污点分析，跟踪隐私信息的数据流流向，得到并输出检测到的跨APP组件间隐私泄露的路径.
PLDetect以非侵扰的方式工作在后台，并将上述步骤中得到的隐私信息泄露路径作为输入，使用插桩技术来修改路径中组件所在的Android应用程序.以此来保证隐私信息在被恶意应用泄露前被加密或替换为无效的数据，从而在不影响APP正常执行的情况下缓解隐私信息泄露造成的风险和危害.具体来讲，因为Soot支持阅读和重写Davilk字节码，因此PLDetect在上述Soot生成Jimple的基础上，通过插桩修改相关Android程序来达到数据加密或替换的目的.假设APP1的Activity1与APP2的Activity2经检测是2个符合跨APP间隐私泄露的组件并通过intent传递隐私信息.那么，PLDetect将在Activity1中插入1个字段，且该字段的作用是唯一标识Activity2 所在的APK的包名.同时，在Activity2组件中，PLDetect会以Jimple形式插入一段功能代码.这段代码的主要作用是判断从intent中获取到的字段值是否与自身包名一致，若一致则加密或替换隐私信息的值,若不一致则不修改.因此，PLDetect采取了简单有效的方法，在保证用户良好体验的前提下解决了隐私被泄露的隐患.
3 系统评测实验与分析
为了验证跨APP组件间隐私泄露的检测模块的检测效果，本文主要从触发程序和商业应用2方面进行验证.其中，触发程序是指实现跨APP组件间隐私泄露的6组APP集合，此类应用程序没有多余干扰路径，主要是为了验证PLDetect功能而开发的应用程序.这些应用程序包含Activity, Service, Broadcast Receiver等不同的Android组件.如表1所示.商业应用是指在360 Market中随机选择的81个真实应用，部分应用程序信息如表2所示.
Table 1 The Sets of Triggered Program
表1 触发程序测试集
Serial NumberTest CaseAbbreviationActivityServiceBroadcast ReceiverICC MethodCategory1GetDeviceID1.apkG1200startActivitySourceApp2LeakDeviceID1.apkL1100SinkApp3LeakDeviceID2.apkL2110startServiceSinkApp4LeakDeviceID3.apkL3101sendBroadcastSinkApp5GetDeviceID2.apkG2200startActivitySourceApp6LeakDeviceID4.apkL4100SinkApp7LeakDeviceID5.apkL5110startServiceSinkApp8LeakDeviceID6.apkL6101sendBroadcastSinkApp
Table 2 The Sets of Business Application
表2 商业应用测试集
Serial NumberApplication NameVersion1com.sinelife.theone1.5.32com.qiyi.video7.5.13com.baidu.BaiduMap6.04com.qidian.QDReader5.1.15com.cubic.autohome5.0.16com.tencent.qqmusic6.07com.sdu.didi.psnger5.1.18com.tmall.wireless5.19.1︙︙︙
3.1 触发应用
如表1所示，为了验证PLDetect系统功能的有效性，本文共构造了6组实现跨APP组件间隐私泄露的触发程序，这些触发程序中没有设置多余干扰检测的组件与路径.我们通过人工对比PLDetect的检测结果与预设的泄露隐私路径，从而验证PLDetect对跨APP组件间隐私泄露的检测效果.
经过PLDetect分析，表1中6组(共8个)触发程序的分类结果为：SourceApp类别的Android APP有G1和G2；SinkApp类别的Android APP有L1，L2，…，L6；SourceOrSink类别中没有Android APP.在分类结果的基础上，我们可以得到的潜在泄露隐私的APP组合序列共计12组，如图6所示.
Fig. 6 The comparison of test results
图6 检测结果对比
PLDetect分析得到，12组潜在泄露隐私的APP组合序列中存在6组Android APP能够泄露隐私信息，并输出泄露隐私的路径.经过人工比较PLDetect的检测结果与预设的泄露隐私的路径，两者完全一致，正确率达100%.
3.2 商业应用
在我们选取的实际商用Android APP中，平均每个应用程序包含组件高达134个，面对平均134个组件间错综复杂的关系，很容易影响PLDetect的检测结果.因此，为了进一步验证PLDetect的检测效果，选取了81个真实应用作为实验对象.
Fig. 7 The results of classification
图7 分类结果
根据2.2节的分类规则，PLDetect得到的分类数据如图7所示，组件exported属性值为true的数目为2 301个，占组件总数10 815的21.28%.其中，29个应用程序包含exported属性值为true的组件，即此29个Android APP能够被第三方应用程序调用；10个应用程序包含有隐式intent或显式调用第三方应用程序的组件，即此10个Android APP能够调用第三方应用程序；42个应用程序既包含exported属性为true的组件，同时能够调用第三方应用程序.实验结果说明52%的应用程序同时具备SourceApp与SinkApp的特点，将成为泄露隐私信息的重要组成部分.
进一步地，PLDetect对获取隐私和泄露隐私的API进行了统计.结果显示，在获取隐私的API中，getLongitude和getLatitude被使用的次数最多，达到了1 834次，如表3所示；在泄露隐私的API中，Log被使用的次数最多，高达66 711次，如表4所示.根据上述数据推测，随着位置探测设备和地理位置信息系统的开发、应用及推广，使得基于位置信息服务(location-based service， LBS)的Android应用程序越来越多，百度地图、微信、滴滴打车等常用Android应用程序都需要位置的支持.因此，Android应用程序中使用getLongitude和getLatitude次数非常多，同时导致位置信息泄露的威胁增大.Log能够输出程序的中间结果，是调试Android APP的一种常用手段，但是，上述数据显示Log的使用次数过多，可能是由于程序员在调试后没有删除Log代码，导致Log遗留在Andorid APP中，从而造成隐私信息泄露的威胁增大.
Table 3 The Sets of API to Get Privacy Information
表3 获取隐私的API
APIFrequencyDescriptiongetLongitude()1834Get longitudegetLatitude()1834Get latitudesgetCountry()547Get country codegetLastKnownLocation(String)209Get the nearest cache locationgetSSID()89Get SSID
Table 4 The Sets of API to Leak Privacy Information
表4 泄露隐私的API
APIFrequencyDescriptionLog66712LogCatputString∕putBoolean∕putInt∕putLong48959Storing dataWrite890Write to filesendTextMessage252Send messageMediaRecorder.start∕MediaRecorder.setVideoSource208Audio
其次，以PLDetect发现的1个具体实例来描述跨APP组件间隐私泄露的细节.PLDetect检测发现com.pdswp.su.smartcalendar和com.xkfop.xhuioa能够合作实现跨APP组件间隐私泄露.其中com.pdswp.su.smartcalendar中用户输入的备忘录内容被com.xkfop.xhuioa劫持，导致备忘录内容被com.xkfop.xhuioa泄露.具体分析为：1)通过com.pdswp.su.smartcalendar.bean.NoteItemBean类中的方法getNote得到备忘录内容，并将备忘录内容赋给putExtra方法的参数；2)通过startActivity传递出去，被com.xkfop.xhuioa中的类com.xkfop.sendService的getIntent方法得到参数android.intent.extra.TEXT的值，并通过sendTextMessage将备忘录内容泄露.
PLDetect在这81个真实应用中共识别和检测到5组跨APP组件间隐私泄露程序.通过统计PLDetect发现的这5组存在跨APP组件间隐私泄露情况的程序包发现其中通过Activity泄露隐私信息的为2个，通过Service泄露隐私信息的为3个，通过Broadcast Receiver泄露隐私信息的为0个.理论上Service组件隐藏在后台运行，不会与用户进行交互，相对来说难以引起用户的注意.实验数据显示，Service组件更容易被恶意软件利用而引发隐私泄露，与理论分析一致.
PLDetect检测到仅有少量的APP组合存在跨APP组件间隐私泄露问题，主要原因在于：360 Market中的APP基本都属于良性应用程序，即使在一般条件下存在ICC漏洞的良性应用程序较多，但是通过2个良性APP配合达到泄露隐私信息的可能性非常低.更多的情况是，APP组合中一个为恶意软件，另外一个则是存在ICC漏洞的良性APP，而据ComDroid研究证明，60%的应用程序至少存在1个以上的ICC漏洞.因此，在真实的用户使用环境中将存在更多的跨APP组件间隐私泄露攻击情况.
4 结论与工作展望
本文设计并实现了一个检测跨APP组件间隐私泄露的自动化工具PLDetect.PLDetect有效地去除了与跨组件间隐私泄露无关的组件，并将虚拟主函数和插桩技术进行了有效结合，解决了在构建CFG时出现的路径爆炸以及代码不连续性问题.最终PLDetect实现了通过静态污点分析技术检测和识别与跨APP组件间隐私泄露相关的路径.实验表明该系统能够有效发现和阻止跨APP组件间隐私泄露问题.
本文重点研究了跨APP组件间隐私泄露的检测和防护方法，实验评估体现了该系统的有效性.其他相关问题，例如对复杂且较少用到的ICC方法的分析、用户体验与隐私泄露之间的权衡等，将在今后的工作中进一步探索.
[1]Tencent. Tencent protection report: Network privacy protection report[OL]. [2018-05-04]. https://m.qq.com/security_lab/news_detail_443.html
[2]Felt A P, Finifter M, Chin E, et al. A survey of mobile malware in the wild[C] //Proc of ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. New York: ACM, 2011: 3-14
[3]Bartel A, Klein J, Traon Y L, et al. Automatically securing permission-based software by reducing the attack surface: An application to Android[C] //Proc of the 27th ACM Int Conf on Automated Software Engineering. Piscataway, NJ: IEEE, 2012: 274-277
[4]DCCI. Android mobile phone privacy security report[OL]. [2018-05-04]. http://www.dcci.com.cn
[5]Arzt S, Rasthofer S, Fritz C, et al. FlowDroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android APPs[C] //Proc of the 35th ACM SIGPLAN Conf on Programming Language Design and Implementation. New York: ACM, 2014: 259-269
[6]Li Li, Bartel A, Klein J, et al. IccTA: Detecting inter-component privacy leaks in Android APPs[C] //Proc of the 37th Int Conf on Software Engineering. Piscataway, NJ: IEEE, 2015: 280-291
[7]Octeau D, Mcdaniel P, Jha S, et al. Effective inter-component communication mapping in Android with Epicc: An essential step towards holistic security analysis[C] //Proc of the 22nd USENIX Conf on Security. Berkeley, CA: USENIX Association, 2013: 543-558
[8]Chin E, Felt A P, Greenwood K, et al. Analyzing inter-application communication in Android[C] //Proc of the 9th Int Conf on Mobile Systems, Applications, and Services. New York: ACM, 2011: 239-252
[9]Mann C, Starostin A. A framework for static detection of privacy leaks in Android applications[C]//Proc of the 27th Annual ACM Symp on Applied Computing. New York: ACM, 2012: 1457-1462
[10]Klieber W, Flynn L, Bhosale A, et al. Android taint flow analysis for APP sets[C] //Proc of the 3rd ACM SIGPLAN Int Workshop on the State of the Art in Java Program Analysis. New York: ACM, 2014: 1-6
[11]Yu Le, Zhang Tao, Luo Xiapu, et al. AutoPPG: Towards automatic generation of privacy policy for Android applications[C] //Proc of ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices. New York: ACM, 2015: 39-50
[12]Rahmati A, Madhyastha H V. Context-specific access control: Conforming permissions with user expectations[C] //Proc of ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices. New York: ACM, 2015: 75-80
[13]Zhang Nan, Yuan Kan, Naveed M, et al. Leave me alone: APP-level protection against runtime information gathering on Android[C] //Proc of the 2015 IEEE Symp on Security and Privacy. Los Alamitos,CA: IEEE Computer Society, 2015: 915-930
[14]Seo J, Kim D, Cho D, et al. FlexDroid: Enforcing in-APP privilege separation in Android[C/OL] //Proc of the 2016 Annual Network and Distributed System Security Symp (NDSS). San Diego, CA: ISOC, 2016 [2018-05-20]. https://dblp.uni-trier.de/db/conf/ndss/ndss2016.html
[15]Sun Mingshen, Wei Tao, Lui John C S. TaintART: A practical multi-level information-flow tracking system for Android runtime[C] //Proc of the 2016 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2016: 331-342
[16]Song Yihang, Hengartner U. PrivacyGuard: A VPN-based platform to detect information leakage on Android devices[C] //Proc of ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices. New York: ACM, 2015: 15-26
[17]Yang Zhemin, Yang Min. LeakMiner: Detect information leakage on Android with static taint analysis[C] //Proc of the 3rd World Congress on Software Engineering (WCSE 2012). Piscataway, NJ: IEEE, 2012: 101-104
[18]Wei Fengguo, Roy S, Ou Xinming, et al. Amandroid: A precise and general inter-component data flow analysis framework for security vetting of Android apps[C] //Proc of the 2014 ACM SIGSAC Conf on Computer and Communi-cations Security. New York: ACM, 2014: 1329-1341
[19]Rasthofer S, Arzt S, Bodden E. A machine-learning approach for classifying and categorizing Android sources and sinks[C/OL] //Proc of the 2014 Annual Network and Distributed System Security Symp. San Diego, CA: ISOC, 2014 [2018-05-20]. https://dblp.uni-trier.de/db/conf/ndss/ndss2014.html
[20]Lam P, Bodden E, Lhoták O, et al. The Soot framework for Java program analysis: A retrospective[C/OL] //Proc of Cetus Users and Compiler Infrastructure Workshop. 2011 [2018-05-20]. https://sable.github.io/soot/resources/lblh11soot.pdf
[21]Bodden E. Inter-procedural data-flow analysis with IFDS/IDE and Soot[C] //Proc of the 1st ACM SIGPLAN Int Workshop on the State of the Art in Java Program Analysis. New York: ACM, 2012: 3-8
