Analyzing Android Taint Analysis Tools: FlowDroid, Amandroid, and DroidSafe 论文精读

Junbin Zhang

问题背景

1. 静态污点分析技术来识别apk中的信息流，但是这些工具往往在合成benchmark上进行优化和评估——难以推广到真实世界
2. 这些工具的评估在不同的配置下进行比较——是不准确的

本文贡献

1. 进行大型可控独立的比较3个最突出的静态分析工具，对这些工具的设置进行对齐，并在通用的一些benchmark（180个apk）上以及一下Google应用（25个apk中人工收集了82个expected flows）上进行评估

从accuracy, execution time, memory consumption方面进行评估

1. 进一步评估了DroidRA额外的处理反射机制的有效性，并将其应用到每个被评估的工具中。
2. 对每个工具的强项和弱点都进行分析
3. 提供了详细的工具设置信息
4. 提出了UBCBench，扩展了之前研究没有包括的flow类型
5. 贡献了25个Google Play with 手工建立的expected flows

主要内容

引言

除了上述所说的问题背景之外，现在大部分的研究集中在记录detected flows and runtime failures，没有考虑到expected flows，也没有分析假阳假阴的原理。因此做了本文贡献的部分。

本文研究三个RQ：

RQ1：这些工具在benchmark上的表现

使用similar的配置以及相同的application，以及相同的sources和sink配置文件

RQ2：在benchmark apk中不准确的主要原因

RQ3：在benchmark上的结论可以推广到Google应用上吗

结论

RQ1：在使用DroidBench and ICC-Bench benchmark中DROIDSAFE has the highest accuracy, FLOWDROID comes second, and AMANDROID has the lowest accuracy。

原因分析

RQ1：Amandroid的作者的结论：F-measure分别为81%和96%，但是本文的结果只有61%，most likely是因为对于benchmark中不同app的选择以及工具的版本

RQ2：手工分析了FP，FN结果，发现对于处理反射，都有问题。DroidRA帮助解决一些反射问题，但是无法处理复杂的与反射相关的结构。此外，Flowdroid无法准确的分析追踪ICC intent涉及复杂的字符串分析和列表管理；Amandroid无法准确的处理Android框架方法，周期和回调函数以及关于位置的流动

RQ3：调查flowdroid和Amandroid是否可以在两个真实应用成精啥识别flow。

1. 1. 从用户输入的登录凭证，到一次互联网传输操作
   2. 从用户或手机特定的敏感信息到互联网的传输操作。

排除了DroidSafe因为其声明无法在Google Play apps上使用

讲了一些选择两个case的原理

在真实世界的应用使用这种信息传输作为期望的流程，并检测工具的识别表现

还手动检查了每个应用程序中发现的所有其他流工具，识别了FP结果，并分析了工具的FP和FN背后的原因。

实验运行结果：

1. 1. Flowdroid有11/25个遭遇crashes在分析到特定的ICC flows和reflective调用。成功分析的14个app，只有2个可以检测到expected的flows，在检测一些回调和reflective calls有困难，因为真实世界app依赖callback和reflection机制（不被benchamark支持的），尽管使用了DroidRA，但是没有帮助提高这个对于反射的准确。尽管Flow可以对benchmark中的android框架建模准确，但是对于Google应用没有cover到，导致了FP和FN
   2. Amandroid可以分析出14个应用，但是在不同的运行中报告了不同的数量，比如在四次独立的运行某app时，报告了0,3,28,43个flow。因此，我们无法对AMANDROID的假阳性和假阴性结果进行可靠的分析。

结论：despite the success on the benchmark apps 但是不能可靠的分析在真实app上的flows。因为这些的失败检测的flows没有被现存的benchmark所cover，本文创建了一个sample app 包含了每个flow。UBCBench

本文的先前研究比较了flowdroid，Amandroid和droidsafe在相同的setup下实验，本文所述的后续工作使用最新版本的工具和基准套件进行了相同的实验

