Android漏洞挖掘技术研究-USB迷|专注于互联网分享

2024年1月4日发(作者：卫秀曼)

摘要.................................................................................................................. i

Abstract .............................................................................................................. iii

第一章绪论 ...................................................................................................... 1

1.1 研究意义 ...................................................................................................... 1

1.2 Android概览 ............................................................................................... 4

1.2.1 系统架构 ........................................................................................... 4

1.2.2 安全机制 ........................................................................................... 8

1.3 国内外研究现状 .......................................................................................... 9

1.3.1 传统平台的漏洞挖掘技术 ................................................................ 9

1.3.2 Android漏洞挖掘技术.................................................................... 14

1.4 论文工作 .................................................................................................... 26

1.4.1 研究内容 ......................................................................................... 26

1.4.2 关键问题 ......................................................................................... 29

1.4.3 解决方案 ......................................................................................... 29

1.4.4 创新点 ............................................................................................. 29

1.5 论文结构 .................................................................................................... 30

第二章基于组合混合符号执行的跨应用数据泄露漏洞检测技术 ..................... 31

2.1 引言 ........................................................................................................... 31

2.2 相关工作 .................................................................................................... 32

2.2.1 Android基础 ................................................................................... 32

2.2.2 相关研究 ......................................................................................... 34

2.3 方法概览 .................................................................................................... 35

2.4 跨应用污点轨迹提取 ................................................................................ 38

2.5 组合混合执行 ............................................................................................ 41

2.6 动态验证 .................................................................................................... 48

2.7 实验评估 .................................................................................................... 49

2.7.1 实验设置 ......................................................................................... 50

2.7.2 与多种方法的比较 .......................................................................... 51

2.7.3 在真实应用集合上的测试结果 ...................................................... 53

2.7.4 对AppWalker分析过程的案例研究 .............................................. 56

第 I 页

2.8 本章小结 .................................................................................................... 58

第三章基于局部路径敏感VSA分析的第三方本地库UaF漏洞检测技术 ........ 60

3.1 引言 ........................................................................................................... 60

3.2 相关工作 .................................................................................................... 62

3.2.1 二进制分析 ..................................................................................... 62

3.2.2 动态UaF分析 ................................................................................ 63

3.2.3 静态UaF分析 ................................................................................ 63

3.3 方法概览 .................................................................................................... 64

3.3.1 几点观察 ......................................................................................... 64

3.3.2 VSA建模 ........................................................................................ 67

3.3.3 局部路径敏感的VSA分析 ............................................................ 68

3.4 控制流检测与变换 .................................................................................... 71

3.5 局部路径敏感的VSA分析 ....................................................................... 77

3.6 实验评估 .................................................................................................... 82

3.6.1 原型系统实现 ................................................................................. 82

3.6.2 实验配置 ......................................................................................... 83

3.6.3 对多种方法的比较 .......................................................................... 84

3.6.4 性能评估 ......................................................................................... 86

3.6.5 案例研究 ......................................................................................... 87

3.7 本章小结 .................................................................................................... 90

第四章基于ARM ETM硬件辅助的内核驱动模糊测试技术 ............................ 92

4.1 引言 ........................................................................................................... 92

4.2 相关工作 .................................................................................................... 94

4.2.1 Android应用-驱动模型 .................................................................. 94

4.2.2 相关研究 ......................................................................................... 97

4.3 方法概览 .................................................................................................. 101

4.4 驱动接口模型提取 .................................................................................. 103

4.5 硬件辅助模糊测试 .................................................................................. 106

4.5.1 终端样本生成与注入 .................................................................... 106

4.5.2 硬件辅助执行轨迹捕获 ................................................................ 108

4.5.3 覆盖率引导的模糊测试 ................................................................ 112

4.6 实验评估 .................................................................................................. 114

4.6.1 实验设置 ....................................................................................... 114

4.6.2 真实设备驱动漏洞挖掘效果 ........................................................ 114

第 II 页

4.6.4 在其在他设备上挖掘漏洞 ............................................................ 115

4.7 本章小结 .................................................................................................. 116

第五章结论与展望 ....................................................................................... 118

5.1 论文总结 .................................................................................................. 118

5.2 未来展望 .................................................................................................. 118

致谢............................................................................................................. 119

参考文献 ......................................................................................................... 120

作者在学期间取得的学术成果 ......................................................................... 139

第 III 页

表目录

表1.1 当前Android漏洞挖掘的主要技术 ............................................................... 15

表1.2 对现有方法的评估 ......................................................................................... 25

表2.1 不同方法在SWE测试集上的实验结果 ........................................................ 51

表2.2两种符号执行算法的性能详情 ....................................................................... 52

表3.1给定一种线程交织情况下的value set前向传播计算过程示例 ..................... 79

表3.2 不同UaF静态检测方法在基准测试样本上的检测结果（#Reported / #True

positive） ................................................................................................................... 85

表3.3 不同UaF静态检测方法在基准测试样本上分析到的指令数量 ................... 85

表3.4 不同UaF静态检测方法在基准测试样本上的检测性能 .............................. 86

表4.1 模糊测试的变异操作 ................................................................................... 113

表4.2 对真实设备的静态驱动接口提取结果 ........................................................ 115

表4.3 对真实驱动进行模糊测试的结果 ................................................................ 115

表4.4 在各种型号设备上发现的漏洞 .................................................................... 115

第 IV 页

图目录

图1.1 近四年来CVE Details报告的Android漏洞数目 ......................................... 3

图1.2 Android系统架构 ........................................................................................... 5

图1.3 漏洞挖掘技术分类 ....................................................................................... 10

图1.4 研究逻辑路线图 ........................................................................................... 27

图2.1 SWE示例应用集.......................................................................................... 36

图2.2 AppWalker系统总体架构 ............................................................................ 37

图2.3 污点轨迹扩展实例 ....................................................................................... 41

图2.4 应用插桩示例 ............................................................................................... 43

图2.5 Android应用混合符号执行示例. ................................................................. 45

图2.6 对SWE示例应用集合进行混合符号执行 .................................................. 47

图2.7 应用账号破解模块 ....................................................................................... 49

图2.8 两种符号执行算法的性能比较 .................................................................... 53

图2.9 跨应用数据泄露案例Ⅰ ............................................................................... 54

图2.10 跨应用数据泄露案例Ⅱ ............................................................................. 55

图3.1 局部路径敏感VSA分析算法的运行实例................................................... 70

图3.2 示例程序源码 ............................................................................................... 71

图3.3 从示例程序中提取到的一个漏洞切片 ........................................................ 82

图3.4 SmartChecker原型系统的总体框架 ............................................................ 83

图3.5 不同方法挖局UaF漏洞的性能 ................................................................... 87

图3.6 在Pbzip2中的一例UaF漏洞 ...................................................................... 88

图3.7 在AdPlug中发现的一例UaF漏洞 ............................................................. 89

图3.8 在gThumb中发现的一例UaF漏洞 ............................................................ 89

图3.9 gThumb中的一个良性UaF模式................................................................. 90

图4.1 Android应用-驱动模型[209] ....................................................................... 95

图4.2 硬件级追踪模型[257] ................................................................................... 98

图4.3 ARM硬件级追踪架构[257] ......................................................................... 99

图4.4 ETMFuzz系统总体架构 ............................................................................ 102

图4.5 设备操作处理方法定义示例 ...................................................................... 104

图4.6 驱动注册示例 ............................................................................................. 105

图4.7 驱动处理方法示例 ..................................................................................... 106

图4.8 注入序列的伪代码示例 ............................................................................. 107

图4.9 CoreSight设备文件 .................................................................................... 108

第 V 页

图4.10 perf PMU设备文件[260] .......................................................................... 109

图4.11 轨迹报文离线解码 ................................................................................... 111

图4.12 位图计算示例 ........................................................................................... 112

图4.13 反馈式样本变异迭代过程 ........................................................................ 113

第 VI 页

摘要

Android系统是移动智能终端的主流操作系统之一，近年来Android相关漏洞层出不穷，这给终端本身带来了极大的安全威胁。Android系统主要分为应用层（application layer）、本地层（native layer）和内核层（kernel layer）。本文围绕这三个层次，从漏洞挖掘角度出发，自顶向下对Android进行安全审查。特别地，我们聚焦于Android应用层的应用组件与通信、本地层的第三方库、内核层的厂商定制设备驱动等薄弱环节，并针对这些环节的安全漏洞研究对应的挖掘方法。

论文主要工作包括：（1）针对多个应用间的交互引发的安全问题、特别是跨应用数据泄露漏洞，进行高效、精确的动态检测；（2）针对本地层第三方库中的释放后重用（use-after-free，简称UaF）漏洞，进行面向二进制程序的精确、可扩展的静态挖掘；（3）针对内核设备驱动漏洞，进行低侵入的模糊测试。

论文主要成果表现在以下几个方面：

 为了缓解对多种应用组合进行审查带来的组合爆炸问题，我们提出了一种称为组合混合符号行走（combinative concolic walking）的技术，它基于跨应用污点轨迹片段，来引导混合符号执行，从而对组合后的应用进行高效的跨应用数据泄露检测，并允许分析人员通过动态确认发生的跨应用数据流是否符合用户意图来对漏洞存在性进行最终判断。该方法首次实现了对跨应用漏洞的系统性地动态分析。我们的方法能够在真实应用集合中有效检测跨应用数据泄露问题。

 针对第三方本地库的UaF漏洞检测任务，我们审查了在可扩展性漏洞分析需求下传统二进制静态分析的路径不敏感策略带来的几个关键问题，即正常编程风格引发的良性UaF模式、多线程交织导致的并发UaF问题、第三方定义的非标准UaF模式出入口API等。基于这些观察，我们提出了一种专为UaF检测问题定制的局部路径敏感的VSA（value-set analysis）分析方法，在保持VSA方法原有可扩展性的前提下，提高检测精度。我们定义了更加完备的UaF出入口集合，并对并发控制流进行修复，然后用路径不敏感的VSA分析检测UaF漏洞模式，最后采用局部路径敏感的搜索过程对良性UaF模式进行剪枝。我们的方法能够在真实本地库程序中有效检测UaF漏洞。

 针对基于真机的Android内核驱动模糊测试问题，为了避免侵入式地修改内核代码逻辑等难以在真实商品机上开展的操作，我们提出了一种利用ARM ETM硬件部件来辅助追踪驱动执行控制流的Android内核驱动灰盒模糊测试方法。我们借助ARM ETM硬件部件低侵入地提取内核驱动控制第 i 页

流执行轨迹，并以此更新代码覆盖率信息，反馈指导系统调用样本的交叉变异。驱动控制流轨迹的提取完全依赖于独立的硬件部件而不会影响CPU

core性能。我们的方法能够在真实终端内核中有效检测内存管理类漏洞。

关键词：跨应用通信；数据泄露；释放后重用；模糊测试

第 ii 页

Abstract

Android is one of the most popular operating system for mobile devices, whose

security poses heavy influence on the device itself. We study vulnerability discovery

techniques for the application layer, native layer and kernel layer of Android, to analyze

the security of the Android system in a top-down manner. We focus on the

inter-component communication of the application layer, the 3-rd party libraries of the

native layer, and the vendor customized device drivers of the kernel layer.

Our works in this paper include: (1) effective and accurate dynamic detection of

inter-app data leakages; (2) accurate and scalable static detection of use-after-free (UaF

for short) vulnerabilities in 3-rd party native libraries; (3) non-intrusive and efficient

fuzzing of Android kernel drivers.

Our contributions are:

 We propose to perform overall security auditing using dynamic analysis

techniques. We focus on data leakage as it is one of the most common

vulnerabilities in apps. We apply concolic execution on combined apps guided

by Inter-App taint paths. We use static Inter-App taint analysis to guide the

dynamic auditing procedure, so that we can target at potential Inter-App data

leakage. To mitigate the exponential blow-up when auditing various paths in

the apps, we introduce a novel technique called combinative concolic walking.

We are the first to research on path-sensitive dynamic auditing of inter-app

vulnerabilities to our knowledge. Experimental results reveal that our method

can effectively detect real-world Inter-App data leakage.

 We exam the situation of vulnerability discovery in 3rd party native libraries

and identify the key side-effects of path-insensitiveness nature of traditional

static UaF detecters for binaries, i.e., benign UaFs caused by conventional

programming style, concurrent UaFs caused by thread interleaving,

non-standard entry pairs defined in 3rd party libraries, and confused memory

addresses. Based on our observations, we propose a novel VSA analysis

method customized for UaF detection, called constrained path-sensitive

value-set analysis. We first provide a list of better-defined UaF entries and

re-construct the concurrent control flows, in a heuristic way. We then use VSA

analysis to detect UaF patterns and use a path-sensitive searching process to

prune benign UaFs. Experimental results reveal that our method can

effectively detect real-world UaF vulnerabilities.

 We propose to use real device for kernel fuzzing, avoiding intrusive testing by

utilizing ARM hardware features. Specifically, we propose a grey-box

Android driver fuzzing method based on ARM ETM's hardware tracing. We

第 iii 页

use ARM ETM to non-intrusively extract the control-flow traces of kernel

drivers, and then update code coverage information with the traces to guide the

