英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料
一种高效，稳健和可扩展的方法
分析互动Android应用程序
Yutaka Tsutano，Shakthi Bachala，Witawas Srisa-an，Gregg Rothermel，Jackson Dinh
计算机科学与工程系
内布拉斯加大学林肯分校
Lincoln，NE 68588，USA
Email: {ytsutano, sbachala, witty, grother, jdinh}@cse.unl.edu
摘要 - 当Android平台上的多个应用程序交互时，可能会发生错误和安全漏洞。软件工程师需要能够分析交互式应用程序来检测这些问题。然而，目前用于执行这种分析的方法并不能扩展到可能需要考虑的应用数量，因此对于应用到真实世界的情况是不切实际的。在本文中，我们将介绍JITANA，这是一个旨在同时分析多个Android应用程序的程序分析框架。通过使用基于类加载器的方法而不是基于编译器的方法（如SOOT），JITANA可以同时分析大量交互式应用程序，执行大型库的按需分析，并有效地分析动态生成的代码。 JITANA的实证研究表明，它比现有的方法更有效率，并且它可以有效和高效地分析最先进的方法所不能处理的包括Facebook，Pokemon Go和Pandora在内的复杂应用程序。
Ⅰ引言
智能移动应用程序平台（如Android）为软件工程师提供了可帮助他们开发GUI并生成框架代码的IDE，以及一个功能强大的应用程序框架，可用于快速创建在Android设备上运行的Java应用程序（应用程序）。 通过这种方式，作为Android提供商的Google可以与外部开发人员协作，构建具有不同功能的应用程序，从而提高Android的价值。 由于这样的原因，Android是目前世界上应用最广泛的智能手机平台。
为确保Android应用程序的可靠性和安全性，工程师和安全分析师需要能够隔离这些应用程序中的故障和安全漏洞。 虽然这些故障和漏洞可能来自各种来源，但很多都是由于应用程序之间的交互而发生的，而这些可能以各种方式存在。 例如，在共谋攻击中，多个应用程序被刻意修改为共同执行恶意行为[1]，[2]。 McAfee Labs最近的一项研究报告称，超过5000个版本的21个Android应用程序包含能够进行数据泄露，文件检查，虚假SMS消息和其他恶意活动的共谋代码[3]。 Memon和Anwar最近的一项研究将合谋列为下一个主要的移动恶意软件威胁[4]。 我们提出的框架JITANA旨在有效地解决这个问题。
又如，Android应用程序可以通过交换消息进行交互[5]，[6]，[7]，并且当交互中涉及的任何应用程序更新时，都可能发生故障。 （最近的一项研究指出，在平台更新之后，23％的Android应用程序行为会有所不同[8]）。这些类型的故障和安全漏洞需要能够分析多个应用程序的程序分析框架，以便可以发现分布式交互。 不幸的是，最广泛使用的Android程序分析工具主要针对单个应用程序运行，因此它们不能直接检测涉及多个应用程序之间交互的故障和漏洞。 尽管如此，试图解决这些问题的研究人员，工程师和分析人员已经基于这些现有工具创建了功能技术[9],[10],[11],[12],[13]。
在用于分析多个互动应用的一种技术中，Li等人 [14]分四个步骤使用EPICC [15]，APKCOMBINER [14]和FlowDroid [16]。 首先，选择两个候选应用程序。 其次，APKCOMBINER用于将两个选定的应用合并到一个应用中。 此步骤的目标是将IAC问题减少为现有ICC分析工具可解决的组件间通信（ICC）问题。 第三，使用当时最先进的ICC分析工具EPICC分析合并的应用程序。 EPICC可以在这种情况下使用，因为所有IAC连接都已在合并的应用中转换为ICC连接。 最后，FlowDroid用于对合并的应用程序执行污点分析以识别可能的恶意ICC连接。
虽然上述方法可以在小规模场景下运行，但它们对于现实世界的使用往往不切实际[17]。 第二部分提供了一个例子，证明上述（最先进的）技术在互动变得相当复杂时无法使用IAC分析一组应用程序。 这是因为合并过程（步骤2）效率低下，易碎且不可扩展。 因此，该技术没有扩展的可能性，无法去分析，甚至是少数真实世界应用程序的故障和漏洞。
这项工作的目标是通过反思一般的程序分析框架设计来克服先前方法中效率低下的根源。 具体而言，我们设计的框架不是设计一次分析一个应用程序的框架，而是可以高效地同时分析多个应用程序，同时保留支持丰富的分析技术所需的所有信息。
在本文中，我们将介绍适用于Android的JITANA（源自“JIT分析”），这是一款能够同时分析多个应用程序的本地支持DEX指令集的程序分析框架。 与用于Java和Android的常用程序分析框架SOOT [18]不同，JITANA的设计不像编译器框架。 相反，它的运行方式类似于任何Java或Android虚拟机中使用的类加载器。 工程师可以加载部分应用程序，整个应用程序或多个应用程序进行静态分析，而无需分解或合并应用程序。 JITANA还支持分析共享系统类和第三方库类。 由于JITANA可以同时分析所有加载的应用程序，因此可以生成跨多个应用程序的重要程序分析图，如数据流图（DFG）和过程间控制流图（ICFG）。
JITANA使用的静态类加载过程具有更多优势。 首先，它以与真实类加载器相同的方式自然地解决了潜在的命名冲突（例如，具有相同名称的两个类）。 其次，它继续保持应用程序之间的明显分离，因此它保留了运行时属性，否则这些运行时属性可能会在合并过程中丢失（例如，Android中的两个应用程序可能是两个独立的进程，因此它们的地址空间不会被隐式共享）。
因为JITANA不会通过检测或合并来修改应用程序，所有应用程序将继续以其惯常的方式运行。相比之下，通过使用APKCOMBINER合并多个应用程序而生成的应用程序不能保证运行[14]。 所以测试它的正确性可能是不可能的。 此外，当许多应用程序合并为一个应用程序时，所产生的应用程序可能很大，使得精确分析技术的使用更加困难。
为了评估JITANA，我们使用三个实验场景来解决三个研究问题（RQ）。
bull; RQ1：JITANA的效率如何？
bull; RQ2：GITANA有多强大？
bull; RQ3：JITANA的可扩展性如何？
在我们的评估中，我们将JITANA方法与合并多个应用程序的方法（如上所述）进行比较。 我们的评估显示，即使在相对简单的分析方案中，JITANA比基于合并的方法效率更高，并且在分析非平凡的实际应用程序组时也更加稳健。 JITANA还可扩展以使用不同数量的已安装应用来有效分析非平凡的真实设备，这是基于合并的方法所无法处理的情况。
在下一节中，我们提供了一个激励的例子。然后我们在第三部分介绍JITANA并在第四部分中对它进行评估。 在第五节对我们的实证结果提供了更多的见解。 第六节则强调了与我们工作有关的先前研究工作，最后在第七节总结。
Ⅱ目的
如第I部分所述，目前分析Android应用程序组与交互相关问题的方法需要将应用程序或其表示集中在一起;然后他们可以通过现有的工具如EPICC，IC3 [19]或SOOT进行分析。 Li等人[14]描述了创建汇总结果的三种方法。第一种方法分析每个应用程序的可能流程，然后结合结果以产生潜在的应用程序间流程。诸如EPICC，IC3和SIFTA [20]等方法属于这一类。这种方法是可扩展的，因为大部分分析工作都是在应用程序内进行的。然而，通过仅考虑分析结果（例如，可能的流程，可识别变化的数据结构），该方法不保留诸如CFG，DFG，ICFG和点对图的各种图（我们将这些图称为分析图）构建为应用内分析的一部分。但是，这些图表对于进行更丰富和更精确的分析（如静态污点或精确的数据流分析）至关重要。
用于创建汇总结果的第二种方法结合了CFG而不是可能的流程。 但是，结合来自多个应用程序的CFG可能会占用大量内存。 解决这个问题的一个选择是以组合形式创建CFG，并将其保存到外部存储（例如，可序列化的对象）。 还应该使用相同的格式（例如，使用相同的工具）生成应用程序的CFG，以便它们可以合并。 迄今为止，我们还没有意识到任何使用这种方法解决IAC分析问题的系统。 Bagheri等人 [21]采取首先生成组件模型，然后将它们组合起来进行分析的方法; 这种方法已被用于检测许可泄漏[21]。 然而，他们的模型仅包含与我们所关心的任务相关的部分分析信息。
创建汇总结果的第三种方法是我们在第一部分中描述的混合方法[14]。同样，该方法使用APKCOMBINER在字节码级别合并一对应用程序，以创建可使用现有ICC分析进行分析的单个应用程序，诸如EPICC [15]等工具或SOOT [18]等通用程序分析框架。 APKCOMBINER解决了两种类型的命名冲突。 当两个应用程序使用通用方法（相同名称，相同代码）时，只保留一个。当两个应用程序使用两个具有相同名称（相同名称，不同代码）的方法时，将重命名一个。
虽然这种方法可能导致产生的应用程序中的代码膨胀，但作者认为，在安全环境中，共谋恶意软件不太可能使用超过几个应用程序，因为用户不太可能拥有所有安装在设备上的应用程序。但是，还有其他的可靠性和安全性上下文可能需要工程师和分析人员一次考虑超过一对应用程序[22]。 例如，分析师可能需要识别安装在可能连接到共享易受攻击组件的设备上的软件组件和应用程序。如果这个易受攻击的组件被大量使用，连接到它的应用程序的数量可能非常大。 因此，APKCOMBINER可能会遇到扩展到应用程序集的问题，因为它一次只能合并一对应用程序。由此产生的应用程序也不能保证运行，所以测试它可能是不可能的。
我们尝试使用APKCOMBINER以成对的方式迭代组合多个应用程序。 例如，要组合四个应用程序（a0，a1，a2和a3），首先组合a0和a1。 然后将得到的应用程序a01与a2组合，并将结果a012与a3组合。 我们发现它无法合并产生的应用程序，例如，a01与另一个应用程序a2：在这种情况下，它会忽略a2而不报告任何错误。
总之，创建汇总分析结果是使用现有程序分析工具分析多个连接的应用程序的方法的必要步骤，该工具可以一次分析一个应用程序。 我们已经讨论了创建这些汇总结果的现有方法; 他们遭受高度复杂性，或未能保存生成的程序分析信息。 为了在控制需要合并的应用数量的同时保留上下文，Li 等人[14]介绍了他们的混合方法。 虽然这种方法可以分析少量连接的应用程序，但我们在第四部分展示了它在用于合并大量应用程序或复杂应用程序时面临可伸缩性和健壮性问题。
III JITANA：分析交互式Android应用程序的框架
为了解决刚刚提到的问题，并为Android提供新的程序分析框架，可以在保存分析图的同时高效并可扩展地分析多个应用程序，现在我们介绍JITANA，一个支持静态和动态程序分析技术的框架。 在这项工作中，我们主要关注的是静态程序分析，但在随后的分析结果讨论中，我们还展示了JITANA如何执行动态分析来处理动态生成的代码。 这使得静态分析更加有效，因为运行时生成的代码也可以包含在分析中。
为了使我们的静态程序分析更高效，我们采用基于类加载器的分析方法，而不是像SOOT这样的工具使用的传统基于编译器的分析方法，这些方法将分析工作集中在应用程序的边界内[23]。 SOOT首先加载应用程序的整个代码并执行分析，包括构建各种程序分析图。通过只关注应用程序中的代码，它不能同时分析多个应用程序。这激励了李等人去[14]开发一个使用SOOT两次的工作流程：一次分析每个应用程序的潜在IAC源和目的地，另一次分析合并的应用程序。而且，基于编译器的方法在处理大型库时常常遇到困难，因为必须分析整个代码库。例如，由Wei等人引入的AMANDROID框架[24]用来构建底层框架和库的模型以促进程序分析。另一方面，我们基于类加载器的静态分析方法以类似于任何Java或Android VM内的实际类加载器的方式加载代码。
图1提供了JITANA框架的架构视图。 我们将JITANA设计为高效的混合程序分析框架，因此它需要能够与Dalvik或Android运行时系统（ART）等语言虚拟机进行交互。 VM接口通过分析控制器提供，该控制器通过Android调试桥（ADB）上的Java调试通信协议（JDWP）连接到Android VM。 这种连接主要用于动态分析，尽管它在程序初始化时动态生成代码的情况下也可以协助进行静态分析（参见第五部分了解我们在本研究中遇到的这一特性的用例）。
该框架中的下一个主要组件是ClassLoader VM（CLVM）。 我们基于Java虚拟机规范[25]实现了CLVM。 存储在文件系统的DEX文件中的类必须由类加载器加载。 ClassLoader的每个实例（它是从抽象类Ljava / lang / ClassLoader继承的Java类）都具有对父类加载器的引用。 当一个类加载器无法找到一个类时，它将该任务委托给它的父类加载器。 在Android虚拟机中，这个过程如算法1所示。我们的方法使用独立的CLVM来基于相同的算法静态加载代码。 通过使用CLVM加载类作为我们的静态分析框架的一部分，随之而来的好处是：
- 类加载器和它加载的类之间的显式关系创建了应用程序中所有类的明确封装。 该属性使我们能够同时加载多个应用程序，同时保持应用程序之间清晰的分离。 这个属性还允许我们的方法自然地解决类命名冲突（即两个具有相同名称的不同类），因为这些类将属于不同的类加载器。
-
由于我们的CLVM的运行方式与实际的类加载器相同，JITANA的动态分析组件可以处理动态生成的代码。 例如，在设备上安装后，我们发现Facebook动态加载多个额外的DEX文件。 我们
全文共25342字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[13679]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
