Drebin

代码笔记：

Drebin_dictionaty.pkl是用来存放每一个特征值对应唯一一个id的文件，初始状态没有这个文件，会创建一个这个空字典，在后面添加特征进去以后再随机分配id进这个字典文件

翻译：

摘要

恶意应用程序对Android平台的安全构成威胁。这些应用程序的数量和多样性不断增加，使得传统的防御措施基本上无效，因此 Android 智能手机通常无法抵御新型恶意软件。在本文中，我们提出了 DREBIN，这是一种用于检测 Android 恶意软件的轻量级方法，可以直接识别智能手机上的恶意应用程序。由于有限的资源阻碍了运行时监控应用程序，因此 DREBIN 执行广泛的静态分析，收集应用程序的尽可能多的功能。这些特征嵌入在联合向量空间中，以便可以自动识别指示恶意软件的典型模式并用于解释我们方法的决策。在对 123,453 个应用程序和 5,560 个恶意软件样本进行的评估中，DREBIN 的性能优于多种相关方法，检测到 94% 的恶意软件，几乎没有误报，其中为每次检测提供的解释揭示了检测到的恶意软件的相关属性。在五款流行的智能手机上，该方法平均需要 10 秒进行分析，适合直接在设备上检查下载的应用程序。

1 介绍

Android是当今最流行的智能手机平台之一。在不同的市场上有数十万个应用程序，它为用户提供了丰富的功能。不幸的是，运行Android系统的智能手机越来越多地成为攻击者的目标，并被恶意软件感染。与其他平台相比，Android允许安装来自第三方市场等未经验证来源的应用程序，这使得攻击者很容易捆绑和分发带有恶意软件的应用程序。根据最近的一项研究，仅在2012年就发现了超过55，000个恶意应用程序和119个新的恶意软件家族[18]。很明显，有必要阻止恶意软件在Android市场和智能手机上的扩散。
Android 平台提供了多种安全措施来强化恶意软件的安装，其中最引人注目的是 Android 权限系统。要在设备上执行某些任务（例如发送 SMS 消息），每个应用程序都必须在安装期间明确请求用户许可。然而，许多用户往往会盲目地向未知的应用程序授予权限，从而破坏了权限系统的目的。因此，恶意应用程序在实践中很难受到Android权限系统的约束。
因此，大量研究研究了在 Android 恶意软件安装之前对其进行分析和检测的方法。这些方法可以大致分为静态分析方法和动态分析方法。例如，TaintDroid [11]、DroidRanger [40] 和 DroidScope [37] 是可以监视应用程序在运行时行为的方法。尽管运行时监控在识别恶意活动方面非常有效，但其开销很大，并且不能直接应用于移动设备。相比之下，静态分析方法，例如 Kirin [13]、Stowaway [15] 和 RiskRanker [21]，通常只产生很小的运行时开销。虽然这些方法高效且可扩展，但它们主要建立在手动设计的检测模式之上，而这些模式通常不适用于新的恶意软件实例。此外，大多数这些方法不提供对其决定的解释，因此对从业者来说是不透明的。
在本文中，我们提出了DREBIN，一种用于检测Android恶意软件的轻量级方法，可以自动推断检测模式并直接在智能手机上识别恶意软件。DREBIN执行广泛的静态分析，从应用程序的代码和清单中收集尽可能多的特性。这些特性被组织成一组字符串（如权限、API调用和网络地址)，并嵌入到一个联合向量空间中。例如，发送高级SMS消息的应用程序被强制转换到与相应的权限、意图和API调用相关联的向量空间中的特定区域。这种几何表示使DREBIN能够使用机器学习技术自动识别恶意软件特征的组合和模式。对于每个检测到的应用程序，可以提取各自的模式，将其映射为有意义的描述，然后作为检测的解释提供给用户。除了检测之外，DREBIN还可以提供对已识别恶意软件样本的见解。
对来自不同市场的 123,453 个应用程序和 5,560 个最新恶意软件样本的实验证明了我们方法的有效性：DREBIN 优于相关方法 [13,26,33] 以及 10 个流行防病毒扫描程序中的 9 个。该方法检测出 94% 的恶意软件样本，误报率为 1%，相当于 100 个已安装应用程序中有 1 个误报。平均而言，在普通计算机上分析应用程序需要不到一秒的时间，而在流行的智能手机型号上则需要 10 秒。据我们所知，DREBIN 是第一种直接在智能手机设备上提供有效且可解释的 Android 恶意软件检测的方法。
综上所述，我们在本文中对 Android 恶意软件的检测做出了以下贡献：