mutation of syscall samples, enabling the fuzzing process to execute deeper

logic of drivers to find more bugs. Experimental results reveal that our method

can effectively detect real-world memory-related vulnerabilities.

Key words：inter-app communication，data leakage，use-after-free，fuzzing

第 iv 页

第一章绪论

本章首先阐明Android漏洞挖掘的背景和研究意义；然后介绍Android架构及其安全机制，通过分析Android架构的安全特点指出漏洞高发点，抛出本文所研究的漏洞挖掘领域的安全问题；对每个安全问题，描述在漏洞挖掘过程中的技术难点，给出解决方案和研究路线，并指出本文方法的创新之处；最后给出本文的论文结构。

1.1 研究意义

移动智能终端作为移动互联网的重要载体，得到了广泛使用。据报道，智能手机的市场份额在2011年首次超过了个人电脑[1]，并在2014年实现年销售增长率超过30%；2018年，全球智能手机出货量达到14.3亿[2]。移动智能终端在政治、经济、文化、科技、军事等方方面面发挥着越来越重要的作用。除了民用以外，移动智能终端也被推广和应用于信息基础设施、政府事业单位、工控系统、作战和外勤系统工作、公共安全单位等国家关键部门或系统。

Android操作系统自从2007年11月由Google公司首次发布以来，始终牢牢占据移动智能终端市场的主要席位。据权威数据分析机构Strategy Analytics称，在2014年，Android占了全球智能手机销售份额的81%；如今，Android继续在全球范围内巩固地位，份额远超其余如苹果、黑莓等移动操作系统[2]。除了智能手机之外，平板、智能电视、智能穿戴设备、物联网终端等其他多种类型的智能终端也大多使用了Android操作系统。我们对Android系统及其终端的主要特点和优势总结如下。

开放性。Android最大的特点和优势、同时也是最成功之处在于它的开放性——开源、免费、可定制。开放的平台可以使其拥有更多的开发者、允许任何移动终端厂商加入到Android联盟中来。开源的代码库和丰富的文档使得开发变得更加简单方便，提供的功能也是不断推陈出新、不断强大。免费的开发软件、社区、第三方开源共享提供给第三方开发商一个十分宽泛、自由的环境，Android由此快速积累了丰富、新颖的软件资源和大量的用户。Android的开放性在带来巨大的竞争的同时也使得Android在短短几年内很快走向成熟。

富应用。作为移动操作系统，Android的另一特点是丰富的终端功能。不同于以往的移动终端系统，Android不再局限于语音通话、短信服务等传统功能，而已经支持邮件收发、网页浏览、视频观看、音乐播放、网上购物、移动支付、及时通信、地图导航、远程办公、网络游戏等数年前只在个人电脑上见到的应用。低第 1 页

功耗的软件性能优化以及硬件本身性能的显著提升，使得Android能流畅运行应用，并保持良好续航能力。

硬件多样。Android系统拥有更加丰富的硬件选择。由于Android的开放性，众多的终端厂商为了达到更加吸引用户的目的，会在Android原有基础上加以改造，推出功能各具特色的多种产品、不断丰富着用户体验。三星、华为、小米等不同厂商生产的终端在功能上具有显著的差异和特色，却不会影响到数据同步和软件的兼容。例如，小米MIX 3采用的高通骁龙芯片搭载了Adreno系列GPU、摄像头则使用了索尼IMX 363，而华为Mate 20采用的Kirin 980芯片则搭载了Mali系列GPU、摄像头则使用了索尼IMX 600；即使同一个厂商的不同手机型号，其硬件配置也是千差万别。

移动互联。为提供更加丰富的功能和用户体验，Android终端应用需与移动网络频繁交互。传统移动终端受限于移动运营商的昂贵上网费用，使得应用功能得不到充分发挥。Android系统的移动互联网特色，极大程度地解放了终端应用，拉近了用户与互联网的距离。特别是随着4G、5G等新技术的发展，Android的这一优势将得到进一步放大。

但是，伴随Android的上述优点而来的，是更为严峻的安全形势。2018年全年，360互联网安全中心共截获国内移动端新增恶意软件样本约434.2万个，全年累计监测移动端恶意软件感染量约为1.1亿人次，其中绝大多数来自Android[3]。Android终端信息泄露、系统破坏、诱骗欺诈等造成了巨大的经济损失。2015年，国内由于手机应用软件漏洞引起的私密信息泄露造成的损失就高达805亿元[4]。2016年，360公司共截获Android平台勒索软件样本17万个，感染大约170万台手机，攻击者日收益在100到300元不等，整个产业达到千万元规模、且在不断扩散增长[5]。Android的优势此时变成了其安全问题的来源。

1） Android的开放性大大降低了攻击者的攻击成本。利用丰富的开发API，恶意样本制作更加简单；利用开放的应用市场，恶意样本传播更加便利；利用开放的系统源码，攻击者能更方便地找到脆弱部位实施攻击。正是由于移动网络与移动终端的普及，攻击的潜在受众也更多，使得攻击者更加有利可图。

2）丰富的终端功能常常与个人隐私数据紧密相关。移动终端中存储着用户的大量隐私信息，并且时常同用户的资金绑定在一起。攻击者不仅可以获得对用户终端的控制，还能获取用户隐私、甚至控制用户资金。此外，对于一些终端功能，Android应用还是过分依赖第三方开发。比如以前Android系统的软件开发套件中就没有内置媒体播放器，而是全部依赖第三方开发实现。

3）移动终端厂商对系统的二次开发，引入了越来越多的绑定式的软件。不同的厂商开发的终端，都有自己的一套系统应用，比如阅读器、视频播放器、应用第 2 页

商店、安全中心、钱包、商城，并且内嵌了大量广告。厂商出于性能和用户体验考虑，还可能采取安全性弱化的软件配置。

4） Android与移动互联网的紧密联系，进一步加剧了安全问题。为了访问网络，应用暴露了大量敏感接口。终端用户的网页浏览历史、浏览过的信息类型、保存过的信息数据、个人偏好等，都可能在用户不知情的情况下被应用暴露或窃取。

综上所述，Android安全研究刻不容缓。而作为Android安全的主要课题之一，Android漏洞挖掘研究也具有重要的研究意义。

Android漏洞无处不在，数量成上升势头。根据CVE Details统计显示，近年来Android平台漏洞数量有明显增加（如图1.1所示），根据其2018年度的最新报告，Android系统以611个漏洞位居各类平台漏洞数量榜前列[6]。阿里巴巴移动安全在2015年度移动安全报告中使用其扫描引擎对第三方应用市场18个行业的Top10应用进行漏洞审查，结果发现97%的应用都有漏洞，总漏洞量15159个，平均每个应用有87个漏洞，且23%的应用都有高风险漏洞[7]。根据360公司对2018年上半年的移动安全形势分析，99.7%的Android设备存在高危漏洞[8]。

9年份图1.1 近四年来CVE Details报告的Android漏洞数目

漏洞数20172018近年来发生了许多著名的Android安全漏洞事件。2012年11月，Android预装短信应用被发现存在接口暴露，任何第三方软件既不需要相关权限，也不需要调用相关系统API，即可在本地构造出接收到的短信[9]。2013年9月，诸多流行的互联网应用集体爆发以WebView接口漏洞为代表的安全漏洞，攻击者可以利用WebView控件的addJavaScriptInterface接口将控制命令注入到本地代码中，从而第 3 页

可导致用户手机被远程控制、用户隐私泄露等风险。该漏洞占所有应用漏洞总量的20%，阿里安全扫描了top 10000应用，发现平均每个应用包含1.9个Webview远程代码执行漏洞[10-11]。2014年7月，Bluebox公布了自2010年引入但一直没被发现的APK签名漏洞FakeID，Android手机“设置-安全”处“受信用的凭据”中是系统最信任的证书，但Android应用安装时并未验证数字证书签名，恶意应用植入到受信任的凭据后就可获得系统最高权限，进一步还可以提升权限、突破沙盒限制[11-12]。2015年9月，多种第三方SDK被指出存在漏洞。例如百度Moplus

SDK、手游常用组件Unity3D、Cocos2d-x等，可利用其采集用户隐私信息[13]。2016年3月，Trend Micro的安全专家曝光了高通芯片上的一个存在了5年之久的重大漏洞，高通为系统服务network_manager（netd）提供了一组编程接口暴露出了获得手机的控制权限的方式，成功的漏洞利用将导致攻击者获得终端的完全控制[14]。2017年5月，安全公司CheckPoint报告称，谷歌在Android6.0.1版允许Google Play商店在应用运行时直接授予权限，这使得从应用商店下载的恶意程序可自动获得授权，从而对用户终端构成威胁[15]。2018年11月，Magisk的开发者发现大量安卓手机上存在procfs权限未锁定漏洞（命名为FGO漏洞），导致第三方应用能绕过SafetyNet Attestation API，无需用户授权就能调用UsageStats或AccessibilityService API，进而查看procfs文件系统以监控其他应用和服务的运行状态，从而实现对用户隐私的窃取[16]。

当前，Android平台漏洞已经对国民经济和社会生活造成了实际危害，而漏洞挖掘技术是Android安全漏洞发现、消除及防护工作的核心所在和基本前提。近年来，学术界和产业界的研究及工作人员围绕传统平台下的漏洞挖掘问题展开了大量工作，也取得了显著进展。然而，现有漏洞挖掘技术在应用于移动平台时面临了许多新挑战，针对以Android为代表的移动平台的漏洞挖掘的研究还处于起步阶段。

1.2 Android概览

本节讨论Android体系架构及其安全设计，为进一步分析Android的攻击面、确立研究内容做准备。

1.2.1 系统架构

Android的体系结构其实就是“Java on Linux”的架构。其整体架构主要分为3层，包括应用程序和应用程序框架所在的应用层，核心库与运行环境层所在的本地层，以及底层的Linux内核层。图1.2给出了Android系统的各个层次。Android应用以Java为主要编程语言，应用使用的API和程序运行环境与其它主流系统有第 4 页

很大不同。

应用程序子层应用层应用框架子层本地层内核层

图1.2 Android系统架构

1.2.1.1 应用层（application layer）

 应用软件子层

Android应用（app）使得开发者在无需修改底层系统的情况下就能扩展和改进终端设备的功能。Android框架提供了一套丰富的API接口来访问Android设备的各种功能。API相当于应用与虚拟机间的桥梁。Android应用分为系统预装应用和用户安装应用两大类。Android应用包含三大要素：应用组件、Manifest文件、Intent。

Android应用都必须遵从Android组件化的编程框架，即任何应用都是由若干关键元素组合而成。这些元素包括Android Manifest文件、Intent消息、Activity组件、BroadcastReceiver组件、Service组件和Content Provider组件。后四种元素是Android应用通信的端口，对于研究应用安全性有着特殊的意义。所有的Android应用包（APK）必须包含Android 配置文件，该文件包含大量对应用的元配置信息，包括专有包名（如）和版本信息、Activity、Service第 5 页

和BroadcastReceier定义、应用需要请求的权限及自定义权限的定义、应用需要使用的外部库程序包的信息、共享UID信息、优先安置路径和UI图标等额外的支持性信息。跨应用通信的一个关键环节是Intent消息结构，其包含了将要执行的操作的信息、被操作的候选目标组件和其他控制信息。

 应用框架子层

Android应用框架是应用与Android运行时库的桥梁，它提供给开发者实现终端通用功能（如管理UI元素、访问共享数据存储、组件间消息传递）所需的包和类，即它提供了Android虚拟机中执行的具体应用无关的代码。这些包都被定义在android.*命名空间中。

Android应用和Android应用框架都是用Java开发、并在虚拟机中运行的。Android的虚拟机为上层应用提供对底层操作系统的高效抽象。Android的虚拟机是一类基于寄存器的虚拟机，解释执行Dalvik可执行程序（DEX）的字节码格式。Android的虚拟机对嵌入式设备存在的较低的处理器和内存访问速度等问题进行了专门的优化。Android虚拟机通过Java Native Interface （JNI）与底层本地代码进行交互。JNI允许应用及应用框架的字节码与本地代码相互调用。

Android应用框架还提供了其他常用包，如Java类和第三方包（如Apache HTTP

client库和SAX XML parser）。此外，Android应用框架还包含大量管理服务，如Activity组件管理服务Activity Manager，UI管理服务View System等。这些服务以线程的形式存在于system_server进程中。Android应用通过Zygote进程进行初始化和启动。

1.2.1.2 本地层（native layer）

Android用户态的本地代码组件包括bionic libc/WebKit/OpenSL等核心库、vold和DBus等本地系统服务、dhcpd和wpa_supplicant等本地网络服务。其中有的服务/库直接与内核态的服务和驱动通信，而其他的只是对底层基本操作的简单封装。Android虚拟机也依赖于本地核心库提供的基础功能。