静态污点分析工具介绍

sensitive

为了处理别名以及virtual dispatch constructs 典型的java徐成静态分析工具应用了一定程度的上下文、对象以及字段敏感，流和路径敏感性用于控制语句的顺序及其与程序分支的对应关系

什么是上下文，对象以及字段敏感呢？

context-sensitive: 我个人理解是对于特定的函数，会完善调用他的函数信息，以及他属于的类别

1. 上下文敏感分析(Context-sensitive analysis)
   考虑调用上下文,可以区分目标方法的不同调用点。

public void foo() {
sink();
}

public void bar() {
sink();
}

public void sink() {
// do something
}

敏感分析可以区分foo()和bar()调用了同一个sink()的情况。

1. 对象敏感分析(Object-sensitive analysis)
   使用对象的分配点(allocation site)作为上下文信息。

Object a1 = new Object();
Object a2 = new Object();

a1.sink();
a2.sink();

public void sink() {
// do something
}

对象敏感分析可以区分a1和a2是不同对象,调用了同一个sink()方法。

1. 字段敏感分析(Field-sensitive analysis)
   区分对象的不同字段,不将所有字段合并在一起分析。
2. 流敏感分析(Flow-sensitive analysis)
   考虑语句的执行顺序。

x = 1;
y = x + 1;
x = 2;

流敏感分析可以推导出y=2,而非敏感分析可能得到y=2或3。

1. 路径敏感分析(Path-sensitive analysis)
   收集路径信息,考虑不同的执行路径。

if (x > 0) {
// 执行语句1
} else {
// 执行语句2
}

路径敏感分析可以区分if分支和else分支的不同路径。

一个不敏感的例子

public class Demo {

  int x; 
  int y;

  public void foo(int a) {
    x = 1;
    if (a > 0) {
      y = 2; 
    } else {
      y = 3;
    }
  }

  public void bar(int b) {
    x = 4;
    if (b < 0) {
      y = 5;
    } else {
      y = 6; 
    }
  }
  
  public void test() {
    int z = x + y; 
  }

}

也就是说对于不敏感的算法，他是直接对常量池等进行暴力搜索，遍历到什么就是什么

1. 构建控制流图(CFG):通过解析代码,构建一个控制流图,包含基本块和控制流转移。
2. 数据流分析:在CFG上进行前向或后向的数据流分析,确定每个程序点变量的定义和使用。
3. 收集定义和使用:在每个基本块内,收集变量的定义和使用。
4. 连接定义和使用:尝试连接基本块之间的定义和使用,进行可达性分析。
5. 合并变量状态:对于合并点(如if-else语句),合并来自不同方向的变量状态。
6. 求值分析:建立变量的值集合,通过迭代分析不断求精,求出变量的可能值范围。
7. 检查目标:最后检查某个目标点(如test()方法)变量的值集合。
   在这个非敏感分析过程中,关键是:

• 不区分路径,在合并点合并所有状态
• 不考虑上下文,方法间分析独立
• 分析过程不跟踪值的确切传播

Implicit Flows

隐式流是指敏感数据通过影响控制流的哪个分支来间接影响观测输出的流隐式流分析之所以可能导致大量误报,主要原因是它通过条件语句的污点传播来追踪数据依赖,过于保守导致污点过度传播。
举个例子:

if (password == "123456") {
access = true;
}

这里如果password变量是污点,隐式流分析会将access标记为污点,因为它依赖于password的条件判断。
但是实际上,只是判断一个密码而授予访问权限,不应该将access标记为污点,否则会产生误报。
这是因为隐式流分析采用宽松的策略,password的污点导致所有依赖该条件的变量和数据都被标记为污点,包括许多实际上并没有被污染的变量,因此产生了大量假阳性结果。
一些改进方法包括:

• 采用类型系统进行隐式流分析,更精确地挑选污点传播
• 区分关键语义,只传播安全关键数据的污点
• 结合程序依赖分析,仅将实际依赖污点的变量标记

控制implicit flows

如果条件分支内部没有对污点变量进行更新赋值,只标记分支条件语句的污点变量而不传播污点,可以改善隐式流分析的误报问题。
我们仔细分析一下代码:

java
if (tainted_var > 0) {
clean_var = 1;
}

这里tainted_var是带污点的,clean_var最初是不带污点的。
隐式流分析的常见做法是:

1. tainted_var在if条件中,将其标记为污点
2. clean_var依赖了if条件,所以也将其标记为污点
   但是实际上,clean_var并没有被tainted_var实际污染,这就产生了误报。
   改进方法是:
3. 只标记if条件中的污点变量tainted_var
4. 如果if内部没有对tainted_var重新赋值,则不传播污点
5. clean_var不标记为污点
   这样就可以避免产生误报,只标记实际依赖了污点的变量。

Android 特色

关于Android静态分析中框架建模和应用生命周期处理的内容:

1. 框架建模
   为了跟踪Android应用与框架的交互时污点的传播,通常有两种方式:
   (a) 保守地假设框架如果方法的参数有污点返回值就污染了
   (b) 精确建模框架的子集方法,手动或者通过分析框架二进制库自动实现
2. 应用生命周期
   Android应用包含四种组件:Activity、Service、Broadcast Receiver、Content Provider。每种组件都有自己的生命周期方法,由系统调用来启动/停止/恢复它们。
   应用还包含回调方法,用来响应系统和用户事件(如位置变化和按钮点击)。
   静态分析工具会识别和建模这些生命周期和回调方法,以确保正确传播污点。
   为了提取这些方法,工具依赖Android开源项目的信息,也会分析应用代码和配置文件,如manifest和布局XML

STUDY DESIGN

Tool Selection

通过文献总是，选择了所有的开源并且在Google Scholar上引用超过100次的

扫描了截至 2020 年 12 月的所有公开可用的污点分析工具列表

基于引用量初选,再通过最新文献调研确定新增工具,联系作者验证工具状态,选择仍可工作的工具加入比较

配置描述

描述了论文中对FLOWDROID工具的配置和使用情况:

1. 为了提取组件间通信(ICC)的流,配置FLOWDROID使用IC3模型,因为根据之前的研究,这个模型的准确率比EPICC更高。
2. 没有使用PRIMO模型,因为它依赖于被分析应用程序之间的统计相似性,而在基准测试集中是没有这种相似性的。
3. 默认情况下,所使用的FLOWDROID版本对ICC相关的流执行“purification”。这意味着工具在处理像startActivity()这样的ICC沉淀时,偏离了标准的污点分析语义,实现了额外的逻辑。
4. 经过一系列实验,确认purification功能没有完全实现也没有按文档描述的行为执行。
5. 通过与FLOWDROID的作者交流,他们建议使用noiccresultspurify参数来禁用此功能,使工具遵循标准的污点流语义。
   总结而言,描述了论文作者如何配置FLOWDROID,发现默认的purification功能存在问题,最终禁用了该功能

对benchmark app的评价方法

如何选择benchmark家以及taint sources and sinks 以及对expected resultd的定义，研究的指标和测量

首先说明了这些benchmark没有bias

DroidBench 3.0	“intra-component and inter-component communication, handling of reflection, sensitivity types and more”(Zhang 等, 2022, p. 4020)	158（排除了28个他们不关注的功能：tracking of implicit flows, inter-application flow detection, native code analysis, and sensitive UI elements detection. 3个关注动态class loading 一个3个）
ICC-Bench 2.0		24

source和这段描述了论文中为了公平比较不同工具,如何统一配置源(sources)和汇(sinks)的过程:

1. 早期工作中,Arzt等和Li等使用了SUSI项目生成的源和汇列表。AMANDROID的作者确认他们使用了每个基准测试中标记的源和汇。
2. DROIDSAFE的源和汇列表不可配置;Gordon等因此使用了工具本身硬编码的全部源和汇(总共4051个源,2116个汇)。
3. 为使所有工具使用相同的源和汇,作者检查了所有182个基准测试的头文件和注释,提取了基准测试中使用的源和汇(5个源,11个汇),将这个列表命名为SS-Bench。
4. 配置FLOWDROID和AMANDROID使用SS-Bench。确认DROIDSAFE考虑的源和汇包含SS-Bench中的源和汇。
5. 为了公平比较,如果DROIDSAFE报告了与SS-Bench不相关的其他源汇之间的流,则忽略这些流。
   总结为:提取基准测试实际使用的源和汇列表,并配置所有工具统一使用这个列表,以保证公平比较

论文中涉及预期结果的处理:

1. 预期结果的完整列表可在线获得。
2. 在表4列出的33个案例中,预期结果与基准测试本身记录的有偏差。例如在ActivityCommunication2基准测试中,额外期待一个流,因为添加了startActivity(Intent)汇,这个汇在其他基准测试如DroidBench IntentSink2中也出现过。
3. 在IMEI1基准测试中,不期待任何流,因为对所有工具禁用了隐式流跟踪。
4. 需要注意的是,设计用于检查被禁用功能的基准测试被排除在分析之外,例如专门检查隐式流的ImplicitFlow1-6

对GooglePlay中APP的选取

场景一

从58个类别中排名前100的应用开始，得到5569 app'

使用aapt得到其中的api level i.e. targetSDKVersion——选择API低于25的，根据不同工具的适用API是不同的——得到188

运行这些app来判断是否有登陆验证功能，并判断是否能够正常使用——得到51个

1. 分析了51个应用的字节码,以确保用户名/密码到互联网相关汇的流完全在工具可以分析的代码内实现。
2. 排除了7个在WebView中实现登录的应用 - WebView是一个在网页中输入登录凭证的组件。
3. 排除了5个使用Unity、React Native等跨平台框架构建的应用。
4. 排除了16个将登录功能委托给谷歌、Facebook等第三方OAuth服务提供商的应用,这些提供商在单独的应用或WebView中实现。
5. 以上情况登录流不在分析的应用内。
6. 此外还排除了3个高度混淆无法判断认证类型和流的应用,以及1个与数据集中更近版本应用高度相似的应用

场景2

1. 从Gartner过去两年最佳终端安全平台魔力象限报告中评选的三大移动安全公司的博客中爬取与恶意软件相关的博文:Trend Micro、Symantec和Sophos。
2. 时间范围聚焦在过去两年(2019年1月至2020年12月),使用“Android”、“Google”、“Playstore”等与谷歌Play相关的词和“malware”、“malicious”等恶意软件相关词进行组合关键词搜索。
3. 共识别出44篇相关博文。

但是这是非常粗粒度的，

1. 初始自动过滤获得的样本中包含了大量无关内容,如广告、非Android恶意软件等。
2. 论文作者进一步人工检查帖子,识别出4篇符合期望标准的博文:描述Google Play的Android原生恶意软件,并包含被篡取的机密细节。作者交叉验证结果,分歧通过讨论解决(2篇博文,5%分歧率)。
3. 从选定的博文中提取所有描述的应用的标识符,在学术仓库、替代应用市场中搜索这些应用。假设这些仓库可能仍包含已从Google Play下架的样本。
4. 共识别出8个应用,剔除2个API等级过高的应用后,使用VirusTotal(一个汇聚60个杀毒引擎结果的在线服务)验证剩余6个应用确为间谍软件。
5. 最后的Google Play应用选择包括25个应用,覆盖Tripadvisor、Airbnb等知名应用。每个阶段排除的应用分布详见论文的在线附录。
6. 论文认为选择的应用集代表性强,代码大小与Google Play应用平均水平相近。
7. 论文专注Google Play应用是因为这对用户、安全专家和研究者最相关。F-Droid开源应用仓库中的应用符合条件的太少,不足以进行分析。
   总结为:详细说明了选择泄露隐私场景样本的全过程,结果具有代表性并符合研究目的

