黑暗危害：基于学习，大规模发现Android应用中的隐藏敏感操作(HSO)

黑暗危害：基于学习，大规模发现Android应用中的隐藏敏感操作(HSO)

摘要

隐藏敏感操作（HSO），例如：在接收SMS消息时窃取隐私用户数据正越来越多地被移动恶意软件和其他潜在危害应用（PHA）用来逃避检测，由于在应用程序运行时触发它们是一个挑战，所以识别此类行为很难；当前的静态方法依赖于事先已知的触发条件或隐藏行为，因此无法捕获先前未知的HSO活动；此外，这些技术往往是计算密集型的，所以不太适合分析大量应用程序，因此，我们对当今真实HSO的理解仍然有限，更不用说减轻这种威胁的有效手段了。

在本文中，我们介绍了HSOMINER，这是一种创新的基于机器学习的程序分析技术，可以大规模发现未知的HSO活动。我们的方法是利用一组程序功能来表征HSO分支，并且可以相对容易地从应用程序（app）中提取，这些特征总结了一组关于HSO条件，其路径以及它们之间关系的独特观察，并且旨在用于发现隐藏的可疑行为；特别地，我们发现与合法分支相比，触发条件不太可能通过数据流或共享资源与其分支的路径相关；此外，HSO分支的两条路径所表现出的行为往往明显不同（一边是清白的，另一边是险恶的），最重要的是，即使这些单独的特征对于自己捕获HSO来说还不够准确，但总的来说它们在识别这些行为方面非常有效。

HSOMINER利用这种差异化的功能对Android应用进行分类，实现了高精度（> 98％）和覆盖率（> 94％），并且在我们的实验中发现效率也很高，新工具进一步用于涉及338,354个真实世界应用程序的测量研究，这是有史以来针对可疑隐藏操作进行的最大规模的应用程序，我们的研究揭示了HSO活动的普遍性，这些HSO活动存在于我们分析的18.7％的应用程序中，令人惊讶的触发条件（例如，点击视图的某个区域）和行为（例如，在动态生成的接收器中隐藏操作），这有助于更好地理解问题，并有助于更有效地防御这种对移动平台的新威胁。

1 介绍

如今，移动技术的渗透也使用户面临新的安全和隐私风险。值得注意的是，据谷歌报道，在过去几年中，移动威胁不断增加，不仅来自恶意软件和其他可能有害的应用程序（PHA），如后门，欺诈应用程序，勒索软件，间谍软件等，但有时即使是大型组织的产品也会出现意外行为，例如未经同意收集私人信息（如精确位置），安装有害程序，有侵略性的广告等。为了抵消这些威胁，今天的主要应用程序商店加强了他们的安全审查，并进行了各种恶意软件扫描。特别是谷歌Play和其他大型商店在短时间内运行提交的应用程序，以捕捉他们的可疑行为。虽然这种保护适用于不太复杂的PHA，但它会导致攻击技术的进一步发展，引入一组新的应用程序，故意将其敏感行为隐藏在仅在目标情况下触发的事件背后。例如，当PHA在物理设备（不是模拟器）上运行并与人交互时（第II部分），PHA仅弹出广告并收集用户的联系人。理解和有效检测这些隐藏敏感操作（HSO，包括隐藏行为及其触发条件）正在成为抗击移动恶意的新前沿。

HSO in mobile apps.

实际上，HSO已经在桌面恶意软件中进行了广泛的研究，例如，尝试识别虚拟机（VM）的存在并改变行为以逃避检测。移动PHA也有类似的技巧，在某些情况下，也是合法的应用程序。一个例子是游戏应用程序，它们在模拟器中运行时停止提供服务。另一方面，移动设备上独特的软件和硬件资源使应用程序能够通过更广泛的触发器来覆盖其行为，即执行隐藏操作的条件；案例包括位置或SMS消息（例如，仅在特定位置收集个人信息），如先前研究所报告的，以及用户输入模式，系统服务器和其他系统事件，如我们的研究中新发现的（第IV部分）。总的来说，虽然人们认为HSO确实存在于移动生态系统中，但到目前为止还很少有人对其安全影响和技术趋势有深入的了解，以及已经出现的意外手段。

这种缺乏理解主要归因于在大规模上发现隐藏操作（特别是以前未知的操作）的挑战。如今大多数桌面HSO恶意软件都是使用某种级别的动态分析捕获的，这是从二进制代码中查找逃避行为的唯一可行解决方案。 然而，分析受到其覆盖范围和可扩展性的限制。对于Android应用程序，它们的字节码更易于访问，因此可以使用静态分析进行检查；问题在于确定触发器的存在是非常困难的：基本上，触发器只是一个分支条件（在我们的研究中也称为检查），这是最常见的程序结构之一；很难将这种情况与隐藏可疑活动的意图联系起来。 当前的解决方案依赖于仔细指定的安全敏感行为（例如，受许可保护的方法，从敏感的内容提供者读取）或明确定义的触发条件以避免误报。一个突出的例子是TriggerScope，它利用符号执行支持的一组狭窄条件来识别可疑触发器；问题是这里的条件需要精确，因此需要限制（例如，时间值和常数之间的比较），这仅限于已知类型的触发器（文章中的时间，位置和SMS）。同样，用于检测的特定行为仅适用于触发器涵盖的一组已知可疑活动。结果，现有技术都没有能够找到未知的HSO。此外，使用重量级技术（如符号执行）使得像TriggerScope这样的方法不太适合大规模研究。

Our approach.

在本文中，我们提出了一种新技术，可以在Android应用程序中大规模发现和分析以前未知的HSO，我们的方法称为HSOMINER，它基于一组在不同类型的HSO中共享的独特功能。更具体地，HSO倾向于仅检查系统输入（例如，时间，SMS，用户输入的密钥等），而不是其托管应用的内部输入，以触发隐藏的行为。此外，由触发条件的隐藏路径执行的这种行为与用于在未触发敏感活动时覆盖敏感活动的另一路径上的操作非常不同（例如，发送SMS而不是简单地退出当前方法）。最有趣的是，除了它们的控制依赖性之外，触发器和隐藏行为往往是不相关的：例如，考虑使用时间来确定何时执行恶意活动（例如，窃取私人数据）；时间很少也可以作为活动的输入。从根本上说，触发器用于检查应用程序是否在目标情况下运行（正确的时刻，位置或设备），这通常与应用程序在该情况下打算做的正交（数据窃取，SMS发送等）。这与正常分支不同，在正常分支中，任一路径上的操作通常通过数据流或共享资源连接到条件（例如，如果摄像机准备就绪，则通过摄像机拍照）。

这些功能都不依赖于特定的触发条件或敏感行为，这可能允许它们用于查找以前未知的HSO。 同样重要的是，它们相对容易从程序中提取，即使它们中的每个个体可能都不够准确以便检测（产生误报），但它们共同提供了对可疑隐藏活动的更精确描述。在我们的研究中，我们利用轻量级程序分析技术从Android应用程序中的分支结构中恢复这些功能，并运行机器学习算法来识别涉及HSO的那些。 我们的评估显示，HSOMINER的精度超过98％，召回率高于94％，每个应用程序的速度为13分钟，而应用程序的尺寸（通常约为8.43 MB）比以前的研究中的应用程序大得多。这种性能水平使我们能够以前所未有的规模对HSO进行测量研究：我们扫描了超过338354个Android应用程序（包括来自Google Play的124,207个和来自VirusTotal的214,147个），并发现了包含HSO的63,372个; 其中，1773涉及从未报告过的HSO技术（第IV部分）。

