最近翻 DroidBench 发现 Reflection-ICC 不能被 FlowDroid + Iccta 解决，ICSE 25 的 PacDroid 在列实验结果的时候也忽略了这一部分。
这篇文章来自 INFOCOM 18，之后扩展到了 TIFS 20。
Introduction
Java 反射机制在安卓应用程序中广泛用于维护代码版本兼容性、访问隐藏/内部安卓接口等，给静态分析工作带来的一定的挑战。而且反射机制也被用来实现动态类加载 DCL，这种情况下包含恶意行为的方法甚至可能不在静态分析工具已知的范围内。此外，应用的 ICC/IAC 可能被反射掩盖。现有工具很难处理这些问题。
文章提出了一种结合静态分析和动态分析的方法 DINA，并在 3000 个良性应用和 14000 个恶意应用上做了评估。
这个例子展示了：恶意应用通过 DCL 调用 getIntent 方法获取包含敏感信息的 Intent 后再使用 Messenger 泄露敏感信息的攻击路径。
这个例子来自真实应用，展示了：可疑方法 toCall 被掩盖在反射调用之后，如果静态分析工具不解析这个反射调用，toCall 实际上不可达。
DINA
DINA 的 workflow 如下：
DINA 包含三个主要的模块：
-
静态分析：生成 IAC 图和识别 DCL 和反射调用
-
动态分析：运行 DCL 和反射调用对应的代码增强 IAC 图
-
利用 IAC 图的生成结果识别可疑路径
Static analysis
DINA 的实现基于 JITANA。
-
Preprocessing：反编译生成字节码，为每个 app 生成方法调用图 MCG 和指令图 IG。
-
Reflection/DCL analyzer：检查 DCL 和反射 API 调用
-
Static IAC analyzer：对每个方法的指令图做遍历，匹配 manifest 文件中的 Intent 字符串，如果找到匹配，则会在两个与匹配的 Intent 动作相关的应用组件之间添加一条新边。
Dynamic analysis
-
Resolving reflection and loading new codes：之前提取的反射信息包括每个应用程序中实现反射和 DCL 的组件名称及相应的方法名称。这些应用程序的方法/组件被视为关注的方法（MoI），采用模糊测试来触发包含反射和DCL调用点的组件。
-
Dynamic IAC analyzer：一旦 DCL 加载新 dex 文件，DINA 会即刻拉取并解析整个类，而不仅限于被触发的 MoI；类内所有方法都会被增量扫描，随时发现二次反射/DCL，持续把新发现的跨应用通信边写回静态图。
IAC vulnerability analyzer
使用双向 DFS 寻找可能的缺陷路径。
Evaluation
在 DroidBench 的 Reflection 和 DCL 相关的测试中干掉了 FlowDroid + Iccta。
另一个结果比较有意思，展示了真实世界中的安卓应用是否真的包含这种模式。实验结果显示，92.0%（即 26,361/31,894）的 AndroZoo 应用实现了反射调用，51.1%（即 16,313/31,894）的应用实现了 DCL 调用。这表明 DCL 和反射机制在 Android 应用中得到了广泛应用。更值得注意的是，99.4% 的 3,000 款热门应用实现了反射调用，90.1% 的应用实现了 DCL 调用。因此，反射和 DCL 机制在热门应用中的采纳更为广泛。就恶意软件应用而言，85.0% 实现了反射机制，而仅有 24.3% 的应用采用了 DCL 机制。
在实验中还发现了一些被真实利用的隐蔽 IAC 漏洞。应用程序 appinventor.ai_created4each.My_Diary 和 com.my.mail 之间存在 Intent spoofing 漏洞，攻击过程如下图，
