原文链接：http://people.csail.mit.edu/mjulia/publications/Covert_Communication_in_Mobile_Applications_2015.pdf

原文题目：Covert Communication in Mobile Applications

手机应用中的隐秘通信

Julia Rubin_, Michael I. Gordon_, Nguyen Nguyenx andMartin Rinard_

_Massachusetts Institute of Technology, USA, xGlobalInfoTek, Inc, USA

[email protected], [email protected], [email protected], [email protected]

摘要：这篇文章是研究手机应用中的通信模型。我们分析发现，在GooglePlay的最流行的免费的安卓应用中会产生63%的额外链接。为了以一个有效的方式去检测这些隐秘通信，我们提出了一个高精度和可扩展的静态分析技术，它实现了91%的精确度和63%和以经验为主的判断进行召回比较，并且能在几分钟之内运行完成。此外根据人们的评价，在47个案例中有42个，禁用通过我们分析出的隐秘通信，这些应用程序可以完好的运行，或者只有微不足道的接口受到了干扰。我们推断我们的技术在识别和禁用隐秘通信上是有效的。我们又用这个技术来研究GooglePlay上前500个应用程序的通信模式。

简介

移动应用程序享有几乎永久的连接，并且它们能够通过自己的后台或者第三方服务器交换信息，这篇论文说明这些连接对于用户来说并不能产生有形的价值：因为禁用这些连接仍然能够完整的使用程序的功能。但是，这些隐秘通信的产生会伴随着其他的损失，比如隐私泄露，带宽占用，电量消耗等，并且还会存在一些不被怀疑的链接在设备和远程组织机构当中。事实上，我们观察这些比较流行的应用程序，比如沃尔玛和推特，它们会产生大量的隐秘连接即使在不使用这些应用程序的情况下，在用户无意识的情况下在后台产生这些服务。

这篇论文主要在于区分对于用户功能产生明显影响的显示连接和那些隐藏的或在用户角度不希望产生的隐式连接。我们从分析GooglePlay应用市场中比较受欢迎的链接模型开始。我们发现这些应用程序中存在大量有动机的隐秘连接，我们开发了一个高精度可扩展的静态分析算法来动态的识别这些连接。我们使用我们的算法来进一步的研究这一不好的现象并且报告的我们的发现。下面这些问题来推进我们的研究：

RQ1：这些隐秘连接的发送频率怎么样？我们对GooglePaly前13名的应用程序（推特，沃尔玛，Spotify，潘多拉等）进行了经验式的研究主要是调查它们产生的自然连接。对于这些应用程序触发的每一个连接，我们屏蔽掉这些连接之后动态执行原始的应用程序。

我们考虑应用程序产生的所有可视化内容，包括必要的广告，避免任何与用户信息相

关性的主观判断。也就是说，我们考虑应用程序执行的等价物，如果他们只有上下文

信息有区别，比如说广告信息的内容或者社交网络应用程序里的信息如Twitter。

我们的研究显示63%的链接内容是隐秘的-----禁止这些连接不会明显的影响应用程序的实际功能。有意思的是，这些应用程序里面少于一半的隐秘连接与发起已知的广告和数据分析包一致。因此，只看数据包的信息去区别隐秘和非隐秘连接是不够的。

RQ2：隐秘信息可以被静态的检测吗？详细调查隐秘连接的多种检测案例启发我们去开发一个新奇的静态应用程序可以自动的去检测这些连接。这个在我们分析之后的核心观念就是我们寻找这种案例在连接的成功和失败的结果的都被默默的忽视后，也就是说没有任何信息呈送给用户通知该连接是成功还是失败。

对于一个连接声明，我们分析程序的控制流图的部分来对应直接处理的链接。这包括向前的堆栈处理和失败处理。前者是连接声明后可达成的非异常执行，但限于Android运行时事件触发连接语句处理后。后者所有的遍历方法是调用堆栈所有的链接语句，但是由于连接语句所引起的停靠点异常和所有相关重新抛出的异常除外。连接调用的直接处理是搜索方法调用装置，可以针对一组预处理的API调用，影响用户界面。如果发现一个调用，这个连接就被定义为非隐秘连接。此外，如果这个连接被实时的传送给安卓（引起应用程序的退出），这样的链接调用也被定义为非隐秘连接。除此之外，定义为隐秘性连接。

把一个连接错误分类成隐秘连接的分析有两个原因。第一，它确实不能考虑到由外部直接连接但是确实由本地或远程连接语句引起的用户界面的更新。第二，直接处理自身的语义被应用程序字节代码单独定义，也就是说它不包括本地代码和中间应用程序执行。实验表明这些情况是罕见的，加上该技术的高扩展性，证明是我们设计的合理选择。

RQ3:静态侦测的情况如何？为了评价静态分析技术的准确度，我们在深层次的全面的动态学习的已经制定的事实集合上进行描述。结果显示我们的技术有很高的精确度：93%的隐秘连接被静态分析通过动态学习精确的识别出来。而且即使这个技术被保守设计，偏向高精度超过高召回的，它仍然能在所研究的应用程序里达到61%的精确度。

只有两个连接被错误的识别成隐秘连接，都是由于上面提出的原因。第一个出现是由于用户界面更新-----在这种情况下呈现出可以从GooglePaly下载的额外的应用程序的图标---发生在直接处理的外部连接上。第二个是因为为了呈现通过安装在设备上的Google Ads组件所产生的广告材料，原因是由于直接处理安装在设备上的谷歌服务器的不可延伸的异步的远程掉用通信的链接。

为了进一步的观察这个技术的质量，我们把它应用到附加的GooglePlay最受欢迎的应用程序上。对于这些应用程序，我们禁用通过分析所定义的所有隐秘链接。然后我们雇佣人员去完成可用的评价：我们提供两台完全相同的设备，一个运行原始的应用程序，第一个运行修改后的版本。我们要求他们跟踪和报告在这两台设备上所运行的应用程序的任何可以观察出来的区别。