sink and sources

登陆场景，人工审查补充

spay软件场景。描述了在泄露隐私场景中确定预期泄露源和汇过程:

1. 分析博文,提取每个应用泄露的敏感用户信息,并映射到对应的Android API。
2. 论文两位作者独立检查每个博文,提取“设备ID”、“短信”、“位置”、“联系人”、“通话日志”等词组。
3. 使用SUSI列表映射这些泄露的机密到Android API。对每个应用,先识别调用过的所有SUSI源API,再根据博文过滤到应用泄露的那些类型。
4. 例如,如果应用调用了TelephonyManager.getLine1Number()并泄露电话号码,则标记该API为分析的源。
5. 每个应用平均识别出11个潜在源,追踪每个源的调用点到设备外发送信息的第一个汇点,标记为汇点。
6. 最后识别出6个应用总共47条流,发送SECRETS的汇有两类:互联网和短信。

实验结果

RQ1 tool performance

性能

先说在那个方面好，哪个方面不好（表现）——举例来说——说明其解释逻辑

总结了三种工具处理跨组件通信(ICC)流的逻辑:

1. 三种工具都偏离了标准污点追踪语义,对ICC流实现了额外逻辑。
2. AMANDROID从3.1.2开始,对ICC相关汇点(如startActivity),过滤掉同组件内流,即使能成功检测。
3. DROIDSAFE使用自己的逻辑处理ICC流。对显式Intent过滤同组件流,对隐式Intent始终报告ICC流的同组件部分,因为其他应用组件可以接收该Intent。
4. FLOWDROID是唯一可开关此逻辑的工具。但该选项不完全受支持,预期实现与另两工具逻辑不同。
   总结:
   三种工具都不同程度偏离了标准语义,实现了自己的ICC流处理逻辑,存在一定差异。这可能导致结果不一致。

总结了三种工具在DroidBench和ICC-Bench基准测试上的准确率比较:

1. 为公平比较,根据标准污点追踪语义重新计算了三种工具的准确率,报告在表8中。表8同时给出了各自处理ICC流逻辑时的原始准确率(括号中)。
2. DROIDSAFE不报告检测流的完整路径,只有源方法、汇方法和入口方法,增加了分析难度。有时入口方法报告错误。但为不影响DROIDSAFE,在计算精确率召回率时忽略了入口方法错误和重复流。
3. 在DroidBench上,DROIDSAFE准确率最高(88%),FLOWDROID次之(79%),AMANDROID最低(61%)。但在ICC-Bench上,AMANDROID性能较好(92%),FLOWDROID为79%。
4. FLOWDROID在6个基准测试上Crash,DROIDSAFE在1个上超时。这些用例均包含预期流,故将其视为对应工具的假负。
5. DROIDRA稍微提升了AMANDROID和DROIDSAFE在DroidBench上的表现。ICC-Bench不包含反射,工具准确率相同。

运行时间和内存消耗

Conparison with earlier experiments