本地层包含了来自多方的核心库。厂商集成的程序库提供了对厂商相关设备硬件的支持（如图像设备、GPS收发部件、蜂窝无限电话），位于/vendor/lib或/system/vendor/lib中。厂商无关的库则位于/system/lib，大多数都是移植自著名的开源项目，如本地数据库管理SQLite、嵌入式的网络浏览器引擎WebKit、位图和向量格式的字体显示库FreeType、JPEG EXIF处理库libexif、Expat XML解析库libexpat、ALSA媒体库libaudioalsa/libtinyalsa、蓝牙库libbluetooth、D-Bus IPC库libdbus，等等。以Android 4.3为例，它总共包含了超过200个共享库。Android还对部分库作了改动。例如，Android为了提供更小内存占用并避免GPL版权问题，对BSD C运行时库进行裁剪并增加了动态链接器和多线程API，从而形成了第 6 页

Android Bionic定制C库。

本地服务负责运行底层操作系统和Android本地组件。这类服务包括对用户空间进行首次初始化的init进程、提供关键调试功能的adbd和debuggerd进程等。主要的几项服务如下。

– init服务：Linux类操作系统内核都会使用init命令启动首个用户态进程init。init进程通过执行一系列命令来初始化用户空间环境。

– 属性服务：init进程中内嵌了Android属性服务，它提供对属性项的基于内存映射和key-value的持久化配置管理。其可以配置的属性包括网络接口、无线通信选项、安全相关配置等。

– 无线通信服务：无线通信接口层（RIL）提供了基本的手机通话功能，包括收发短信、连接运营商网络等。

– Debuggerd服务：负责Android崩溃报告。

– Android Debugging Bridge（ADB）调试服务：包括终端上的adbd daemon进程、主机上的adb服务进程和对应的adb命令行客户端。

– vold服务：Android用vold daemon进程负责管理文件系统卷，它实现了对终端设备上多种文件系统的挂载和卸载。Vold采用了类似于uevent（Linux文件系统服务）的事件监听机制。

1.2.1.3 内核层（kernel layer）

Android系统最底层是Linux内核。Android的核心内核与标准Linux核心内核存在许多显著差异。由于大量改动造成的不兼容性，Google早期在Linux内核项目树中创建了单独的Android内核分支，最初版本的内核引入了从文件系统、到网络处理、再到内存管理等大约250个补丁，其中大多用于性能和安全优化，例如，Android核心内核引入的Paranoid networking机制能够根据请求进程的组信息对网络操作权限进行限制。

Android对Linux内核的另一部分重要改进，是以设备驱动的形式加入到现有内核而不是直接去修改核心内核。厂商定制的内核会引入大量新的硬件专用内核驱动，这为系统带来了众多新的功能，如摄像头、Wi-Fi和其他网络设备访问，但也引入了安全风险。AOSP对Android内核引入的通用设备驱动主要有以下几类。

– Binder驱动：它是Android对Linux内核最主要的改进之一。Android基于OpenBinder实现了内核IPC通信，并将内核IPC功能实现为Binder驱动。整个IPC过程基于client-server模型，允许一个进程可以同步地调用远程进程的方法，使得过程调用变得好像在本地一样。Binder采用进程号PID和用户号UID来标识调用方，使得被调用方能根据调用来源采取不同的访问控制和权限检查，这种管理保证了一定程度的安全性。

第 7 页

– Ashmem驱动：Android实现了基于内存文件和引用计数的共享内存接口，即匿名共享内存ashmem驱动。Surface Flinger、Audio Flinger、System

Server和Android虚拟机等很多Android本地层核心组件都会用到ashmem。Ashmem专门针对低内存设备，提出了自动内存cache收缩、低内存时内存区域回收等优化措施。

– Pmem驱动：该驱动用于管理设备中物理连续的1MB到16MB、甚至更大的大内存。通过访问Pmem驱动，这些内存可被用户态进程和内核驱动共享。

– Logger驱动：Android实现了新的日志子系统logger。logger驱动为上层日志缓冲区查看命令logcat提供底层支持。根据日志信息的类型，它提供了main、radio、event和system这4种日志缓冲区。main缓冲区包含了大量与应用相关的事件，具体可以分级为informational、debug和error。system缓冲区记录了系统进程产生的全系统事件。

1.2.2 安全机制

下面介绍Android系统各层的主要安全机制，主要围绕漏洞利用缓解技术进行展开。

应用层采用的安全机制主要有：

– 应用沙盒：其核心要素是：标准Linux进程隔离、唯一用户标识UID、严格的文件系统权限约束。不同用户运行的进程不能相互干扰（如访问对方内存空间）。Android继承了Linux的UID/GID机制，但用Android IDs（AIDs）映射文件取代了传统的passwd和group配置方式。当应用执行时，相应的UID、GID和其他组信息被授予创建的进程。内核根据这些标识信息进行底层的权能约束和跨应用交互管理。

– 应用签名：Android使用公钥加密来对应用进行多方面的安全管控。对预装系统应用，Android用专用密钥对应用包进行签名，以标识其具有system用户权限。对于第三方应用，Android则用开发者密钥进行签名，此类应用只具有最低用户权限。应用签名主要用来防止未授权的应用更新。Android允许开发者用自己的私钥对应用签名，因此Android的应用签名不能保证应用本身可信。

– 用户认证：Android提供了密码、图案、生物特征等多种方式的桌面锁屏和应用用户认证。随着硬件功能的不断丰富，越来越多样化的用户认证方式将会出现。

– 应用权限管理：应用权限包括API权限、文件系统权限、IPC权限。第 8 页

PackageManager从应用的Manifest文件中提取权限信息并存储于/data/system/。当应用进程自动时，系统根据该文件进行授权。Android 6.0以后将权限分为普通权限和危险权限，后者需要动态申请。

本地层采用的安全机制主要有：

– SEAndroid：最开始Android只支持自主访问控制（DAC）。例如，Unix文件系统权限管理机制就是典型的DAC，因为非特权用户无需管理员授权就能修改其拥有的文件权限，以允许其他用户对其进行访问。后来Android逐渐将Linux的那一套SELinux强制访问控制机制（MAC）引入到框架层中，称为SEAndroid。在该机制中，只能由管理员约定哪个用户能够访问什么文件。MAC的缺点是很难恰当地对访问控制策略进行配置。

– OTA更新验证：Android对系统固件OTA（over-the-air）更新包也要求进行代码签名，以防止用户安装恶意固件补丁。

内核层采用的安全机制主要有：

– 数据执行保护：硬件级数据执行保护最早由AMD实现，即Never Execute（NX），而Android自ARMv6以后也实现了类似功能，称为Execute Never（XN）。Android内核可以指定特定内存区域为不可执行，当程序试图执行该区域，处理器就会生成一个错误并提交给系统内核，后者将终止该进程。应用程序需要在编译时添加相关标识才能打开数据执行保护功能。

– 地址空间布局随机化：地址空间布局随机化（ASLR）用于增加应用进程地址空间的熵，从而避免攻击者轻易获取程序内存布局。ASLR也需要在应用编译时打开相关配置。

– boot loader锁：第三方厂商通常会对boot loader加锁，它其实是一种代码签名。厂商一般将可信源存储在只读的内存芯片中，当系统启动时，最底层的boot loader程序会验证后续启动的boot程序是否来自该可信源。

1.3 国内外研究现状

1.3.1 传统平台的漏洞挖掘技术

漏洞挖掘技术主要分为被动漏洞挖掘和主动漏洞挖掘两类，如图1.3所示。被动漏洞挖掘是对已知漏洞的部分信息来重新发现漏洞，主动漏洞挖掘是指在目标软件中发现未知漏洞。

第 9 页

漏洞挖掘技术漏洞主动挖掘漏洞被动挖掘手工分析动态分析静态分析攻击分析补丁分析缺陷假设模糊测试符号执行污点分析机器学习抽象解释模型检验……

图1.3 漏洞挖掘技术分类

被动挖掘技术主要包括攻击分析和补丁分析。

攻击分析是指通过直接分析漏洞利用攻击行为来发现被利用的漏洞本身的方法。主流攻击分析大多基于蜜罐实现。蜜罐技术通过构建特定设备、网络等配置下的环境（即蜜罐），诱使攻击者对蜜罐内的目标实施攻击，从而达到对攻击行为的捕获和分析的目的。Anthony[17]首次给出了蜜罐的定义、价值和实现方案，厘清了对蜜罐技术的各种误解。Jedidiah等人[18]提出了基于模拟Minos蠕虫架构的蜜罐技术，用于捕获和分析攻击。采用这种架构的好处是，基于控制数据破坏的漏洞利用行为可以在控制流劫持的关键点被分析人员终止。He等人[19]提出了一种基于IaaS云服务的蜜罐，用于收集并分析僵尸网络流量。Leita等人[20]提出了针对0-day漏洞利用攻击的分布式蜜罐SGNET。SGNET能够避免传统方法的高度依赖于用户交互的问题。Suh等人[21]提出了一种基于动态信息流追踪的蜜罐技术，能以几乎可以忽略不计的性能代价显著提高对攻击检测效果。Crandall等人[22]实现了DACODA蜜罐系统。该系统用蜜罐收集的漏洞利用攻击的额外约束，然后基于符号执行求解约束，从而达到预测攻击变种的目的。Portokalidis等人[23-24]实现了基于x86模拟器的蜜罐Argos，能够在程序执行过程中通过追踪网络数据识别非法跳转指令、函数地址、指令等。

补丁分析作为另一种被动挖掘技术，是指通过分析漏洞补丁程序来检测被修复的漏洞的方法。补丁分析的核心问题是对修复前后的二进制程序进行二进制比对。Flake[25]提出了一种结构化的二进制程序比较方法，方法的核心是对出现在两个相似但版本不同的二进制程序文件的同一组函数，启发式地构造同态结构。Park等人[26]实现了二进制比较工具SCV。SCV对汇编代码中的结构和常量信息提取摘要，通过比较这些信息来得到二进制程序间的差异。Gao等人[27]提出了二进制差异比较工具BinHunt。不同于之前基于句法差异的二进制比较方法，BInHunt能够检测二进制的语义级差异。Brumley等人[28]提出了基于补丁分析的自动化漏洞第 10 页

利用方法。在实验中，他们利用Windows更新包成功对5个Microsoft程序生成了漏洞利用程序。Wang等人[29]提出了一种基于补丁分析的内存覆盖漏洞的检测方法，并利用符号执行成功解决了检测中的多重循环问题。

漏洞主动挖掘技术种类繁多，主要包括手工分析、静态分析和动态分析三大类。每一种类型下又包含多种具体的技术方法，图1.3中所列出的是其中最典型的一部分方法。

人工漏洞审查是指通过手工分析的方式来发现漏洞。人工挖掘虽然是最原始的漏洞挖掘方法之一，但至今仍然发挥着巨大作用。相比自动化漏洞挖掘技术，人工分析可能更有助于探索新漏洞类型。Weissman[30]提出了一种称为缺陷假设法的程序验证方法。缺陷假设法是一种入侵预测技术。分析人员通过分析目标系统的规格说明书和帮助文档，枚举可能存在的缺陷。这些被预测的缺陷的优先序综合考虑了发生概率大小、漏洞利用难易程度等因素。缺陷假设法之后多用于程序缺陷和安全漏洞的人工分析过程[31]。人工漏洞分析过程中经常会需要逆向。IDA

Pro[32]是目前功能最完善、最智能的交互式静态反编译工具。它支持Windows, Mac

OS和Linux等多种操作系统。可以说，IDA Pro已经成为了漏洞挖掘和恶意代码分析必不可少的工具。此外，文献[33-35]也进行了相关研究。

抽象解释是基于有限集单调函数（特别是格）来刻画程序语义，从而对程序漏洞等程序行为进行可靠性近似的理论。简单地说，它能够通过局部推演计算出控制流、数据流等语义信息，而不需要涉及全局性的计算。Cousot[36]首先提出了将程序语义抽象为数学结构，然后用抽象解释理论刻画程序执行特征。Cousot此后又发现[37]基于抽象解释的程序分析方法等价于使用程序分析框架，并针对形式化语义对程序分析框架提出了系统化的设计。他还研究了[38]在面向一般化的句法、语义和抽象时，如何对时序逻辑进行抽象表示的问题。Astree[39]首次实现了对10万代码行规模级别真实工业程序的抽象解释静态分析。它能对实时嵌入式工业软件进行近似的抽象解释，从而自动化证明缓冲区溢出、指针误用、算术溢出等运行时错误的存在性。Astree的发布使得抽象解释开始得到真正的实际应用。

模型检验也称属性检验，它针对给定系统的有限状态机模型，用穷举的方式自动化检查该模型是否满足给定约束。对于漏洞挖掘来说，这些约束可以是能引发系统崩溃等问题的关键状态条件。ANF DATA[40]研究了ANSI C99标准下C语言在内存分配、锁、中断处理时可能存在的漏洞。他们基于有限自动机刻画了这些漏洞，实现的Stanse程序分析工具能有效挖掘大规模程序漏洞。Holzmann[41]发现传统静态分析工具分析范围过广，往往报告所有可以计算的结果而不是那些可能存在缺陷的部位。他提出了一种简单有效的源代码分析工具UNO，能够对未初始化变量使用、空指针解引用等用户属性进行模型检查。Chen[42]提出了一种基第 11 页