Findings.

我们对同类中最大的HSO的测量揭示了整个Android生态系统中隐藏活动的普遍性：大约18.7％的应用程序被发现涉及他们试图掩盖的一些可疑行为。 除了已知的触发器，例如时间，位置和SMS，我们发现可疑行为（如发送SMS）受到监控各种系统事件的保护，包括传入的Intent，添加的新软件包，屏幕锁定等，以及通过检测存在人类用户：例如，设置屏幕上两次连续点击之间的间隔的阈值。即使对于旧技巧，例如识别仿真器，也已采用新技术，例如检查/ system / bin / linker的某些位以确定应用程序是否在X86系统上运行。此外，HSO技术似乎随着Android的发展，利用操作系统中添加的新功能及其支持的新服务：一个示例是PHA使用设备管理器来隐藏窃取用户数据的行为。我们的研究表明，HSO代码具有通过GitHub和pudn等技术论坛/存储库共享的库传播。PHA作者也迅速提出了学术界提出的新技术。例如，HITCON 2013上提出的反仿真技术被发现用于现实世界的PHA。

Contributions.

该文件的贡献概述如下：

（1）New technique.

我们开发了HSOMINER，这是一种新颖的基于机器学习的程序分析技术，用于大规模自动检测隐藏的敏感操作，包括以前未知的操作。HSOMINER建立在一系列简单但突出的程序功能之上，利用它们的集体差异化能力来识别HSO。通过这种方式，我们保持功能一般，从而允许该技术处理新类型的触发条件和可疑行为。此外，使用轻量级程序功能和机器学习来避免复杂代码分析的高级想法可以在其他安全域中找到它的应用程序。

（2）New discoveries.

使用HSOMINER，我们进行了迄今为止最大规模的HSO研究。在该研究中，扫描了超过330K的最新应用程序，这导致发现了超过60K具有隐藏行为的应用程序。对这些应用程序的分析进一步揭示了新的HSO技术及其不断发展的趋势。这对于更好地了解移动HSO风险以及加强我们对这一新兴威胁的防御是非常宝贵的。

Roadmap.

本文的其余部分安排如下：第二部分介绍了我们的研究背景；第三节阐述了我们对HSOMINER的设计，实施和评估；第四节描述了我们的大规模测量研究和发现；第五节调查了相关的先前研究；第六节讨论了我们的技术和未来潜在研究的局限性，第七节总结了论文。

2 研究背景

在本节中，我们阐述了在我们的研究和现有HSO技术中研究的HSO活动，特别是在Android应用程序中使用的那些，我们还介绍了我们研究中的假设。

HSO and Android.

如前所述，我们使用术语“隐藏敏感操作”（HSO）来描述隐藏安全敏感行为的分支条件（触发器）以及触发器的一条路径上的行为，只有在条件满足时才能调用。恶意软件作者长期以来一直利用这种HSO技巧来逃避动态分析。这里，触发条件用于确定恶意软件是否在其目标环境中运行，这通常通过一组启发式方法找到：例如，查找某些API的输出中的差异，虚拟机（VM）的存在系统文件或与虚拟化等相关的可观察的性能降级。此外，人类交互的检测和各种分析引擎（例如，FireEye多向量虚拟执行引擎）的使用在桌面HSO中也变得流行。在没有触发此类行为的情况下，复杂的恶意软件甚至可以显示消息以掩盖其服务的中断作为配置问题。

同样，用于检测模拟器的技巧构成了Android应用程序所采用的HSO技术的支柱。这些方法倾向于利用QEMU和VirtualBox上的信息泄漏，包括其独特的系统文件和某些API调用结果中的常量值，如getDeviceId，IMEI，Build.FINGERPRIN，getLine1Number。此外，如今的移动设备的特点是其丰富的内置传感器和对用户交互的强大支持，这也开辟了隐藏敏感代码的新途径：例如，检查相机的存在，以确定应用程序是否确实运行在 电话或屏幕上的点击模式，以确定是否确实是人（而不是自动测试仪）正在使用该设备（第IV-C节）。

为了避免HSO逃避模拟器和其他分析环境，已经提出了用于覆盖这些环境的痕迹的技术。例如，在没有保护的情况下，对android.os.Build.MODEl的调用会立即在Android模拟器中返回google_sdk；为了避免这种暴露，可以通过挂钩这些API并强制它们输出模仿真实世界设备的假值来增强模拟器：例如，SM-G920F。或者，流行的应用程序可以安装在真正的手机上并进行分析。一个问题是，这种anti-HSO措施完全依赖于特定HSO行为的知识，因此对未知的HSO往往效果较差。因此，发现和理解新的HSO行为对于缓解这种潜在的安全威胁非常重要。

Assumptions.

我们考虑应用程序开发人员利用各种系统事件来确定何时触发隐藏敏感操作的情况。请注意，只要触发器涉及系统（设备构建信息，传感器状态等），我们不会假设任何特定形式的触发条件（例如，时间值和常量之间的比较，如先前的研究中所做的那样）或用户输入（第III-B节）；我们也不会将隐藏操作限制为一组手动选择的安全敏感行为，只要这些操作确实涉及至少一个曾经被滥用的API，就会对应用程序用户造成伤害（第III-C节）。Android官方安全文档提供了此类敏感API的示例。此外，就像之前所有关于HSO静态分析的努力一样，我们不考虑其分支条件已被深深混淆的应用程序。最后，正如之前的研究中所发现的那样，合法应用程序也可能表现出一些回避行为。一个突出的例子是游戏应用程序，其中许多停止在模拟器中运行。因此，重要的是要注意本研究旨在了解此类行为，而不是直接检测PHA，尽管HSO的发现通常表明存在潜在危害行为。

3 FINDING HSO

在这里，我们详细说明了我们技术的设计，实施和评估。

A. Overview

HSOMINER的设计侧重于分支的结构，当涉及隐藏行为时，无论操作的细节如何，它都具有独特的特征。可以从分支的各个组件之间的关系（包括其条件和路径）以及组件和系统事件之间的关系来观察这些特征。更具体地说，触发条件总是与系统输入（时间，位置，屏幕触摸等）相关，而非HSO分支可能仅依赖于应用程序的本地数据（例如，循环变量与常量之间的比较）。进一步比较触发器控制的路径，一个是敏感操作，另一个不是（作为前者的封面），我们可以看到它们的行为之间存在显着差异（例如，在一条路径上检索准确的位置数据和显示UI元素） 另一方面，后者的行为不那么令人担忧，以避免对整个分支的任何怀疑；同样有趣的是，触发器比合法条件更不可能与敏感操作共享资源：例如，对于合法的Intent处理程序，在检查传入的Intent的内容之后，后续操作也将发生在Intent；然而，在分支仅作为HSO的伪装的情况下，操作可以与Intent完全无关（数据窃取，发送SMS等）。从这三类关系中，我们的方法提取了7个特征（参见第III-B节），这些特征描述了条件和系统事件之间以及条件与其安全敏感路径之间的关系，以及两条路径之间的行为距离。然后，通过它们的区分能力（第III-B节）证明的这些显着特征被共同用于捕获HSO分支。

Architecture