这个评估结果是鼓舞人心的：有63.8%的应用程序没有明显区别（30种）。25.6%的应用程序（12种），区别与用户功能性无关，比如说广告和装饰性图片。只有10.6%的应用程序（5种）

缺少用户需要的主要功能特性。这个结果表明我们输出的静态分析产品可以剔除很多隐秘通信。

RQ4：在实际的应用程序中隐秘连接所产生的频率是多少，它们最主要的共同来源是什么？我们应用这个分析方法在GooglePlay最后欢迎的500个应用程序上，这个实验表明有46%的连接语句被定义为隐秘连接。隐秘连接最主要的共同来源是Google服务器和各种各样的A&A服务。然而，这不是隐秘连接独有的来源，从这些包里面产生的链接也并不都是隐秘连接。

这项工作的重要性：在[1][2][3]的参考文献里，作者表明“系统应该连续不断的通知用户它们正在做什么”。通过这个原理的激发，我们的工作就是识别用户对应用程序隐藏的功能。这篇文章的研究范围是从受欢迎的应用市场下载应用程序并且被千万用户安装开始。我们相信我们的发现有助于提高移动通信领域的透明性和可信性。

贡献：这篇文章产生以下贡献，

1）它在自动化方式识别隐秘和非隐秘连接中设置了一个新问题。

2）它提议了一个半自动的检测方法用于检测安卓程序中的隐秘连接。这个方法应用在交互式注入连接失败的应用程序中，识别这些注入连接是否明显的影响应用程序否功能。

3）它提供了一些在实际应用程序中比较流行的隐秘连接的经验的证明。特别地，它显示在GooglePlay前13的最流行的应用程序中有63%的链接企图落入这一分类。

4）它提出一个二进制技术在应用程序二进制文件上识别隐秘连接。这项技术有高科扩展性和高精确度：在GooglePlay 47个受欢迎的应用程序中，当屏蔽掉通过该技术所定义的隐秘连接时，63.8%的工作没有产生任何干扰，25.6%的工作产生了非常不重要的影响。这项技术在通过动态确定的真值集合中进行评估时仍然表现出93%的精确度和61%的召回。

5）它对GooglePlay前500的受欢迎的免费的应用程序提出了定量实证和识别它们的共同模型。

Android 里的通信

这一节，我们对安卓程序最本质的通信表现的研究设计进行了描述。现在，我们开始

讨论研究结果：

A．研究的设计

1）连接语句：

表1 列出了我们这篇文章需要考虑的链接语句的基本分类和方法，我们当然也包括了表中列出的子类。

当发生一个连接失败，举个例子，当所需的服务器没能得到或者服务器断开或手机处于飞行模式。这个方法就会抛出一个java.io.IOException异常。因此，为了调查这个连接对于应用程序整体行为的意义所在，我们通过替换连接语句否抛出异常的语句注入一个失败的链接。这种方法通过关闭应用程序本地处理异常的进程，因此要尽可能的减少我们的操作所产生的副作用。

2）应用程序启动

作为我们研究的输入，我们假定应用程序向我们提供apk文件。我们使用dex2jar工具套装从apk中提取jar包文件。我们使用ASM框架实现两个类型的替换。

l 对于产生原始应用程序记录所有连接（表一中列出的）日志的监控替换。

l 指定获得连接语句失败列表的额外输入配置文件的阻塞替换。然后产生一个指定连接语句被抛出异常语句替换的原始应用程序版本。

这个jar文件通过dex2jar工具套被重新安装回apk并且使用标准分布式Java JDK的jarsigner工具写上我们自己的签名。由于我们都知道的重新签名应用程序的副作用，它们的Google Plus APIs身份验证可能会被破坏。因此，用户可能不能注册GooglePlus账户和执行程序内的购买操作。由于这个原因，在我们的分析中回避这样的操作。

TVBLE1CONSIDERED CONNECTION STATEMENTS.

Class or Interface

Method

java.net.URL

java.net.URLConnection org.apache.http.client.HttpClient java.net.Socket

openConnection

connect execute getOutputStream

3）自动的应用程序执行和比较

比较可观察的用户的行为需要动态的执行所分析的应用程序。执行比较的最主要障碍是以可重复的方式复制程序执行的能力。为了克服这一障碍，我们写了一个脚本可以自动的执行每一个程序。

我们用Android’s Monkey tool进行试验，但是由于它会通过应用程序外部所研究的应用程序不能被处理的手势迅速的锁死自身，它不能提供一个合理的详尽的覆

盖。

我们因此手动的记录所期望的应用程序的执行情况，包括记录用户被应用程序要求输入的任何语义，例如，用户名和密码。我们使用安卓getevent来捕获用户和核

心所有的输入事件。我们确保用户手势之间的停顿，假定应用程序相应。我们通过getevent强化了脚本在每一个停顿和延长的序列之间加入了屏幕捕捉命令。

比较应用程序的执行，我们开始于两个并行执行的应用程序的截屏，比较两个图片的外观上的区别，如图1.展示的是沃尔玛应用程序的。我们使用ImageMagick工具去自动却别两张不同的图片。然后我们手动的扫描产生的输出忽略的小部件以动态方式产生的内容填充差异，因为这些小部件将期望区别不同程序之间的运行。也就是说，我们忽视广告信息的精确内容（但并不是它们的整体存在/缺失和位置信息），社交网络的内容，比如推文，设备的状态，比如精确的时间。因此图片1（a）和图片1（b）被视为相似的：它们只有广告信息和状态栏的通知信息不一样。

Fig.1.Visual differents