1. 将本文中的工具准确率结果与之前其他研究进行了对比,发现本文的结果通常较低。
2. 出现这种差异的原因在于:本文的测试用例集更大;不同研究之间采用的测试用例集存在差异,每个论文只关注特定的测试方向;有些论文使用的是工具作者提供的测试集,在这些集合上工具表现较好。
3. 即使测试同一工具,不同研究之间也难以直接比较,因为工具版本和集成组件可能不同。例如DROIDRA的作者只在早期FLOWDROID版本上验证,而本文使用的是已经整合反射处理的新版本。
4. DROIDRA的作者未将其与AMANDROID和DROIDSAFE组合验证过,而本文的实验发现DROIDRA可以提升这两款工具处理反射的能力。
5. 不同研究采用的测试用例存在差异是导致结果难以直接比较的主要原因。
6. 不同的工具在使用的基准测试、参数配置以及源和汇的设置上有差异,这使得工具之间的比较变得困难。本研究使用统一的设置和大规模的基准测试对工具进行独立评估,以公平比较工具的性能。
7. 与之前的工作[24]相比,本研究使用更新后的DroidBench 3.0版本,新增了49个基准测试程序,导致所有三个工具的缺陷更多地暴露出来。如果排除新程序,FLOWDROID的F值可达84%,AMANDROID的F值可达65%,与之前工作中的85%和68%相当。
8. 在执行时间方面,本研究结果与其他报告一致,FLOWDROID比AMANDROID快,AMANDROID比DROIDSAFE快。由于硬件配置不同,不能进行数量上的执行时间比较。
9. 在内存消耗方面,由于相关文献未提供该指标,本研究也无法与其他文献进行内存消耗的比较。
10. DROIDBENCH基准测试套件从2.0升级到3.0版本,新增测试程序,更全面地揭示了工具的缺陷。使用统一环境测试有助于更公平地比较工具性能。

RQ2： 不准确的原因causes of inaccuracy

1. 首先确定每个基准测试的目标标准,也就是基准测试设计用来测试的污点分析的特定方面。——用来检测什么功能的
2. 基准测试可以评估多个目标标准。研究人员通过解耦标准来解释一些失败情况。
3. 研究人员总共新增了19个基准测试程序加入UBCBench,其中9个用于解耦标准,10个用于识别的新的目标标准。
4. 实验中仅使用DroidBench和ICC-Bench,未使用新增的基准测试程序。
5. 基准测试套件中总共有192个预期流,其中DroidBench有158个,ICC-Bench有34个。
6. 不使用DROIDRA扩展的情况下,表明了每个工具在预期流上的假正例和假反例数量。
7. 根据失败标准对每个工具在不同基准测试套件上的结果进行了聚合。
8. 研究确定了基准的目标标准,解释了失败情况,并加入新的基准测试程序,以更全面地评估工具的能力。

可以看出AMANDROID在处理Android框架方法时过于保守,导致了24个假正例(FP)的结果。具体来说:

1. AMANDROID在建模Android框架方法时,如果一个参数被污染,会自动把污染传播到其他参数。
2. 例如在图11中,Toast.makeText方法的第一个参数被污染,AMANDROID会错误地认为第二个参数msg也被污染。
3. 但事实上第二个参数msg本没有被污染,所以AMANDROID这里报告了假正例。
4. 这是因为AMANDROID对Android框架方法建模过于保守,默认如果一个参数被污染,就认为其他参数也被间接污染。
5. 但实际上Android框架方法内部不一定会传播不同参数之间的污染,所以这个保守建模导致了假正例的产生。
6. 这个问题可以通过更精细地对Android框架方法建模来解决,避免简单地默认参数间会相互污染。
7. FLOWDROID和DROIDSAFE在这一问题上表现更好,没有像AMANDROID那样大量报告假正例。
8. 总之,AMANDROID在Android特定方法上的保守建模是其报告假正例的主要原因之一。

1. FLOWDROID在识别源和汇方法时并不解决反射调用，而是依赖于API签名。
2. 当所涉及的对象通过casting访问时，无法传播污点，FLOWDROID在通过强制类型转换访问对象时,无法正确传播污点

上述Fig 10中的代码示例来具体说明一下为什么FLOWDROID没有在casting赋值中正确处理污点传播:

$r1 = virtualinvoke $r0.<MainActivity: void onCreate(android.os.Bundle)>($r2)

$r4 = staticinvoke <android.widget.Button: android.widget.Button getButton(android.content.Context)>($r1)

