原标题：一个机器人家族： 通过静态和动态分析，分析基于行为模型的安卓恶意软件检测

  随着智能手机在我们的日常生活中发挥着逐渐重要的作用，为移动生态系统设计的应用程序（APP）的数量也在激增。这些应用程序的设计是为满足不同的客户的真实需求，如银行、通信、社交网络等，因此经常处理敏感信息。因此，慢慢的变多的网络犯罪分子瞄准了移动生态系统，设计和发布恶意的应用程序，窃取信息或对设备的所有者造成了严重的伤害。为了对付他们，一些基于静态或动态分析的技术已被用来为安卓恶意软件建模并建立检测工具。然而，我们对哪种分析方法在哪些情况下最有效还缺乏充分的了解。

  具体来说，我们以MAMADROID为基础，这是一个最先进的检测系统，依靠静态分析，从抽象的API调用序列中创建行为模型。 为了将其移植到动态分析中，我们修改了CHIMP，这是一个最近提出的用于众包应用测试的人类输入的平台，以便从在CHIMP虚拟设备上执行应用时产生的痕迹中提取API调用的序列。我们称这个系统为AUNTIEDROID，并利用自动（Monkey）和用户生成的输入来实例化它。我们得知，结合静态和动态分析可以产生最好的性能，其F值达到0.92。我们还表明，静态分析至少和动态分析一样有效，这取决于应用程序在执行过程中是如何被刺激的，并探究了不同方法之间不一致的错误分类的原因。最后，我们研究了动态代码加载的普遍性，这构成了基于静态分析的工具的一个可能的限制。

  如今，个人依赖智能移动电子设备进行大量的社交、生产力和工作活动。这不可避免地使他们成为网络犯罪分子的重要目标，因此，每年有越来越多的恶意软件被开发出来，专门针对移动操作系统[10]，鉴于其市场份额[34]，尤其是安卓系统。 与桌面恶意软件相比，恶意应用程序构成了新的威胁，因为攻击者可能能够，例如，击败银行系统的双因素认证

  因此，研究界提出了许多技术来检测和阻止基于静态或动态分析的Android恶意软件。对于前者，代码从apk中恢复出来，并提取特征来训练机器学习分类器。对于后者，应用程序在受控环境中执行，通常是在模拟器或虚拟设备上，通过真人或自动输入发生器，如Monkey[18]。 当然，这两种方法都不是没有限制的。 例如，从应用程序请求的权限中提取特征的静态分析方法往往会产生很高的假阳性率，因为良性的应用程序实际上可能需要请求被归类为危险的权限[15]，而根据API调用频率进行分类的系统[1]往往需要不断重新训练。此外，重新检测和动态代码加载可以用来逃避基于静态分析的检测。另一方面，动态分析的准确性在很大程度上取决于恶意代码是否在测试执行期间被实际触发。

  最近提出了一些方法来解决其中的一些限制。Mariconti等人[26]介绍了MA - MADROID，并根据恶意软件样本的抽象API调用序列（通过静态分析）建立行为模型；这比以前的工作产生了更高的准确性，同时也提供了对API变化的更高弹性，减少了重新训练模型的需要。 另外，以前的工作[4，9，24]提出了旨在模仿人类使用应用程序的输入发生器，比标准的安卓伪随机输入发生器（Monkey）更有效，从而提高了执行过程中触发恶意代码的机会。此外，混合分析，即结合静态和动态分析，已经被用来获得两个世界的最佳效果。通常情况下、

  以下是两种可能的策略：（i）静态分析用于收集被分析的应用程序的信息（例如，应用程序监听的意图限制，API调用的执行路径等），然后在动态分析阶段执行应用程序，同时确保所有感兴趣的执行路径被触发[9, 40]；（ii）使用静态分析提取的特征（例如、 权限、API调用等）与动态分析（如文件访问、网络事件等）的特征相结合，并用于训练一个集合机器学习模型[22, 23]。

  尽管有大量的工作提出了各种Android恶意软件分析和检测方法，但研究界

  尽管有大量的工作提出了各种Android恶意软件分析和检测方法，但研究界仍然缺乏对每种方法的优势和劣势的深入了解，特别是在使用相同的建模方法来评估它们时。在本文中，我们旨在通过解决以下研究问题来填补这一研究空白：

  1. 我们能否将基于行为建模的恶意软件检测技术（按照MAMADROID[26]）扩展到动态分析？这些是更有效还是更不有效？

  2. 当同一技术被用于建立恶意软件检测模型时，不同的恶意软件分析方法（即静态、动态和混合分析）在检测性能方面如何相互比较？为什么？

  3. 与Monkey[18]等伪随机输入生成器相比，在动态分析期间让人类测试应用程序是否能提高恶意软件的检测率？

  为了回答这些问题，我们首先修改了CHIMP[2]--一个最近提出的平台，允许人群输入测试Android应用程序--以支持建立一个基于行为模型的恶意软件检测系统。也就是说，我们使用与MAMADROID[26]相同的方法，从在虚拟设备（而不是apk）中执行应用程序时产生的痕迹中提取抽象的API调用序列。我们称这个系统为AUNTIEDROID，并通过使用自动（Monkey）和用户生成的输入来实例化它。 然后，我们使用相同的建模方法（即依赖于从抽象的API调用序列中建立的马尔可夫链的行为模型）、相同的特征和相同的机器学习分类器来评估每种分析方法。

  贡献。我们的工作有几个贡献。首先，我们介绍了AUNTIEDROID，一个扩展了CHIMP的虚拟设备。

  我们介绍了AUNTIEDROID，这是一个虚拟设备，它扩展了CHIMP，并允许收集方法轨迹

  (从中提取特征），并允许收集应用程序执行时产生的方法痕迹。 第二，我们建立并评估了一个融合了基于行为的静态和动态分析功能的混合系统。第三，我们表明，动态代码加载在野外很普遍，理论上恶意软件开发者可以利用它来规避静态分析工具。最后，我们进行了比较分析，表明混合分析表现最好，静态分析至少和动态分析一样有效，这取决于动态分析期间应用程序的输入是如何产生的。

  论文组织。 本文的其余部分组织如下。下一节回顾了以前关于Android恶意软件的工作。 然后，在第3节，我们描述了我们对CHIMP的修改。

  在第4节，我们介绍了我们的实验设置和用于评估的数据集。 接下来，我们在第5节和第6节分别介绍和比较了所有方法取得的结果。最后，本文在第7节中得出结论。（在附录中，我们还讨论了我们的动态分析工作的挑战和我们的虚拟设备测试平台的局限性。）

  我们现在回顾一下以前使用静态、动态和混合分析的Android恶意软件检测工作。

  基于静态分析的安卓恶意软件检测旨在通过依赖从应用程序的apk（即其源代码）中提取的特征，将一个应用程序分类为恶意或良性。在[15，19，32，33]中提出的技术从应用程序请求的权限中建立特征，利用恶意软件经常倾向于请求危险/不需要的权限的事实。 然而，这种方法可能容易出现误报，因为良性的应用程序也可能请求危险的权限[15]。 此外，自安卓6.0以来，权限模型允许用户在运行时授予权限，当它们被需要时，因此一些危险的权限可能实际上从未被授予（事实上，应用程序开发人员经常请求从未被使用的权限[17]）。 Drebin[6]结合了从应用程序清单中提取的几个特征（如意图、硬件组件、应用程序组件）以及反汇编的代码（被禁止的和可疑的API调用，以及网络地址）来训练分类器。可惜的是，基于反编译代码的技术可以通过动态代码加载、反射和使用本地代码来规避[28, 30]。

  其他工具则依赖于API调用。DroidAPIMiner[1]根据恶意软件更经常使用的API调用进行分类。然而，由于Android API的变化，以及恶意软件的演变，这需要经常重新培训系统，因为新的API被发布，新的恶意软件类型被开发。随着新API的发布，API调用的废弃和/或增加是很常见的，这可能会促使恶意软件开发者转向不同的API调用。

  同样基于静态分析的还有MAMADROID[26]，它使用从API调用的序列而不是频率建立的行为模型。具体来说，它通过描述不同API调用之间的转换来操作，包括以下四个阶段：（1）它提取应用程序的调用图，即apk中API调用的控制流图；（2）它将调用图解析为API调用的序列，这些调用被抽象为两种模式之一，即它们的 家族 或包名称。在包模式下，API调用被抽象为其包的名称，使用来自Android和Google APIs的大约338个包的列表，而在族模式下，抽象为Google、java、javax、android、xml、apache、junit、json或dom族。混淆的和开发者规格化的API调用被抽象为混淆的和自我定义的，重新谱系化；（3）接下来，它将（抽象的）调用序列建模为马尔可夫链，并将其作为一个新的模型。

  (3) 接下来，它将（抽象的）调用序列建模为马尔可夫链，并提取状态之间的转换概率作为特征；(4) 训练一个机器学习分类器，用于标记样本为良性或恶意。

  MAMADROID实现了较高的检测精度（高达0.99的F1分数），与[1]相比，它能在较长的时间内保持检测精度，因为它建立的模型对API变化和恶意软件的演变更有弹性。 在本文中，对于静态分析部分，我们在MAMADROID的基础上，重新使用bitbucket上公开的源代码1，使用从API序列建立的行为模型进行和比较恶意软件检测，同时使用静态、动态和混合分析（见第4节）。

  基于动态分析的技术试图通过捕获应用程序的运行时行为来检测恶意软件，目标是通用恶意软件行为或特定行为。

  DroidTrace[42]使用trace（一种经常被窃听者用来控制进程的系统调用）来监控选定的系统调用，允许运行动态有效载荷并将其行为分类，例如，文件访问、网络连接、进程间通信或权限升级。Canfora等人[8]通过在虚拟机上执行应用程序，从系统调用序列中提取特征，而Lageman等人[21]利用系统调用和logcat日志对应用程序在虚拟机上执行期间的行为进行建模。

  CopperDroid[37]采用动态分析，通过观察执行的系统调用自动重建恶意软件行为。而CrowDroid[7]，一个在设备上运行的轻量级客户端，捕获应用程序产生的系统调用，并将其发送到中央服务器，后者为每个应用程序建立行为模型。相比之下，对于我们论文的动态分析部分，我们从调用API的序列（而不是API是否被调用）来建立每个应用程序的行为模型。

  一些工具结合了静态和动态分析，例如，使用前者来分析一个apk，后者来确定穿越哪些执行路径，或者结合使用静态和动态分析提取的特征。Andru- bis[23]是一个恶意软件分析沙盒，它从应用程序的清单和实际字节码中提取许可、服务、广播接收器、活动、软件包名称和SDK版本；然后，它使用静态特征和选定的动态特征动态地构建行为特征，如读/写文件、发送短信、拨打电话、使用加密操作、动态注册广播接收器、加载dex类/原生库等。请注意，尽管我们进行了方法追踪，与Andrubis类似，我们使用了一个虚拟设备，并允许人类（而不仅仅是Monkey）测试应用程序，因为后者执行的是一连串随机的行动/事件，不一定反映人类如何使用这些应用程序，也可能不会触发某些恶意代码。 此外、

  我们从方法追踪中观察到的所有API调用中建立应用程序的行为特征，而不是选择API。

  Marvin[22]使用静态和动态分析的特征给应用程序打恶意分数（从0到10不等），并将分数大于5的应用程序列为恶意软件，而CuriousDroid[9]，一个自动化的Android应用程序的用户界面（UI）交互，集成了Andrubis[23]作为其动态模块，以检测恶意软件。 它对应用程序的用户界面进行实时分解，并创建一个基于上下文的模型，生成一系列的交互，以模拟真实的人类交互行为。IntelliDroid[40]引入了一个有针对性的输入发生器，与TaintDroid[14]集成，旨在跟踪敏感信息从源头（例如，内容提供商，如联系人列表数据库）流向水槽（例如，网络插座）。它需要动态分析工具来指定目标API，并以精确的顺序生成输入，可用于刺激被分析的应用程序（AUA），以观察潜在的恶意行为。

  由于安卓应用有几个入口（例如，通过活动、服务和广播），动态刺激AUA通常是使用Monkey或MonkeyRunner等工具或人类来完成。有针对性的输入生成工具，如CuriousDroid和Intellidroid，旨在为应用程序提供一种替代性的刺激，这种刺激更接近于人类的刺激，比Monkey和MonkeyRun- ner更智能。

  最后，我们向寻求有关安卓恶意软件的大量工作细节的读者推荐[3，16，36]中有关安卓恶意软件家族和检测工具的有用调查，以及[31]中有关安卓分析技术的评估。

  在本节中，我们将介绍AUNTIEDROID，这是一个基于动态分析提取的行为模型进行安卓恶意软件检测的系统。我们的主要目标是将其性能与静态分析的对应系统，即MAMADROID[26]（见第6.1节）进行比较。事实上，我们在它的基础上，再次将（抽象的）调用序列建模为马尔可夫链，并使用状态间的转换概率作为特征。

  为了在动态分析中建立行为模型，我们修改了一个虚拟设备，允许我们从应用程序的运行时执行跟踪中捕获API调用序列。我们称这个系统为AUNTIEDROID，并在图1中总结了它的操作。 首先，我们在一个虚拟设备中执行应用程序，由一个自动程序（Monkey）或人类刺激。 然后，我们解析执行过程中产生的痕迹，并提取特征进行分类。本节的其余部分将介绍每个组件的细节。

  如上所述，AUNTIEDROID的第一步是在虚拟设备中执行apk样本，其中包括（i）人类用户或（ii）UI自动化工具，如Monkey[18]。我们的虚拟设备测试平台，将在下文中详细描述，它建立在CHIMP的基础上，这是一个最近在[2]中提出的安卓测试系统，可以用来收集来自移动应用程序的人类输入。

  CHIMP[2]。 CHIMP使用Android-x86平台对Android设备做虚拟化，在Linux服务器上的QEMU实例后面运行。尽管它使用的是x86 Android图像，但CHIMP实际上支持两种应用二进制接口（ABI），即同时支持ARM和x86指令集。一旦运行，虚拟化的设备可以由一个长期运行的自动化工具（如Monkey）来刺激，或者用户界面可以流向一个远程浏览器，允许真正的人与之互动。 CHIMP可拿来收集广泛的数据（用户互动、网络流量、性能等）以及明确的用户反馈；然而，为了便于研究，我们将在下文中介绍。

  AUNTIEDROID，我们对它进行了修改，以生成和收集运行时的痕迹，即一个应用程序的交互式执行的调用图。

  对CHIMP的修改。 为了有效监控恶意软件的执行，我们对CHIMP进行了大幅修改，其原型在[2]中提出，主要是为了实现对良性应用的大规模人工测试。 事实上，最初的原型支持通过一个名为EMMA[13]的Java代码覆盖库进行代码检测，不幸的是，EMMA需要对应用程序的源代码进行检测，而对于像我们工作中分析的那些封闭源代码的应用程序来说，通常无法获得这些代码。 因此，我们对CHIMP进行了修改，以便从未检测的代码中获取调试级别的运行时信息。 请注意，在安卓系统中，每个应用程序都运行在一个专门的虚拟机上，该虚拟机使用Java的De-bug Wire Protocol（JWDP）打开一个调试器端口。只要设备被设置为去

  buggable（ro .debuggable属性），我们就可以连接到虚拟机的JWDP端口来激活虚拟机级别的方法追踪。

  我们还必须激活跟踪：在Android中，可以使用Android的活动管理器（AM）或DDM服务。 两者最终都实现了相同的功能--即在dalvik .system .VMDebug和android .os .Debug上启动MethodTracing，但是通过不同的方法。也就是说，AM（通过adb am）暴露了一个有限的API，最终通过进程间通信（IPC）到达应用程序，而DDM服务（DDMS，由Android Studio使用）直接打开一个连接到虚拟机的调试器，提供对跟踪参数的细粒度控制。我们选择第二种方法，因为它是可参数化的，允许我们设置跟踪缓冲区的大小，默认情况下（8MB）只能容纳几秒钟的方法跟踪。因此，我们在CHIMP中实现了一个新的DDM服务，使用ddmlib库[11]与虚拟机进行通信并激活跟踪。 我们的DDM服务通过一个单一的调试器复用所有的跟踪请求，我们进一步修改了dmlib的跟踪方法，将跟踪数据转储到虚拟机的文件系统中，并将跟踪缓冲区的大小设置为128MB。然而，在虚拟设备上测试的应用程序可能会产生超过128MB的痕迹，因此，我们添加了一个后台工作，每隔30秒就会从虚拟机中重新提取和删除痕迹。除了防止追踪缓冲区被填满之外，这也让我们对可能在刺激过程中崩溃的应用程序进行部分追踪。

  为了处理恶意软件通过使用相同的软件包名称伪装成合法应用程序的问题，我们根据二进制文件的哈希值，加上软件包名称和独特的测试活动标识符来唯一地识别应用程序。 然后将其映射到应用程序在磁盘上的存储位置。我们还修改了CHIMP，以禁用应用程序的验证。

  如前所述，为了刺激被分析应用（AUA），我们同时使用Monkey和人类。

  Monkey[18]。Monkey是安卓系统事实上的标准UI建模工具，用于生成输入。 在AUNTIEDROID中，Monkeys（即一个以上的Monkey实例）被部署在虚拟设备运行的同一台机器上。我们设置Monkeys运行一个应用程序5分钟（每个应用程序一个虚拟设备虚拟机）：每个Monkey被设置为每100ms产生一次事件，并忽略超时、崩溃和安全异常（尽管我们仍然记录和处理它们）。由于Mon-key产生事件的频率可能高于一些应用程序能够处理的频率（例如，产生ANR事件），我们也以较低的频率（300ms）重新运行了一些需要处理的应用程序。正如第4.3节所讨论的，一些应用程序无法执行，原因有三：（i）它们无法安装，（ii）崩溃，或（iii）没有互动的el-ements（例如，后台应用程序），通过logcat和Monkey的输出本身观察到。

  人类。 为了让真正的用户来刺激样本，我们从包平台上招募了工作人员。 更具体地说，我们让他们与虚拟设备互动，通过一个HTML5客户端将其用户界面传输到他们的浏览器上。

  HTML5客户端。客户端将用户的操作传送回AUN - TIEDROID，由其翻译。

  TIEDROID，它将这些动作翻译成Android输入，并将其传送到虚拟设备上。 除了虚拟设备的用户界面外，还提供了用户控制，例如，在测试会话中移动到下一个应用程序。

  每个用户从我们的数据集中随机选择了4个应用程序，并被告知在进入下一个应用程序之前尽可能多地探索其功能。我们没有对用户必须花在测试应用程序上的时间执行一个下限，因为考虑到我们样本的性质，一些应用程序的互动机会可能有限。 因此，我们让至少三个不同的用户来刺激同一个应用程序。我们还将应用程序的滞留时间限制在40秒内，以避免让用户感到沮丧。我们在2017年8月9日和11日之间运行测试会话，我们向每个用户支付每个会线美元。

  伦理。 对于涉及人类的实验，我们已经通过我们机构的伦理审查程序获得了批准。 尽管我们要求提供基本的人口统计学数据（年龄、性别、国家和移动应用程序的使用专长），但我们没有收集隐私敏感信息，因为用户被要求不输入任何真实的个人信息，如账户的详细信息。在参与者的设备上不需要安装任何软件：他们在一个专门的网页上与应用程序互动，而我们在后台收集有关应用程序执行的信息。还要注意的是，我们为用户提供了需要时使用的电子邮件凭证，这样他们就不必使用自己的凭证或其他联系信息。

  如上所述，我们的虚拟设备组件负责收集方法追踪、网络数据包和应用程序运行时产生的事件日志。 为了解析这些痕迹，我们可以使用不同的策略，例如，从选定的源（例如，使用getDeviceID()API的设备ID）到汇（例如，使用writeBytes()API的数据输出流）跟踪数据流，或者使用频率分析来得出恶意软件常用的API调用（如DroidAPIMiner[1]）。

  AUNTIEDROID遵循MAMADROID[26]的基于行为模型的方法，基于应用程序在运行时执行的API调用序列，而不是从apk中统计提取。 这样，我们的目标是捕捉到良性和恶意应用程序在访问敏感信息时的不同行为。

  例如，一个良性的SMS应用可能会收到一条短信，使用getMessageBody()获取短信正文，然后通过视图依次执行setText(String msg)和show()方法向用户显示该信息。然而，一个恶意的应用程序可能会通过对每条信息执行sendTextMessage()，然后再将其显示出来，从而截获所有收到的短信。

  为了得出API的调用序列，我们收集了方法追踪，并使用dmtrace-dump[29]将其转换为调用图。 从调用图中，我们使用一个自定义脚本提取序列，同时保留API调用的执行次数作为每个序列的乘数。 如上所述，为了避免在跟踪缓冲区满时丢失跟踪，我们每30秒收集一次虚拟设备的跟踪，并为进入的跟踪清除缓冲区。 按照同样的思路，我们让三个不同的用户运行同一个应用程序的中位数，以提高所收集的痕迹的质量。因此，我们将他们为同一个应用程序产生的API调用序列汇总为一个单一的序列。 在图2中，我们提供了一个从其他两个序列中聚合起来的API调用 .eni .ChefJudy030 .AppEntry .onNewIntent的序列的例子。我们没有显示参数和返回类型以方便展示。另外，在某些情况下，跟踪1可能包含在跟踪2中没有调用的序列中的API调用，因此，聚合的跟踪也反映了这种调用。

  如同MAMADROID[26]在两种模式中的一种，即家族或包，AUNTIEDROID也将解析后的跟踪中的每个API调用抽象为其对应的家族和包名称，使用API级别26的Android API包和最新的Google API包。这种抽象允许对安卓框架中的API变化具有弹性，因为与单个API调用相比，包被添加或废弃的频率较低。这也有助于减少特征集的大小，因为每个应用程序的特征向量是马尔可夫链中状态数的平方。

  还要注意的是，我们修改了MAMADROID的抽象API调用的方法：在对包或族进行抽象之前，我们首先使用白名单方法将API调用抽象到其类。 我们这样做是为了避免将API调用抽象到错误的包或族中，以防应用程序将其包名与安卓或谷歌API中的一个名字放在一起。

  然后，我们从抽象的API调用序列中建立一个行为模型，通过建立马尔可夫链对序列进行建模，从中提取用于将应用程序分类为良性或恶意的特征。 更具体地说，特征是在代表应用程序中API调用序列的马尔可夫链中从一个状态（即API调用）过渡到另一个状态的概率。

  最后，我们进行分类--即使用监督机器学习分类器将一个应用程序标记为良性或恶意软件。更具体地说，我们使用具有10倍交叉验证的随机森林。 我们选择随机森林，因为它在高维空间的二元分类中表现良好。

  我们选择随机森林，因为它在高维空间的二元分类中表现良好，而MAMADROID的基于马尔可夫链的模型就是这种情况。

  在这一节中，我们将介绍我们的实验，评估中使用的数据集，以及对它们进行的预处理。

  如第1节所述，我们的目的是对基于行为模型的Android恶意软件检测系统进行比较分析，使用静态、动态和混合分析。为此，我们进行了三组实验。(1) 静态： 我们评估MAMADROID[26]，它在静态分析中基于行为模型进行安卓恶意软件检测；（2）动态： 我们分析AUNTIEDROID（见第5.2节）的检测性能，它使用动态分析，同时还比较了自动输入生成（Mon-key）和人类生成的输入；（3）混合：我们通过合并两种方法的API调用序列来结合静态和动态分析，再次比较Monkey和人类的输入生成。

  所有的方法都在两个抽象层次中的一个进行操作，也就是说，API调用被抽象为它们的族名或包名。总的来说，我们使用相同的建模技术和相同的机器学习分类器。 更具体地说，我们使用随机森林分类器，在族（或包）模式下，我们使用51棵（或101棵）深度等于8（或32）的树的配置。

  我们的评估使用了两个数据集：一个是最近的恶意软件样本集，另一个则是由一个数据集组成的。

  良性样本。 为了保持一致性，我们选择重新使用MA - MADROID论文[26]中标记为 newbenign 的2,568个良性应用程序集。2017年6月，我们重新下载了所有的应用程序，以确保我们有工作的应用程序和它们的最新版本，获得了2242个（87%）应用程序。我们用Google Play商店列出的29个类别中a的前49个应用（截至2017年6月）的33%样本来补充这个列表，增加了一个

  额外的481个样本。总体而言，我们的良性数据集共包括2723个应用程序。

  恶意软件样本。我们的恶意软件数据集包括2017年6月从VirusShare获取的样本--一个可能是恶意的应用程序库。2更确切地说，VirusShare包含在各种操作系统平台上被检测为恶意软件的样本，包括Android。为了只获得安卓系统的恶意软件，我们检查每个样本是否被正确地压缩并打包成apk，包含一个清单文件，并有一个打包的名字。使用这种方法，我们收集了2692个有效的Android样本，这些样本在2017年被VirusShare上的反病毒引擎标记为恶意软件。此外，我们还增加了两个来自Google Play商店的应用程序（Chef Judy和Dress Up Musa），它们被新闻报道为恶意软件，后来从Play商店中删除。

  静态分析。对于静态分析，我们重新使用bitbucket上的MAMADROID的源代码。4我们为调用图的提取设置了6小时的超时限制，在良性和恶意软件的数据集中，分别有98个（3.6%）和251个（9.3%）的应用程序无法获得调用图。这与[26]中报告的实验一致，由于超时，也由于样本超过了内存要求（我们为JVM堆空间分配了16GB）。

  动态分析。在动态分析过程中，在虚拟设备上运行应用程序之前，我们使用androguard5静态地处理它们，以确定它们是否有活动。在我们的数据集中的5417个应用中，我们发现有82个应用没有活动。由于与安卓应用的互动需要视觉效果，用户可以单击、点击或触摸来触发事件，因此我们将这些应用排除在使用Monkey或人类刺激的样本之外。 我们还删除了244个没有启动器活动的应用程序，因为在虚拟设备上启动这些应用程序不会有任何视觉效果；也就是说，没有用户界面会被展示给测试者。最后，我们不包括139个由于表1中的原因而无法在虚拟设备上安装的应用程序。

  混合分析。 为了得到一个混合检测系统，我们合并了使用静态和动态分析得到的抽象化API调用序列（我们从中提取特征）。更具体地说，我们按照第3.3节中讨论的用于聚合痕迹的相同策略来合并API调用序列。 当然，对于混合分析，我们使用的是同时具有静态和动态分析痕迹的样本。

  最终数据集。 在表2中，我们在最右边一栏报告了每种分析方法在每个数据集中的最终样本数。 在动态分析过程中，当用Monkey刺激时，我们无法获得724个应用程序的痕迹，而用人类刺激时，我们无法获得693个。 我们在检查了日志后讨论了失败的原因，见附录A。请注意，混合分析方法包括我们以静态和动态方式获得痕迹的样本。

  在本节中，我们将介绍我们的实验评估结果，报告检测性能和动态分析的代码覆盖率。

  我们使用MAMADROID[26]的一个稍加修改的版本进行静态分析。 具体来说，我们在抽象到它们各自的族或包名之前，将API调用序列抽象到它们的类名。我们这样做是为了防止错误地抽象出以Android/Google包名开始的开发者定义的API调用。 还需要注意的是，虽然[26]使用的是API级别24，但我们使用的是更近的API级别26。

  我们对获得调用图的样本（2625个良性样本和2443个恶意软件）进行了实验，并在表3的前两行报告了在家族和包模式下操作时获得的F值。 我们观察到，后者的表现稍好，实现了0.91的F值，而前者为0.86，这与[26]中报告的结果一致。 包模式实现了比家族模式更高的F值，因为它在更小的粒度上捕获了应用程序的行为，揭示了更多区分

  接下来，我们报告动态分析（即使用AUNTIEDROID）取得的结果，比较Monkey和人类进行的刺激。

  检测性能。 对于Monkey，我们对表2所示的数据集进行评估，即对2,336/1,892个样本进行良性/恶意软件的分类。 当AUNTIEDROID在家庭模式下运行时，它的F值、精度和召回率分别为0.86、0.84和0.89。而在软件包模式下，它的F值、精度和召回率分别为0.92、0.91和0.93，如表3所报告。当人类刺激应用程序（2,348个良性和1,911个恶意软件），AUN - TIEDROID在家庭模式下运行时，我们得到的F-measure、preci- sion和recall分别为0.85、0.80和0.90。而当在包模式下运行时，F-measure、精度和召回率分别上升到0.88、0.84和0.92（见表3）。 总的来说，与静态分析相比，动态分析的所有操作模式中较低的F值（即AUN-TIEDROID与MAMADROID）是由于错误的pos-itives增加。

  它的增加。事实上，在所有的实验中，召回率约为0.90，而精确度则低至0.80（有人类的家庭模式）。

  代码覆盖率。如前所述，动态分析工具的性能会受到恶意代码是否在执行过程中被触发的影响。

  gered during execution. 由于AUNTIEDROID依靠API调用的序列来检测恶意软件，我们分析每个应用程序的代码覆盖率，以衡量一个应用程序的API调用有多少Monkey/humans成功触发。为此，我们关注以应用程序的包名开始的API调用。对于我们获得痕迹的应用程序（85%和86%、

  图3：(a)在Monkey和人类刺激下，良性和恶意应用程序所覆盖的代码百分比的累积分布函数，以及(b)动态分析中动态加载的API调用。

  对于Monkey和人类来说，Monkey平均能够触发20%的API调用。在图3(a)中，我们绘制了代码覆盖百分比的累积分布函数（CDF），表明对于90%的良性应用，至少有40%的API调用是由Monkey触发的。 而对于恶意软件样本，至少有57%的API调用被触发。至于人类，我们发现，用户平均能够触发14%的API调用。同样，图3（a）显示，在90%的良性应用中，至少有29%的API调用被触发。然而，在90%的恶意应用程序中，41%的API调用被触发。

  在两种刺激器中，恶意软件应用的代码覆盖率都高于良性应用。 这是由于在我们的数据集中，恶意软件的规模比良性应用小。 良性应用和恶意软件应用中API调用的平均数量分别为43,518和16,780。然而，就刺激物而言，与人类相比，Monkey能够在应用程序中触发更多的代码，这可能是由于Monkey在各自测试应用程序的时间内触发了比人类更多的事件。

  动态代码加载。我们还报告了应用程序动态加载的代码的百分比，方法是检查存在于动态跟踪中但不在apk中的API调用。 也就是说，我们使用apktool[5]从apk中提取API调用，并测量动态跟踪中的调用的百分比，而不是静态提取的调用。我们这样做是为了评估应用程序中动态代码加载的普遍性，因为这可能被用于恶意的目的[28]。 例如，恶意软件开发者可能会设计他们的应用程序（或重新包装的良性应用程序），只动态加载恶意代码并逃避静态分析工具 .

  总的来说，在我们90%的恶意软件样本中，有高达99.5%的代码是动态加载的，我们认为，动态代码加载可能确实会给仅基于静态分析和依赖API调用的恶意软件检测工具带来问题。 也就是说，这些工具可能无法抵御动态加载代码的规避技术，因为很大一部分执行的代码根本就不会被检查。另一方面，由于良性的应用程序也大量使用动态代码

  我们现在报告混合分析取得的结果，在Monkey和人类进行的刺激之间进行组合分析。 回顾一下，只有那些我们在静态和动态分析中都获得了痕迹的样本，如图2中报告的那样，才会被合并和评估。

  在家庭模式下，混合系统使用Monkey产生的痕迹，达到了0.88的F值，而当使用人类产生的痕迹时，达到了0.87。 在包模式下，使用Monkey，它的F值为0.92，而使用人的F值为0.90，如表3所示。

  请注意，我们不报告混合分析中的代码覆盖率，因为静态分析的痕迹是对应用程序中的API调用的高估。因此，合并后的痕迹并不反映每个应用在执行时的代码覆盖率。

  我们现在开始检查和比较：（1）每种分析方法的检测性能，即根据通过静态、动态或混合分析建立的行为模型检测恶意软件，（2）每种方法被错误分类的样本，以及（3）被一种方法错误分类但被另一种方法正确分类的样本。 由于每种方法都有其固有的局限性，在以前的工作中并不清楚它们如何相互比较。因此，在本节中，我们将对它们的比较进行说明。

  我们首先比较了不同分析方法的结果。回顾一下，我们已经把每个API调用抽象为它的族名或包名，因此，每个方法都以两种模式之一运作

  在两种模式中的一种。当在族模式下操作时，通过静态分析，我们的F值为0.86，而通过动态分析，当应用程序被Monkey刺激时，我们的F值为0.86，被hu-mans刺激时为0.85（见表3）。在软件包模式下，我们通过静态分析达到了0.91的F值，而通过动态分析，当应用程序被Mon-key刺激时，我们达到了0.92的F值，而被人类刺激时，达到了0.88（见表3）。

  结果表明，静态分析至少和动态分析一样有效，这取决于动态分析期间使用的应用程序刺激器。 我们认为这是因为用于执行检测的行为模型主要利用了API调用。虽然静态分析无法检测到代码动态加载时的恶意行为，但它提供了apk中API调用序列的过度计时。因此，所有可以从apk中提取的行为实际上都被静态分析分类器所捕获。 另一方面，动态分析只捕捉到样本在运行时表现出来的行为。 因此，任何在运行期间没有观察到的行为都不会被用于动态分析分类器的决策中。

  为了验证这一假设，我们评估了当不同的应用激励器被应用时，以及在正确分类和错误分类的样本中，代码覆盖的百分比有何不同。从图4(a)中，我们观察到，当Monkey被用作应用激励器时，90%的样本中至少有48%的API调用被触发，而由人类激励的样本中只有35%被触发。 同样，如图4（b）所示，当Monkey被用来刺激应用程序时，90%的样本中有49%的API调用被触发，而90%被错误分类的应用程序中有44%的API调用被触发。当人类被用来刺激应用程序时，90%的样本中有40%的API调用被触发，而90%被错误分类的样本中有38%的API调用被触发。由于代码覆盖率较高，与众包用户激发的应用相比，猴子激发的应用的动态分析效果更好。因此，我们发现，除了不受动态代码加载等规避技术的影响外，基于API调用的动态分析工具与基于静态分析的工具相比可能没有优势，除非代码覆盖率得到提高。

  然而，当静态和动态分析的痕迹被合并到一个混合系统中时，在家庭模式下，当动态痕迹由Monkey产生时，我们达到了0.88的F-measure，而静态分析和动态分析（用Monkey）单独达到了0.86。同样，在人类刺激应用程序的情况下产生的动态痕迹的F值为0.87，而单独进行静态和动态（人类）分析的F值分别为0.86和0.85。 在软件包模式下，当动态痕迹由Monkey产生时，混合系统的F值为0.92，而由人类产生时为0.90。 混合系统在所有模式下（即家族和包）都优于动态分析系统，因为它还捕捉到了由于静态分析的高估而在应用程序运行期间没有表现出来的行为，同时它改进了静态分析，因为它捕捉到了频繁使用的API调用--一种静态分析无法捕捉的行为--以及动态加载的API调用。

  接下来，我们研究每种分析方法中被错误分类的样本，旨在了解正确分类和错误分类的样本的模型差异。我们对已被三种方法分类的样本进行分析，并以打包模式进行分析。

  为了了解样本被错误分类的原因，我们提出并验证这样一个假设：错误分类是由于缺少被分类者认为是 重要 的API调用。为此，我们选择了每个分类器所使用的100个最重要的特征来区分潜在的恶意软件和良性样本，并评估每个样本中存在的这些特征的平均数量。我们选择100个最重要的特征是因为它最多代表了我们实验中记录的特征的10%。回顾一下，在我们的检测技术中，一个特征是唤起一个滥用的API调用的概率，在体验过程中没有唤起的转换的概率为0。在我们的数据集中，概率为0的特征的最大数量是1,869（静态分析），最小是1,022（与人类的动态分析）。 我们期望被错误分类的样本与相反类别的样本有类似数量的重要特征。

  因此，使用每个分类器的前100个特征，我们比较了真阳性（即正确分类的恶意软件样本）与假阴性（被分类为良性的恶意软件）以及真阴性与假阳性的平均特征数量。

  假阳性。在图5(a)和5(b)中，我们分别报告了每种分析方法的假阳性数量（即被归类为恶意软件的良性样本），当应用程序在动态分析中受到人类和Monkey的刺激时。对于前者，在静态、动态和混合分析中分别有215、317和209个误报。 对于后者，通过静态、动态和混合分析，我们得到217、178和137个误报。使用前100个特征，我们发现，静态分析中的假阳性表现出与真阳性相似的行为。 具体来说，它们平均有54. 12士22.65的特征，这与线相似。

  阳性样本中的59.96士19.46士。在动态和混合分析中也观察到同样的行为，而不考虑应用程序的刺激因素。

  在图6中，我们绘制了所有分析方法在动态分析中由人类刺激应用程序时，每个分类类型中存在的特征数量的CDF，并在图7中绘制了Monkey。图中显示，所有分析方法中假阳性的行为模式与真阳性的行为模式相似。例如，在图6(c)（透明分析）中，90%的假阳性者在100个最重要的特征中不超过50个（与线(b)中，我们报告了每种分析方法的假阴性（即恶意软件样本被分类为良性）的数量，即应用程序受到人类和猴子的刺激时。对于前者，在静态、动态和Hy-brid分析中，分别有148、151和153个错误的否定，而对于后者，我们得到149、132和126个错误的否定。在静态分析中，我们发现假阴性体的行为模式与在真阴性体中观察到的相似。 特别是，在用于区分恶意软件和良性样本的100个最重要的特征中，每个假阴性样本平均有82.08士11.75个特征。该值更类似于每个线个重要特征，而不是每个线个重要特征。 同样的结果也在动态分析中观察到，不管是哪种刺激器，在混合分析中也是如此。回顾一下，在图6和图7中，我们分别展示了在动态分析中，当人类和Monkey被用作激励器时，每个分类类型中存在的特征数量的CDF。 例如，在图7（b）（动态分析）中，90%的假阴性样本有100个特征中的84个，这个数值与89个特征（线 不同分析方法的错误分类

  接下来，我们试图澄清为什么有些样本被一种分析方法错误分类，而被另一种方法正确分类。 这些方法之间的第一个重要区别是代码覆盖率：动态分析并没有覆盖一个应用程序的整个代码库。此外，用Monkey和人类进行刺激会产生不同的代码覆盖率。这可能会导致一些不同的情况：

  2. 静态分析可能会发现一些不一定是恶意的API调用序列，但却是许多恶意应用程序的特征；

  3. 在动态分析过程中没有被触发的API调用可能会毒害所产生的马尔可夫链，导致样本的错误分类，这取决于样本是否是训练集或测试集的一部分。

  请注意，情况（1）和（2）是静态分析正确检测到一些样本而动态分析没有的可能原因，而（3）指的是相反的情况。 尽管混合系统从静态和动态分析中捕捉到了API调用的序列，但它实际上产生了全新的马尔科夫链和训练与分类的特征。虽然比单独的方法更准确，但随着特征值的变化（即过渡概率），它也会有不同的结果。

  另一个重要因素是代码中存在等待用户互动的循环。 在我们的数据集中，一个很好的例子是游戏《蠢蛋的死法1和2》。 这些应用程序有 迷你游戏，用户必须在正确的时间点击屏幕上的正确位置数次。当执行时，应用程序进入一个循环，等待用户的行动，并根据所发生的情况决定下一个行动，然后再返回到等待用户的行动。静态分析会捕捉到循环的四个不同的结果（即执行路径），即错误的点击、正确的点击、用户赢了游戏、用户输了游戏。动态分析会根据人类或猴子的连续点击而多次重复循环，而用户/猴子可能永远不会赢或输。

  用户/猴子可能永远不会赢或输。静态分析将记录四个可能的循环路径，而不会在其痕迹中重复序列，而用户/猴子可能不会记录所有可能的序列，但由于多次点击导致相同的结果而有重复的序列。 所有这些差异都是记录的痕迹的特征，因此可能导致不同的马尔科夫链和方法之间的决定。

  分析方法，即静态、动态和混合分析，使用一个共同的建模方法。 具体来说，我们根据抽象的API调用序列建立了每个样本的行为模型，正如MAMADROID[26]所做的那样，因为它能有效地捕捉到恶意行为，即使在Android API的变化和不断发展的恶意软件中。 为此，我们建立了一个动态分析工具AUNTIEDROID，它支持通过人类（通过众包）和伪随机输入生成器（Monkey）刺激应用程序。 我们还稍微修改了MAMADROID，在抽象到其他模式之前，先抽象出对其类的API调用，以避免抽象到错误的包。 然后，为了建立一个混合系统，我们合并了静态和动态分析的API调用序列。 所有这三种方法都在两种模式中的一种运行，即家族和包，基于滥用程度；在家族模式下，静态、动态（人/猴子）和混合分析分别达到0.86、0.85/0.86和0.88的F值。而在包模式下，我们实现了

  混合分析的表现最好，因为它抓住了两方面的优点，即静态和动态分析，因为它能够捕获实际执行和/或动态加载的API调用序列（来自后者），并捕获测试期间由于代码高估而没有执行的代码（来自前者）。尽管如此，静态分析总体上表现良好，往往比动态分析更好；当观察不同方法的错误分类时，我们发现，那些在动态分析中出现而在静态分析中没有出现的错误可能是由于代码覆盖率低，因此，动态分析的特征向量可能没有揭示出我们数据集中恶意软件的特征（例如，重新包装的样本中的一大块良性代码）。 然后，我们表明，动态分析的猴子比人类表现得更好，因为前者比后者能够触发更多的代码。

  尽管AUNTIEDROID的虚拟设备有一些特有的特点（例如，它作为一个硬件辅助的虚拟化运行），应该可以防止那些试图利用环境变量绕过仿真器/虚拟设备的恶意软件的规避[12,20,25,27]，我们计划，作为未来工作的一部分，更新它以使用一个看起来尽可能接近真实设备的虚拟装置。在附录B中，我们还强调了它的一些局限性，我们将在不久的将来解决这样一些问题。此外，我们打算使用针对应用程序特定行为的输入生成器，以便针对恶意软件大多使用的某些API调用，而不是在动态分析期间试图提高代码覆盖率。最后，我们计划检测和测量专门采用动态代码加载作为逃避技术的恶意软件的流行程度。