FuzzerAPP：Android应用程序组件通信鲁棒性测试

张 密 杨 力 张俊伟

(西安电子科技大学网络与信息安全学院 西安 710071) (zmic@sina.cn)

FuzzerAPP：Android应用程序组件通信鲁棒性测试

张 密 杨 力 张俊伟

(西安电子科技大学网络与信息安全学院 西安 710071) (zmic@sina.cn)

针对Android应用程序的安全性问题，提出一种基于模糊测试方法的组件通信鲁棒性测试方案.首先构造测试集和测试用例，随后将测试用例发送给目标应用程序并收集测试数据，最后对测试数据进行分析.依据测试方案设计并实现了模糊测试工具FuzzerAPP，进而对常用应用程序进行鲁棒性测试.通过对测试数据的分析，发现发送特殊Intent可以导致应用程序的崩溃，甚至引发系统服务的级联崩溃.此外，发现测试集中多款应用程序存在测试模块暴露的问题，可能会导致隐私泄露、拒绝服务等严重安全问题.最后，通过与其他工具的对比，表明测试方法的有效性和测试工具的实用性.

安卓；组件通信；模糊测试；鲁棒性；测试模块暴露

随着Android系统的飞速发展，Android APP(application)的数量也随之不断增长.现有APP分发平台包括Google Play等，通常情况下允许任何开发者在其平台上传应用，导致APP质量参差不齐，安全性难以保障.数量众多的Android APP在为用户提供更多应用和更丰富体验的同时，也会为用户带来一系列的安全与隐私问题[1].

为了应对安全与隐私问题，Android系统已提供了沙箱模型、权限保护等机制[2].这些安全机制通常情况下是有效的，但是，当系统中某一APP组件发送错误或者异常信息给其他APP组件时，可能会引起目标组件的错误行为，从而使上述一系列保护措施效果大大削弱.保护机制的削弱，极大地影响了APP组件间通讯的鲁棒性，使APP组件间进行通信时，可能会遇到信息窃听、组件欺骗、拒绝服务等安全问题.随着Android APP数量的飞速增长以及程序间通信可能存在的上述问题，对APP组件间通信鲁棒性研究需求越来越迫切.

通常情况下，Android APP在正式对外发布前会经过一系列的基本测试.在对APP的测试方面，Android官方提供了Monkey[3]工具，供开发者对APP进行基础测试.其他工具如MonkeyRunner[4]，DroidPilot[5]，Dynodroid[6]等，均可针对某一方面对APP进行测试.

模糊测试[7]是一种通过向目标系统提供非预期输入并监视异常结果来发现软件漏洞的方法.在对Windows和Unix等操作系统的鲁棒性验证方面，模糊测试的方法已取得有效结果[8-10].将模糊测试的方法用于Android系统安全的研究，同样得到研究者的广泛重视.Mulliner等人[11]通过构造异常输入数据来测试Android系统的SMS模块，并在其运行时检测异常.Android Kernel Fuzzer[12]被用来发现Android Linux的核心漏洞.与此同时，模糊测试的方法也被用来研究Android APP组件间通信的安全性.由iSEC partners开发的Intent Fuzzer[13]使用模糊测试的方式来测试在系统中注册组件的健壮性.Maji等人[14]利用模糊测试的方法测试Android系统的IPC机制时构建的，主要通过构造不同类型的显式和隐式Intent测试Android系统预留APP IPC的鲁棒性.DroidFuzzer[15]使用MIME等数据对APP组件中的Activity进行模糊测试.Sasnauskas等人[16]使用静态分析和模糊测试结合的方法测试Google核心APP以及少量第三方APP，测试过程中出现APP重启，甚至是操作系统重启的现象.

在本文中，我们针对Android第三方APP组件间通信的鲁棒性展开测试，探究当输入数据多样化时可能导致的问题.本文设计了一种基于模糊测试的方案，该方案使用Android SDK提供的数据，按照本文中指定的规则自动化构造测试用例.然后，综合时间、效率等因素，将测试用例发送给待测APP组件，最后对目标组件在测试过程中的交互信息以及输出数据进行统计分析.根据该方法设计实现了测试工具FuzzerAPP，并对大量APP进行测试.