图1说明了HSOMINER的体系结构，包括预处理器，特征提取器和分类器。预处理器解压缩应用程序的APK，然后将其代码反编译并转换为中间语言，最终转换为全局控制流图（CFG）。建立在Soot之上的CFG根据应用程序的入口点包含一组子图。子图进一步与异步任务，Android组件的生命周期和过程间调用相关联。HSOMINER自动处理这些子图，识别潜在的条件分支，并输出它们以进行特征提取。为了完全理解条件语句中涉及的触发器，为语句中出现的变量构造了反向数据依赖图（DDG），而在构造CFG期间直接识别路径的行为。预处理器还在应用程序中对程序包进行集群（第III-C节），这有助于最小化要分析的入口点集。

特征提取器将触发条件及其相应的路径作为其输入，并输出从它们收集的一组特征（第III-B节），这些功能以及一组已确认的HSO或非HSO培训实例用于学习分类模型，该模型用于检测其他HSO应用程序。

Example

这里我们使用图2中的示例来解释HSOMINER的工作原理。图中突出显示的分支条件 !containsAV，检查当前设备上是否存在任何防病毒扫描程序。 如果没有，该应用程序会收集用户的电话号码和准确位置（稍后发送）；否则，它只是将空白内容附加到邮件中。

在分析分支时，HSOMINER会追溯到定义布尔变量containsAV的程序位置，并发现它已由getInstalledPackage返回的系统输入确定，其中包含所有已安装包的列表。同时查看两个路径之间的差异，我们的方法发现敏感API getPhoneNumber和getLatitude存在于一条路径上，而不会出现在另一条路径上。 最后，与包列表相关的条件与安全敏感路径上的语句没有任何数据依赖性或其他资源共享（例如，通过公共对象）。 结果，我们的分类器将分支标记为可疑，下面我们将介绍所选功能和各个系统组件的详细信息。

B. Features

如前所述，HSOMINER依赖于一组独特的程序功能来识别HSO活动，包括表征触发条件约束，不同路径的行为差异和触发行为关系的活动。在这里，我们展示了这些功能，并使用213个已确认包含HSO活动的VirusTotal应用程序和213个被认为合法的随机选择的GooglePlay应用程序展示了它们的差异化功能。Virustotal应用程序与已知Android恶意软件的签名相匹配，例如，Android.HeHe，RCSAndroid和先前研究报告的那些，并且GooglePlay应用程序已被VirusTotal清除并手动双重检查。

Triggle condition

HSO的触发器用于识别调用隐藏活动的情况。对于文献中讨论的几乎所有HSO实例，这种情况的特征在于一些系统属性（例如，移动设备的OS或硬件跟踪）或环境参数（时间，位置，用户输入等），这些仅是通过系统界面暴露给应用程序。结果，期望HSO条件直接或间接地涉及用于与OS交互的一个或多个API调用。例如，Android定时炸弹倾向于直接将当前时间（由java.util.Calendar返回）与常量进行比较，常量通常直接嵌入触发条件中。 另一个例子，布尔变量containsAV，如图2所示，与调用getInstalledPackages有关。

值得注意的是，与HSO无关的普通条件也可能涉及系统输入。但是，在大多数情况下，它们仅使用局部变量，例如，在每次迭代期间比较循环变量。有趣的是，我们发现一个简单的二进制特征，关于是否有任何系统输入涉及条件，用SI（系统输入）表示，可以很好地指示HSO的存在。如表I所示，当在我们的地面实况数据集上识别HSO实例时，SI的F分数为0.85（精度为0.812）。第III-C节提供了从应用程序的字节码中提取功能的详细信息。

Behavior differences

在不满足HSO条件的情况下，将采取没有隐藏活动的“暴露”路径。直观地说，这条路径上的应用程序行为和隐藏路径上的应用程序行为应该有很大不同：如图2所示，隐藏路径涉及一组敏感的API调用（getPhoneNumber和getLatitude），而暴露的路径则没有。显然在这个例子中，Jaccard距离：

其中Ol和Or是分支语句的两个路径上的敏感操作集，描述了隐藏路径和暴露路径之间的不同行为。这些行为由被认为具有安全和隐私影响的API指定，如Android官方文档和一些其他列表（PScout和DroidSIFT）以及其他系统属性和Android设置所提供的。请注意，我们选择的API集比以前的研究中采用的更为通用。同样重要的是，我们对不同类型API的关系（例如，数据检索API和接收器之间的顺序）的限制较少，这使得它更有可能捕获未知的HSO活动。

然而，在实践中，情况可能更复杂。图3说明了一个合法分支，其路径涉及不同的敏感API，即使它们都执行类似的操作，即查询设备的MAC地址。有趣的是，如果我们关注不同类似的API和其他系统属性，交叉路径行为看起来并没有那么不同：例如，NetworkInterface和WifiInfo都可以用来收集网络信息；其他示例包括系统或Android属性，如“https.proxyHost”和“android_id”，其内容也可以通过API获取，如Proxy.getDefaultHost()和TelehonyManager.getDeviceId()。为解决此问题，我们根据功能的相似性对API或系统密钥进行分组。我们跨不同路径的距离D是根据各个API或系统属性的组标识计算的，我们称之为AD（活动距离）。表III显示了图中所示分支的AD。

此外，即使两个路径都涉及不同的API组，它们仍可能执行类似的操作。 图4显示了另一个示例：两个路径上的API组完全不同。条件“operatorCode equals 01”下的路径包括SMS API，而另一条路径则不包括。如果单独使用AD进行检测，则可以将此案例标记为HSO。然而，事实证明这是完全合法的：该分支实际上位于俄罗斯网络提供商的实用程序应用程序中，为客户提供通过SMS或非结构化补充服务数据（USSD）检查其帐户余额的选项。识别路径之间的这种微妙关系显然是非常重要的。

然而，在我们的研究中，我们观察到路径中共享变量和常量的存在通常表明存在这种关系。 在上面的示例中，为了更新帐户余额的值，跨越路径显示共享偏好键的内容。 直观地说，合法分支在其路径上比HSO分支更可能具有数据依赖性。基于这一观察，我们利用我们研究中的另一个特征，称为DD（数据距离）来补充AD。 具体地：

其中Vl和Vr是变量集（不包括在当前路径上本地定义的那些），并且F1和Fr是分支语句的两个路径上的引用类字段的集合。 表I显示了我们的地面实况数据集中AD和DD的F分数。

Conditon-path relation

此外，我们观察到，对于涉及隐藏行为的分支，其条件与沿其路径的操作之间的链接通常非常薄。实际上，前者正好位于后者的控制流程中。但是，除了这种关系之外，触发器通常不会将任何数据流传播到其路径，也不会与其中的操作共享其他资源。从根本上说，虽然HSO条件是为了确定运行其隐藏代码的正确情况，但代码本身并不意味着处理条件提供的任何输入。例如，当HSO应用程序从寄存器中读取以查明它是否在仿真器内运行时，由条件调用的用于窃取私有用户数据的代码不应该将OS指纹作为其输入。为了利用这个属性，我们提出了两个独特的功能，如下所述：