有效检测。我们引入了一种结合静态分析和机器学习的方法，该方法能够以高精度和很少的误报来识别 Android 恶意软件，并且独立于手动设计的检测模式。
可解释的结果。所提出的方法提供了一种可解释的检测。可以从向量空间追溯到指示检测到的恶意软件实例的特征模式，并提供对检测过程的洞察。
轻量级分析。为了提高效率，我们应用线性时间分析和学习技术，能够检测智能手机上的恶意软件并在合理的时间内分析大量应用程序。
我们需要注意的是，DREBIN 建立在静态分析的概念之上，因此不能排除移动设备上存在混淆或动态加载的恶意软件。我们在第 4 节中专门讨论了我们方法的这一局限性。然而，由于对功能进行了广泛的分析，我们的方法提高了攻击者用恶意应用程序感染智能手机的门槛，并增强了 Android 平台的安全性，正如我们的评估所示。
本文其余部分的组织如下：第 2 节介绍了 DREBIN 及其检测方法。第 3 节介绍了实验以及与相关方法的比较。第 4 节和第 5 节分别讨论了局限性和相关工作。第 6 节总结了本文。

2 方法

为了检测智能手机上的恶意软件，DREBIN 需要全面而轻量级的应用程序表示，以便能够确定恶意活动的典型迹象。为此，我们的方法采用广泛的静态分析，从不同来源提取特征集并在表达向量空间中分析这些特征集。此过程如图 1 所示，概述如下：

广泛的静态分析。第一步，DREBIN 静态检查给定的 Android 应用程序，并从应用程序的清单和 dex 代码中提取不同的功能集（第 2.1 节）。
嵌入向量空间。然后将提取的特征集映射到联合向量空间，其中可以对特征的模式和组合进行几何分析（第 2.2 节）。
基于学习的检测。特征集的嵌入使我们能够使用有效的机器学习技术来识别恶意软件，例如线性支持向量机（第 2.3 节）。
解释。在最后一步中，识别有助于检测恶意应用程序的功能并将其呈现给用户以解释检测过程（第 2.4 节）。
在以下部分中，我们将更详细地讨论这四个步骤，并提供分析所需的技术背景。

2.1 应用程序静态分析

第一步，DREBIN 对给定的 Android 应用程序执行轻量级静态分析。虽然表面上很简单，但特征的静态提取需要在受限的环境中运行并及时完成。如果分析时间太长，用户可能会跳过正在进行的过程并拒绝整个方法。因此，选择可以有效提取的特征变得至关重要。
因此，我们关注应用程序的manifest和反汇编的 dex 代码，这两者都可以通过对应用程序内容的线性扫描来获得。为了进行通用且可扩展的分析，我们将所有提取的特征表示为字符串集，例如权限、意图和 API 调用。特别地，我们提取以下 8 组字符串。

2.1.1 manifest中的特征集

每个为 Android 开发的应用程序都必须包含一个名为 AndroidManifest.xml 的清单文件，该文件提供支持应用程序安装和以后执行的数据。