于改进的有限自动机的形式化方法，能在安全相关的软件中寻找漏洞并验证其存在性。他将目标程序转化成下推自动机，并将安全编程规范用有限自动机编码为安全属性，然后检查程序模型是否遵从这些属性。他将所提出的方法实现为MOPS程序分析工具。Ball等人[43]提出用基于反例驱动的自动化模型检验方法发现程序错误。他们提出了一种快速轻量级的自动化定理证明器Zapato，利用无量词一阶逻辑确定程序路径的可达性，实现对程序安全属性的自动定理证明。Ye等人[44]提出用模型检验检测源代码中的UaF漏洞。他们结合经典的静态分析方法（如污点分析和符号执行）提取程序语义模型，然后配置UaF安全约束，最后进行针对UaF漏洞的模型检验。此外，文献[45-48]也进行了相关研究。

模糊测试是一种通过构造异常程序输入达到软件漏洞检测的自动化软件测试技术。这些异常数据包括无效、非预期或随机的数据。通过监控程序在注入给定输入后的运行行为，如崩溃、断言处理、内存泄露等，测试人员得以发现目标程序的潜在问题。Miller等人[49]首次提出了模糊测试的漏洞挖掘方法。他们在研究操作系统实用程序的鲁棒性时，对其注入随机的异常输入流时。他们测试了6个版本的UNIX操作系统的90个实用程序，模糊测试能导致24-33%的程序发生崩溃，这其中包括了编辑器、命令行程序和文件格式化程序。SPIKE[50]是最早的一批通用网络协议模糊测试器。SPIKE引入了独特的基于块的模糊测试策略。协议格式一般由相同原语的不变量、块和变量构成。基于块的变异策略会对每个单元替换成变异的字符串，其优势在于新样本离原始样本较近、不会破坏协议格式。它提供了对HTTP、FTP等多种协议的支持。SPIKE基于低级C语言实现，于2000年开源。Peach[51]是2007年发布并至今仍然受到追捧的一款综合模糊测试工具。它支持进程监控和模糊测试两个部分。其中，Peach通过代理机制来实现进程监控，通过XML配置文件来定义目标程序输入数据的结构、类型和内部依赖。此外，文献[52-75]也进行了相关研究。

污点分析会记录对污点数据进行操作的指令，然后依次解释传播，从而得到被污染的所有指令集合所形成的程序路径。Denning等人[76]研究了保证程序信息流动的机制。他们利用基于格的数学框架来对信息流进行形式化建模。这项工作为污点分析技术的发展打下了基础。Juan等人[77]提出用动态污点分析对协议格式进行逆向，辅助漏洞挖掘。协议的具体实现在处理接收到的应用数据时，会体现出一些协议格式相关的特征。以协议数据为污染源，动态污点分析能够识别敏感协议域。他们将所提出的方法实现为Polyglot工具。Lin等人[78]用污点分析收集协议数据的每一个字节对应的执行上下文信息，然后通过聚类获得协议格式。协议中那些层次化的非扁平结构往往被不同的执行上下文处理，因此他们的方法取得了较好的效果。Clause等人[79]提出了通用的动态污点分析框架Dytan。Dytan第 12 页

具有较高的灵活性和可定制性，允许基于数据流和基于控制流的保守污点追踪，且不需要依赖对运行时系统的定制。此外，Clause等人还提出了[80]一种基于动态污点分析的程序输入安全关键域定位方法。该方法在程序输入进入程序时对其进行标记，在程序执行时动态追踪这些输入数据的传播，最后当观察到程序错误时，识别与错误相关的程序输入域子集。他们将该方法实现为Penumbra工具。Kang等人[81]提出了一种改进的动态污点分析框架DTA++。他们首先基于信息保持变换检测隐式控制流依赖，然后为这些控制依赖关系增加额外污点项，从而避免了沿着所有控制依赖关系无区分地传播污点。Wang等人[67]利用污点分析识别流入安全敏感API的输入数据字节，然后知道模糊测试修改这些指定字节，可控地产生畸形样本。用这种方法产生的样本能保持原有文法结构，同时又增加了容易触发漏洞的畸形值。

符号执行将程序变量视为符号，根据程序语义进行符号推理。Boyer等人[82]于1975年提出了形式化程序调试辅助系统SELECT，这被认为是符号执行的开山之作。SELECT系统性地处理LISP语言程序的所有代码路径。对每条路径，SELECT返回一个简化的由输入变量引起路径执行的条件约束。对于那些线性等式和不等式，SELECT能够返回满足这些约束的测试用例。用户可以在任意程序点以符号化可执行断言的形式插入约束条件。这些条件能使得系统能够选择用户指定域值内的测试用例。SELECT还可以用来判断程序路径可满足性。King[83]明确给出了符号执行的概念，并讨论了符号执行与程序证明间的关系。他实现了基于符号执行的程序测试和调试系统EFFIGY。该系统包含了标准调试组件、符号表达式管理和证明组件、简单的程序测试管理组件和程序验证组件。Bush等人[84]提出了一种基于静态符号执行的编译时分析方法，能够检测大规模真实程序的动态缺陷。他们追踪源码的执行路径，对内存进行符号化抽象建模，最后通过提供缺陷相关的上下文信息来报告模型可能存在的不一致性问题。Das等人[85]提出了一种新的多项式时空开销的局部程序验证算法。他们对安全属性相关的路径分支建立静态符号约束模型，以检查安全属性相关的程序状态。他们实现了ESP原型系统，能避免全路径敏感分析的指数级性能代价。此外，文献[86-110]也进行了相关研究。

近年来，随着人工智能热潮，围绕如何应用机器学习的方法来挖掘漏洞，涌现了不少相关研究。DEBIN[111]可以利用机器学习恢复x86/x64/ARM精简二进制程序中的名字、类型等调试信息。它能基于决策树分类模型区分寄存器分配型变量和内存分配型变量。此外，它还能基于概率图模型对有意义的变量/函数名字和类型进行结构化预测。DEBIN所用模型训练自数千个开源的非精简二进制程序。Wang等人[112]提出用n-gram语言模型来检测漏洞。他们将程序表示为句柄序列，然后用n-gram模型计算其概率值。概率较低的序列表明这种程序行为很少出现，第 13 页

很可能存在漏洞等异常行为。Godefroid等人[113]提出用LSTM深度学习模型实现自动化测试用例生成。他们详细分析了PDF文件的复杂格式，并针对Microsoft的一款PDF解析程序，实现了模糊测试工具。他们利用深度神经网络学习正常PDF文件格式，然后对个别数据域引入随机扰动，产生畸形样本。Lv等人[114]实现了基于深度学习的模糊测试框架SmartSeed，产生高质量的测试用例。他们用深度神经网络学习输入样本中潜在的敏感域，从而能够引导模糊测试对敏感域进行针对性的畸变。他们的方法有效提高了模糊测试触发漏洞的能力。Grieco等人[115]提出基于深层神经网络预测样本能否触发漏洞，并实现了VDiscover系统。他们提出了一系列轻量级的静态和动态特征提取算法，用于提取特征。他们的方法能够以合理的精度有效预测哪些程序存在危险的内存崩溃漏洞。Kim等人[116]提出一种基于SVM的可扩展的相似漏洞代码检测方法。针对现实存在的漏洞代码复用现象，他们提出用机器学习来学习漏洞代码的相似性，对相似的脆弱代码判定为存在克隆行为。Li等人[117]提出VulPecker系统，基于机器学习判断给定的程序是否存在漏洞。VulPecker对程序补丁提取特征，然后结合多种代码相似度算法训练模型。Li等人后来又提出[118]用深度神经网络实现静态漏洞检测，以避免人工特征工程代价。他们提出用代码部件来表示程序，并基于词法分析将代码部件转成特征向量。他们通过用深度学习模型学习漏洞程序特征，来检测新程序中的未知漏洞。

1.3.2 Android漏洞挖掘技术

传统漏洞分析技术已经不能完全适用于Android平台，原因如下。第一，移动智能终端采用了Android和iOS等移动操作系统和ARM等嵌入式处理器，这不同于传统PC的体系结构。第二，Android应用编程模型采用的是多入口的程序架构，这也与传统程序不同，直接影响了传统漏洞分析技术。第三，Android系统实行了较严格的安全机制，在一定程度上限制了代码执行等漏洞形式，同时也引入了新型安全漏洞。第四，Android应用由于Dalvik字节码容易被反编译的特点，普遍采用更复杂的加固机制来对抗破解，这无论对手工还是自动化漏洞分析，都构成巨大障碍。第五，新的应用场景改变了应用漏洞的危害程度和表现形式，如移动终端更关注以电话薄、短信记录和地理位置为代表的隐私数据。以上新情况均要求研究者改进已有漏洞分析技术或者提出新的方法。

Android常见漏洞类型包括：缓冲区类漏洞（CWE-119）、权限类漏洞（CWE-264）、资源管理类漏洞（CWE-399）、数据泄露类漏洞（CWE-895）等。缓冲区类漏洞指内存拷贝不当导致的堆栈溢出、因访问不当导致的越界读写等问题。权限类漏洞指因缺少权限检查而使攻击者能以高权限执行代码的问题。资源管理类漏洞是指UaF、类型混淆等与内存指针有关的问题。数据泄露类漏洞是指第 14 页

对设备上的敏感数据进行不安全的存储和传输，从而导致其被攻击者获取的问题。Android还存在跨站脚本、数据库注入等其他漏洞类型。

Android终端上的漏洞可有多种触发路径。例如移动浏览器中的漏洞，可以通过访问恶意网页来远程触发。文件解析库中的漏洞，可以通过向应用提供恶意文件，实现远程代码执行。手机本地的提权漏洞，可以通过组件间通信获取高权限进程的上下文、并在其中执行攻击代码。

从2010年以来，以Android平台为主的移动漏洞挖掘一直是安全领域学术研究的热点问题。国际顶级安全学术会议基本上每年都会设立一个专门的Android安全版块。在国内，包括北大、清华、上海交大、复旦大学、中国科学院大学、国防科大、阿里、360等在内的多家科研单位和企业，都发表了与Android漏洞挖掘相关的研究报告和学术论文。我们根据Android架构应用层、本地层、内核层这三个层次，对现有研究进行介绍，并在表1.1中对它们进行了分类和总结。

表1.1 当前Android漏洞挖掘的主要技术

检测层次

缓冲区类

漏洞大类

资权限类

源管理类

数据泄露类

其他

静态

方式

需要动态

混合

源码

使用模拟器

修改系统

方法

应用本地内核层层层

Androguard

● ● ● ●

Drozer

Dynodroid

Android S2E

Taintdroid

Flowdroid

●

● ●

●

第 15 页

AAPL

Harvest

UIPICKER

Acteve

Condroid

AppIntent

IntelliDroid

OSV-Hunter

XPMChecker

Wu, et al.[151]

Chizpurfle

Lee,

al.[154]

Armando,

al.[155]

●

● ●

●

Wu, et al.[157]

Xing,

al.[158]

DroidScope

Invetter

●

第 16 页

Kratos

Feng,

al.[165]

●

BinderCracker

DexFuzz

ADDICTED

Aafer,

al.[181]

●

BOOTSTOMP

Hay,

al.[184]

Dave,

al.[185]

Shkator,

al.[186]

Zhang,

al.[188]

MangoFuzz

DIFUZE

ADDFuzzer

Charm

Verdult,

al.[205]

●

● ● ●

●

在应用层，Google提供了开源的Android逆向和分析工具Androguard[119] 。第 17 页

Androguard能够将DEX/ODEX/APK等二进制格式映射到Python数据结构进行管理，并提供了面向基本块、指令和权限的静态分析API。Androguard还能对用户给定的应用提供漏洞风险评估。Drozer[120]提供对Android应用的全面安全评估。它允许分析人员直接与Dalvik虚拟机、其他应用的IPC端口以及底层操作系统进行交互，从而能确认开发者在应用和设备开发过程中没有引入漏洞风险。Drozer还提供了一些工具来帮助用户使用和共享公开的远程漏洞利用代码，提供了丰富的漏洞分析和漏洞利用功能。Machiry等人[121]提出了一种无须修改应用就能实现自动用例生成的框架Dynodroid。它针对UI事件进行非侵入的模糊测试，特别地，它考虑了事件序列间的关联性。Kang[122]实现了Android全系统混合符号执行平台Android S2E。他使用全系统模拟器来解决符号执行的环境依赖问题，并针对符号执行和具体执行的切换问题提出了改进。Android S2E能对本地应用进行覆盖率测试。Taintdroid[123]是最早、也是目前为止被使用最多的面向Android平台的动态污点分析工具，它标记踪污染源API产生的数据，并在Dalvik虚拟机指令级细粒度和文件及进程间通信级别粗粒度污点跟踪，在污点出口API使用的数据中检查污点标记。但是该方案缺乏控制流分析，也不支持native代码。Flowdroid[216]是著名的开源静态分析项目，它移植了Java上的基于中间表示的程序分析工具soot，针对Android多入口问题，构造辅助主函数作为调用图的唯一入口，并在此基础上利用多种先进的静态分析技术提供了上下文相关的控制流和数据流污点分析。Lu等人[124]实现了应用隐私泄露自动检测系统AAPL。AAPL基于多个专门针对Android应用提出的静态分析技术，包括有条件的控制流识别和联合流追踪。AAPL还是用了一项称为同行投票的新技术，用来过滤大部分合法隐私泄露。Zhou等人[125]分析了8个流行的Android智能手机，发现厂商手机镜像没能合理地保证权限模型。他们实现了Woodpecker系统，用来识别这些泄露的权限。Rasthofer等人[126]针对应用的动态加载这一高危行为实现了Harvest检测方法，他们采取了更加轻量级的方法，仅仅动态运行程序的一部分切片，就能提取所需运行时变量值。Grace等人[127]实现了RiskRanker，可以检测应用程序的动态加载加解密行为。Nan等人[128]针对应用界面的敏感输入域提出了一种自动化识别方法，并实现了UIPICKER工具。它基于自然语言处理和分类算法，检测用户界面中可能的隐私数据域，并追踪到程序中的具体处理操作。Anand等人[129]提出用符号执行来遍历应用UI界面的所有可能的用户UI操作、达到UI界面模糊测试的目的，并实现了符号执行系统Acteve 。Acteve是最早将混合符号执行技术应用到Android的研究之一。Schutte等人[130]改进了Acteve，结合静态分析，实现了对动态加载、敏感函数调用等关键代码的定向符号执行。Yang等人[131]采用污点分析为导向，提出了事件图约束下的混合执行技术，通过自动化生成测试用例并触发应用执行，由第 18 页