virtualinvoke $r4.<android.widget.Button: void setHint(java.lang.CharSequence)>($r3)

1. 第一行,调用onCreate()方法,$r1是MainActivity类型。
2. 第二行,通过getButton()拿到一个Button,存入r4是View类型。
3. 第三行,是关键的casting赋值语句:

• • 通过casting将$r4转换为Button类型
  • 然后调用setHint()给这个Button设置提示文本
  • 这里参数$r3包含污点

1. 在这行代码中,污点本应该从r4,因为$r4的内部字段hint被污染了。
2. 但是FLOWDROID没有这样做,污点停留在r4。
3. 原因是在casting赋值时,FLOWDROID的指针分析和数据流分析都存在缺陷,没有把r4。
4. 这样会导致在后续如果$r4泄露出去,污点也不会跟着泄露,产生假阴性。

后面对每个工具的弱点进行分析，具体就不写了讲AMANDROID在处理循环时过于保守,导致产生假正例(FP)的问题。主要内容如下:

1. 代码首先在第1行将v2变量设置为null,在第3-4行将v3变量设置为来自源方法的污染值。
2. v6和v1用于检查循环条件,循环体在第8-16行。
3. 关键的是v4和v5变量,它们被设置为v2(即null),和污染的v3一起传给sink方法(第14行)。
4. 为保留循环语义,AMANDROID对每个循环进行3次展开。
5. 因此第14行的sink方法会连续执行3次。
6. 在第一次迭代中,由于v3被污染,AMANDROID成功报告了流向sink的问题。
7. 但是,由于其对Android方法建模过于保守,污染从v3传播到了其他参数,包括v2、v4和v5。
8. 在每次循环迭代中,v0和v1被重新赋值(第10-11行),但v2保持被污染,并在下一轮又污染了v4和v5(第12-13行)。
9. 结果是,AMANDROID在第14行针对错误污染的v2、v4、v5每个报告了3个假正例。

related work

Internal Tool Evaluation

工具作者做的评价

1. Arzt等人[ 2 ]在DroidBench 1.0版本上将FLOWDROID的精确率和召回率与IBM APPSCAN SOURCE [ 75 ]和强化SCA [ 76 ]两个商业工具进行了比较，当时包含了39个基准程序。他们提供了一个详细的工具包来解释如何重现他们的实验[ 77 ]。作者还在Virus Share数据集中的500个最流行的Google Play应用程序和1000个已知的恶意软件应用程序上运行了FLOWDROID (不含ICCTA ) [ 78 ]。他们得出结论，FLOWDROID可以检测日志文件中敏感信息的泄漏。然而，作者没有报告该工具成功分析的应用程序数量和每个应用程序报告的流数量。他们也没有将所有的流量分类到FP和FN结果中
2. Li等[ 4 ]在作者开发的22个ICC相关基准和ICC - Bench的9个基准上，对无ICCTA的FLOWDROID、有ICCTA的FLOWDROID、DIDFAIL [ 79 ]和AMANDROID进行了比较。作者还在15000个随机选择的Google Play应用程序上运行了FLOWDROID (使用ICCTA )，并显示该工具在337个应用程序中报告了2，395个与ICC相关的泄漏。与先前的研究一样，作者没有进一步检查报告流程的有效性。当比较FLOWDROID (与ICCTA )和AMANDROID在随机选择的50个Google Play应用程序上的执行时间时，作者发现FLOWDROID比AMANDROID更快，这与我们的研究结果一致。
3. Wei等人[ 5 ]将AMANDROID与EPICC [ 1 ]和FLOWDROID进行了比较，也关注了ICC的处理能力。课题程序包括39个来自DroidBench的应用程序，16个来自ICC - Bench的应用程序，以及另外4个专有的测试用例。后来，相同的作者对该工具进行了升级，并进行了新的比较[ 11 ]，重点研究了18个DroidBench和24个ICC - Bench应用程序，涉及ICC和IAC。在这两份报告中，作者还分别在753个和2300个Google Play应用上评估了AMANDROID，表明该工具在实际应用中能够检测数据泄露。再次，他们没有对工具报告的流的有效性进行深入分析。
4. Gordon等人[6]使用DroidBench的94个应用程序，团队开发并贡献给DroidBench的40个额外基准测试，以及来自专有基准测试的24个应用程序，将DROIDSAFE与FLOWDROID进行了比较。作者没有在任何Google Play应用程序上运行DROIDSAFE，并指出该工具不是为此目的而设计的。
5. 最后，Li等人[19]和Sun等人[20]比较了DroidBench 2.0版的4个反射相关应用程序和作者开发的9个应用程序上的FLOWDROID，以及没有DROIDRA。作者还评估了100个实际应用程序的工具，但没有分析检测到的流程的正确性。我们的工作扩展了这一评估，以考虑DROIDRA与AMANDROID和DROIDSAFE的组合;我们还对检测结果进行详细分析。