具体来说，我们试图找出路径上的任何操作或变量是否与条件中的任何变量具有数据依赖性。这是通过对每条路径上的每个变量执行的定义 - 使用分析来完成的（详见第III-C节）。在我们的研究中还分析了隐式条件路径关系：我们从每个路径上的变量中恢复与系统相关的对象实例，以便检查这些资源对象（例如：LocationManager）是否也与变量、API或系统密钥相关（例如：'location_providers_allowed'）在条件内。例如，隐式关系可以是在条件内检查关键location_providers_allowed（是否可以访问位置信息），以及对路径中的LocationManager的访问（使用位置数据）。在共享对象实例的情况下，可以通过程序分析找到一些关系（例如，通过getSimState（）使用TelephonyManager实例检查默认SIM卡的状态，并通过getLine1Number（）获取相同实例的电话号码。路径）。在其他情况下，我们需要领域知识来确定密钥是否与API相关或两个API是否相关。在我们的研究中，我们使用从其分支机构观察到的最普遍的API-API或密钥-API对从合法应用程序收集此类关系。详情见第III-C节。

描述这种触发器 - 行为关系的特征包括DF（数据依赖性），它是通过数据流连接到条件的路径上的变量的比率，以及IR（隐式关系），它是隐含的变量，密钥和API的数量。 与病情有关。在我们的地面实况集上测量的两个特征的F分数如表I所示。

C. Detection

所有功能的选择不仅基于它们的差异化功能，还基于它们从应用程序代码中收集的相对便利性。下面我们将阐述如何运行轻量级本地化程序分析以恢复这些功能以及如何使用它们来检测HSO活动：

Pre-processing 给定一个应用程序，预处理器首先运行Apktool来解压缩它并从其apk文件中提取字节码。然后，我们的分析工具，建立在Soot之上，寻找不同包的入口点，包括生命周期回调（例如onCreate），用户交互式回调（例如onClick）和广播接收器回调（即onReceive），正如先前的研究所做的。从每个入口点开始，HSOMINER探索所有可到达的代码以创建控制流图（CFG），我们将其称为关于条目的全局子图或简称为全局子图。为了提高此分析的性能，我们使用一种技术来自动识别之前分析的包，基于一组功能（例如，一组Android API的调用频率，API调用的总数以及元中的其他统计功能） -data）指纹他们。对于那些几乎总是共享库的包，我们的方法会跳过它们的入口点，而不会构建它们的全局子图。

全局子图模拟Android活动/服务生命周期并处理组件间通信（ICC）和异步任务：在我们的实现中使用Epicc（一种开源ICC映射系统）分析ICC，并且Android框架内的异步类是使用DroidSIFT提供的调用约定表进行描述。我们的方法还支持对所选变量进行上下文敏感，流量敏感和过程间的后向数据流分析，以构建其数据依赖图（DDG）。该技术的目的是在导致敏感API的条件下发现所选变量的来源（第III-B节），这对于诸如建立分支条件和系统输入之间的链接等任务非常重要。

在每个子图上，HSOMINER首先找到包含敏感活动的所有基本块（一个不涉及任何分支的语句块），这些活动由Android文档定义的一组广泛的API表示。请注意，与其他应用程序行为描述的先前工作不同，这里我们打算采用更通用的列表，除了Java / Android中的基本类（例如，java.lang。*）之外，几乎所有重要的API都在板上，实用程序类（例如，android.util.Log）和与数据格式相关的其他类（例如，JSONObject），因为它们几乎不能链接到任何有害操作。一旦发现了这样的敏感块，预处理器就会在CFG上向后转，以找到所有分支语句（例如，if-then，switch-case等）来预测该块。一旦找到，通过探索分支的不同路径直到路径收敛的程序位置，在子图上确定这种分支的范围。此外，对每个分支执行反向数据流分析，为其条件携带的变量生成DDG。DDG和分支的范围形成一个新图形，称为条件路径图（CPG），用于后续特征提取。图5中显示了一个示例CPG。从图中我们可以看到，与子图一样，CPG是跨程序的，完全保留了用于精确分支分析的信息。

Feature extraction 在CPG上，特征提取器自动识别HSO查找的分支特征，如下所述。

SI 如第III-B节所述，SI用于确定分支条件是否与系统输入相关，这在触发条件中比无害条件分支（不涉及任何HSO的分支）更普遍。要从给定分支中提取此功能，HSOMINER会检查分支条件中的所有变量，以确定它们是否受到任何从系统资源（例如：geo-locations,，IMEI）接收输入的API的影响（通过对后向DDG的可访问性分析）等）或来自用户界面的影响。此类API的示例包括<Date getTime（）>，<Locale getCountry（）>和<Settings $ Secure getInt（…）>。在我们的研究中，这些API的列表是使用SuSi获得的，它自动将Android API分类为sources和sinks。我们的实现包括由SuSi识别为系统输入的sources，具有18,076个用于Android 4.2的API。请注意，系统输入并非始终来自API。实际上，应用程序可以直接从系统属性（如android.os.Build）读取，并从Intents或其他系统事件接收数据。因此，我们还将这些属性和事件添加到列表中（因此，与这些属性和事件相关的条件被视为接收系统输入）。

给定系统输入列表，我们的特征提取器会自动遍历分支的CPG，以查找分支条件变量的DDG上是否存在输入。链接到任何此类输入的分支的SI设置为1。 否则，它变为0。值得注意的是，对条件的这种约束（与系统输入的关系）比Triggerscope 更宽松，后者利用特定约束，例如当前时间是否在'2016-12-22'之后。通过这种方式，我们期望该功能与其他功能一起可以帮助找到未知类型的HSO。

AD and DD AD（活动距离）和DD（数据距离）用于测量同一分支的两个路径之间的行为差异。如前所述，我们的研究表明，与真正的HSO相关的路径往往与附加到正常分支（Section III-B）的路径不同，由于隐藏的活动（例如访问位置数据，发送SMS和修改系统设置）明显不同于，并且通常完全独立于那些被暴露的活动。为了提取AD，我们的方法只是通过附加到其CPG上的分支的路径来识别所有敏感API和涉及敏感系统属性的操作（Section III-B）沿着路径将它们映射到它们对应的行为组，然后计算这两组行为组之间的Jaccard距离（分别在两条路径上）。

为了发现路径之间的数据依赖性，一般的方法是回溯路径上每个变量的数据流，以确定它是否确实与另一条路径上的某些变量相关：也就是说，它们都被追溯到相同的赋值或定义语句或所有引用相同的对象。这种分析显然是重量级的，并且似乎没有必要：对于在我们的研究中发现的所有具有此类关系的合法分支，我们观察到相关变量都与分支的CPG内的共同声明（赋值或定义）相关联或通过过程间调用传递给托管分支的方法的对象。因此，我们可以通过简单地分析它们在分支的CPG和当前方法上的数据流来建立跨越路径的变量之间的数据依赖性。这使我们能够方便地计算DD，如Section III-B所述。

DF and IR 与其他特征一样，DF和IR都描述了显式数据流和分支条件与其路径之间的隐式关系，也从分支的CPG中提取。具体而言，DF通过数据流测量路径上的变量如何受条件影响。此特征是通过define-use分析从分支中提取的：即，路径上使用的任何变量是否实际上已在条件中定义。这里“define”表示变量是定义或赋值语句（即变量获取新值的位置）执行的操作的目标。给定路径上的一组变量v1，...，vn，我们的方法只是检查CPG上的每个变量，以确定它是否已在条件中定义，DF计算为k / n，k是与条件相关的数量。