在所分析案例的一种情况下，我们不得不回复到手工运行程序的执行和比较。这种情况涉及到需要迅速响应时间的视觉游戏的交互，因此程序自动执行不能提供可靠的结果。

4）执行方法

我们分三个阶段完成我们的研究。第一个阶段，我们在Nexus 4，安卓版本为4.4.4的移动设备上安装我们所要分析的应用程序的原始版本。我们手动运行每一个应用程序大约十分钟，探索它们对我们的可见功能。我们的目标是(a)实现足够的覆盖和(b)保持应用程序足够的活跃时间允许任何一个背景数据提取显示在程序交互界面。然而我们避免执行注册Google Plus账户和程序内购买相关操作，原因是重新签名限制了上述提到的操作。我们记录所有捕获触发操作的执行脚本。然后我们重新安装程序重新运行脚本来收集我们要作为基线进行进一步比较的屏幕截图。

第二阶段，我们使用监控转换产生一个新版本的应用程序，记录现存的所有信息和触发链接的声明。我们运行这个使用记录执行脚本和收集连接语句统计数据的版本。

最后一个阶段，我们重复所有的触发的连接语句，逐一的禁用它们，为了评估每一个连接对于用户可见功能的必要性。也就是说，我们在一个列表里按字典顺序排列所有的连接语句，然后使用阻塞转换禁用列表里的第一个连接语句。我们运行使用记录执行脚本和获取程序执行的屏幕截图的改造版本的应用程序。如果禁用该连接语句不影响应用程序的行为，我们就将其标识为"隐秘"。并在随后的迭代中禁用它，然后进行列表中的下一个连接。否则的话，我们标记这个执行的连接为显示的，使它在接下来的迭代序列中保持可用。我们继续这一过程，直到列表中所有的连接都被测试过。

作为最后的质量检测，我们手动检测所有隐式连接被阻塞后的版本程序的执行情况，去检测自动分析每一个可能错过的问题。

5）主题

关于我们研究的主题，我们下载了2014年11月Google Play前20名最受欢迎的可得到的应用程序。我们排除列表里的聊天应用程序，因为我们的评估方法不允许我们评估没有可预测聊天对象的聊天应用程序。我们同样排除基于ASM启动失败的应用程序，很有可能它们使用的语言设计不支持这种架构。剩下的13个应用程序在表二2的第一列列出；它们相应的归档的代码字节码大小在表格的第二列给出。

TABLE II. ANALYZEDAPPLICATION

B.结果

研究的定量结果在表格2呈现出。3,4列仅仅展示出小数量的重新编码的事实上是动态触发的连接语句。一些非触发式的语句的相应的执行路径通过我们的动态程序遍历是检测不到的。然而，大多数的连接语句包含在应用程序所引用的第三方库中，例如，Google和Facebook提供给移动开发者的服务器，和各种各样的A&A数据库。这些数据库经常被应用程序部分的使用，这可以解释不完全覆盖性。

一个有趣的案例是Facebook应用程序（表2的第5行），排除Facebook，因为它大部分的应用程序代码是在运行时态加载APK文件资源。我们的分析无法遍历这些自定义的资源，因此我们排除了这一应用程序的进一步分析，并指出，在应用程序中唯一的三个连接语句并没有被触发。我们同样排除Candy Crush Saga 应用程序（表2第8行）的进一步分析，因为它没有表现出任何隐秘连接。

1）触发语句否分类

确定这些隐秘连接的原始目的是一个不平凡的任务，因为它们的本质，它们不表现出任何可观察的行为。由于混淆，几乎没有语义表明可以从这些应用程序的二进制文件中手动分析出它们的目的。企图查明这些隐秘连接的一点本质，我们检测数据包和类名也执行堆栈跟踪。我们也检测这些连接相应的数据流量，通过通过使用代理的路由通信，嗅探数据，解密套接协议层的编码，如果需要的话。

我们发现52个连接中有只有22个（43%）来自于A&A数据库，如表的最后一列所示。另外11个（21%）连接也是由于A&A内容需要产生的。然而，它们要么来自于特殊的数据包，要么来自于不能被立即连接到A&A的第三方数据库。举例，沃尔玛应用程序从com/walmartlabs/analytics/数据包触发一个隐式连接，这似乎是一个专有的分析服务。

收集关于应用程序性能的信息,分析服务崩溃和使用数据,以及应用程序内的用户执行的操作。虽然这些信息对于开发人员有一个明确的价值，但是它却没有明显的描述指定的性质和收集呈献给用户的频繁数据。事实上，许多应用程序在在活动之前就开始搜集数据信息。比如，推特，沃尔玛，潘多拉在手机整个运行时间只要手机一启动就开始定期收集信息，甚至在程序本身从来没有被使用过的情况下。在大多数情况下，用户除非卸载程序否则不能选择停止这些数据的分享。

除了A&A，多种应用程序向自身或第三方服务器传送数据，不会在应用程序上产生任何明显的行为。比如，Twitter使用隐秘链接手机视频和伴随用户发送的推文的富媒体附件。GOKeyboard 应用程序通过隐秘连接向launchermsg.3g.cn发送大量的ID，它也会向nextbrowser.goforandroid.com发送一些我们不能破译的加密数据。潘多拉和Spotify音乐播放器都使用Facebook的社交网络服务，发送应用程序的使用信息。另一个例子，沃尔玛应用程序合并Red Laser（一个专门比较价格的eBay公司）提供的条形码扫描库。这个库可以使应用程序发送扫面的条形码信息到data.redlaser.com服务器。然而阻塞这一信息的发送并不影响扫描功能。

回答RQ1：我们推断隐秘连接在实际使用的应用程序中经常产生：有62.9%的触发链接语句可以被定义为隐秘连接。

2）经验教训