通过对大量常用第三方APP的测试和对测试数据的进一步分析，我们发现对APP组件发送特殊Intent不仅可以导致APP崩溃，甚至可以导致Android框架层服务的级联崩溃，进而造成Dalvik子系统重启.我们发现的另一个重要的问题是，包括国内某著名购物APP在内的多款APP存在测试模块暴露的问题.测试模块的暴露会造成用户隐私泄露、APP拒绝服务以及联合其他漏洞对服务器发动DDoS攻击等严重的安全问题.对测试数据结果的分析以及与类似工具的对比均证明了所提出方案的有效性以及测试工具的实用性.

1 背景知识

1.1 Android APP组件

Android APP的组件主要包括4种类型：Activity，Service，Broadcast Receiver，Content Provider.

1) Activity.Android APP与用户交互的每个界面都属于Activity.Activity可以通过Intent启动其他组件，也可以被其他组件启动.

2) Service.Service在后台运行，通常用于为其他组件提供后台服务等比较耗时的操作，比如音乐播放、文件下载等.

3) Broadcast Receiver.Broadcast是一种广泛使用的在APP间传输信息的机制.而Broadcast Receiver是对发送来的广播进行过滤接受并响应的一类组件.

4) Content Provider.Content Provider是Android提供的一种标准共享数据的机制.

1.2 组件通信

Android系统中APP组件间通信主要依靠Intent和Binder.在实际使用中，由于Intent可以动态地选择和绑定目标组件，使得它具有更好的灵活性和多样性，可以更有效地构建测试用例，因此本文选择使用Intent进行测试工作.

在组件通信中，Intent作为需要传递信息的载体存在.Intent负责描述APP中单次操作的动作、动作涉及的数据以及附加数据等内容，Android框架层服务则根据Intent的描述，负责找到处理Intent的对应组件，然后将Intent发送给目标组件完成信息的传递.Intent不仅可用于APP内组件间的通信，也可用于APP间组件的通信.在组件通信中，Intent Filter用于描述APP组件所能响应Intent请求的能力，即该组件可以处理的Intent的行为类型和数据类型等.

在Android系统中，组件之间通过Intent信息和Intent Filter来完成信息的交换.Intent信息包含了对组件通信信息的具体描述，在本文所提供的方案中，我们通过对通信信息——Intent信息中各种描述信息的更改，达到对目标组件鲁棒性测试的目的.通过对组件通信鲁棒性的测试，可以发现组件通信中潜在的问题.

1.3 组件暴露

Android APP的组件分为私有组件和公有组件2类.如果某组件只能接收同一APP内组件发送的Intent，则该组件为私有组件.如果一个组件可以接收到来自其他APP组件发送的Intent，则此组件为公有组件，或称其为暴露组件.公有组件把自身的功能暴露给其他APP的组件，可能会带来包括信息窃听、组件欺骗、拒绝服务等在内的一系列安全问题[17-19].

2 方案设计

本方案主要为了展开对Android第三方APP公有组件间通信的鲁棒性测试.组件通信的鲁棒性是指当Android APP组件接收到携带各类异常或者非预期数据的Intent时，APP能否有效处理.鲁棒性通常是系统在异常和危险情况下生存的关键.对数据处理的鲁棒性同样也是APP正常提供服务的关键.本方案需要构建高覆盖面的Intent作为测试用例，以测试目标组件的鲁棒性.所谓高覆盖面是指构造的Intent要尽可能完全覆盖被测组件的Intent Filter，即在所构造的测试用例中存在完全匹配(成功启动)被测组件的Intent.

在方案的设计过程中，我们参考了Intent Fuzzer[13]工具.Intent Fuzzer工具仅发送空Intent给目标Broadcast Receiver和Service组件，并且只能测试单个Activity，其功能受限且测试覆盖率不高.我们对其改进后提出本方案，并根据本方案形成新的测试工具FuzzerAPP，FuzzerAPP不仅能全面测试各种Activity，也能测试其他相关组件，构造的Intent种类也大大增多.在Android系统中，FuzzerAPP与其他APP的交互关系如图1所示.在图1中，FuzzerAPP作为用户层APP运行于应用程序层.

Fig. 1 Interaction between FuzzerAPP and other APPs图1 FuzzerAPP与其他APP的交互