同样如Section III-B所述，分支条件可以通过共享资源隐式链接到路径，特别是公共对象实例（例如，java.net.Socket，在条件中检查其isConnected（）属性并且 getInputStream（）方法用于路径），相关的API（例如，<Environment getExternalStorageState（）>和<OutputStream write（...）>），相关的系统key-API对（例如“ACCESS_FINE_LOCATION”和<LocationManager requestLocationUpdates（...）>）。在我们的研究中，我们通过检查1500个流行的合法应用程序中的11,463个分支机构系统地收集了一组此类相关资源，并从分支机构中挑选了前50个普遍的API-API和密钥-API对（参见表II中的示例）。在操作期间，HSOMINER自动检查分支的CPG，查找与条件和路径之间的相同资源对象和相关API或密钥-API对相关联的变量。 然后将路径的IR计算为其相关API，变量和键的数量。

值得注意的是，所有这些特征，SI，AD，DD，DF和IR都是通过局部分析来识别的，该分析侧重于分支的CPG。通过这种方式，我们使特征提取变得轻量化，这对于实现HSO分析的可扩展性至关重要。

Classification 如表I所示，这些轻量级特征确实有助于单独检测HSO活动。然而，这种贡献是有限的，带来显著的误报和否定：这些特征的精确度从56.4％到84.6％不等，其覆盖率从51.4％到84.3％。显然，它们都不是完美的，它们都不能单独工作。这主要是由这些特征保留的一般性引起的，这对于找到未知的HSO很重要：例如，不是精确地指定触发条件应该是什么样的（例如，时间变量与常数相比），我们只期望条件涉及系统输入。HSOMINER的关键思想是集体使用这些不完美但轻量级的功能，以提高其发现隐藏活动的效率。为此，我们采用机器学习技术，使用分类模型来预测分支是否确实是HSO。我们的研究表明，这种方法显着提高了HSO检测的质量，将精确度提高到98％，覆盖率提高到94.4％（Section III-D）。

具体地，我们构造特征向量v =（SI; AD; DD; DF1; DFr; IRl; IRr），其中l和r分别表示分支的左和右路径。为简单起见，此处的向量仅描述具有两个路径的分支。当涉及多个路径时，我们可以使用AD和DD来表示所有路径对的最大距离，并为每个路径添加DF和IR到特征向量v。表III显示了一些特征向量的例子，包括在某一天触发隐藏行为的定时炸弹（触发器使用日历连续检查当前日期），在启动网络过程之前检查INTERNET权限的良性实例，以及在章节中描述的另外两个实例（访问MAC和检查帐户余额）Section III-B。

然后使用该矢量，在地面实况数据集上训练分类模型。我们研究中的数据集包括已确认的HSO应用程序，如Android.HeHe 和合法的应用程序（Section III-D）。在HSOMINER中实现的机器学习算法是支持向量机（SVM），由于其过度拟合的特性而在我们的研究中被选择。与其他基于学习的方法一样，我们使用交叉验证对SVM模型进行了训练，然后对其进行了评估，然后再针对330K真实应用程序运行。Section III-D节提供了本研究的细节。

D. Evaluation

在本节中，我们报告了我们对HSOMINER的评估，包括HSOMINER识别HSO活动及其性能的能力。

Settings 我们的实现是通过标记的坏集，标记的好集和未知集来评估的。为了避免由不平衡数据引起的过度拟合，我们制作了相同大小的好集和坏集。坏集包含已确认的213个PHA，每个PHA都有一个HSO分支。好的集合涉及213个谷歌播放应用程序，这些应用程序从未被VirusTotal上托管的任何反病毒（AV）服务标记。为了克服由小训练集引起的潜在过度拟合并使我们的分类器更通用，我们通过使用手动确认的分类样本作为训练样本进行了两轮重新训练。未知集有338,354个应用程序，其中124,207个从Google Play收集，其余214,147从VirusTotal随机下载。表IV中描述了我们的数据源的详细信息。请注意，虽然大量应用程序至少被一个VirusTotal扫描程序标记，但由于这57个扫描程序引入的误报，其中许多应用程序实际上是无辜的，这些扫描程序对具有丰富功能的应用程序（如集合）特别敏感位置信息。VirusTotal托管的许多应用程序也是合法的。

对于性能评估，我们从Google Play中随机选择了3000个热门应用，其大小从36KB到90MB不等。此外，还测试了先前研究使用的35个相对较小的应用程序，以便让我们了解我们的系统与前一个系统相比的表现。这些实验是在配备3.3GHz Intel Core i5处理器和16GB RAM的戴尔台式机上进行的。分析的超时设定为60分钟，与先前的研究一致。

Effectiveness 为了理解HSOMINER的有效性，我们首先使用基于多项式核的SVM在标记集上训练分类器。我们的4倍交叉验证表明，HSOMINER在HSO检测中的精度达到98％，召回率为94.4％。详细结果见表V。

然后，我们运行经过训练的模型来预测所有338,354个应用程序中的未知实例。总共有63,372个应用程序和70,660个分支被标记为可疑的HSO。其中，我们随机抽样了125个应用程序（每个都有一个标记的分支）进行手动验证。除了两个实例之外的所有实例都被认为是真阳性，精确度为98.4％，与我们从标记集中发现的一致。在两个可能的误报中，应用程序首先尝试检索设备ID，如果不成功，请尝试读取当前设备的MAC地址。我们没有看到具体的证据表明应用程序打算通过一些狭窄的触发条件隐藏这些活动。我们也没有发现敏感的用户数据被泄露。因此，我们并未将其视为真正的积极因素。在所有其他情况下，我们清楚地发现了HSO行为，例如基于时间触发隐藏活动，UI输入，环境类型（模拟器与否）等。表VI列出了从这些实例中发现的触发条件的类型。列表中的顶部是“时间”，“设备信息”和“系统事件”。我们的方法还揭示了一些鲜为人知的触发器，如“进度条”，“客户经理”，以及独特的隐藏行为，如广播中继和系统版本推断。我们在未知组中的发现详情见第四节。

Performance 为了理解HSOMINER的性能，我们在来自Google Play的3000个随机选择的应用程序中运行了我们的原型，平均大小为8.43 MB。平均而言，HSOMINER在每个应用程序上花费了765.3秒（除了8.4％的应用程序，在超时之前进行了部分分析）。此外，我们试图将我们的方法与TriggerScope [34]（一种逻辑炸弹探测器）进行比较。如果不访问其代码，我们唯一能做的就是在用于评估TriggerScope的应用程序上测试HSOMINER。总而言之，我们有35个这样的应用程序，其大小从14KB到461KB不等。所有其他应用程序显然过于陈旧，无法在线找到。将分析超时设置为60分钟后，HSOMINER平均在42秒内成功处理了这些应用程序，最差情况下为255秒，79.2％的应用程序不到60秒。请注意，之前的研究报告平均每个应用程序的性能为219.21秒，比我们的方法慢约5.2倍，但这种比较可能不完全公平，因为缺少Triggerscope代码和评估环境的不确定性。至少，该研究确实表明HSOMINER确实有效。

4 MEASUREMENT AND DISCOVERIES