如表2的最后一列所示，只有43%的隐蔽连接起源于我们所知道的A&A数据库。因此仅仅通过考虑包名的模式区别隐秘和非隐秘连接是无效的。而且，很多恶意的应用程序故意通过看起来合法和良性的包名隐藏它们的字节码数据。我们推断一个用于识别隐秘连接的更精致的技术是急需的。

为了对隐秘连接的实现模式获得更多的见解，我们手动的研究所要分析的应用程序否的二进制文件。我们发现，无论这些连接成功或是失败都不会对用户产生视觉上的告知。对于失败的链接所触发的异常经常被捕获或者被该问题连接悄悄忽略，或者更普遍的这个异常被向上传播的调用堆栈然后被另一个调用方法忽略。在一些情况下，错误或警告的信息会被写到Android日志文件里。然而这些信息基本上是被开发者使用而不是终端用户。

回答RQ2：我们推测隐秘连接可以通过连接语句成功和失败的用户界面元素的更新的检测中识别出来。这些用户界面更新的确实象征着用户对于通信的成功失败的结果是无意识的操作的连接是隐秘的。

静态分析分类连接

在这一部分，我们将描述我们试图分类连接的静态分析算法。Android应用程序是JAVA作为一系列的外部事件处理程序开发的，如按钮点击和应用程序退出。给定一个安卓应用程序，静态分析分类每一个可能唤醒隐秘或非隐秘连接调用的语句。我们一通过分析假设的一个给定的精确的隐秘和非隐秘的连接开始。

定义（隐秘和非隐秘连接）

对于一个连接语句s,s满足下述的至少一个条件就被定义为非隐秘连接。

1) 连接失败时用户界面提示失败： 当s触发一个异常e,在进行故障处理s的e的期间，用户会通过用户界面得到失败提示。

2) 连接失败时程序退出：当s触发一个异常e,由于传播异常e恢复到安卓运行时，程序可能会停止执行。

3) 连接成功时用户界面提示：当s连接成功时，它会在(a)应用程序处理下一个外部事件或者(b)除了失败处理s外继续处理之前，在用户界面生成一个可能的修饰。

相反的，一个隐秘连接不满足任何一种情况。

故障处理在段落Section III-B精确给出定义。直观的，连接语句s的异常类型e的故障处理是处理e和任何通过处理e触发的故障（通过再次抛出异常）的计算路径。当e触发是所有异常被处理完并回到正常的操作故障处理结束。

接下来，我们讨论怎样计算以安卓应用程序中每个调用表达式为目标的表示可能的方法的静态调用图。然后我们在这张图上讨论我们的分析。对于每一个连接。分析由三部组成：故障处理器分析，成功前进分析和成功后退分析。

表1列出了被视为连接调用的目标方法。被视为影响用户界面的目标方法在表3（也

包含所有的重载方法）中列出。

A.对安卓应用程序构建一个准确的调用图

对安卓应用程序的静态分析是出了名的困难，因为安卓实时的动态和复杂性的本质和API；精确地，全面的分析有着错失动态程序行为的高风险而且不能扩展到现实世界真正使用的应用程序当中。静态分析要么模拟安卓执行环境要么对可能的程序动态行为做出解释都是保守的分析选择；否则的话，一些运行时的动态行为就可能会被

忽视。

我们的分析比较接近应用程序运行时的行为，不接近可能是隐秘的连接调用。这个分析的优先次序是高精确性超过高召回，原因是我们不想阻挡非隐蔽通信所执行的连接调用。我们的分析使用类层次结构分析（CHA）去建立一个通过内部程序，数据流实现的精致的调用图，作为稍后讨论。大量的高精度的实验之后，虽然脆弱，但针对于分析技术而言，这个分析组合给了我们分析任务的最好性能。我们的分析在Soot分析框架中实现，使用DroidSafe提供的安卓API模型。我们的分析在应用程序是Jimple中间语言描述的程序上性能表现是较低的。

为了计算调用图，我们通过DroidSafe安卓设备接口（ADI）增加应用程序代码。这个安卓设备接口是基于JAVA的安卓运行模型和API。它试图表达运行时一般使用类的完整的运行环境语义。我们的调用图从每一个可能成为安卓运行时目标的应用程序方法开始构建，也就是，应用程序的事件处理器方法。调用图形构建并不能遍历安卓API方法。像这样，这个调用图实际上是一个树形图标，根节点是应用程序的事件处理器，每个图表包含只有应用程序定义的方法。然而，我们发现说明API调用是直接调用回应用程序的调用是必要的，举例，Thread.start()。我们通过用API调用可能引起的直接调用应用程序的方法（比如Thread.run()）来替换API调用来实现。这个调用图通过下面的方针来增强说明反射方法调用。当一个反射调用被发现，我们添加以所有相同包域作为调用者的所有方法为目标的图标（例如，com.google, com .facebook）。这个边缘被下述策略修剪：如果参数的数目和参数类型可以使用定义分析定义，我们限制边缘仅仅以有相同数目或类型的参数为目标。这种策略在实际中效果很好，并能积极地反映语义。

B.故障处理器分析

故障分析决定在一个连接异常时是否能改变UI或退出程序。我们组织静态故障处理分析在调用图上作为一个循环遍历。对所有应用程序调用迭代器分析分别每个可能成为应用程序连接调用的目标的语句和通信失败显示的异常。

从概念上讲，s上的异常e的故障处理被定义为一片指令。在这一部分中，所有的语句可以从可以处理异常e的catch块中获得。然后，对于在这一部分内每一个可获得的语句可以抛出一个f类型的异常，我们递归的向这部分中添加所有可以从可以动态的处理f catch块中得到的语句。接下来，我们动态处理这些可以抛出一个异常的新添加的语句。在这个过程中，安卓API方法是不被考虑的，搜索处理器不会传送到安卓实时环境中。