本方案由5个模块组成，分别为信息获取模块、测试用例生成模块、测试用例发送模块、待测组件选择模块以及结果收集模块.这5个模块的总体架构如图2所示.在图2中，矩形表示组成本方案的各个模块；椭圆表示各模块生成的信息或者是各模块正常工作所需要的信息，比如：图中的Intent信息，既作为测试用例生成模块产生的信息，又是测试用例发送模块所必须的信息.图2中各个模块的功能如下:

1) 信息获取模块.以待测APP的apk安装文件为输入，使用静态分析的方法，通过对反编译文件的分析，输出待测APP的详细组件信息.

2) 测试用例生成模块.以待测APP的组件信息和Android SDK提供的标准Action等数据为输入，根据测试用例生成策略，构建Intent消息.

Fig. 2 Architecture of the test scheme图2 测试方案总体架构

3) 待测组件选择模块.根据待测APP的详细组件信息，判断每一个组件是否为暴露组件.若是暴露组件,则加入待测组件列表.若为私有组件，则略过处理.

4) 测试用例发送模块.按照一定的发送策略，将构建的Intent消息发送给待测组件.

5) 结果收集模块.在测试APP时，收集Android系统、被测APP、测试APP的输出.

接下来，将对本方案中的核心模块和功能进行详细介绍.

2.1 组件详细信息获取

待测APP组件详细信息的获取在信息获取模块完成.该模块主要负责使用静态分析方法对待测APP安装包进行分析.对待测组件详细信息的获取，主要通过以下方式获得：

1) 反编译待测试应用程序安装包；

2) 使用XML分析技术分析AndroidManifest.xml文件；

3) 使用关键词搜索方法分析反编译后的应用程序代码.

通过对AndroidManifest.xml文件的分析，可以获得在APP中使用静态注册方式注册的所有组件详细信息.通过对反编译后应用程序代码的分析，可以获得在APP中使用动态注册方式注册的Broadcast Receiver组件.因此，同时使用2种方法可以获得待测APP的详细组件信息，这些信息包括：

1) 待测APP组件列表信息；

2) 待测APP组件是否定义exported属性，若定义则记录其属性值；

3) 待测APP组件的Intent Filter信息；

4) 访问待测应用程序组件是否需要权限，若需要则记录访问权限.

信息获取模块将以上获得信息，以APP为单位，以组件为索引，分别创建exported，Action，Data，权限数据集.这些组件信息有以下2个作用：1)使用这些组件信息供待测组件选择模块使用，用来确定待测组件；2)在测试用例生成阶段使用，将这些待测组件详细信息与其他数据相结合，共同生成测试用例.

2.2 测试用例生成策略

通过构建策略创建的Intent是否能够匹配第三方APP组件中的Intent Filter以及是否能够成功启动第三方APP组件等，对测试结果的准确性有着重要影响.这里的准确性是指，使用测试用例对待测组件的测试结果是否符合其原本情况.准确性越高，则测试结果的可信度越高，测试结果更具有说服力.为了确保测试结果的准确性，我们需要构建覆盖面尽可能高的Intent作为测试用例.

Intent消息包含Action，Data，Type，Component，Extras等字段.Action和Data是表现Intent动作以及动作所涉及数据的主要字段，在组件通信中的使用频率极高，能表现出组件间通信的特性;Extras字段值具有很好的随机性，可以很好地测试组件间通信的鲁棒性.本方案只创建显式的Intent，因此我们需要设定Component域的值.综上，在测试过程中需指定Intent的Action，Data，Extras，Component域的值，其余字段则默认为空.

本方案基于模糊测试方法，结合测试目标，考虑覆盖面等因素设计如下Intent构建策略：

1) 空Intent.仅指定处理该Intent的目标组件，其余字段为空.例如：Intent{cmp=com.example.appcom.example.app.someComponent}.

2) Action域与Data域的交叉.同时指定Intent的Action域和Data域的值，二者均不能为空.Action和Data域的值设置为每一个标准Action[20]的值与每一个系统支持的Data值组合.例如：Intent{act=ACTION_EDIT;dat=geo:***,***;cmp=com.example.appcom.example.app.someComponent}.

3) 仅指定Action域、Data域为空或为随机值.Action域的值来自Android SDK提供的标准Action值，Data域为空或从构建的Data数据库中随机选择.例如：Intent{act=ACTION_EDIT;cmp=com.example.appcom.example.app.someComponent}.