领域专家判断应用的隐私敏感操作是否符合用户意图。Wong等人[132]对Android应用符号执行技术的事件序列生成和网络依赖进行了细致的改良，进一步提高了分析覆盖率。Mendoza等人[133]提出对移动应用的app-to-web类API通信进行静态分析，检测应用与其对应的web API服务的输入验证逻辑的不一致性漏洞。作者从应用中提取了向web API服务发出HTTP通信template，然后将其中包含的输入验证约束与通过黑盒测试提取的服务端验证逻辑进行比较。作者实现了WARDroid分析工具，并测试了10,000个应用，发现有4,000个都使用存在这种漏洞的API。Yang等人[134]分析了基于HTML5的应用跨域通信机制hybrid

postMessage，发现了一种新型漏洞OSV。上述通信机制没有严格检查消息的源信息，这样，攻击者可以向WebView注入恶意代码，向任意接收方发送消息并获取他们的隐私数据。作者在文章中提出了一种轻量级的OSV漏洞静态检测方案OSV-Hunter ，检测发现有74个应用存在这一问题。Zhang等人[135]发现了应用内嵌Web浏览器的新型漏洞——Web API跨角色资源管理漏洞XPM。作者提出了静态检测工具XPMChecker ，对80,694个应用检测发现4.8%的应用存在上述漏洞。Oltrogge等人[136]对在线Android应用生成服务进行了安全性评估。他们通过对应用生成指纹，从而建立起应用与生成器的关联。基于这种关联方法，他们发现Google Play11.1%的应用都是基于在线生成器自动生成的。作者通过结合动静态分析和人工分析，发现自动生成器的生成模型存在代码注入等漏洞。Yang等人[137]设计实现了针对单点登录SDK的漏洞挖掘工具。它能够高效地检查单点登录类应用SDK的逻辑正确性、识别漏洞。Pan[138]等人针对具体上下文时的应用隐私泄露检测问题，实现了流级别的流相关语义提取以及与给定信息流自动关联，实现了FlowCog工具。FlowCog通过静态控制流或数据流依赖检测，来发现所有与给定流相关的Android视图组件，然后基于自然语言处理来推测被提取的语义是否与给定流相关。Zhou等人[139]发现可以通过分析环绕声音信号来刻画移动设备屏幕上的点击动作。基于这个发现，他们实现了基于声音分析攻击的屏幕模式锁破解工具PatternListener。它利用目标设备的扬声器和麦克风播放一段人耳无法听到的声音，然后记录屏幕点击时反射的声音信号。Wei等人[140]提出了一种跨语言数据流分析技术，实现对Android应用的漏洞检测，并构建了相应的分析框架JN-SAF。JN-SAF能够高效地计算流敏感和上下文敏感的指向性（points-to）信息，从而有效地串联了Android应用的Java代码和C/C++本地代码，实现了对跨语言类型的漏洞的有效检测。Lee等人[141]针对PWA应用进行了系统的漏洞分析。PWA应用是近年来新出现的一类Web应用，能提供类似本地应用的浏览器体验。他们在主流浏览器和流行的三方推送服务中发现了大量设计缺陷和漏洞，使得它们容易遭受钓鱼风险。他们针对这类漏洞，提出了一种新的侧信道攻击方法，能第 19 页

够推测用户在PWA应用中的浏览历史。Murali等人[142]提出了一种基于深度贝叶斯网络的应用API误用漏洞检测方法。他们通过建立一个话题模型和神经网络结合的模型，来对代码的语义和行为进行关联。Xia等人[143]提出了一种基于动静态协同分析的高效、实时的应用漏洞审查技术。他们首先提出了一种新的称为近似执行的动态分析技术，能够模拟程序的一部分代码的执行并在每个程序状态实现自定检查。然后他们用近似执行对高效的激进静态分析进行误报剪枝。ISEC[144]提供了应用组件模糊测试工具Intent fuzzer，能针对Intent消息数据进行畸变，对应用组件进行模糊测试。Sasnauskas等人[145]提出了一种针对Intent消息的更完善的模糊测试框架。他们提出了一种新的结合了静态分析和随机用例生成的模糊测试技术，通过静态数据流分析解析应用组件的Intent接口格式，从而能生成可被组件接受的高质量的Intent消息。Yang等人[146]提出了一种基于Intent消息模糊测试来检测应用权限泄露漏洞的方法。他们通过收集并利用模糊测试过程中应用的运行时轨迹，提高样本通过率和权限漏洞挖掘效果。Joshua等人[147] 实现了针对Android浏览器的模糊测试工具BrowserFuzz,和chrome fuzz。

在本地层，Wu等人[151]分析了10个代表性Android系统镜像，研究厂商对系统的定制化修改的安全问题。对每个镜像，他们用物源分析将镜像中的应用分成三大类：源自AOSP的应用、厂商定制的应用、第三方应用。然后他们对预加载应用进行权限分析，以找到那些获取过高权限的应用。最后，他们针对重代理漏洞和隐私泄露漏洞进行了漏洞分析。结果表明，厂商定制极大地损害了Android设备安全，并对他们检测到的存在的漏洞问题负全责。Wang等人[152]实现了本地层强制控制访问框架FlaskDroid。他们借鉴了SELinux，针对Android中间件语义提出了一种高效的安全策略语言。他们通过对选定的隐私保护等安全模型实现策略驱动的初始化过程，显示了该框架的灵活性。Iannillo等人[153]提出了针对厂商定制本地服务的灰盒模糊测试工具Chizpurfle。Chizpurfle能在未修改的真实设备操作系统上运行，从而能有效应对未开源的厂商系统。它并能对系统服务进行自动发现、模型测试和采样。Lee等人[154]分析了本地层Zygote进程的创建模型。Android系统设计了Zygote服务来加速应用启动，但是作者发现Zygote削弱了Android的地址空间布局随机化ASLR机制。所有应用进程都被Zygote以几乎相同的内存布局初始化。他们实现了能绕过ASLR的远程和本地攻击，实现ROP漏洞利用。Armando等人[155]发现了一类未被披露的Android系统新型漏洞，可被利用来实现DoS攻击。他们讨论了Zygote服务的设计缺陷，发现了一种影响所有Android版本的漏洞。针对发现的漏洞，他们提出了两种不同的轻量级漏洞修复方案。360安全[156]披露了框架层图形子系统的libcutils共享库存在严重的整数溢出漏洞。利用该漏洞，可以破坏堆从而获得system_server权限。Wu[157]发现了框架第 20 页

层Media server服务的数个整形溢出漏洞，漏洞影响波及89%的Android用户。利用这些漏洞，攻击者可以实现远程执行，或者通过引发设备重启并耗光所有电量来实现DoS攻击。Xing等人[158]首次系统性地研究了Android框架的更新机制。他们围绕本地包管理服务PMS进行审查，发现了一种成为Pileup的新型漏洞。利用该漏洞，攻击者可以在低版本框架策略性地申请一组权限和属性，并等到升级后再提权。Yan等人[159]实现了DroidScope，利用VMI，提供接口用于监控硬件层、系统层和Dalvik虚拟机层，试图利用系统调用、Java调用构建内核层和框架层的行为语义。zergRush[160]和GingerBreak[161]是著名的Android Root方法，分别利用了具有root权限的vold服务的漏洞。zergRush利用库中字符指针数组argv和字符数组tmp的双重栈溢出漏洞，最终触发对argv数组的UaF，实现任意对象劫持，完成提权。GingerBreak通过一个负数索引绕过handlePartitionAdded()函数只针对最大值的有符号整数检测，进而能够实现对mPartMinors数组位于堆上之前的元素的访问。Ongtang等人[162]提出一种安全应用交互系统框架来实现应用安装时权限授予和运行时权限管理。他们通过修改Android框架层，来提供具有丰富语义的应用安全策略及其管理机制。Zhang等人[163]实现了Invetter，结合及其学习和静态分析来定位本地层系统服务的敏感输入验证等容易出错的关键部位。Invetter在8种系统镜像中找到了103处敏感部位，最后确认了至少20个安全漏洞。Shao等人[164]研究了Android本地层的不一致安全管控问题。他们实现了分析工具Kratos，对整个框架层进行路径敏感的数据流分析，通过建立精确的函数调用图来识别那些运行第三方应用访问敏感资源、从而违背安全策略的路径。他们发现了包括后台隐秘摄像、非法记录按键等安全威胁和漏洞。Feng等人[165]研究了100多个针对Binder本地服务的漏洞攻击案例。他们发现大部分漏洞产生的原因是由于人们对安全边界的概念非常模糊，而实际安全边界是位于系统开发者自身的。由此，他们提出系统开发者需要对Binder服务接口进行有效的测试和防护。Huan等人[166]实现了自动化的BInder服务测试框架BinderCracker。BinderCracker针对Binder服务的客户端事务数据有效性验证代码，进行了参数感知的模糊测试。他们在6个主要Android版本中发现了超过100个漏洞，其中部分漏洞能造成提权代码执行和永久性的DoS。Kim等人[167]对Android的OpenSSL PRNG本地服务进行漏洞审查。他们发现由于Zygote进程对每个应用使用相同的OpenSSL初始化过程，这就导致其PRNG服务产生的随机数来源于相同的初始状态，进而严重降低了OpenSSL服务的安全性。他们提出了有效方法来恢复OpenSSL PRNG的初始状态。Fahl等人[168]研究了Android使用SSL/TLS协议来保护数据传输时的API误用问题。他们发现，由于缺乏对SSL/TLS API使用的可视化的安全提示，API误用现象非常严重。他们发现这些不合理的SSL/TLS

第 21 页

API使用可以导致中间人攻击。Egele等人[169]研究了核心库加密API在使用过程中是否按照一种能够保证安全性的方式进行。他们针对这种情况开发了自动化的程序分析技术，发现88%的加密API使用存在至少1个错误。他们还提出了针对这一问题的专门修复方案，以增强系统层加密安全。Livshits等人[170]发现第三方库可以通过伪造API，实现在无需用户同意甚至用户反对的情况下访问隐私资源。他们实现了一种基于图理论的算法来及时对每个资源访问进行管控。Backes等人[171]提出了一种库程序检测技术，能够对抗传统的代码混淆。他们能精确地定位库并确定库的精确版本。他们通过从原始库SDK中提取完整的库摘要信息，然后对程序进行长时间跨度的库使用和演变分析。他们在实验中发现，开发者对新库版本的更新非常慢，导致用户长期暴露于漏洞利用攻击的威胁中。Nauman等人[172]实现了安全策略管理框架Apex，用来加强本地层安全性。Apex允许用户选择性地对一个应用授予权限，并且还能对资源的使用增加额外约束。Felt等人[173]研究了权限重分配漏洞，并通过对系统发动真实攻击来展示其风险。他们还讨论了解决权限重分配问题的可能解决方案，并提出了一种新的操作系统级权限重分配防御方案IPC Inspection。Dietz等人[174]针对系统混淆代理漏洞，实现了Quire安全机制。Quire首先追踪远程RPC通信的调用链，然后对通信会话进行轻量级签名，实现对手机的可验证的远程通信服务。Uellenbeck等人[175]研究了系统解锁模式的安全性。基于大规模用户调研，他们评测了真实用户的模式选择情况、而不是理论上对口令空间的考察。基于他们收集的数据，他们发现可以用Markov链来对Android解锁模式的强度进行定量建模。他们还发现，在模式选择过程中，人们存在很大的倾向性，比如左上角和三点长的直线是最常被采用的策略。因此解锁模式的熵值很低，使得Android系统提供的解锁方案不那么安全。Huang等人[176]研究了系统核心服务System Server的DoS安全漏洞。由于System Server设计复杂且对上层应用提供了必要功能，他们猜想System Server可能容易遭受DoS攻击。通过分析源代码，他们发现了System Service并发控制机制的一个通用的设计缺陷，可导致智能手机的单点失效。Cao等人[177]分析了Android专有输入验证漏洞。他们评测了漏洞对应的攻击面和当前Android系统服务的输入验证安全现状。然后他们实现了一种新的输入验证漏洞扫描器，通过对系统服务发送带畸形参数的请求来进行模糊测试。Luo等人[178]实现了框架层漏洞挖掘和自动漏洞利用攻击。他们提出了一种面向本地代码的符号执行技术来发现并利用漏洞。Kyle等人[179]实现了ART虚拟机的自动测试工具DexFuzz。他们结合了域感知二进制模糊测试技术和差异化测试，通过利用虚拟机执行时出现的多个执行模式，实现了自动缺陷测试。Android S2E[122]也能对本地层代码进行基于全系统符号执行的模糊测试。