HSOMINER的效率使我们能够以前所未有的规模研究HSO。通过对超过330K应用程序的系统分析，包括来自Google Play的热门应用程序，我们的研究揭示了HSO活动的普遍性，这些活动在18.7％的应用程序中找到，并且触发器的多样性（基于UI事件的模式，状态系统服务器等）和隐藏活动（动态代码加载，视频录制等）。同样重要的是，HSOMINER发现之前从未报道的新HSO活动。示例包括用户数据收集仅在视频播放10毫秒后发生，并且仅当点击屏幕上的特定区域时才调用敏感活动。此外，我们的研究揭示了HSO活动如何演变以及HSO技术的传播。下面我们详细说明这些发现。

A. Landscape

我们的测量研究共计338,354个Android应用程序，其中214,147个是从VirusTotal缓存的内容和Google Play的124,207个中随机选择的。根据SHA256删除了重复的应用程序。应用程序发布时间的分布表明：尽管多年前发布了应用程序，但大多数（约70.9％）是2015年之后新提交的应用程序。此外，我们将说明如何在图6中选择VirusTotal缓存的应用程序。下载的应用程序 从那里随机选择了标记它们的反病毒（AV）扫描仪的数量（其中约三分之一被认为是合法的）。平均而言，这些应用程序的大小为5.98 MB，在从它们中提取的所有2,245,235个软件包中，94％被HSOMINER成功处理，没有造成任何超时。

Pervasiveness 从338,354个应用程序中，HSOMINER报告其中63,372个（18.7％）包含HSO分支机构。但是，对于大多数这些应用程序，它们的隐藏行为来自共享库。总而言之，我们从这些应用程序中找到了3,491个独特的HSO实例。这些实例在所有标记的应用程序中的分布如图7所示。具体来说，60.9％的这些实例存在于不超过2个应用程序中（因此显然与库无关），而剩余的39.1％存在于由数十个文档在库中广泛的被分享在成千上万的应用程序。另请注意，12.6％的VirusTotal应用程序包含此类non-library HSO分支，而只有8.0％的Google Play应用程序包含此类分支。例如，com.baidu.kirin库中的定时炸弹被9710个应用程序共享；HSO涉及仅在由常量kirin_open_period指定的时间间隔期间访问设备信息并启动网络更新过程。

此外，我们在图8中显示了这些HSO应用程序在不同国家/地区的分布（从开发人员证书的“C（国家/地区）”属性中恢复）。从图中可以看出，其中包括托管大多数HSO应用的15个国家，俄罗斯，以色列和中国位居榜首。同样有趣的是，显然一个国家的HSO实例数与那里的每次安装成本（CPI）之间存在相关性。使用AppBrain提供的CPI数据，我们发现CPI越高，应用程序参与HSO活动的可能性就越小。

HSO and PHA 我们还发现HSO确实与可能有害的应用（PHA）有关。图9显示了VirusTotal标记的non-HSO应用程序（HSOMINER未报告的应用程序）与HSO应用程序之间的比率。我们的研究表明，前者的69.71％至少被一台AV扫描仪检测到，而后者的93.08％触发了警报。当我们将警报阈值设置为至少9个扫描仪时，这两组应用程序之间的差距变得更大。在这种情况下，59.01％的non-HSO应用程序被报告，88.22％的HSO应用程序被发现是PHA。该发现表明HSO可以作为检测PHA的指标。

 

Triggers 我们将从检测到的应用程序中观察到的HSO触发条件总结为7个类别，如图10所示，包括时间，位置，设备信息，设备设置，用户界面，系统事件和系统服务。具体地，在特定时间，特定经度和纬度范围内，或者当设备由特定网络运营商服务时，调用敏感行为。此外，发现设备特定信息被广泛用于检测仿真器：例如，设备ID“9774d56d682e549c”的存在可能表明该应用正由Bouncer进行分析。此外，我们观察到移动设备的设置用于监视设备的状态并确定运行敏感代码的情况。例如，如果isDebuggerConnected为True，则停止解密可执行文件或从资源文件加载隐藏代码的打包程序，以及在设置adb_enabled时静默安装/卸载应用程序的PHA。

除了前面提到的触发器之外，这些触发器或多或少地被先前的研究所提及。我们的方法也确定了以前从未报道的一系列条件。特别是，发现UI小部件以巧妙的方式保护敏感操作。还可以利用重启或日期更改等系统事件来激活隐藏的行为。甚至Android系统服务也用于触发HSO操作：例如，当电话帐户在AccountManager中可用时，PHA窃取设备所有者的隐私，如电话号码，网络运营商和区域设置。特别感兴趣的是将多个触发条件组合在一起以涵盖HSO活动的发现。例如，com.feicong包只在某天收到短信时才在后台发送短信。

Hidden behaviors 此外，我们研究了触发器隐藏的HSO行为。表VII列出了我们研究中发现的10类活动。正如我们从表中看到的那样，网络操作是最普遍的操作，在我们研究中研究的所有HSO实例中占近70％。其他常见活动包括访问设备信息（例如，电话号码）（15.27％），发送SMS（12.32％）和读取位置数据（7.02％），这些都被认为是安全敏感的。此外，HSOMINER确定了十几个应用程序，这些应用程序可以动态加载代码，修改系统设置，录制音频/视频，拍照并在触发后访问用户帐户。显然，这些行为可能对设备用户有害。

B. Understanding HSO

在本节中，我们将重点关注我们研究中最有趣的发现，包括新类型的HSO，这种隐藏行为的演变以及跨应用程序开发人员传播HSO技术的渠道。

New HSO 正如Section IV-A所述，HSOMINER不仅揭示了已知HSO触发器的普遍性，如时间和位置，还揭示了几种不太知名的触发条件，包括UI，系统事件和系统服务。具体来说，我们发现51个应用程序的敏感行为只能由一些独特的UI事件调用。其中一些HSO令人惊讶地复杂，利用了各种UI小部件的状态。例如，只需单击其小部件就无法触发包com.jackeey的隐藏行为。相反，HSO条件需要通过fling事件的正确距离和速度来满足：仅当屏幕上的擦除速度超过20.0（以像素为单位）时才激活网络操作。作为另一示例，com.FREE APPS 237包在点击特定视图的预定义区域之前不表现出任何敏感行为。所有这些HSO都可以轻松逃避动态分析，即使使用最先进的UI自动化工具也是如此。在我们的研究中还发现了多种传统触发器的组合。

例如，jp.co.benesse.maitama中的HSO只能通过在给定日期之前单击视图来激活。其他有趣的案例包括在应用程序的进度条或视频视图中隐藏行为，我们将在Section IV-C中详细说明。

我们还发现在HSO活动中使用了Android系统服务。这种系统服务（也称为系统服务器）包括大量接口，供设备用户访问和管理系统配置。例如，AccountManager用作管理用户帐户的集中注册表。在我们的研究中，HSOMINER检测到20个利用这些服务来覆盖其敏感操作的应用程序。作为一个突出的例子，带有com.nrs包的应用程序首先检查AccountManager中是否存在org.telegram.account，如果存在，它会继续禁用当前设备的Wi-Fi状态并更新用户信息（如IMEI，移动国家代码）通过移动数据连接到服务器。另一个例子涉及DeviceManager：当没有为当前用户激活服务时，app包com.example.comandroid不会出现任何可疑行为（仅显示其主要活动）；然而，一旦服务启动，应用程序立即通过禁用其主要活动隐藏自己并启动服务以在后台窃取传入的SMS消息。