4) 仅指定Data域、Action域为空或为随机值.Data域的值来自构建的Data数据库，Action域值为随机标准Action，Action可以为空.例如：Intent{dat=http:www.***.com;cmp=com.example.appcom.example.app.someComponent}.

5) 执行策略2～4的同时，添加随机Extras值.我们在执行策略2～4后，对产生的每一个Intent添加随机Extras值.例如：Intent{act=ACTION_EDIT;dat=http:www.***.com;cmp=com.example.appcom.example.app.someComponent(has extras)}.

在上述构建策略中，使用空域(策略1)、交叉值(策略2)、随机值(策略5)方法，以及这3种方法的结合(策略3和策略4)来确保FuzzerAPP构建的Intent中包含可以与目标组件完全有效匹配(Action域与Data域均匹配)、半有效匹配(Action域与Data域只匹配1个)以及完全不匹配(Action域与Data域均不匹配)的Intent.基于上述策略构建的Intent，可以更大限度地测试目标组件针对各种有效和无效输入处理的鲁棒性.

2.3 测试算法

测试流程的算法如算法1所示.将使用测试用例生成策略构建的多类型Intent，按照发送策略依次发送给目标APP的每一个公有组件，最后按照结果收集阶段的方法收集数据.这里仅将Intent发送给Activity，Broadcast Receiver，Service这3类组件，并没有显式地测试Content Provider组件.针对Content Provider的测试，是通过在其他组件测试的Intent的Data数据域中加入相关Content Provider的URI进行的，在测试其他组件的同时测试Content Provider.

算法1. APP测试算法.

Input:exAPP-the application to be examined:

allAction=Action数据集;

allData=Data数据集;

allExtra=Extras域支持的全部数据格式;

sleepTime=测试线程成功启动目标组件时休眠时间;

components=getAllExportedComponents-InexAPP(exAPP).

start a new ThreadsendThread

for every componentcmpin components

action∈allAction,data∈allData,extra∈allExtra;

intents=createIntent(action,data,extra,component);

for every intentintin intents

send(int,comp);

sendThread.sleep(sleepTime);

end for

end for

endsendThread

在实际测试过程中，当出现以下2种情况时，需要手动干预测试过程：1)APP崩溃产生的系统警告.因为FuzzerAPP工具属于用户层APP，所以不能隐藏系统级别的警告.2)Activity在新栈启动.此时，调用者不能使用finishActivity()结束它.虽然在上述2种情况下，需要手动干预测试过程，但并不影响实验结果的准确性.

3 FuzzerAPP实现

根据所设计的方案，实现测试工具FuzzerAPP，并进一步明确其功能.

在信息获取模块，FuzzerAPP选择使用Apktool工具反编译后获取待测APP的AndroidManifest.xml文件，随后使用DOM(document object model)解析文件，获取在AndroidManifest.xml文件中的组件详细信息.使用dex2jar工具将APP的可执行文件Classes.dex文件反编译为Jar格式文件，然后使用关键代码搜索的方法获取在程序代码中动态注册广播接收者详细信息.

在测试用例生成模块，FuzzerAPP需要设置相应Intent的Action，Data，Extras，Component域的值.Component域为待测组件选择的待测试组件.Action，Data域来自信息获取模块获取的组件详细信息和Android SDK提供的标准数据的结合.Data域的值由一系列不同意义的Uri组成，如“http:”，“mailto:”，“tel:”，“geo:”，“content:”等.Extras域的值是根据Android SDK规定的Extras支持的所有数据类型逐一构造的，如int，String，ArrayList等.确定了这4个域值的来源后，FuzzerAPP将按照所述策略构建相应Intent.

在测试用例发送模块，FuzzerAPP使用使用setComponent()为Intent确定目标组件，使用startService()发送Intent给目标Service，使用sendBroadcast()发送Intent给目标Broadcast Receiver.对于Activity，使用startActivityFor-Result()和finishActivity()来确保组件成功启动并运行后关闭，以减少对系统资源的消耗.FuzzerAPP为APP中的每一个被测组件创建单独线程并为其发送Intent.对每一个线程，每1次成功启动组件后暂停一段时间，防止系统资源耗尽.