分析从图片2列出的FINDCATCHES步骤开始。它使用了一些辅助步骤，及特别性的一个在图片4中列出，完整的列表可以在参考文献[19]中找到。FINDCATCHES分别被每一个连接语句和一对异常调用。进程参数也包括stmt的封闭方法（甲基）；当前的访问语句和异常（正在访问的）初始化清空；当向前搜索调用图（堆栈）路径的时候，调用堆栈建立，初始化清空。

对于stmt和ex，程序首先咨询stmt正在包含的方法去找一个合适的catch（第四行）。如果ex并没有在本地捕获，meth是一个时间处理器（从安卓运行时调用的,然后我们保守计算，stmt可能造成应用程序退出，然后将其添加到非隐秘集合（6-9行）。否则的话这个分析方法就会递归访问所有直接调用的方法去发现可以捕捉调用图边缘的catch块（10-21行），正如稍后所讨论的。

如果一个兼容的处理器在本地本发现（24-26行），这个分析调用步骤ANALYZEHANDLER，图3，兼容块的语句。这个步骤分析可获得的处理器的语句。如果一个可以触发UI方法的调用是也遇到的，这个语句自从故障处理影响用户界面后开始被处理器分析为非隐秘的（图3 7-9行）。如果分析发现调用本地方法，我们假设这个方法会抛出定义抛出的所有异常，处理器会对每一个已经声明抛出的异常产卵式的生成FINDCATCHES实例（10-13行）。当这个分析发现一个应用程序方法的调用，它会推进当前的语句和方法到一个堆栈上，为这些新方法递归的调用自身去分析新方法的语句（14-20行）。

如果分析发现一个throw语句，它会产生一个新的FINDCATCHES分析去发现所有可能的每一个重新抛出异常的处理器（22-42行）。朝向这个的结束，它首先计算本地连锁定义获得的异常类型。在第23-34行，分析认为所有本地达到被抛出价值的def。如果一个分配的语句到达throw，那么就把这个类型添加到可能重新抛出异常的类型。若果捕获到一个异常参考c，达到throw语句，然后与c catch块有关的try块，然后就会被所有可能被抛出的受检测的异常分析。这个通过GETPOSSIBLETHROWNTYPES调用ANALYZEHANDLER的29行执行。如果只有配置和捕获到的异常达到抛出价值，这个处理器分析就会排卵式产生FINDCATCHES实例去分析故障处理。

一个成对的方法调用语句的堆栈和目标方法是被保持的。这个方法使用堆栈在FINDCATCHES中在一个方法调用被处理器进一步执行到堆栈之后集中处理器搜索（图2 的11-15行）。当我们初始化一个连接调用的分析，这个堆栈是空的，并且FINDCATCHES分析去搜索连接语句异常处理器所有可能的堆栈（包含方法的前身）。然而，一旦一个处理器被发现，这个处理器调用一个以可能重新抛出异常告终的方法序列，这个方法的序列定义了唯一可以寻找重新抛出异常处理器的堆栈（11行）。

这个堆栈为了每一个可达成处理器代码的方法调用在ANALYZEHANDLER的16行被推进。在处理器在FINDCATCHES中寻找执行堆栈期间，这个堆栈被咨询去引导在11行中搜索，只访问在最前面的堆栈的边缘。当在FINDCATCHES 的15行的当前方法中访问一个调用方法时，这个堆栈被取出。

C.成功度分析

对于连接语句stmt，在失败处理和堆栈处理stmt的异常期间，没有用户界面调用被唤醒，这个分析就继续沿着stmt的成功路径。这个成功分析决定如果在连接成功之后，在控制回到安卓运行时环境之前，在控制合并之前有任何一个用户界面修改，回到失败处理路径。

这里我们总结了紧闭在方法meth内的连接调用stmt的成功分析通过呈现两个高水平的在构思阶段的描述：

1)成功正向分析

在stmt之后的语句可获得的代码被用来寻找一个连接调用。这是通过遍历起始于stmt和跟随方法通过调用图表达式的过程控制流图（CFG）中的所有路径完成的。在分析CFG时，我们即跟随正常的也跟随异常的控制路径。

2)成功逆向分析

对于所有的方法，调用，在调用图中从调用到meth的一个路径，在失败处理分析中寻找的调用器，检查所有影响用户界面调用的调用器的语句。这个有从UI调用的stmt的meth上遍历调用图的效果，在事件处理器停止，在一个路径上，一旦stmt的异常被处理就会停止。

如果成功定向和逆向分析都没有发现任何一个影响用户界面的调用，这个连接调用就被定义为隐秘的。

D.设计讨论

我们静态分析的直觉是，非隐秘的连接无论成功与失败都会影响用户界面。从第二段的研究中得到的另一个观察是，正常的连接过程经常在异常和非异常控制流路径合并时结束。因此，成功逆向分析只能测试被失败分析算法分析的方法。而且，我们使用执行时间处理程序去限制连接呼叫处理。

实验

我们从评估我们的静态分析质量的技术开始。然后我们使用这个技术去收集Google Play中前500个最受欢迎的应用程序的隐秘连接的普遍模型的信息。

A.静态分析的质量

我们首先，在我们深层次的案例研究已经确定的真实集合中（见第二部分），评价我们技术的准确度，也就是查准率和查全率。然后，通过一个可用的评价，在运行一个当所有被定义为隐秘的连接都被禁用的应用程序的版本时，我们评价用户实验。

1）准确度

对于准确度的评估，我们再一次看一下表2的应用程序列表，排除Facebook和

CandyCrush因为这些应用程序没有显示出任何隐秘连接。我们限制静态分析对那些实际上是动态触发的结果报告，因为只有这些我们已经建立了比较正确的结果。我们评估这个结果，我们单独的对每一个应用程序用下面的权值对所有的应用程序取平均值来评估这个结果：