在内核层，Zhou等人[180]第一次研究了Android驱动定制的安全风险。他们第 22 页

基于实现的新工具ADDICTED来对定制的驱动保护措施实现自动化缺陷检测。他们在修改过的手机上通过动态分析来关联安全敏感设备操作与其Linux设备文件，然后决定这些文件是否在Linux层得到保护（通过将其与官方Android系统进行比较）。Aafer等人[181]系统地研究了一种新的Android系统安全问题，即系统定制所引入的变化是否会导致安全风险。他们对591个定制镜像进行了大规模差异分析，来检测不一致性安全漏洞。他们在研究中发现这些差异问题普遍存在于定制镜像中。Zhang等人[182]研究了现有比较流行而对大众来说却很神秘的各种Android root方案，并围绕漏洞分析、漏洞利用过程的防护情况、私有漏洞利用方案与公开方案的联系等等问题展开研究。他们分析了160个漏洞实例，发现了超过10种从未被公开的设备驱动漏洞。Redini等人[183]研究了移动bootloader程序的设计和实现漏洞。他们调查了4个流行厂商的bootloader程序，讨论了它们应当满足的安全标准和设计原则。他们实现了基于多标签污点分析和动态符号执行的漏洞审查工具BOOTSTOMP，能够定位攻击者输入能够影响bootloader执行的问题部位。他们发现了6个bootloader新漏洞。Hay等人[184]研究了Android bootloader的fastboot接口的安全性。他们在多种设备上发现了多个fastboot漏洞，这些漏洞能够绕过Motorola和OnePlus 3/3T的bootloader的安全启动或设备锁。Dave等人[185] 系统地研究了智能终端中内核预制AT命令的安全性。他们从超过2000种Android智能手机镜像中提取了3500条命令，并通过设备USB接口测试这些命令暴露的功能。他们发现部分暴露的AT命令能重写设备固件、绕过Android安全机制、泄露敏感设备信息、解锁屏幕、隐秘地注入点击事件。Shkator等人[186]发现和揭示了多个远程可利用的智能终端系统漏洞。他们审查了三种不同类型的漏洞，研究其利用方法以及针对真实漏洞利用攻击的潜在修复方案。mempodroid[187]能够利用mem字符设备内存提权漏洞，将print输出信息重定向到proc文件系统的mem文件中，从而可以修改应用的执行程序，开启root权限。Zhang等人[188]系统地分析了与Android统一内存接口ION相关的漏洞，讨论了漏洞产生根源和具体实现决策问题。由于ION通常在不同Android设备上被深度定制，具体漏洞有不同的表现。他们通过静态分析和动态测试，发现了最新Android设备上的大量漏洞，包括拒绝服务和内存泄露。他们提供了如何消除这些问题的ION设计建议。Brendan等人[189]实现了GUI元素重建工具GUITAR，能够自动地从智能手机的系统内存镜像中爬取GUI数据元素，并将其重新组装恢复应用的GUI界面。GUITAR能够对GUI树拓扑结构、绘图操作和运行时环境进行重建。他们的实验结果表明GUITAR能够生成与原始GUI相似度达80-95%的界面，从而揭示了一种新型的系统侧信道漏洞。Corina等人[190]实现了轻量级的Android内核驱动模糊测试工具MangoFuzz，基于随机样本生成来进行非侵入式的内核漏洞挖掘。他第 23 页

们还实现了接口感知的模糊测试工具DIFUZE，能够自动化生产合法输入来触发Android内核驱动执行。他们利用静态分析来生成良好结构的用户态输入。他们在7个Android智能手机上发现了32个新漏洞。He等人[191-192]提出了一种基于遗传算法的新的Android内核驱动黑盒模糊测试方法，该算法根据执行结果判断测试用例参数是否应该保留或进行变异。他们的方法能够将合法参数传递给下一代用例，而对非法参数进行变异，从而使得模糊测试用例能够迅速收敛到有效值域。他们实现了Android设备驱动模糊测试工具ADDFuzzer，测试了大量Android手机内核版本并发现了9个未知漏洞。Wang等人[193]首次系统地提出了一种针对内核double-fetch漏洞的静态检测方案。基于模式匹配方法，他们发现了90个新漏洞，其中5个漏洞得到厂商确认。Talebi等人[194]实现了针对移动系统设备驱动程序的动态分析工具Charm。Charm的核心思想是对设备驱动实现远程执行，使得设备驱动能够在工作站的虚拟机中执行。它只允许底层和频繁的IO操作通过低延迟的定制的USB通道来访问真实移动系统。它无需任何专用硬件，很容易被用于部署分析。Wang等人[195]首次深入研究了内核lacking-recheck（LRC）漏洞，并实现了静态分析系统LRSan来检测内核LRC漏洞。LRSan采用了过程间分析和多个新技术，它首先自动识别安全性检查语句、关键变量及其使用语句，然后对安全检查后的修改行为的存在性进行推理。当发生修改行为而内核没有进行重新检查时，它就能检测到一个LRC漏洞。他们在多个版本内核中发现了19个新的LRC漏洞。usb device fuzzing工具[196-197]能够对手机的USB接口进行模糊测试，它允许用户定义模糊测试器、常见异常类型，并支持MTP、MSC、SCSI、CCID、QCDM等多种协议。文献[147]实现了对SMS-rild驱动的简单模糊测试工具，能够有效挖掘拒绝服务漏洞。Liu等人[198]对Android系统代码应用控制流挖掘技术和人工检查脚本，来检测典型内核漏洞。Coker[199]将SELinux机制移植到了Android系统，并讨论了移植过程中对应用和安全策略的必要修改，以使得SELinux能够在小型设备上运行。Trinity[200]是Linux系统调用模糊测试工具，也能够用于挖掘Android内核漏洞。它通过随机调用系统调用，并试图填充合法的函数参数。以文件描述符参数为例，它会打开管道、扫描sysfs、procfs文件系统和dev目录，然后通过随机网络协议批量创建socket，当一个系统调用需要一个文件描述符时，它随机选取其中一个socket来进行尝试。syzkaller[201]是一款无监督的覆盖率导向的内核模糊测试工具，它能根据内核执行过程中的代码覆盖率来引导模糊测试样本变异。Hendrik等人[202]将多种设备驱动验证技术集成在一个单一的工具链中。他们基于SLICx规格说明语言实现了模型检验工具CBMC。CBMC能从内核文档中提取API规范规则，然后用模型检验检测内存泄露等漏洞。Ashcraft等人[203]提出用系统感知的静态分析方法来发现安全漏洞。他们提出由程序员编写系统有关第 24 页

的插件，通过将其链接到编译器来实现漏洞检测。他们在多个版本的内核中发现了超过100个漏洞。Hazelwood等人[204]将Intel的动态插桩系统移植到ARM平台Pin for ARM，他们针对有限内存和处理能力的嵌入式系统环境，提出了对Pin的多种优化改进。 Verdult等人[205]发现Nokia 6212的NFC协议无需用户同意就能发起蓝牙连接的设计可被利用来安装恶意应用。Bernhard等人[206]提出一种基于组合测试的内核系统调用接口漏洞挖掘方法。他们将Trinity的输入参数建模技术应用到了组合测试中，然后基于ACTS组合用例生成工具实现可配置的测试框架Eris。Wang等人[207]发现智能手机的可编程USB硬件和内核驱动可能会改变端到端USB通信的默认行为。他们提出了一种新的策略来利用USB连接的功能实现攻击，从而进一步印证了这一新问题。Hwang等人[208]提出了一种名叫AppWatch的新机制来对Android内核驱动漏洞进行动态监控，它能够利用系统的页面管理机制来监控目标地址空间。

我们基于四个最主要也最常用的漏洞挖掘技术评价指标[209-214]来对上述研究进行评估。这四个指标分别是：

 误报（false positives）：指将正常程序模式判定为漏洞。

 漏报（false negatives）：指将漏洞模式判定为正常程序模式。

 性能（rutime overhead）：指检测的时间和空间开销。

 人力（manual effort）：指检测中所需要额外的人工分析代价。

具体分析结果参见表1.2，其中对于引起误报、漏报、高性能开销、高人力参与度的项，我们用“+”进行表示。

表1.2 对现有方法的评估

方法

Androguard

Drozer

Dynodroid

Android S2E

Taintdroid

Flowdroid

AAPL

Harvest

UIPICKER

Acteve

Condroid

AppIntent

IntelliDroid

OSV-Hunter

漏报

误报

开销

人力

第 25 页

XPMChecker

Wu, et al.[151]

Chizpurfle

Lee, et al.[154]

Armando, et al.[155]

Wu, et al.[157]

Xing, et al.[158]

DroidScope

Invetter

Kratos

Feng, et al.[165]

BinderCracker

DexFuzz

ADDICTED

Aafer, et al.[181]

BOOTSTOMP

Hay, et al.[184]

Dave, et al.[185]

Shkator, et al.[186]

Zhang, et al.[188]

MangoFuzz

DIFUZE

ADDFuzzer

Charm

Verdult, et al.[205]

由上可知，虽然上述方法针对Android漏洞挖掘课题进行了初有成效的探索，但是这些方法仍然在误报、漏报、性能、人力方面存在一定的不足。

1.4 论文工作

1.4.1 研究内容

本文将沿着Android编程模型的“应用->库->驱动”调用层次，对Android整体的安全性进行自上而下的审查。图1.4展示了本文的总体研究思路。

第 26 页

对象Inter-App

communication

AppApp|特点|

app layer权限全局性执行上下文跨应用行为隐蔽native layerLibsopenclosereadwriteioctl编程风格差异化多线程交织漏洞入口定义不精确syscallkernel layerdriverdriveruser spacekernel space真实硬件依赖性内核修改/刷机保护driver性能要求高

| 漏洞|方法|技术|指标数据泄露漏洞面向Java字节码的跨应用组合混合符号执行静态污点追踪误报混合符号执行漏报UAF漏洞面向二进制代码的局部路径敏感VSA分析VSA分析程序流分析性能资源管理类和缓冲区类漏洞面向内核驱动的ARM ETM硬件辅助灰盒模糊测试二进制反编译人力遗传模糊测试

图1.4 研究逻辑路线图

在第1.2节调研的基础上，我们在这里对Android每一层上引人注意的的关键安全特性进行进一步聚焦。针对如下关键安全特性，我们将引出本文所研究的具体安全问题以及对应的解决方案。

 应用层的核心是组件通信。其表现出来的安全特性，一是组件化内部交互机制，这暴露了许多新型攻击面，例如Activity/Service/Broadcast

第 27 页

Receiver/Content Provider组件、Intent消息、事件机制（GUI、系统事件等）。二是其宽松的应用权限管理（UID和Java虚拟机构成的应用沙盒、签名、动静态权限），使得攻击者能够轻易获取隐私数据。

 本地层的核心是函数库。其表现出来的安全特性，一是碎片化。手机生产商和个人开发者，都可以自由的定制系统框架，而各个系统版本均在市场上占有不可忽略的比例。二是核心层使用了大量三方闭源库（包括厂商库和三方项目）。整个系统共享核心库，但这些库质量良莠不齐，并且缺乏审查。为了实现终端的流畅性，这些库引入了大量轻量级并发优化，并受到高效的多进程管理，例如通过Zygote多进程管理可以按需加载、及时释放本地库。而本地代码相比Java代码还多了一种比较严重漏洞类型，即内存崩溃漏洞，这些漏洞能绕过Android虚拟机隔离，对全系统造成威胁。三是本地层很多功能还是过分依赖第三方。AOSP的官方系统只提供了基础功能。四是大量厂商对本地层闭源，这加大了安全审查难度。

 内核层的核心是驱动和核心内核。其表现出来的安全特性，一是存在不同于传统平台内核的特殊的危害程度、表现形式。通过漏洞提权，泄露终端存在的大量个人隐私数据、或使原本看似安全无关的设备产生安全隐患。对设备驱动漏洞的利用同时也是最简单的root方案。内核漏洞利用能够绕过了大部分漏洞利用缓解机制。二是引入大量第三方设备驱动。内核碎片化严重、芯片厂商代码良莠不齐。丰富并持续涌现的硬件（如多摄像头、指纹识别、重力感应器、NFC等）必然会增加对驱动程序的需求。分析目标增多，使得驱动漏洞挖掘意义更加凸显。三是内核会对移动场景性能优化（如进程间通信binder、匿名共享内存ashmem/pmem、电源管理wake