Evolution 我们的研究也揭示了HSO活动的趋势。具体来说，我们从每个应用的APK文件中收集元数据，包括其ZipModifyDate（当文件已被更改时）和证书信息，并分析这些技术随时间的流行度。图11显示了HSO应用程序从2008年到2016年的演变，基于其托管应用程序的时间戳。我们发现包括HSO在内的应用程序的百分比在大多数情况下都会上升。这一发现表明HSO近年来越来越受欢迎，并且在反击程序分析方面变得越来越突出。

此外，我们根据应用程序的常用软件包名称确定了软件包中的变体。从这些软件包中，我们发现其中355个实际上包含了HSO版本。 例如，在2014-05-13标记的应用程序中的包net.daum.adam尚未发现任何HSO行为，而同一个包的变体在不同的应用程序中具有时间戳2015-06-26 使用多个因素（例如，设备ID，构建模型，构建平台）来确定它是否在模拟器内运行，而当它不是时，包上传用户信息并从服务器请求广告。

Propagation 我们的研究还提供了关于HSO技术如何传播的新线索。我们发现HSO实例显然是通过在线论坛传播的。例如，旨在隐藏其360安全性行为的com.feicong软件包已在网上发布（即pudn），后来出现在我们样本中的四个应用程序中。有趣的是，这些应用程序在2015年6月首次由VirusTotal扫描，尽管它最早于2012年10月发布。另一个观察结果是，学术界提出的一些新的HSO技术很快被应用程序开发人员采用。例如，在HITCON 2013上发布的一些反仿真/污点/猴子技术在com.uc108库中被发现，该库在2014年全部集成到我们样本中的6个应用程序中。

C. Case Study

在这里，我们详细阐述了我们研究中发现的一些真实的HSO案例。

Video trigger 图12显示了在我们的研究中发现的应用程序，该应用程序在其HSO触发条件下使用VideoView。具体来说，应用程序通过getCurrentPosition监视播放视频的状态：如果视频播放了100毫秒，它将开始收集设备ID和位置数据。虽然100毫秒是一个非常短的时间框架，但对于像monkeyrunner这样的UI探索工具来说，这个技巧非常有效，因为这些工具通常不会等到视频完全加载以生成另一个用户事件。我们的研究发现，在我们的数据集中的27个HSO实例中使用了类似的技术。

Trapdoor on view 普通应用程序的UI的设计方式是特定功能与单个窗口小部件/子视图相关联。但是，我们观察到一些HSO应用程序将其操作隐藏在视图上的特定区域后面。对于图13中所示的应用程序，每次单击其视图时，应用程序都会检查触摸的坐标是否位于视图中间的矩形内，高度为50像素，宽度为整个视图的一半；只有当这个“陷门”被击中时，该应用才会调用其隐藏的活动，包括发送短信。虽然这些应用程序是否实际上是恶意的并不完全清楚，但这种技巧确实使UI自动化工具更难以触发敏感的HSO操作。

Click interval

在我们的研究中发现的另一种UI-based的触发技术是用于检测人类用户的存在。该方法利用了这些自动工具旨在积极探索用户界面的观察，而人类在与应用程序的连续交互之间始终存在延迟。因此，app（com.unjiaoyou.mm）监视两次点击之间的时间间隔，如图14所示，在unFastDoubleClick（）函数下：它开始收集用户信息（电话号码，SIM卡和IMSI的序列号）间隔大于0.5秒，否则只退出OnClickListener。

Platform-specific attribute  用于检测仿真器的大多数已知HSO技术依赖于设备ID或构建信息。但是，HSOMINER发现了一种新方法，可将移动和桌面系统与可执行文件的特定平台内容区分开来。具体来说，播放此技巧的应用程序从/system/bin/linker读取以ELF格式检查其e_machine字段（第19和第20字节）。对于ARM，该字段为0，对于X86，该字段为3，其中公开了系统是在真实移动设备上还是在仿真器中运行。在app中还发现了一个类，它读取内存映射以确定/system/bin/linker64的存在。这些条件（无论是在模拟器上运行还是在当前系统上运行是64位）都可以作为隐藏行为的触发器，包括解压缩和动态加载隐藏代码。

Broadcast relay. 除了新颖的触发条件外，我们还观察到一些有趣的隐藏行为，为可疑活动提供了额外的保护层。具体来说，我们发现应用程序通过注册BroadcastReceiver receiver1来持续监控电话状态的变化。有趣的是，这个接收器进一步定义了另一个BroadcastReceiver receiver2，从应用程序的资源文件加载其代码并通过反射调用它。此外，在标记了receiver2时，receiver1没有对VirusTotal造成任何警报。这种方法可能使隐藏的活动更难以检测。

Version inference. 我们的研究还表明，掩护下的行为可能比他们看起来更微妙。作为一个突出的例子，我们发现一个应用程序，一旦触发其隐藏路径，调用setMobileDataEnabled，比较调用前后的移动状态（使用getMobileDataEnabled获取），并将比较结果发送到其服务器。仔细查看应用程序的代码可以发现，这种不寻常的操作实际上是为了推断当前操作系统的版本：API setMobileDataEnabled在Android L之前可用但之后不再支持；这可以通过调用该API的尝试是否可以通过来揭示。实际上，我们发现应用程序将推断的版本ID放在它发出的消息中。显然，它不想直接调用Build.Version来获取版本号，而是使用推理来隐藏其意图。

5 Related Work

Trigger conditions 从二进制可执行文件开始，最近转向Android应用程序，已经研究了用各种触发条件隐藏敏感行为十年。大多数先前的工作是检测虚拟机（或Android的模拟器）和规避动态分析。作为一个突出的例子，RCSAndroid是HackingTeam的监控套件，它通过静态属性（如'ro.kernel.qumu'）检测仿真器。在另一示例中，识别传感器的存在（基于诸如虚拟程序计数器和高速缓存的使用的特征）以区分真实移动设备和仿真器。 杠杆作为触发条件也是平台之间的性能差异。甚至可以自动发现这种启发式方法，如先前的工作所证明的那样。

除了VM或仿真器检测之外，其他触发条件还利用时间，位置和SMS来识别移动设备上运行敏感代码的正确情况。最近的一项研究通过提议区分人类用户和自动UI探索工具来扩展HSO触发器的范围，因此安全敏感操作仅在人类存在的情况下发生。

这些先前研究的一个问题是它们适用于相对较小的一组应用程序，通常只有几千个。结果，人们对野外发生的事情知之甚少。在我们的研究中，我们对超过330K的真实应用程序进行了测量研究，并发现了大量的HSO实例，包括之前从未报告过的实例，扩大了对该主题研究的关注。作为一个例子，最近提出的基于UI的方法已经证明已经在野外，与其他复杂的，令人惊讶的技巧（Section IV）一样，如利用视频播放的状态。

Detection 还提出了许多新技术来自动检测HSO活动，二进制可执行文件或移动代码。一些研究建议捕捉不同环境中可能有害的应用程序的行为偏差。该想法基于以下观察：反模拟器HSO在分析环境中运行以及在未经检测的设备上运行时很可能采取不同的行为。由于这种行为比较需要使用相同的执行跟踪来完成，因此这些方法通常记录应用程序在一个环境中与系统的交互，并将它们重播到另一个环境中的同一个应用程序。正如我们在这里看到的，这些方法针对的是反模拟器，而HSOMINER则是针对更一般的目的而设计的，针对不同类型的HSO活动。此外，这些基于动态分析的技术往往是重量级的，不太全面。相比之下，我们的方法使用静态分析，因此可以扩展到数十万个应用程序的级别。