l 查准率：通过技术被定义为隐秘连接的分数

l 查全率：我们期望被定义为隐蔽连接也就是说在动态的连接当中被标记为隐秘的连接的分数。

l 执行时间：此处列出在什么样的设备配置上测出的执行时间。

这个实验的结果总结概括在表4。表的第二列显示我们分析的整体平均查准率为93.2%。除了两个隐秘连接分析都正确的识别出来了。第一个，在com.devuni.flashlight里，负责呈现应用程序可以从Google Play下载的扩展标致。这个失败的原因在于这个标致的用户界面更新在成功和失败的统一的路径之后，因此被我们的研究错过了。

第二个分类错误的连接在net.zedge.android里，负责呈现广告材料，属于应用程序A&A服务包的com.mopub.mobileads。

这个数据库依赖安装在相同设备上的Google服务的RPC通信。我们的分析目的并不在于追踪不同应用程序之间和设备上的服务之间的程序见的通信，因此这个结果是错误是积极的。

虽然我们的分析是保守设计的，它能正确识别在实证研究中被确定为隐秘连接（表4的第三列）的61.5%。我们不能实现更高的查全率的主要原因是：（1）保守的，虽然分析切实可行，与连接调用有关的直接处理定义和（2）保守的调用图形构建，特别的，w.r.t.反射。这样的解决方案与我们提供可操作的结果的目标对准，虽然在近似的水平之下他们也是安全的。

最后，这个分析是高效率的，即使在大量的应用程序之下在几分钟内就能运行完，正如表4 的最后一列所展示的。

2）可用性评估

为了检测我们的技术是否能够提供可靠的结果，我们挑选了2015年1月和5月GooglePlay前500的最受欢迎的免费的应用程序中都出现的100个应用程序。我们安装每一个应用程序的原始版本在Nexus，安卓版本为4.4.4的设备上。在另一个同样的设备上，我们安装使用块替换（见第二部分）使通过我们的静态分析定义为隐秘连接失效的应用程序。

我们招募了两名人工，他们都是经验丰富的软件开发人员，也是这篇论文的作者之一。每一个人给一个安装原始版本的设备和一个安装修改后版本的应用程序的设备。我们要求他们在10分钟内在两台设备上同时执行同样的应用程序，然后记录在执行期间所能观察到的不同。和第二部分的实验描述相似，我们的目标是确保足够的覆盖范围和应用程序界面呈现后台提取的数据。我们避免参与者注册Google Plus账户和在Google Play store执行程序内购买，因为这些操作不被重签名的应用程序支持（如第二部分讨论的那样）。

TABLEIV． COMPARISON WRTH THE MANUALLY ESTABLISHEDRESULTS

为了以一个可靠的方式分析实验结果，我们排除了不可操作的（不能以原始版本或必要的支付方式继续运行）14个应用程序；基于ASM的17个应用程序启动失败或由于重签名的问题不能运行；2个Google应用程序我们不能重新安装在一个设备上；5个聊天应用程序；4个不包含连接语句或没有检测到隐秘连接语句的应用程序和11个在应用程序执行期间没有触发隐秘连接的应用程序。

其余的47个应用程序的信息在下面列出。

相同的：30（63.8%）。我们的参与者没有发现任何可观察到的不同在这30个应用程序中，这表明通过静态分析被定义为隐秘连接语句对应用程序的用户可见行为不产生任何影响。

缺失广告：9（19.2%）。在9个案例中广告信息缺失，和上面描述的Zedge例的原因一样。

缺少次要功能：3（6.4%）。参与者观察被视为次要功能的性能的缺失：两个案例缺少图标，Talkingben和我们之前讨论过的Flashlight；一个案例不能为杀毒软件创建一个账户，但是应用程序核心的功能是完整无缺的。

缺少必要的功能：5（10.6%）。只有5个应用程序缺少必要的功能：Battery Saver,Spider-Man andMinion Rush games, Microsoft Office Mobileand PicsArt Photo Studio。我们推测最后一个案例与重签名的问题有关。其他情况源于我们静态分析技术的限制：在程序内执行分析，忽视状态性的通信和仅寻找在成功和失败路径统一之前的产生的语句的页面的更新。我们相信这些案例是小数量的，加上我们分析算法的高扩展性，证明是很好的选择。

平均看来，每个应用程序在运行时触发2.6个（最小1；最大9；中数：2）隐秘连接。由于每个语句可能被多次执行，我们也统计了这些语句动态调用的所有实例，得到每个应用程序隐秘连接调用的实例是299（最小1；最大4011；中数11）。这高的平均数字是由于应用程序一旦安装就持续在后台运行，并且事实证明企图网络通信。这些应用程序的例子有com.cleanmaster.mguard 和com.ijinshan.kbatterydoctoren.。

回答问题3：我们推断这篇论文中提出的静态分析方法可以应用于隐秘连接准确的检测。这个技术是精确的，高可扩展性的并且提供在绝大多数情况下可以用来直接禁用隐秘连接的可操作的输出。

B.在外部的隐秘连接

我们接下来把我们的技术应用到2015年1月从Google Play应用市场下载的500个最受欢迎的应用程序中。通过考虑大数据集合，我们的目标是调查隐秘连接产生的频率和它们共同的来源。

我们的分析揭露了应用程序所有的连接中有46.2%的连接被视为隐秘连接（8,539/18,480）。Z这些结果，被证实有93%的查准率和61%的查全率，和我们第二部分实验研究所描述的一致。