在组件抽取方面，FuzzerAPP使用图3所示方法获取在系统中注册的所有APP;然后用再逐个判断所获取的应用是否为第三方APP，若结果为TRUE则为第三方应用;最后通过解析第三方APP的PackageInfo获取对应的暴露组件信息.

Fig. 3 PackageManager gets the APP component code fragment图3 PackageManager获取APP组件代码片段

在结果收集方面，FuzzerAPP使用LogCat收集测试数据.FuzzerAPP分类收集在测试期间的各类数据，这些数据包括被测APP和系统的一般日志信息、警告日志信息、错误日志信息.这些数据将用于对实验结果的分析.

按照以上5个方面对FuzzerAPP的各模块进行实现，FuzzerAPP实现的结果如图4所示：

Fig. 4 FuzzerAPP UI图4 FuzzerAPP界面

图4(a)为所有待测APP；图4(b)为选择待测APP后的测试界面，根据不同组件类型显示不同组件，并可选择3种测试方式；图4(c)为选择不同测试组件类型时的界面.

4 实验及分析

使用FuzzerAPP测试第三方APP组件通信的鲁棒性.首先，从国内较大的第三方Android APP分发平台之一的360手机助手下载待测APP.从其平台软件分类排行榜中选择13类，每类中选择排名前20的APP，合计260款APP.根据实验方案的设计，使用FuzzerAPP对所下载的260款APP进行测试，其中有效测试249款(因设备版本过低或不支持Add-on属性，11款APP未能测试).在测试的249款APP中，共包含4 764个暴露组件(其中Activity组件2 763个，Broadcast Receiver组件1 437个，Service组件654个).在完成所有APP测试后，FuzzerAPP共收集了约5.1 GB的测试数据.

根据从测试工作中获取的数据，以及测试过程中发送特殊Intent后目标APP的界面变化，从以下4个方面对实验结果进行分析：

1) 对被测APP同一组件发送大量Intent时，被测APP是否发生崩溃以及崩溃的次数.

2) 在模糊测试期间，Android系统和被测APP抛出的各类异常的种类，以及这些异常产生的原因.

3) 在测试过程中，发送特殊构造Intent造成系统服务级联崩溃的原因分析.

4) 待测APP测试模块暴露给用户带来的安全威胁及其产生原因分析.

4.1 APP崩溃分布

在向组件发送依据构造策略构造的Intent时，组件可能会因为未捕获异常等原因造成APP崩溃.当APP崩溃时，会由AndroidRuntime抛出具有“Fatal Exceptoin：main”标志的异常.相应地，可以通过“Fatal Exception：main”标志来统计APP的崩溃次数以及跟踪造成崩溃的异常种类.

经过对测试结果中APP崩溃数量的统计分析，共有153款APP发生902次崩溃，崩溃率为62.65%.FuzzerAPP将APP分为13类进行测试，每类APP的崩溃数量如图5所示，每类APP的崩溃次数如图6所示.

Fig. 5 The number of APP collapse classification statistics图5 崩溃APP数量分类统计

Fig. 6 Crashing times classification statistics图6 崩溃次数分类统计

从图5和图6中，发现发生崩溃的同类APP数量与同类APP发生总崩溃次数总体呈正比关系.其中，摄影摄像类APP的崩溃率最高，同时，摄影摄像类APP的总崩溃次数也是最高的.进而对此类APP的崩溃时Log数据进行分析，发现出现次数最多的3类异常分别为SQLiteCantOpenDatabaseException，FileNotFoundException，IllegalStateException.这3类异常的产生原因多与缓冲区和文件操作有关，这也正与摄像类APP的频繁存储操作相对应.

4.2 未捕获以及捕获的异常分布

对同一组件发送大量包含不同数据的Intent，如果该组件对接收到的数据不加过滤地随意使用，就会使目标组件所属APP或者是Android系统的某些服务抛出一系列异常.若在目标APP中没有相应异常的处理模块，那么这些异常就会对相应APP甚至是Android系统造成包括拒绝服务在内的一系列问题，这些问题会严重影响用户对APP的体验.若目标APP包含相应异常的处理模块，但对这些异常只是简单的捕获、抛出，并不进行深度处理，在这种情况下，其他APP开发者或者安全研究人员可以通过分析抛出的异常信息，构造危险数据，同样可以造成包括混淆代理人在内的一系列问题.

1) 未捕获异常