1. 作者比较了FlowDroid在DroidBench基准上的精确率和召回率,以及在Google Play应用上的检测能力。但没有深入分析报告流的正确性。
2. Amandroid的作者在DroidBench、ICC-Bench和Google Play应用上评估了工具。同样没有检查报告流的有效性。
3. DroidSafe的作者用DroidBench和自定基准比较了它和FlowDroid。但没有在Google Play应用上测试。
4. FlowDroid结合DroidRa的评估只在少量DroidBench应用上进行。
5. 这些内部评估因为使用不同的基准集、工具版本,结果难以比较。很少描述详细的工具配置。
6. Google Play应用评估更关注可扩展性而非准确性。
7. 本文作者提供了一个独立的准确性评估。深入分析了各工具的假正例和假反例原因。

External Tool Evaluation.

1. Pauck等人提出了一个自动化框架来评估流量分析工具的报告,比较了6个静态污点分析工具在DroidBench、ICC-Bench和DIALDroid-Bench上的准确率和执行时间。但没有深入分析失败原因。
2. Bonett等人提出了一个基于变异的框架来发现Android静态污点分析工具的未公开缺陷。他们通过向7个开源App注入污点来评估3个工具,发现了回调方法处理不准等问题。但是没有考虑真实场景下的污点。
3. Rodriguez和Kouwe在AndroZoo上的应用上测试了3个工具,发现了许多崩溃和超时的问题,主要是反编译问题导致。但是他们使用的应用API level不被工具支持。
4. Luo等人提出了COVA工具来分析FlowDroid报告的污点流条件,提供了如何提高精确率的建议,但没有进行工具之间的比较。
5. Tiwari等人专门比较了多个工具在ICC/IAC相关基准上的表现,发现新的IIFA工具支持高API level的IAC检测。我们的工作不仅关注ICC/IAC流。
6. 与以前工作不同,我们手工构建了预期结果集,以发现未检测和错误检测流的具体原因。

Surveys

1. 有几篇论文调研了用于检测权限泄露、加固抵抗混淆以及应用间通信漏洞的Android特定静态分析技术。
2. 一些工作给出了Android安全漏洞的分类体系。Li等和Sadeghi等进行了大规模的文献综述,提出了一个将Android安全评估机制分类的框架。
3. Reaves等不仅进行概念性调研,还进行了实证比较实验,评估了工具的可用性、性能和精确度。但主要关注可用性,没有深入分析准确性。还使用了默认配置,影响了结果的可信度。
4. 与之形成对比的是,我们的研究首先统一了配置,不仅报告了整体准确率,还分析了所有失败的具体原因,总结了每个工具的主要缺陷。
5. 在我们所知,我们的研究是首个大规模、深入的在统一设置下对这些工具进行比较分析。而且我们的配置和结果都是公开的,可以重现。