表5显示了产生隐秘连接的前10名的包。由于我们分析的免费的应用程序频繁的使用第三方的数据包，然后合计这500个应用程序的数字，并不惊讶谷歌服务器，gaming，和A&A服务器在列表的顶部，应用程序使用这些包的数字在表5的第三列中展示出。比较令人惊讶的是com.gameloft包（表5第二行），虽然它只是相同公司发布的17个不同的移动应用程序的一部分，这些游戏软件隐秘连接的数字是值得引人注意的。

TABLEV. TOP 10 COVERT COMMUNICATION CALLERS

表5的最后一列展示了在相应的包中隐秘连接占所有连接的百分比。这些数字在24%到87%之间不等，再一次，我们在第二部分中初步观察，连接的来源不能用来推断对应用程序行为的影响。

回答问题4，我们推断隐秘连接在真实的应用程序中是普遍的。这些连接不是A&A包

所独有，而且这个包所产生的连接并不都是隐秘的。

有效性的限制和威胁

1)实证研究

我们的实证研究有一个动态的本质，因此遭受众所周知的动态分析的限制：它不能提供一个应用程序行为的详尽的探索。虽然我们努力覆盖所有应用程序对我们可见的功能性，我们也有可能错过一些行为，举例来说，这些系统之下是触发设置与我们不同。为了使结果的意外性最小化，我们在一台相同的设备上执行我们所有的动态试验，在相同的位置和时间接近对方。我们也会自动地执行我们的脚本去比较在相同的场景和设置下不同的版本的行为的不同。我仅仅对这些相似运行的比较结果做报告。

然而，由于动态分析的限制，我们可能遭遇假阳性的结果：一个我们分类为隐秘的连接语句可能会对程序的一个位置部分产生影响。同时，我们可能也会有假阴性的结果：改变用户界面的可能起源于非确定性的应用程序自身而不是通信的缺少。而且，通过集中于个体的连接语句，我们不能区别在多个应用程序之间相同代码形式的语句的通信。我们因此保守的认为只要一个连接至少对一个用户行为是非隐秘的就视为非隐秘连接。为识别隐秘连接探索更精准的技术可能成为我们未来工作的一个课题。

最后，我们的研究仅仅包含一些数量有限的科目，所以这些结果不能推广到其他的应用程序中。我们试图通过不偏执的选择应用程序而是从GooglePlay中选择最受欢迎的应用程序来减轻这一问题，然后保证在所有的应用程序中观察相同的通信模型。

2)检测隐秘连接的静态技术

我们的技术认为隐秘状态的通信切换通信连接的状态，但是不向用户呈现任何信息。在很多情况下，静态的检测这些通信是不可能的，因为代码的执行目标是不可知和不可得的。因为同样的原因，在这项工作中，我们不考虑安装在相同设备上的PRC通信。

而且，我寻找通信的分析算法是以直接的方式影响应用程序的UI而不是通过其他来源间接地影响。在这些情况中扩展分析算法，维护自身的可扩展性和精确度，是我们接下来工作的另一个主题。

我们静态的定义的一些隐秘连接可能永远不会被动态的触发，这些连接的一大部分都是起源于第三方库，它们包含在应用程序中，却只有一部分被使用。因此，由于这些代码可能会被其他的应用程序所使用，所以分析它们仍然是有意义的。

结论

隐秘通信会损害设备操作的透明性，默默地消耗设备资源，最后会破坏用户对移动设备应用程序生态系统的信任度。我们的分析显示隐秘连接在Google Play最流行的安卓应用程序中是很普遍的。我们的成果显示我们的分析可有有效的识别和取出隐秘连接并且促进更加透明和可靠的应用程序的发展。

参考文献

[1] J. Nielsen and R. Molich, “Heuristic Evaluation ofUser Interfaces,” inProc. of the International Conference on Human Factors in CmputingSystems (CHI’90), 1990, pp. 249–256.

[2] M. H. Blackmon, P. G. Polson, M. Kitajima, and C. H.Lewis,“Cognitive Walkthrough for the Web,” in Proc. of the International Conferenceon Human Factors in Computing Systems (CHI’02), 2002,pp. 463–470.

[3] A. J. Ko and X. Zhang, “FeedLack Detects MissingFeedback in Web Applications,” in Proc. of the International Conference onHuman Factors in Computing Systems (CHI’11), 2011, pp. 2177–2186.

[4] dex2jar, “https://code.google.com/p/dex2jar/.”

[5] ASM Java Bytecode Manipulation and AnalysisFramework,“http://asm.ow2.org/.”

[6] Google APIs Console Help,“https://developers.google.com/console/help.”

[7] Android’s UI/Application Exerciseronkey,“http://developer.android.com/tools/help/monkey.html.”

[8] Android Getevent Tool,“https://source.android.com/devices/input/getevent.html.”

[9] P. Hornyack, S. Han, J. Jung, S. Schechter, and D.Wetherall, “These Aren’t the Droids You’re Looking for: Retrofitting Android toProtect Data from Imperious Applications,” in Proc. of the 18th ACM Conference onComputer and Communications Security (CCS’11), 2011, pp.639–652.

[10] ImageMagick Compare Tool,“http://www.imagemagick.org/script/compare.php.”

[11] Charles – an HTTP proxy / HTTP monitor / ReverseProxy,“http://www.charlesproxy.com/.”

[12] Facebook’s Social Graph, https://developers.facebook.com/docs/graphapi.

[13] Red Laser – an eBay company, “http://redlaser.com/.”

[14] Y. Zhou and X. Jiang, “Dissecting Android Malware:Characterization and Evolution,” in Proc. of the IEEE Symposium on Security andPrivacy (SP’12), 2012, pp. 95–109.

[15] J. Dean, D. Grove, and C. Chambers, “Optimization ofObject-Oriented Programs Using Static Class Hierarchy Analysis,” in Proc. ofthe 9^th European Conference on Object-Oriented Programming(ECOOP’95), 1995.