通过对实验数据的统计分析，共有196款APP抛出未捕获异常，合计11 748个38类异常，详细的异常分布情况如表1所示:

Table 1 No Catching Exception Distribution Statistics表1 未捕获异常分布统计

在表1中，其他类异常包括一些未捕获数量较少的26种异常，如java.net.SocketException，java.lang.OutOfMemoryError等.由于这些异常抛出次数较少，在表1中将它们统一归为其他类.在未捕获的38类异常中，26类异常的产生原因直接或间接与FuzzerAPP构造的Intent携带的数据有关，这26类异常占所有类型异常抛出次数的80%.由此可见，APP未捕获异常与APP组件缺乏对输入数据的处理有极大关系.

2) 捕获异常

通过对实验数据的统计分析，共有241款APP抛出异常被捕获，其详细异常分布如表2所示.与表1相同，其中其他项包括捕获次数较少的多种异常.组件抛出的异常如果被APP捕获则可以避免APP崩溃等一系列问题.我们通过对捕获到的异常进行分析，可以更加清楚地知道在相应APP中容易产生问题的组件或模块，可以使开发者在对APP更新时更具有针对性，在开发类似模块时可以降低同类问题产生的概率.

Table 2 Catching Exception Distribution Statistics表2 捕获异常分布统计

4.3 System_Server崩溃

对测试数据分析的过程中，发现APP的崩溃可能会引发system_server(系统服务)的崩溃，并产生级联崩溃.进一步分析，在FuzzerAPP的测试过程中，共有41款APP引发系统服务崩溃，约占测试集APP数量的16.47%.而在JarJarBinks工具测试中，仅发现3个Activity可以导致系统服务崩溃.实验中，发现导致系统服务崩溃的APP共有41款.在一定程度上证明了第三方APP不如系统预留APP的鲁棒性高.

分别定位到41款APP在系统服务崩溃时的输出，分析其崩溃过程以及原因.分析得出系统服务崩溃时的过程如图7所示.在图7中，在Fatal exception 处为Android系统框架层提供的一些关键性服务，如ActivityManager，WindowManager等.Exit zygote处为测试时system server在系统中的PID.

Fig. 7 Cascaded collapse图7 级联崩溃

从图7中可以知道，正是APP的未捕获异常引发了system_server的中断，最终导致zygote的重启.zygote为Android APP的孵化进程，system_server进程由zygote进程孵化，这二者在Android系统体系中具有非常重要的地位.一旦system_server进程被杀死，系统的Dalvik 子系统(运行安卓APP的Java虚拟机)就会重新启动，这会让设备看上去像重新启动了一样.

对图7中Fatal exception处的崩溃组件进行统计，如表3所示，对造成这些组件崩溃的原因进行统计，如表4所示.从表3和表4中可以看出这些异常主要为非法变量异常和越界异常.同时，表内的所有异常均为与数据变量相关的异常种类.分析认为，这些异常主要是由组件在接收外部Intent时，对接收到的数据不加处理而直接使用造成的.

Table 3 System Component Crash Triggered by APP Crash表3 由APP崩溃引发的系统组件崩溃

Table 4 Exceptions that Causes APP to Crash表4 引发APP崩溃的异常

4.4 测试模块暴露示例分析

随着Android APP开发机制的日益完善，大多数APP必须通过多种测试后才能正式对外发布.对Android APP的测试，可以通过其他软件进行测试，也可以在APP内构建测试模块进行测试.在测试过程中，我们发现包括多款知名购物软件、阅读软件、打车软件等在内的多款APP存在测试模块暴露的问题.这些暴露的测试模块包括Activity和Service组件.

测试模块的暴露进一步可能带来更加严重的安全问题.在发现测试模块暴露的APP中，以购物类软件暴露出的问题较为严重.由于购物类软件与用户财产密切相关，因此带来的问题也更为严重.在多款APP的暴露组件内，有链接内网的Web页面，有未对外公开的内部测试框架，有多种测试引擎，有多种功能测试模块等.这些内容可以给开发者大量关于APP架构、测试、网络连接甚至服务器的信息.如果恶意攻击者获得这些信息，可能会对该APP进行针对性的攻击，如利用此客户端和其他恶意软件合谋进行DDoS攻击等.

4.5 实验对比