$S_{1}$ 硬件组件：第一个功能集包含所需的硬件组件。如果应用程序请求访问智能手机的摄像头、触摸屏或 GPS 模块，则需要在清单文件中声明这些功能。
$S_{2}$ 请求权限：恶意软件往往比无害的应用程序更频繁地请求某些权限。
$S_{3}$ 应用程序组件：应用程序中存在四种不同类型的组件，每种组件定义不同的系统接口：活动、服务、内容提供者和广播接收器。每个应用程序都可以在清单中声明每种类型的多个组件。这些组件的名称也收集在功能集中，因为这些名称可能有助于识别众所周知的恶意软件组件。
$S_{4}$ 过滤意图（intent）：Android 上的进程间和进程内通信主要通过意图执行：作为异步消息交换的被动数据结构，并允许在不同组件和应用程序之间共享有关事件的信息。Drebin收集清单中列出的所有意图作为另一个功能集，因为恶意软件通常会侦听特定意图。

2.1.2 反汇编代码的特征集

Android 应用程序是用 Java 开发的，并编译成针对 Dalvik 虚拟机优化的字节码。该字节码可以被有效地反汇编，并为 DREBIN 提供有关 API 调用和应用程序中使用的数据的信息。为了实现低运行时间，我们基于Android平台的dex库实现了一个轻量级反汇编器，它可以输出应用程序中包含的所有API调用和字符串。我们使用这些信息来构建以下功能集。

$S_{5}$ 限制API调用：Android权限系统限制对一系列关键API调用的访问。我们的方法在反汇编代码中搜索这些调用的出现，以便更深入地了解应用程序的功能。揭示恶意行为的一个特殊案例是使用未请求所需权限的受限 API 调用。这可能表明恶意软件正在使用 root 漏洞来超越 Android 平台施加的限制。
$S_{6}$ 使用的权限：在s5中提取的完整调用集被用作确定请求和实际使用的权限子集的基础。为此，我们实现了Felt等人[15]引l入的方法来匹配API调用和权限。与s相反，这个特性集提供了一个应用程序行为的更通用的视图，因为多个API调用可以由一个权限来保护（例如，sendMultipartTextMessage()和sendTextMessage()都需要将SEND_SMS权限授予应用程序)。
$S_{7}$ 可疑的 API 调用：某些 API 调用允许访问智能手机的敏感数据或资源，并且经常在恶意软件样本中发现。由于这些调用特别可能导致恶意行为，因此它们被提取并收集在单独的特征集中。我们特别收集以下类型的 API 调用：
- 用于访问敏感数据的 API 调用，例如getDeviceId() 和 getSubscriberId()
- 用于通过网络进行通信的 API 调用，例如 setWifiEnabled() 和 execHttpRequest()
- 用于发送和接收短信的 API 调用，例如 sendTextMessage()
- 用于执行外部命令（例如 Runtime.exec()）的 API 调用
- 经常用于混淆的 API 调用，例如 Cipher.getInstance()
$S_{8}$ 网络地址：恶意软件定期建立网络连接以检索命令或窃取从设备收集的数据。因此，反汇编代码中找到的所有 IP 地址、主机名和 URL 都包含在最后一组功能中。其中一些地址可能涉及僵尸网络，因此存在于多个恶意软件样本中，这有助于改进检测模式的学习。

2.2 向量空间中的嵌入

恶意活动通常反映在提取特征的特定模式和组合中。例如，发送高级 SMS 消息的恶意软件可能在集合 S2 中包含 SEND SMS 权限，并在集合 S1 中包含硬件组件 android.hardware.telephony。理想情况下，我们希望制定布尔表达式来捕获功能之间的这些依赖关系，并在检测到恶意软件时返回 true。然而，从现实世界的数据推断布尔表达式是一个难题，很难有效解决。
作为补救措施，我们的目标是使用机器学习中的概念捕获特征之间的依赖关系。由于大多数学习方法都是在数值向量上操作的，我们首先需要将提取的特征集映射到向量空间。为此，我们定义了一个联合集S，它包含了8个特征集中包含的所有可观察字符串

S = S_{1} \cup S_{2} \cup \cdot \cdot \cdot \cup S_{8}