[16] R. Vall´ee-Rai, E. Gagnon, L. J. Hendren, P. Lam, P.Pominville, and V. Sundaresan, “Optimizing Java Bytecode Using the Soot Framework:Is It Feasible?” in Proc. of the 9th International Conference on Compiler Construction(CC’00), 2000, pp. 18–34.

[17] M. I. Gordon, D. Kim, J. Perkins, L. Gilham, N.Nguyen, and M. Rinard, “Information Flow Analysis of Android Applications inDroidSafe,” in Proc. of the 22nd Annual Network and Distributed System SecuritySymposium (NDSS’15), 2015.

[18] A. Aho, M. Lam, R. Sethi, and J. Ullman, Compilers:Principles,Techniques, and Tools, 2nd ed. Addison Wesley, 2006.

[19] Helper Function Definitions for the ConnectionAnalysis,“http://people.csail.mit.edu/mjulia/covert-helpers.pdf.”

[20] J. Huang, X. Zhang, L. Tan, P. Wang, and B. Liang,“AsDroid: Detecting Stealthy Behaviors in Android Applications by UserInterface and Program Behavior Contradiction,” in Proc. of the 36thInternational Conference on Software Engineering (ICSE’14), 2014.

[21] A. Gorla, I. Tavecchia, F. Gross, and A. Zeller,“Checking App Behavior against App Descriptions,” in Proc. of the 36thInternational Conference on Software Engineering (ICSE’14), 2014.

[22] K. O. Elish, D. D. Yao, and B. G. Ryder,“User-Centric Dependence Analysis for Identifying Malicious Mobile Apps,” inProc. of the IEEE Mobile Security Technologies Workshop (MoST’12), 2012.

[23] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung,P. McDaniel, and A. N. Sheth, “TaintDroid: An Information-flow Tracking System forRealtime Privacy Monitoring on Smartphones,” in Proc. of the 9^th USENIXConference on Operating Systems Design and Implementation (OSDI’10), 2010, pp.1–6.

[24] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A.Bartel, J. Klein, Y. L. Traon, D. Octeau, and P. McDaniel, “FlowDroid: PreciseContext, Flow, Field, Object-sensitive and Lifecycle-aware Taint Analysis forAndroid Apps,” in Proc. of the ACM SIGPLAN Conference on Programming LanguageDesign and Implementation (PLDI’14), 2014.

[25] W. Klieber, L. Flynn, A. Bhosale, L. Jia, and L.Bauer, “Android Taint Flow Analysis for App Sets,” in Proc. of the 3rd ACMSIGPLAN International Workshop on the State of the Art in Java Program Analysis(SOAP’14), 2014.

[26] L. Li, A. Bartel, J. Klein, Y. L. Traon, S. Arzt, S.Rasthofer, E. Bodden, D. Octeau, and P. McDaniel, “I Know What Leaked in YourPocket: Uncovering Privacy Leaks on Android Apps with Static Taint Analysis,” arXivComputing Research Repository (CoRR), vol. abs/1404.7431,2014.

[27] V. Avdiienko, K. Kuznetsov, A. Gorla, A. Zeller, S.Arzt, S. Rasthofer, and E. Bodden, “Mining Apps for Abnormal Usage of SensitiveData,”in Proc. of the 37th International Conference on SoftwareEngineering(ICSE’15), 2015.

[28] W. Yang, X. Xiao, B. Andow, S. Li, T. Xie, and W.Enck, “AppContext:Differentiating Malicious and Benign Mobile App BehaviorUnderContexts,” in Proc. of the 37th International Conference on SoftwareEngineering(ICSE’15), 2015.

[29] F. Shen, N. Vishnubhotla, C. Todarka, M. Arora, B.Dhandapani, E. J.Lehner, S. Y. Ko, and L. Ziarek, “Information Flows as aPermission Mechanism,” in Proc. of the ACM/IEEE International ConferenceonAutomated Software Engineering (ASE’14), 2014.

[30] Byeong-Mo Chang, Jang-Wu Jo, and Soon Hee Her,“Visualization of Exception Propagation for Java Using Static Analysis,” inProc. ofthe 2nd IEEE International Workshop on Source Code Analysis and Manipulation,2002, pp. 173–182.

[31] B.-M. Chang, J.-W. Jo, K. Yi, and K.-M. Choe,“Interprocedural Exception Analysis for Java,” in Proc. of the 2001 ACMSymposium on Applied Computing (SAC’01), 2001, pp. 620–625.

[32] C. Fu, A. Milanova, B. G. Ryder, and D. G.Wonnacott, “Robustness Testing of Java Server Applications,” IEEE Transactionson Software Engineering, vol. 31, pp. 292–311, 2005.

[33] C. Fu and B. G. Ryder, “Exception-Chain Analysis:Revealing Exception Handling Architecture in Java Server Applications,” inProc. of the International Conference on Software Engineering (ICSE’07), 2007,pp.230–239.

[34] J. W. Jo, B. M. Chang, K. Yi, and K. M. Choe, “AnUncaught Exception Analysis for Java,” Journal of Systems and Software, vol.72, pp. 59–69, 2004.

[35] X. Qiu, L. Zhang, and X. Lian, “Static Analysis forJava Exception Propagation Structure,” in Proc. of the 2010 IEEE InternationalConference on Progress in Informatics and Computing (PIC’10), vol. 2, 2010, pp.1040–1046.

[36] G. Kastrinis and Y. Smaragdakis, “Efficient andEffective Handling of Exceptions in Java Points-to Analysis,” in Proc. of the22nd International Conference on Compiler Construction (CC’13), 2013, pp.41–60.

Ichimaru_Gin_

发布了25 篇原创文章 · 获赞 4 · 访问量 5万+

私信关注

Covert Communication in Mobile Applications 手机应用中的隐秘通信