在之前的研究工作中，也存在着使用模糊测试方法测试APP的工具.Intent Fuzzer[14]和JarJarBinks[10]就是这样的工具.Intent Fuzzer和JarJarBinks与FuzzerAPP具有类似之处，因此我们将对这三者在功能、性能以及测试结果等方面进行对比，结果如表5～8所示.

Table 5 Component Support表5 对组件的支持

Table 6 Test Performance and Test Objectives表6 测试性能和测试对象

Table 7 Intent Construction Category表7 Intent 构建类别

Table 8 Test Results表8 测试结果

在表5～8中，“√”表示工具支持相应功能或者测试结果包含相应方面.Intent Fuzzer提供对Android APP的基本测试功能，在官方网站并没有提供对APP的测试结果，因此，在表5～8中对应条目用“-”表示不包含该项.

FuzzerAPP与JarJarBinks在功能上具有一定的相似性，因此我们详细比对这2种测试工具.在JarJarBinks中得出以下结论：APP组件缺乏对异常的处理；当发送特殊Intent时可以从用户层造成Android运行时的崩溃.对于FuzzerAPP，除了JarJarBinks中发现的问题外，还发现在测试集中4.02%的APP存在测试模块暴露的问题.测试模块的暴露会带来包括拒绝服务在内的一系列安全问题.

综上所述，FuzzerAPP与Intent Fuzzer相比，提供了更加丰富的功能.FuzzerAPP与JarJarBinks相比，不仅二者测试目标不同，而且在测试结果方面，FuzzerAPP比JarJarBinks发现了更多APP存在的问题.

5 结束语

本文提出了一种对Android第三方APP组件通信鲁棒性进行测试的方案.该方法使用Android SDK提供的数据构建高覆盖面的测试用例，并将其发送给目标组件，最后对收集到的数据进行分析.我们根据所提出的方法实现了FuzzerAPP工具.最终的实验结果表明了测试方法的有效性以及测试工具的实用性.

[1]Zhang Yuqing, Wang Kai, Yang Huan, et al. Survey of Android OS security[J]. Journal of Computer Research and Development, 2015, 52(7): 1385-1396 (in Chinese)(张玉清, 王凯, 杨欢, 等. Android 安全综述[J]. 计算机研究与发展, 2015, 52(7): 1385-1396)

[2]Google Inc. Android security[EB/OL]. [2015-10-10]. https://source.android.com/devices/tech/s-ecurity/index.html

[3]Google Inc. UI/application exerciser monkey[EB/OL]. [2015-10-10]. http://developer.android.com/tools/help/monkey.html

[4]Google Inc. MonkeyRunner[EB/OL]. [2015-10-10]. http://developer.android.com/tools/help/mon-keyrunner_concepts.html

[5]Yunmai Co.Ltd.DroidPilot[EB/OL]. [2015-10-10]. https://droidpilot.wordpress.com

[6]MacHiry A, Tahiliani R, Naik M. Dynodroid: An input generation system for Android apps[C] //Proc of the 9th Joint Meeting on Foundations of Software Engineering. New York: ACM, 2013: 1-12

[7]Koski D, Lee C P, Maganty V, et al. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services[R]. Madison:University of Wisconsin-Madison, Computer Sciences Department, 1995

[8]Miller B P, Fredriksen L, So B. An empirical study of the reliability of UNIX utilities[J]. Communications of the ACM, 1990, 33(12): 32-44

[9]Forrester J E, Miller B P. An empirical study of the robustness of Windows NT applications using random testing[C] //Proc of the 4th USENIX Windows System Symp. Berkeley, CA: USENIX Association, 2000: 59-68

[10]Miller B P, Cooksey G, Moore F. An empirical study of the robustness of MACOS applications using random testing[C] //Proc of the 1st Int Workshop on Random Testing. New York: ACM, 2006: 46-54

[11]Mulliner C, Miller C. Fuzzing the phone in your phone[J/OL]. Black Hat USA, 2009 [2015-10-10]. http://mulliner.org/security/sms/feed/smsfuzz_26c3.pdf

[12]Dismfyp. Android kernel fuzzer[EB/OL]. [2015-10-10]. https://androidfuzzing.wordpress.c-om

[13]iSEC. Intent fuzzer[EB/OL]. [2016-03-22]. https://www.isecpartners.com/tools/mobile-se-curity/intent-fuzzer.aspx