我们通过向每个功能集中的所有字符串添加唯一的前缀来确保不同集合的元素不会发生冲突。在我们的评估中，集合 S 包含大约 545,000 个不同的特征（参见第 3 节）。
使用集合 S，我们定义一个 |S| 维向量空间，其中每个维度为 0 或 1。应用程序 x 通过构造向量 φ(x) 映射到该空间，这样对于从x 各自的维度设置为 1，所有其他维度设置为 0。正式地，可以为一组应用程序 X 定义该映射 φ，如下所示

φ : X \to {0, 1}^{| S |}, φ (x) \mapsto (I (x, s))_{s \in S}

其中指标函数 I(x, s) 简单定义为

I (x, s) = {\begin{cases} 1, & 如果应用程序 x 包含功能 s \\ 0, & 否则 \end{cases}

在此表示中，具有相似特征的应用程序彼此靠近，而具有主要不同特征的应用程序则相距很远。此外，该空间中的方向可用于描述特征组合，并最终使我们能够学习可解释的检测模型。
让我们举个例子，考虑一个发送收费短信的恶意应用程序，因此需要请求某些权限和硬件组件。此应用程序的相应向量 φ(x) 如下所示

乍一看，映射 φ 似乎不适合应用程序的轻量级分析，因为它将数据嵌入到高维向量空间中。幸运的是，从应用程序中提取的特征数量与其大小呈线性关系。即，一个包含m字节代码和数据的应用程序x最多包含m个特征字符串。因此，无论向量空间的维度如何，向量 φ(x) 中只有 m 维非零。因此，仅存储从应用程序中提取的特征即可，例如使用哈希表[6]或布隆过滤器[3]来稀疏表示向量 φ(x)。

2.3 基于学习的检测

第三步，我们应用机器学习技术来自动学习区分恶意应用程序和良性应用程序。机器学习的应用使我们不必为提取的特征手动构建检测规则。
虽然可以应用多种学习方法来学习两个类别之间的分离，但只有少数方法能够生成有效且可解释的检测模型。我们考虑使用线性支持向量机 (SVM) [8, 14] 来完成此任务。给定两个类的向量作为训练数据，线性 SVM 确定一个以最大间隔分隔两个类的超平面（见图 2）。其中一类与恶意软件相关，而另一类对应于良性应用程序。通过将未知应用程序映射到向量空间并确定它是否落在超平面的恶意（+）侧或良性（-）侧来对未知应用程序进行分类。

线性 SVM 的检测模型简单地对应于向量 $w \in R^{| S |}$ 指定超平面的方向，其中相应的检测函数 $f$ 由下式给出

f (x) = ⟨ φ (x), w ⟩ = \sum_{s \in S} I (x, s) \cdot w_{s} = \sum_{s \in S} w_{s}

返回 $φ (x)$ 相对于 $w$ 的方向。 $f (x) > t$ 表示恶意活动，而 $f (x) \leq t$ 对应于给定阈值 $t$ 的良性应用程序。
为了有效地计算函数 $f$ ，再次利用映射 $φ$ 的稀疏表示。给定一个应用程序 $x$ ，只有从 $x$ 中提取的特征在 $φ (x)$ 中才具有非零条目。所有其他维度均为零，并且对 $f (x)$ 的计算没有贡献。因此，可以将检测函数 $f$ 简化如下

f (x) = \sum_{s \in S} I (x, s) \cdot w_{s} = \sum_{s \in S} w_{s}

我们最终得到了一个简单的和，而不是一个复杂的学习模型，它可以通过添加应用程序 $x$ 中每个特征的权重来有效地计算。这个公式使我们能够在智能手机上应用学习到的检测模型，也允许我们解释支持向量机获得的结果。

线下学习

在我们的实现中，我们没有学习智能手机上的检测模型。相反，我们在专用系统上离线训练支持向量机，并且仅将学习到的模型 w 传输到智能手机以检测恶意应用程序。

2.4 Explanation 说明可解释性？

在实践中，检测系统不仅必须指示恶意活动，还必须为其检测结果提供解释。基于学习的方法的一个常见缺点是它们是黑盒方法[34]。就 DREBIN 而言，我们解决了这个问题并扩展了基于学习的检测，以便它可以识别有助于检测的应用程序的特征。此外，可解释的检测还可以帮助研究人员检查恶意软件的模式并更深入地了解其功能。
凭借线性SVM的简单检测功能，我们能够确定每个单个特征 $s$ 对函数 $f (x)$ 的贡献。在 $f (x)$ 的计算过程中，我们只需要存储最大的 $k$ 个权重 $w_{s}$ ，将应用程序转移到超平面的恶意一侧。由于每个权重 $w_{s}$ 被分配给特定的特征 $s$ ，因此可以解释为什么应用程序被分类为恶意或非恶意。这种方法可以通过在计算函数 $f (x)$ [6] 期间维护堆中的 $k$ 个最大权重 $w_{s}$ 来有效地实现。
在按权重提取前 k 个特征后，DREBIN 会自动构建描述这些特征背后的功能的句子。为了实现这个目标，我们为每个特征集设计了句子模板，可以使用相应的特征来完成。表 1 列出了这些模板。对于恶意软件中经常观察到的功能，例如SEND_SMS权限，我们提供了单独的描述。

对于大多数特征集，从表 1 中的模板构建句子很简单。例如，对于硬件功能，我们利用它们的命名方案来构造有意义的句子。例如，如果应用程序使用 android.hardware.camera 功能，DREBIN 会显示句子“应用程序使用硬件功能相机”。给用户。
同样，我们为请求和使用的权限提供解释。权限的解释可以从 Android 文档中获得，该文档提供了正确的描述——至少对于所有系统权限。我们稍微修改这些描述，以便向用户提供有意义的解释。然而，由于应用程序开发人员能够定义自定义权限，我们还提供了一个通用句子，如果不存在正确的描述，则会向用户显示该句子。对于基于某些权限的使用的受限 API 调用，我们遵循相同的方法。对于所有其他功能集，模板直接填充功能名称或相应的占位符。
图3显示了一个由DREBIN生成的解释示例。所呈现的样品属于GoldDream家族。DREBIN正确地识别出恶意软件与外部服务器通信并发送短信。在安装过程中，应用程序请求16个权限。许多用户忽略了这么长的权限列表，从而成为这类恶意软件的受害者。与传统的基于权限的方法相反，DREBIN将用户的注意力直接吸引到表明恶意活动的相关方面。此外，DREBIN还会给用户一个分数，告诉他这个决定有多自信。因此，用户能够决定所呈现的功能是否符合他的期望。
除了给用户带来好处之外，生成的解释还可以帮助研究人员发现常见恶意软件家族中的相关模式。我们将在下一节中更详细地讨论这个方面。

3 评价

在详细介绍 DREBIN 后，我们现在对其功效进行实证评估。具体来说，我们进行了以下三个实验：

检测性能。首先，我们在包含 5,560 个恶意软件样本和 123,453 个良性应用程序的数据集上评估 DREBIN 的检测性能。我们将其性能与相关方法和防病毒扫描程序进行比较（第 3.2 节）。
可解释性。在第二个实验中，我们详细分析了 DREBIN 针对不同恶意软件家族提供的解释，并验证它们是否与恶意软件的实际特征相关（第 3.3 节）。
运行时性能。最后，我们评估了 DREBIN 的运行时性能。在本实验中，我们使用五种常见的智能手机型号以及常规台式计算机进行不同的运行时间测量（第 3.4 节）。

3.1 数据集

对于所有实验，我们都考虑真实 Android 应用程序和真实恶意软件的数据集。特别是，我们获得了包含 131,611 个应用程序的初始数据集，其中包括良性软件和恶意软件。样本收集时间为 2010 年 8 月至 2012 年 10 月。具体而言，该数据集包含来自 GooglePlay 商店的 96,150 个应用程序、来自不同替代中国市场的 19,545 个应用程序、来自替代俄罗斯市场的 2,810 个应用程序以及来自其他来源的 13,106 个样本，例如例如 Android 网站、恶意软件论坛和安全博客。此外，该数据集还包括来自 Android 恶意软件基因组项目 [39] 的所有样本。
为了确定恶意和良性应用程序，我们将每个样本发送到VirusTotal服务，并检查十种常见反病毒扫描仪（AntiVir，AVG,BitDefender,ClamAV,ESET,F-Secure,Kaspersky,McAfee，Panda,Sophos)的输出。我们将至少两个扫描程序检测到的所有应用程序标记为恶意程序。这个过程确保我们的数据(几乎)正确地分为良性和恶意样本一一即使十个扫描器中的一个错误地将良性应用程序标记为恶意应用程序。
最后，我们从数据集中删除标记为广告软件的样本，因为此类软件处于恶意软件和良性功能之间的模糊地带。最终数据集包含 123,453 个良性应用程序和 5,560 个恶意软件样本。据我们所知，这是用于评估 Android 上恶意软件检测方法的最大恶意软件数据集之一。
表 4(c) 概述了我们数据集中的前 20 个恶意软件家族，其中包括目前活跃在应用程序市场中的几个家族。请注意，仅显示了前 20 个家族，我们的数据集还包含 1,048 个恶意样本。