另一项研究重点是触发分析，基于以下观察：触发条件通常依赖于对手感兴趣的一些独特输入（例如，时间，网络），并且敏感操作仅在满足狭窄的要求（例如，当前日期等于预定义的触发日期;移动设备位于特定区域中）。为了自动识别这种基于触发器的行为，这些方法通常利用符号执行，动态检测和形式验证等技术。其中，与我们的工作最相关的是TriggerScope，其目的是探测某些类型的逻辑炸弹（时间，位置和SMS触发的HSO）。与HSOMINER相比，一个主要区别是TriggerScope旨在捕获已知的HSO案例，其预期的触发条件非常具体。相反，HSOMINER仅假设触发条件应该接收某些系统输入，这使得识别未知HSO成为可能。另一个重要的区别是TriggerScope建立在重量级技术（如符号执行）之上，而HSOMINER利用高效的特征提取，使其更适合大规模分析。

与我们的研究相关的还有AppContext，一种基于监督机器学习的PHA检测系统。它利用了可以将良性和恶意行为与其上下文区分开的观察结果，例如UI事件，系统事件和环境属性方法。虽然在使用学习技术方面类似于HSOMINER，但AppContext更多地关注PHA检测而不是HSO行为发现。

Defense 除了试图检测HSO之外，还努力使HSO技术效率降低。例如，Ether利用硬件虚拟化扩展来保持对恶意软件的透明度。另一种技术动态地修改整个系统仿真器的执行，以在面对反仿真恶意软件时模仿真实设备。 类似地，在Android中，已经提出了通过运行时挂钩和Android源修改使模拟器透明的实现。

6 Discussion

凭借其在理解并最终击败隐藏敏感操作方面迈出的重要一步，目前HSOMINER的设计和实施仍处于初步阶段，还有许多不足之处。在这里，我们讨论了我们的方法和潜在的未来方向的一些限制。

Accuracy and completeness HSOMINER建立在现有静态分析技术的基础之上，已知这些技术不太准确，特别是在处理Android的组件间通信（ICC）时。例如，我们采用的定义 - 使用分析可能会产生不准确的结果。如我们的研究中所观察到的，更有可能的是，某些应用程序太复杂而无法分析。虽然提高基础静态分析技术的精度和完整性超出了本研究的范围，但重要的是要指出HSOMINER的设计较少依赖于各个特征的准确性。相反，我们尝试利用从程序中提取的一组属性来识别HSO行为，即使个别属性受到一定程度的噪声污染。我们坚信，利用不太准确但差异化的程序功能的集体力量，可以为更具成本效益的安全分析开辟一个充满希望的新方向。

此外，尽管HSOMINER的设计比现有方法更通用，这使得它能够捕获新的HSO实例，但它仍然基于一组未能涵盖某些HSO案例的假设。例如，理论上，触发条件不需要涉及任何系统输入：一旦活动被访问了一定次数，就可以激活隐藏行为。然而，在实践中，之前从未观察到这种类型的技巧。最重要的是，HSOMINER基于一组特征对分支结构进行分类，这限制了单个特征的影响，并且仍然可以捕获上述情况。这需要在未来的研究中进一步研究。

Evasion 就像所有现有方法一样，HSOMINER可以通过精心设计的HSO技术来回避。HSO分支总是可以以模仿合法分支的方式构建，以使我们的技术效率降低。另一方面，我们认为HSOMINER的设计理念将使这种攻击更难以成功：对手可能无法通过简单地避免一两个特征来绕过我们的防御;她需要考虑多种功能组合的识别能力，仔细提出欺骗我们的分类器的策略。即使为我们的实现选择的功能在出现新攻击时变得不那么明显，HSOMINER的框架也可以轻松容纳其他功能，进一步提高了逃避尝试的门槛。因此，我们有理由相信像HSOMINER这样的技术比基于单一功能的方法（如TriggerScope）更强大。与此同时，未来的研究肯定需要更好地了解我们的方法下的逃税成本，并找到新的方法来增强我们的技术来对付这种威胁。

此外，我们当前的实现无法处理本机代码中嵌入的HSO。但是，我们的设计可以扩展到帮助识别那里隐藏的行为。此外，HSO触发器可以部署在服务器端，我们的静态分析器无法直接观察到。另一方面，这种技术需要服务器向应用程序发送命令，这也需要在应用程序内进行检查。这只是提供了使用我们的技术识别隐藏操作的机会。此外，攻击者可以使用反射和其他技术来混淆代码以破坏HSOMINER的有效性。然而，这种尝试可以通过现有技术检测，使PHA更少隐身。基于UI的HSO活动也很难捕获，因为将它们与合法的UI相关操作区分开来存在挑战。通过利用UI文本和应用程序行为之间的语义关系，使用AutoCog和现有的自然语言处理工具来提取此功能，可以解决该问题。但是，对于仅基于回调而不是传统分支结构的UI相关行为，需要开发新技术来检测它们。

Further optimization. 如前所述，HSOMINER意味着高效，仅对特征提取执行轻量级代码分析。然而，我们目前的实施仍然涉及一些重量级技术。特别是，建立需要分析ICC的全局子图是昂贵的。然而，在实践中，我们发现在大多数情况下，本地识别的特征（没有ICC映射）足以捕获HSO分支。未来的研究可能会研究从Intent构造和ICC组件中提取特征以进行行为分类的潜力，以避免昂贵的ICC映射，以及其他替代方案以进一步提高我们方法的可扩展性。

7.Conclusion

恶意软件长期以来一直使用隐藏敏感操作（HSO）来逃避检测。今天，这种技术在移动PHA社区中获得了新的吸引力。随着针对应用程序市场和其他HSO策略审查过程的各种反仿真应用程序的报告，对威胁的普遍性及其技术趋势和影响知之甚少，主要是由于系统地发现和分析现实世界的挑战 HSO实例。尽管已经努力静态地检测这些活动，但是现有技术被调整为特定触发条件或隐藏行为，并且还非常重量级，使得它们在大规模检测先前未知的HSO应用程序方面效率较低。

在本文中，我们报告了一种创新技术，可以在大量真实的Android应用程序中分析和发现未知的HSO实例。我们的方法HSOMINER建立在一系列关于HSO条件，路径和它们之间关系的独特观察之上。特别是，我们发现这种情况往往涉及系统输入，但不太可能通过数据流或共享资源链接到其分支路径。此外，隐藏路径与覆盖它的对应物之间的行为通常是非常不同的。发现在这些观察中总结的特征在集体使用时易于提取并且非常有效。在我们的研究中，我们实现了一个原型系统，该系统运行分类器来检测具有这些功能的HSO实例。它被设计为通用的，装备精良，可以捕获以前未知的HSO实例。我们的研究表明，这项新技术的精度达到98％以上，覆盖率达到94％以上。它也很有效，使我们能够对330K以上的应用程序进行大规模的测量研究。本研究揭示了野外Android HSO活动的新亮点，揭示了HSO作者所采用的HSO行为和新技术的普遍性，包括广泛使用UI，系统事件和服务作为触发条件和令人惊讶的隐藏行为。我们的新技术以及新的理解有助于更好地防范这种对移动生态系统的新威胁。

原文链接：http://dx.doi.org/10.14722/ndss.2017.23265