[14]Maji A K, Arshad F A, Bagchi S, et al. An empirical study of the robustness of inter-component communication in Android[C] //Proc of the 42nd Annual IEEE/IFIP Int Conf on Dependable Systems and Networks. Piscataway, NJ: IEEE, 2012: 1-12

[15]Ye H, Cheng S, Zhang L, et al. Droidfuzzer: Fuzzing the Android apps with intent-filter tag[C] //Proc of Int Conf on Advances in Mobile Computing & Multimedia. New York: ACM, 2013: 68

[16]Sasnauskas R, Regehr J. Intent fuzzer: Crafting intents of death[C] //Proc of the 2014 Joint Int Workshop on Dynamic Analysis (WODA) and Software and System Performance Testing, Debugging, and Analytics (PERTEA). New York: ACM, 2014: 1-5

[17]Chin E, Felt A P, Greenwood K, et al. Analyzing inter-application communication in Android[C] //Proc of the 9th Int Conf on Mobile Systems Applications and Services. New York: ACM, 2011: 239-252

[18]Kantola D, Chin E, He W, et al. Reducing attack surfaces for intra-application communication in Android[C] //Proc of the 2nd ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. New York: ACM, 2012: 69-80

[19]Fu Jianming, Li Pengwei, Yi Qiao, et al. A static detection of security defects between inter-components’ communication[J]. Journal of Huazhong University of Science and Technology: Natural Science Edition, 2013, 12(41): 259-264 (in Chinese)(傅建明, 李鹏伟, 易乔, 等. Android 组件间通信的安全缺陷静态检测方法[J]. 华中科技大学学报:自然科学版, 2013, 12(41): 259-264)

[20]Google Inc. Intent class overview[EB/OL].[2015-10-10]. http://developer.android.com/reference/android/content/Intent.html

Zhang Mi, born in 1990. Master in the School of Cyber Engineering at Xidian University. His current research interests include mobile security and vulnerability discovery.

Yang Li, born in 1977. Associate professor in the School of Cyber Engineering at Xidian University. Senior member of CCF. His current research interests include network security and mobile security.

Zhang Junwei, born in 1982. Associate professor in the School of Cyber Engineering at Xidian University. His current research interests include cryptography and network security (jwzhangxd@126.com).

FuzzerAPP：The Robustness Test of Application Component Communication in Android

Zhang Mi, Yang Li, and Zhang Junwei

(SchoolofCyberEngineering,XidianUniversity,Xi’an710071)

The study of Android security has attracted wide attention because of the huge share in operation system market for mobile devices. Aiming at the security issues of Android application, this paper presents a robustness test scheme of application components based on fuzzy testing method. Firstly, a test set and the corresponding test cases are designed. These cases are sent to a target application for collecting and analyzing the test data. Considering the time, efficiency and other factors, the test case is sent to the application components to be tested. Then, the interaction information of the target component in the test process and the statistical analysis of the output data are analyzed. According to the design of test scheme, a platform named as FuzzerAPP is implemented which can test the robustness of the common applications in Android system. Many applications in some famous Android application markets are tested under FuzzerAPP, and the experiments results are collected. By the analysis of the test data, we find that if FuzzerAPP sends a particular Intent to the target application, it will make the application crash or even lead to the cascading breakdown of system services. Besides, there is a test module exposure problem in many applications of the test set, which can cause serious security problems such as privacy leaks and DoS (denial of service attacks). Finally, on contrast of other similar plans in component supporting, test performance, test objectives and Intent construction categories, the results show the effectiveness of the test method and the practicability of the test platform.

Android; components communication; fuzzy test; robustness; test module exposure

2015-11-23；

2016-03-22

国家自然科学基金项目(61671360,61672409,61672415,61672413,61472310,U1135002);中央高校基本科研业务费项目(JB161505,BDZ011402)；信息保障重点实验室开放课题(KJ-14-109) This work was supported by the National Natural Science Foundation of China (61671360, 61672409, 61672415, 61672413, 61472310, U1135002), the Fundamental Research Funds for the Central Universities (JB161505, BDZ011402), and the Foundation of Science and Technology on Information Assurance Laboratory (KJ-14-109).

杨力(yangli@xidian.edu.cn)

TP39