3.2 检测性能

在我们的第一个实验中，我们评估了 DREBIN 和相关静态检测方法的检测性能。在本实验中，我们将数据集随机分为已知分区 (66%) 和未知分区 (33%)。 DREBIN的检测模型和相应参数是在已知分区上确定的，而未知分区仅用于衡量最终的检测性能。我们重复此过程 10 次并对结果取平均值。分区确保报告的结果仅涉及 DREBIN 学习阶段未知的恶意应用程序。对于相关方法，例如 Kirin [13] 和 RCP [33]，此实验过程略有不同，因为并非所有方法都需要单独的训练步骤。

3.2.1 与相关方法的比较

我们首先将 DREBIN 的性能与检测 Android 恶意软件的相关静态方法进行比较。特别是，我们考虑了 Kirin [13]、RCP [33] 和 Peng 等人的方法。 [26]，我们使用 SVM 而不是朴素贝叶斯分类器来实现后者。该实验的结果如图4（a）所示为ROC曲线，即针对不同检测方法阈值，将检测率（真阳性率）与假阳性率绘制在一起。
DREBIN明显优于其他方法，以1%的误报率检测出94%的恶意软件样本，相当于安装100个应用程序时的一次误报。其他方法在这种假阳性率下提供10%-50%的检出率。由于Kirin和RCP都只考虑请求权限的一个子集，因此它们在检测恶意应用程序方面有明显的限制。即使Peng等人考虑所有权限的方法在本实验中也无法以足够的准确性检测恶意软件。DREBIN的良好性能源于用于对恶意活动建模的不同特征集这些集合包括请求的权限，但也包含应用程序的其他相关特征，如可疑的API调用、过滤的意图和网络地址。