lock/alarm等）。Android内核无udev或pagefile、并由Init负责创建/dev，这些优化可能引入了新的漏洞。

基于对上述关键安全特性的认识，本文围绕以下Android漏洞高发点（T1~T3）及其安全问题（P1~P3）展开研究。

 应用层漏洞高发点： Android组件，包括应用组件、系统服务组件（system_server/mediaserver）等。（T1）

– 对于该部位，我们的目标是挖掘跨应用组件通信提权漏洞（以数据泄露漏洞为例），其核心问题是如何对一组应用进行整体权限分析。（P1）

 本地层漏洞高发点：第三方本地库，包括应用所依赖的各种多媒体解码库、图形图像加速库、蓝牙库等。（T2）

– 对于该部位，我们的目标是挖掘第三方本地库资源管理漏洞（以UaF漏洞为例），其核心问题是如何对闭源本地库进行二进制分析。（P2）

第 28 页

 内核层漏洞高发点：设备驱动，包括为本地层服务提供底层硬件操作的设备定制的内核驱动程序。（T3）

– 对于该部位，我们的目标是挖掘内核驱动中的内存管理类漏洞，其核心问题是如何对真机内核驱动进行低侵入、低开销的灰盒测试。（T3）

1.4.2 关键问题

结合第1.3节对国内外漏洞挖掘技术的调研，我们发现现有技术在解决前述安全问题P1~P3过程中，存在如下关键问题（Q1~Q3）。

 应用组合漏洞无法被局部地检测（Q1）。具体表现如下：

– 组件通信能突破局部应用权限，使得局部审查难以检测到跨应用越权。（Q1a）

– 传统分析方法对组件数据流和控制流进行简单拼接，容易丢失跨组件的程序上下文。（Q1b）

– 许多跨组件数据流可能是用户授意的，本身未必存在数据泄漏漏洞。（Q1c）

 二进制库VSA分析存在路径不敏感性问题（Q2）。具体表现如下：

– 本地库大量采用轻量级多线程优化，这引入了线程控制流断裂和线程交织等问题。（Q2a）

– 差异化的编程风格可能带来内存地址重置等良性漏洞模式。（Q2b）

– 第三方非标准库的使用会导致程序分析时对漏洞模式的出入口API进行不精确的定义。（Q2c）

 终端内核灰盒模糊测试存在高侵入性问题（Q3）。具体表现如下：

– 基于模拟器的模糊测试技术无法模拟多种硬件设备，导致很多代码无法得到测试。（Q3a）

– 终端内核执行轨迹难以获取，并且在商品机内核上难以应用动静态插桩技术。（Q3b）

– 传统模糊测试的代码覆盖率计算过程严重影响内核运行性能。（Q3c）

1.4.3 解决方案

针对以上提出的关键问题（Q1~Q3），我们分别提出如下解决方案（S1~S3）。

 面向Java字节码的跨应用组合混合符号执行。（S1）

 面向二进制代码的局部路径敏感VSA分析。（S2）

 面向Android内核驱动的ARM ETM硬件辅助灰盒模糊测试。（S3）

1.4.4 创新点

第 29 页

与我们提出的上述方案（S1~S3）对应的创新点（N1~N3）如下。

 提出了针对跨应用数据泄露漏洞的动态检测方法（N1）。实现对一组应用进行整体数据流追踪；自动生成触发跨组件数据流的GUI操等事件序列，然后由分析人员确认该数据流是否符合用户意图，减少了误报。

 提出了精确、可扩展的二进制库UaF漏洞检测方法（N2）。实现启发式的跨线程控制流修复和控制流枚举方法，能够有效检测与并发相关的漏洞；实现基于局部路径敏感分析的良性模式剪枝方法，避免内存地址重置等误报。

 提出了对内核驱动内存管理类漏洞的有效的真机模糊测试方法（N3）。进行覆盖率导向的真机模糊测试；基于ARM ETM硬件低侵入式地计算执行轨迹。

综上所述，本课题将针对Android应用漏洞挖掘技术展开深入研究。课题主要支撑来源于国家自然科学基金-P2P僵尸网络检测关键技术研究（No.21）。

1.5 论文结构

本文后续章节安排为：第二章介绍基于组合混合符号执行的跨应用数据泄露漏洞检测技术；第三章介绍基于局部路径敏感VSA分析的第三方本地库UaF漏洞检测技术；第四章介绍基于ARM ETM硬件辅助的Android内核驱动漏洞模糊测试技术；第五章对本文进行总结并对今后工作作出展望。

第 30 页

第二章基于组合混合符号执行的跨应用数据泄露漏洞检测技术

2.1 引言

Android拥有不断增长的第三方应用源，例如F-Droid、Amazon Appstore、GetJar等应用市场。此类市场中的应用缺乏严格管理、往往鱼目混杂，其安全性成为了安全研究人员重点关注的一大问题。

Android的跨组件通信（简称ICC）为Android应用提供了一套高效的数据交换机制。但同时，它也导致了许多新型漏洞，比如跨应用数据泄露、合谋攻击等。这些漏洞的成因，都是源于某一个应用的一部分功能可以很轻易地被其他应用通过ICC调用来利用。通常，一个用户在智能终端上会安装十几个甚至更多的应用，包括浏览器、阅读器、播放器、地图、游戏、邮件、短信应用等等。这种拥有丰富应用的终端环境，就使得已安装的大量应用的整体安全性变成了一个崭新且值得研究的问题。

跨应用数据泄露漏洞是指，攻击者利用应用中的敏感数据访问API来获得敏感设备数据，但是敏感数据并不直接在该应用内发送到设备外部（如发送给攻击者），而是传递给其他一个或多个应用，并最终由后者的敏感数据发送API泄露敏感数据。对跨应用漏洞进行审查，其挑战在于蕴含脆弱行为的程序执行路径被分散在多个应用中。对已知存在跨应用漏洞的应用集合中的任意一个应用，当它被孤立地进行分析时，往往无法检测出安全问题，因为单独一个应用不会表现出跨应用敏感行为。跨应用敏感行为是所有应用的配合产生的结果。

尽管现有很多研究围绕着单个应用的安全审查问题开展了大量研究[126-156]，很少有研究能够针对一组应用的整体安全性进行研究。IccTA[215]能够对跨应用数据通信进行静态污点追踪，但它不能确定数据流是良性的还是确实存在敏感行为。Convert[216]提出用静态模型检验来检测跨应用提权漏洞，但是它同样无法区分正常行为和漏洞，而且还无法检测数据泄露类型的漏洞。上述静态检测方法由于没有真正执行程序、而只是通过源代码来推测程序状态，其本质上是不精确的。特别是对于隐私泄露检测任务，这一问题尤为突出，因为就算静态分析发现的数据泄露路径确实可以被触发，它仍然无法保证该泄露行为是用户授意为之还是违背了用户意图（误报）。因此，我们提出以混合符号执行[93]为代表的的动态审查技术为主，来检测跨应用漏洞。通过将寄存器视为符号值、记录每条执行路径的所有路径约束、最后利用SMT求解器求解这些路径约束来得到所需输第 31 页

入，混合符号执行实现了自动化的测试用例生成，这为最终动态触发漏洞并对其验证用户意图提供了保证。

混合符号执行通常会面临众所周知的路径爆炸问题。这一问题在跨应用的问题背景下将变得更加严峻，当分析一组应用时，我们往往需要分析应用的每种组合及其执行顺序，这使得传统分析过程变得极为低效。我们提出了一种称为组合混合符号执行的方法，通过限制符号执行沿着给定的跨应用污点轨迹进行，来对给定一组Android应用集合进行高效的动态分析。

在基准测试集以及真实应用集合上的实验结果表明，我们的方法实现了比现有方法取得了更好的跨应用数据泄露检测效率和精度。

本章工作的贡献有：

 实现了对跨应用数据泄露漏洞的自动化动态验证。我们通过动态分析来验证数据泄露能否真正发生、以及是否违背用户意图，从而减少误报。就我们所知，我们是第一个对跨应用通信漏洞进行动态审查的工作。

 提升了对一组应用进行混合符号执行时的性能。我们提出了一种称为组合混合符号执行的新技术，能够有效缓解路径爆炸问题和应用组合开销问题。

 实现了跨应用数据泄露动态审查工具。我们实现了AppWalker，能够在真实应用集合上挖掘跨应用数据泄露漏洞。

本章剩余部分按如下进行组织。第2.2节介绍Android应用基本知识和一些现有的应用审查方法。第2.3~2.6节给出了我们提出的跨应用数据泄露漏洞检测框架的总体架构和设计细节。第2.7节给出了实验结果。第2.8节讨论了本章的不足并进行了总结。

2.2 相关工作

2.2.1 Android基础

Android组件。Android框架定义了4大应用组件类型。最常见的跨组件通信（ICC）机制是Intent。跨应用通信（IAC）类似于ICC，但是它会跨越应用边界。

Activity是应用与用户直接交互的组件，即UI实体的抽象。Activity由窗口和内嵌的UI元素构成。Activity Manager服务负责管理Activity组件、以及处理那些试图通过跨应用或应用内跨组件方式来唤醒Activity组件的Intent消息。这些组件都被定义在Manifest配置文件中。

BroadcastReceiver是另一类接收Intent消息的实体。当应用需要接收一个全局广播的Intent消息（可能包含额外的条件约束）时，需要使用这类组件。例如，如果一个应用需要接受短信相关的消息，则会在Manifest配置文件中（或运行时动第 32 页

态地）注册一个BroadcastReceiver组件，并同时定义一个用来只匹配那些短信相关的Intent消息（即规定其只能接受action属性为_RECEIVED的Intent）的过滤规则。应用还可以配置BroadcastReceiver权限信息，从而限制能向该组件发送Intent消息的应用范围。

Service组件是不涉及UI、在背景执行的应用组件，用户无需直接与之交互。常见的service组件包括SmsReceiverService和BluetoothOppService。Service组件虽然对于用户来说不可见，但仍可以通过Android的IPC机制来进行管理。Service组件通常通过接收Intent消息来实现组件的启动、停止或绑定。Intent消息的发送方可以通过绑定一个service组件实现对service组件内功能的进程间调用。

Content Provider组件提供了对通用共享数据存储的结构化的访问接口。例如，Contact provider和Calender provider实现了对通信录数据项和日历数据项的中心化管理，并使得其他具有相关权限的应用能通过它们来访问通信录或日历。每个应用还可以创建自定义的Content Provider组件，并且可以选择性地暴露给其他应用。这些Content Provider管理的数据一般存储在SQLite数据库或者文件系统路径中。和其他应用组件一样，Content Provider的读写行为也受权限约束。

权限模型。Android权限模型包括API权限、文件系统权限、IPC权限三方面。

API权限用于控制访问高层Android API或应用框架提供的功能，例如获得读取手机状态的READ_PHONE_STATE权限，应用可以调用getDeviceId等敏感API。AID将上层的某一个权限映射为一个组（如camera组）。系统将某个app映射为一个用户，这个app拥有特定权限；在底层将该用户加入对应权限组，更底层linux的用户组权限管理系统可以自动处理应用进程（user）访问特定资源（如照相机）的设备文件时发生的权限关系。早期Android只允许静态权限申请，应用安装后直接获得开发者在Manifest中声明并且用户安装时授权的权限。静态权限申请很不安全，因为如果用户没有在应用安装时关闭敏感权限（有时应用的正常功能也确实需要这些权限、所以也很难完全关闭），用户隐私就很容易遭到恶意应用窃取。

文件系统权限继承自Unix，Android应用沙盒与文件系统权限紧密相关。应用的专有UID/GID默认用于对文件系统中的数据存储路径进行访问授权。同时，由应用创建的文件也会拥有与应用本身所具有的文件访问权限相一致的权限，例如一个应用的私有数据目录下的所有文件的属主和权限都只与该应用的UID/GID关联，其他应用无权访问。对于像SD卡这种公共文件路径，一般有特定的GID。如果需要允许一个应用访问SD卡，就需要额外地将该应用加入上述SD访问组。

IPC权限模型限制了哪些组件能接受哪些Intent消息。这通常是通过定义为Intent消息接受组件的manifest文件中的Intent Filter来进行明确。其实，这类权限的声明和管理可以发生在运行时、库函数、应用内部等不同层次，例如Binder驱第 33 页

动提供的IPC机制也会对消息收发方的权限进行检查。由于Android 6.0

(Marshmallow)以后版本引入了运行时权限模型，应用能够在执行时索取授权，而不是在安装时静态得获得所有权限。但是，对于预装应用可能很难去取消其权限，

而且运行时权限只能用于使用Marshmallow SDK 进行开发的应用。

2.2.2 相关研究

静态应用漏洞审查。除了简单的基于黑名单或者规则的审查方式，最常用的也是研究最多的静态应用漏洞审查方法（特别是数据泄露漏洞）是静态污点追踪。它会首先指定一组入口和出口。它对源数据进行标记，然后对每条接下来的指令污染所有与源数据相关的变量。因此，这种方式能提供数据传输路径的有用信息。

静态模型检验也常用于检测多种常见类型的应用漏洞。