3.2.2 与 AV scanners的比较

尽管与相关方法相比，DREBIN表现出更好的性能，但最终在实践中它必须与常见的反病毒产品竞争。因此，我们还将其与数据集中选定的十个防病毒扫描程序进行比较。每个扫描仪的检测性能再次取自 VirusTotal 服务。我们进行了两个实验，首先考虑数据集中的所有恶意软件样本，然后仅考虑 Malgenome 项目 [39] 提供的样本。我们为 DREBIN 选择 1% 的假阳性率，我们认为这对于实际操作来说足够低。
实验结果如表2所示。不同的反病毒扫描仪的检测率差异很大。虽然最好的扫描程序可以检测到超过 90% 的恶意软件，但某些扫描程序只能发现不到 10% 的恶意样本，这可能是由于不专门检测 Android 恶意软件。在完整数据集上，DREBIN 提供了第二好的性能，检测率为 93.9%，优于 10 个扫描仪中的 9 个。这一观察结果非常引人注目，因为根据我们的测试设置，至少两个扫描仪应该能够检测到每个恶意软件样本。因此，每个样本都必须已知一定的时间，并且大多数防病毒扫描仪都应配备相应的签名。然而，事实证明，DREBIN 自动生成的检测模型比许多扫描仪手动制作的签名更有效。在 Malgenome 数据集上，防病毒扫描仪实现了更好的检测率，因为这些样本已经公开了更长的时间。因此，几乎所有防病毒扫描程序都为此数据集提供正确的签名。

3.2.3 恶意软件家族检测

3.2.4 未知恶意软件家族检测

3.3 Explanations 可解释性？

3.3.1 恶意软件家族说明

3.3.2 错误和漏检

3.4 Run-time Performance

4 局限性

之前的评估证明了我们的方法在检测 Android 平台上最新恶意软件方面的有效性。然而，DREBIN 通常不能阻止恶意应用程序的感染，因为它建立在静态分析的概念之上，缺乏动态检查。特别是，静态分析无法检测到的转换攻击（例如基于反射和字节码加密的转换攻击[参见 30]）可能会阻碍准确检测。为了缓解动态分析的缺失，DREBIN 提取了与代码混淆和加载相关的 API 调用，例如 DexClassLoader.loadClass() 和 Cipher.getInstance()。这些功能至少使我们能够发现隐藏代码的执行——即使我们无法进一步分析它。与其他功能相结合，尽管使用了一些混淆技术，DREBIN 仍然能够识别恶意软件。
为了避免手动制作检测模式，我们利用机器学习来生成检测模型。虽然学习技术为自动推断模型提供了强大的工具，但它们需要有代表性的数据基础来进行训练。也就是说，DREBIN 检测模型的质量关键取决于代表性恶意和良性应用程序的可用性。虽然收集良性应用程序很简单，但收集最新的恶意软件样本需要一些技术努力。幸运的是，离线分析方法，例如 DroidRanger [40]、AppsPlayground [29] 和 RiskRanker [21]，可能有助于自动获取恶意软件，并为随着时间的推移更新和维护 DREBIN 代表性数据集提供基础。
使用机器学习带来的另一个限制是模仿和中毒攻击的可能性[例如，25、27、35]。虽然重新打包、代码重新排序或垃圾代码插入等混淆策略不会影响 DREBIN，但在学习和检测阶段之间重命名活动和组件可能会损害判别性特征 [30, 38]。同样，攻击者可以通过将良性特征或虚假不变量合并到恶意应用程序中来成功降低 DREBIN 的检测分数 [25, 27]。虽然一般不能排除这种针对学习技术的攻击，但对学习数据的彻底清理[参见 7] 和对代表性数据集的频繁再训练可以限制其影响。

5 相关工作

Android 恶意软件的分析和检测在过去几年中一直是一个活跃的研究领域。人们提出了几种概念和技术来应对这种恶意软件数量和复杂性的不断增长。 Felt 等人的研究概述了当前的恶意软件格局。 [16]以及周和江[39]。

5.1 使用静态分析进行检测

第一种检测 Android 恶意软件的方法受到静态程序分析概念的启发。已经提出了几种静态检查应用程序并反汇编其代码的方法[例如，12、13、15、21]。例如，Kirin [13] 方法检查应用程序的权限是否存在恶意活动的迹象。同样，Stowaway [15] 分析 API 调用以检测特权过高的应用程序，RiskRanker [21] 静态识别具有不同安全风险的应用程序。用于静态分析的常见开源工具是 Smali [17] 和 Androguard [10]，它们可以轻松剖析应用程序的内容。
我们的方法 DREBIN 与这些方法相关，并采用类似的功能来识别恶意应用程序，例如权限、网络地址和 API 调用。然而，它与以前的工作有两个主要方面的不同：首先，我们放弃手动制作检测模式，而是应用机器学习来分析从静态分析中提取的信息。其次，DREBIN 的分析针对有效性和效率进行了优化，这使我们能够直接在智能手机上检查应用程序。

5.2 使用动态分析进行检测