FlowDroid[217]是最著名的并且也仍然是当前最先进的应用数据流分析工具之一，它将静态污点追踪从传统程序分析移植到Android应用分析任务。然而，它只能用于分析单个应用，而不能分析一组应用的整体数据流。

Didfail[218]利用FlowDroid，对一个应用内的每个组件进行静态污点分析。然后，它根据应用的ICC信息连接所有污点路径，从而合成跨组件污点传播模型。不同地，IccTA[215]首先将所有待分析的应用合成为一个单独的应用，然后对合成的应用进行类似于FlowDroid的污点追踪。IccTA的实验结果表明，通过这种方式可以提高跨组件数据流分析精度。

COVERT[216]提出使用静态模型检验来审查跨应用提权漏洞。它进行过程内和过程间控制分析，然后利用这些收集到的信息对每个单独的应用建立静态模型。当它尝试挖掘IAC引发的漏洞时，它对所有模型进行统一的模型检验，从而检查特定漏洞模式的存在性。然而，由于COVERT采用的是可达性分析而不是污点追踪，它无法检测数据泄露漏洞。

动态应用漏洞审查。TaintDroid[123]使用动态污点追踪来检测Android应用中的数据流。作者声称TaintDroid能获得比FlowDroid等静态污点追踪方法更好的精度。但是由于污点分析近似性传播的本质特征以及昂贵的执行开销，污点追踪仍然主要用于极个别复杂情况下的动态验证。

混合符号执行（Concolic execution）结合了具体执行与符号执行，实现了对给定程序自动生成程序输入。当一次具体执行终止时，它收集相关路径约束，然后调用符号执行来求解约束，从而生成新的能触发更深层次的具体执行的程序输入。除了产生程序输入，混合符号执行也常被用于验证程序路径的可达性。

AppIntent[131]是第一个提出来用于分析Android应用的混合符号执行工具。它能产生程序输入来触发应用内局部数据泄露，以供分析人员后续进行审查。第 34 页

ConDroid[130]尝试利用混合符号执行来检测某些无法在常规分析环境中触发的恶意API调用，如逻辑炸弹等。IntelliDroid[132]类似于AppIntent，它也采用混合符号执行来审查单个应用的数据泄露问题。其作者进一步还提出了一种能产生事件序列的新方法，使得IntelliDroid能够执行到应用的内部更深处。

2.3 方法概览

跨应用数据泄露示例。我们使用图2.1中描述的一组应用来展示我们的算法。我们称这组应用为SWE应用集，这个名字源自于这三个应用中每个应用的包名首字母。本文的SWE应用集受到了文献[218]的启发。进一步地，我们在应用中增加了能影响到传统静态漏洞审查方法的、在真实应用上颇为常见的挑战性特征。一类特征是有状态操作。例如，在SendSMS发送的一个Intent消息中，Intent的键值需要通过StringBuilder类通过字符串拼接操作来动态地创建“secrete1”字符串。另一种特征是运行时条件依赖。例如，WriteFile的一条执行路径上包含了依赖于getData()所获取的特定用户输入的分支条件。

在SWE所展示的跨应用数据泄露实例中，SendSMS应用通过调用敏感API

getDeviceId()来获得设备id号，然后通过隐式Intent调用startActivityForResult()将敏感数据发送给其他应用并索取返回值。一旦某个应用（以Echoer应用为例）接受到了这个Intent消息（只要该Intent与其Intent Filter相匹配）并通过调用setResult()对该Intent发送者进行回复，那么SendSMS应用的 onActivityResult()回调函数就会被Android框架调用。它将Intent回复消息中包含的数据（在本案例中为设备id号），通过调用敏感API函数sendTextMessage()，以SMS消息的形式进行外发。注意Android框架规定SendSMS应用需要声明READ_PHONE_STATE和SEND_SMS才能使用这两个敏感API，而Intent接受方Echoer并不需要进行权限声明。对于WriteFile应用也是类似的，后者能够获取位置信息的敏感数据，通过隐式Intent消息将其发送给Echoer应用，接受返回的Intent回复，最终将接受到的Intent消息中的数据写入文件。

第 35 页

(A)public classSendSMSextendsActivity {protected void onCreate(Bundle savedInstanceState) {...Button b = (Button) findViewById(.b);lickListener(newOnClickListener(){public voidonClick(View v) {Intent i= new Intent(_SEND);e("text/plain");String uid= (TelephonyManager)

getSystemService(ONY_SERVICE).getDeviceId();// SRCStringBuildersb= new StringBuilder();("secret");("1");// ra(ng(), uid);if (tTimeMillis()>1483228800) {ctivityForResult(i, 0);// SNK}…}});}protected voidonActivityResult(intrq, intrs, Intent i) {...if (!=null) {String msg= ras().getString("secret1");// ault().sendTextMessage("10086",, msg,,);// SNK}...}}public classWriteFileextendsActivity {protected voidonCreate(Bundle savedInstanceState) {...Button b = (Button) findViewById(.b);lickListener(newOnClickListener(){public voidonClick(View v) {Intent i= newIntent(_SEND);e("text/plain");String curLoc= (LocationManager)

temService(ON_SERVICE).getLastKnownLocation(_PROVIDER).toString();ra("secret2", curLoc);if (getData()==“broadcast") {ctivityForResult(i, 0);// SNK}…}});}protected voidonActivityResult(intrq, intrs, Intent i) {…StringBuildersb= new StringBuilder();("secret");("2");String sinkData= ras().getString(ng());// SRCFileOutputStreamoutputStream;…// check permif (checkCallingPermission(“_EXTERNAL_STORAGE”)==SION_GRANTED) {if (!ns("goldfish")) {(es());// SNK}}...}}(B)(C)public classEchoer extends Activity {protected void onCreate(Bundle savedInstanceState) {...Button b = (Button) findViewById(.b);lickListener(newOnClickListener(){public void onClick(View v) {// check emulif (!ns("goldfish")) {Intent i= getIntent();// ult(0, i);// SNK}…}});}}

图2.1 SWE示例应用集

第 36 页

SendSMS和WriteFile都不会单独地泄露隐私数据（设备id、位置信息）。它们依赖于Echoer来传递这些隐私数据，以避免敏感数据只在单个组件或应用中流动，因为这种情况很容易被FlowDroid等传统组件内分析技术检测到。在这里，Echoer起到了代理的作用。注意Echoer本身不会获取或泄露敏感数据，因为它根本没有调用任何敏感API。

这些应用不仅需要传统的文本数据输入（例如SendSMS的文本输入），也需要Android特有的输入（如对每个应用UI界面的按键点击事件）。由于我们的方法主要基于动态分析实现，这些程序输入需要被恰当地产生和注入，从而能够触发跨应用敏感路径的执行。

系统目标。我们需要构建一个有效且高效的跨应用数据泄露漏洞检测系统。我们确立了如下4个设计指标。

自动化：尽量避免人工分析代价。

有效性：能够以较低的误报率和漏报率检测跨应用数据泄露。

高效性：提升对大量应用进行分析时的分析性能。

健壮性：能够正确处理真实应用。

图2.2描绘了整个系统框架，我们对其工作流程描述如下。

App combinerLink builderCombinerExtended taint tracesLinksCombined AppStatic model extractorXML parserComponentmodel,input specificationAPI ModlerCFG analyzerSymbol instrumentorInstrumented apkInputsAppInstrumentorRunnerHandler instrumentorConcolic engineSolverConcolic executorTaint trace extractorInter-App taint traces

图2.2 AppWalker系统总体架构

跨应用污点轨迹提取：为了能为后续的动态分析提供定向引导，我们预先会对整个待测应用集合进行了一次全局的静态分析，用于提取可能引发数据泄露的跨应用轨迹。我们会对待分析的应用集合提取IAC/ICC信息，并将所有应用组装第 37 页

成单个应用。然后我们对合成后的应用提取接口模型、程序输入数据格式信息、控制流图和跨应用数据泄露污点路径。我们会基于隐式控制流依赖关系来提取事件链，用来对污点路径进行扩展，以保证这些路径能被恰当地执行。

组合混合符号行走：应用集合中的所有应用会被合并成一个单一应用。对于合并后的应用，我们利用一种改进的混合符号执行技术来确定每条跨应用污点轨迹的运行时可达性，并充分自动化地生成那些能够触发轨迹执行的程序输入。具体地，我们会对应用的Java字节码进行插桩（需结合人工植入），来对Android生命周期入口、事件处理函数、轨迹上的变量寄存器以及寄存器相关的赋值语句进行符号化处理。我们还会对用户指定的外部API进行建模，以保证动态分析时它们能够返回预期的值。我们需要在模拟器中运行插桩后的应用并启动每条污点轨迹起点的应用组件，记录路径上的所有分支，然后在对路径的最后一个分支条件进行取反后用约束求解器求解生成的路径约束，最后将得到的解（即程序输入）注入到已插桩应用中的符号寄存器中。这个过程会迭代执行，直到每条跨应用污点轨迹都得到分析。

受控执行和漏洞验证：我们实现了一个简单的动态监控模块，利用混合符号执行生成的输入来执行应用，然后观察整个应用集合的运行时组合行为。程序输入的注入过程将严格按照一种受控的顺序来进行。如果跨应用污点轨迹确实能被执行并且敏感数据的泄露行为确实违背了用户的原本意图，那么我们就能够确认该数据泄露程序路径确实是一个漏洞。

2.4 跨应用污点轨迹提取

我们在动态审查跨应用漏洞之前，首先将应用反编译为soot[221]中间代码，并利用静态污点分析来提取应用集合中的有用信息。我们首先从整个应用集合中提取组件模型，以此为基础我们进而可以提取到跨应用污点轨迹，后者将被直接用于引导动态分析。

组件模型提取。在静态分析阶段，我们首先对应用集合中的每个应用收集其组件信息。组件模型（CM）描述了一个组件能够发送或接收的IPC消息的类型。我们采用Android应用最常用的IPC通信消息，即Intent。我们从应用的Manifest文件中可以提取到如下信息：（a）应用包名；（b）应用内所有Android组件的名字及其权能（如该组件能处理什么类型的Intent消息）；（c）主进程名字；（d）应用请求的权限（被定义在Intent Filter中）；（e）其他应用在访问该应用组件时所需要的权限。Manifest文件中定义的Intent属性包括（消息接收组件的行为，如当接收到action为ACTION_CALL的Intent消息时应用会进行拨号操作）、（action发生所依赖的环境，如设定第 38 页

CATEGORY_BROWSABLE环境类型，应用便可以在浏览器中被启动），

android:mimeType/>（被传输的数据类型）。由于所有元素都按良好定义的XML格式进行组织，我们可以很方便地从Manifest文件中提取到与应用组件有关的所有信息。

一个应用通常需要用户输入来与之交互，这通常通过规定用户必须在特定区域（如应用界面中的文本输入域）中输入数据来实现。通过分析应用的layout布局文件（同样也是XML格式），我们能够静态地确定此类输入区域在应用UI中的具体位置。

此外，我们还需要提取ICC link[215]信息。ICC link能够基于Intent信息对Android组件的不连续模型进行连接。一个ICC link可以形式化地定义为映射l:m->C，即将包含了用于访问目标组件C的Intent信息（如类名、action、category、mimetype、URI）的ICC方法m，映射到目标组件C。ICC link提取过程包括ICC方法识别、Intent信息提取和目标组件识别。Android开发文档明确地定义了用目标组件的Intent Filter来匹配ICC方法的具体规则。如果一个Intent显式地规定了目标Intent接受方，那么我们可以直接对其进行配对。否则，Intent消息将通过隐式方式进行配对，这需要解析Intent Filter。当Intent的发送组件满足另一个组件的Intent Filter中定义的约束时，这两个组件才可以通过ICC link进行连接。有时Intent

Filter可以通过动态的方式进行声明，而不是被静态地定义在Manifest文件中，对于这种情况我们也需要针对性地检查动态声明代码并提取约束。ICC link的提取过程类似于IccTA，更多细节可以参考后者。我们采用IC3[219]来构建ICC link并将其存储于持久数据库中。

应用组装。为了实现跨应用分析，我们采用一种朴素的方法来将集合中的Android应用组装成单个应用。我们提取了每个应用的组件和UI layout文件，然后将其重打包到一个单一apk文件中。对于Manifest文件，我们也会将不同应用的Manifest文件合并成一个文件。这部分工作我们主要基于ApkCombiner[215]来实现。这种组装方式能够减少应用插桩和混合符号执行的复杂性，因为我们可以将整个应用集合当做单个应用来看待，而不需要动态协作。但是，组装后的应用是不完整的，因为它没有指定默认入口，即默认的主Activity组件，我们需要为动态执行指定入口。组装后的应用如何定义默认入口，这取决于在动态分析阶段我们期望具体执行哪条跨应用路径。应用组装中最关键的问题是包名冲突和类名冲突问题，文献[215]对这一问题提出了重突化解算法，本文不再对其赘述。当我们只分析应用内ICC通信时，可以跳过此步骤。

跨应用污点轨迹提取。当一条程序路径跨越了组装前的应用边界时，我们称之为跨应用路径。我们基于连接后的应用代码进行污点数据传播分析。盲目地执第 39 页