研究的第二个分支研究了运行时 Android 恶意软件的检测。最值得注意的是分析系统 TaintDroid [11] 和 DroidScope [37]，它们能够在受保护的环境中动态监控应用程序，其中第一个侧重于污点分析，而后者则支持在平台的不同层进行自省。虽然这两个系统都提供有关应用程序行为的详细信息，但它们在技术上过于复杂，无法部署在智能手机上并直接检测恶意软件。
因此，动态分析主要用于离线检测恶意软件，例如扫描和分析大量Android应用程序。例如，DroidRanger[40]AppsPlayground[29]和CopperDroid[31]等方法已被成功应用于研究不同Android市场中存在恶意行为的应用。类似的检测系统Bouncer目前由谷歌运营。这种动态分析系统适用于从Android市场中过滤恶意应用程序。然而，由于Android平台的开放性，应用程序也可能从其他来源安装，如网页和记忆棒，这需要在智能手机上运行的检测机制。
ParanoidAndroid [28] 是少数采用动态分析并可以发现智能手机上恶意活动的检测系统之一。为此，智能手机的虚拟克隆在专用服务器上并行运行，并与设备的活动同步。此设置允许监控克隆上应用程序的行为，而不会中断真实设备的功能。然而，这涉及到功能的重复，而且在实践中，数以百万计的智能手机大规模运行 ParanoidAndroid 在技术上是不可行的。

5.3 使用机器学习进行检测

手动制作和更新 Android 恶意软件检测模式的难度激发了机器学习的应用。已经提出了几种使用学习方法自动分析应用程序的方法[例如，2、26、33]。例如，Peng 等人的方法。 [26]将概率学习方法应用于应用程序的权限来检测恶意软件。类似地，Crowdroid [4]、DroidMat [36]、Adagio [20]、MAST [5] 和 DroidAPIMiner [1] 方法使用机器学习技术分析从 Android 应用程序静态提取的特征。最接近我们的工作的是 DroidAPIMiner [1]，它在最近的恶意软件上提供了与 DREBIN 类似的检测性能。然而，DroidAPIMiner 建立在 k 最近邻分类器的基础上，这会导致显着的运行时开销并妨碍在智能手机上运行该方法。此外，DroidAPIMiner 并非旨在为其检测提供解释，因此对从业者来说是不透明的。
总体而言，之前使用机器学习的工作主要集中在恶意软件的准确检测上。不考虑其他方面，例如检测的效率和可解释性。我们解决了这些问题，并提出了一种提供有效、高效且可解释的恶意应用程序检测的方法。

6 结论

Android恶意软件是一种新的快速增长的威胁。传统的防御措施，如反病毒扫描程序，越来越无法应对应用程序市场中恶意软件的数量和多样性。而最近的方法，如DroidRanger[40]和AppPlayground[29]支持从这些市场中过滤此类应用，但它们会产生运行时开销，这对直接保护智能手机是禁止的。作为补救措施，我们介绍了DREBIN，一种检测Android恶意软件的轻量级方法。DREBIN结合了静态分析和机器学习的概念，使其能够更好地跟上恶意软件开发的步伐。我们的评估证明了这种方法的潜力，其中DREBIN优于相关方法，并以很少的假警报识别恶意应用程序。
在实践中，DREBIN 为 Android 平台的安全提供了两个优势：首先，它能够高效扫描大量应用程序，例如来自第三方市场的应用程序。由于普通计算机上每个应用程序的平均运行时间为 750 毫秒，因此分析 100,000 个未知应用程序只需不到一天的时间。其次，DREBIN可以直接应用于智能手机，当新应用程序下载到设备时可以触发分析。因此，DREBIN 可以保护从不可信来源（例如网站和第三方市场）安装应用程序的用户。
尽管 DREBIN 在我们的评估中有效地识别了恶意软件，但它表现出了静态分析的固有局限性。虽然它能够检测混淆或动态执行的迹象，但该方法无法访问检索到的代码。类似的设置已成功解决用于 JavaScript 代码的分析 [参见 9]，并且每当加载新代码时动态触发 DREBIN 的静态分析似乎是未来工作的一个有前途的方向。