💻 computer science

Towards LLM-Enhanced Android Taint Analysis

本文表明，智能体化大语言模型（LLM）方法在检测 Android 数据泄露方面显著优于传统的静态分析器 FlowDroid，尤其是在组件间通信、隐式流和反射等复杂场景下，这表明 LLM 的推理能力可以有效地补充现有的污点分析技术。

原作者： Nicholas Miazzo, Marco Alecci, Jordan Samhi, Jacques Klein, Eleonora Losiouk

发布于 2026-08-26

📖 1 分钟阅读☕ 轻松阅读

原作者： Nicholas Miazzo, Marco Alecci, Jordan Samhi, Jacques Klein, Eleonora Losiouk

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

在移动应用程序的数字世界中，一场针对私人信息窃取的持久且无声的战斗正在进行。每当智能手机应用访问用户的地理位置、联系人或唯一的设备 ID 时，它都在触碰一段敏感数据。当这些数据从其来源源流向不安全的目的地（例如网络服务器或公共日志）时，危险便随之而来，因为在那里它们可能被恶意攻击者拦截。为了阻止这种情况，安全专家使用一种称为“污点分析”（taint analysis）的技术。可以将这一过程想象成一个数字追踪系统，它为敏感数据打上一个虚拟的“污渍”，并追踪它穿过应用程序复杂的代码，以观察它是否最终到达了危险的出口。多年来，实现这一目标最可靠的方法是通过静态分析工具，这些工具就像是专家们呕心沥血绘制的高度专业化的地图，用以理解 Android 操作系统的运作方式。这些地图允许工具预测数据的移动路径，但它们是脆弱的；如果应用程序使用了地图未知的技巧，追踪器就会失去信号。

最近，软件领域涌现出一种新型的智能：大语言模型。这些强大的计算机系统经过海量文本和代码的训练，能够像人类读者一样理解上下文并进行逻辑推理。来自帕多瓦大学和卢森堡大学的研究小组提出了一个大胆的问题：这些智能系统在没有任何特殊训练或预设 Android 世界地图的情况下，能否自行弄清楚敏感数据如何在应用中移动？他们想看看，一个理解语言的机器是否能仅仅通过阅读代码、寻找线索，就能发现传统工具所遗漏的泄露漏洞。他们的研究表明，答案是肯定的，而且这些新系统可能不是要取代旧工具，而是与它们协同工作，以捕捉那些最难以捉摸的威胁。

研究人员通过将一种标准的、知名的安全工具与现代大语言模型进行对比，来测试这一想法。他们使用了一个名为 DroidBench 的基准测试集，这是一个包含 190 个测试用例的集合，专门用于挑战具有隐藏代码、动态加载和应用各部分之间复杂通信等棘手场景的安全软件。这种被称为 FlowDroid 的标准工具依赖于前文提到的精心设计的地图。当研究人员运行测试时，传统工具仅找到了大约一半的已知数据泄露，其得分反映了它在处理困难案例时的挣扎。相比之下，大语言模型（具体为 Gemini-3 Flash 版本）扮演了一个自主智能体的角色。它并没有遵循一套僵化的规则，而是被赋予了逐步探索应用程序代码的能力，像人类分析师一样提出问题并追踪路径。这种方法使其找到了测试集中几乎所有的泄露点，其成功率几乎是传统工具的两倍。

最显著的结果出现在传统工具通常失败的类别中。当数据通过复杂的内部通信移动，或者当应用使用“反射”（reflection，一种代码可以在运行时检查并修改自身的技术）时，传统工具往往一无所获。然而，大语言模型成功地应对了这些障碍，高精度地识别出了数据流。它在处理“隐式流”（implicit flows，即数据通过微妙的副作用而非直接传输而泄露）以及“原生代码”（native code，由不同语言编写且通常对标准分析隐藏的代码）方面也表现得异常出色。研究人员发现，虽然传统工具非常谨慎且极少做出错误指控，但它漏掉了太多真实的问题。相反，大语言模型在发现隐藏泄露方面表现得好得多，尽管它偶尔也会犯错，即把不存在的模式误认为是有问题的模式。

为了验证这在现实世界中是否成立，团队将同样的方法应用于从 Google Play 商店下载的一小部分真实的 Android 应用程序。由于没有完美的真实应用泄露清单可供对比，研究人员对发现的结果进行了人工检查。他们发现，大语言模型发现了 17 个传统工具完全错过的潜在泄露点。经过人工仔细核查，其中 16 个被证实为真实的数据泄露，这证明了该模型能够发现活跃软件中尚未被检测到的风险。其中一个具体的例子涉及一款应用，其触发数据泄露的方法被隐藏在一个反射调用之后，这一技巧阻断了传统工具甚至开始搜索的过程。然而，大语言模型能够理清其中的混乱，并追踪到数据的路径。这表明，这种新方法不仅是一个理论练习，更是一个能够发现真实漏洞的实用工具。

这项研究并不声称大语言模型是现有安全工具的完美替代品。研究人员指出，对于简单案例，这种新方法并非总是必要，且计算成本较高。此外，模型可能会出现不一致的情况，有时会对同一段代码产生不同的结果，并且偶尔会产生“幻觉”，即编造不存在的泄露。为了解决这个问题，团队多次运行分析，并且只接受在多次运行中一致出现的发现。最终的结论是，应用程序安全的未来很可能在于一种混合方法。传统工具对于常见问题而言既快速又可靠，可以处理大部分工作；而大语言模型则可以有选择性地部署，用于应对标准地图失效的最复杂、最令人困惑的情景。这种结合将利用成熟方法的快速性和人工智能的推理能力，构建起一道更强大的防范数据窃取的防线。

技术摘要：迈向 LLM 增强型 Android 污点分析

问题陈述

污点分析是检测 Android 应用中敏感数据泄露的一种关键技术，通过追踪数据从隐私关键源（例如设备标识符、位置信息）到不安全汇聚点（例如网络接口）的流向。虽然像 FlowDroid 这样具有高精度和上下文感知能力的静态分析工具被广泛采用，但它们也面临着众所周知的局限性。这些工具过度依赖于人工构建的 Android 框架模型，在处理复杂的行为时往往表现不佳，例如 组件间通信 (ICC)、反射 (Reflection)、动态代码加载、隐式流 (Implicit Flows) 以及 原生代码 (Native Code)。因此，在框架建模不完整或过于复杂的场景下，这些工具经常会遗漏有效的污点流（导致低召回率）。

与此同时，大语言模型 (LLMs) 已展示出强大的自然语言与编程语言推理能力，成功弥补了软件工程任务（如漏洞检测和漏洞分析）中的鸿沟。然而，一个悬而未决的问题是：在没有特定任务训练或手工编写框架模型的情况下，现成的 LLMs 是否能够有效地推理 Android 应用中的污点流。

方法论

作者提出了一种初步方法，利用智能体化 LLM (Agentic LLM) 进行污点分析，通过迭代式代码探索来取代对显式框架建模的需求。

核心方法

智能体交互 (Agentic Interaction)： LLM 作为一个分析智能体，动态地导航反编译后的应用程序代码。它不再依赖静态模型，而是通过迭代地探索代码库来假设并验证“源到汇聚点”的关系。
工具链 (MCP)： 为了实现与代码的交互，系统采用了模型上下文协议 (Model Context Protocol, MCP)。该标准允许 LLM 调用外部工具：
- JADX-MCP： 用于反编译 Android APK，并提供用于方法检索、交叉引用和类层级结构导航的 API。
- Ghidra-MCP： 用于分析原生库（.so 文件），以检查底层程序结构和函数。
工作流：
- 通过 JADX 对 APK 进行反编译。
- 通过 Ghidra 处理原生库。
- LLM 查询这些工具，以追踪敏感信息跨组件和跨语言的传播。
- 识别出的流被序列化为结构化的 JSON 报告。
缓解非确定性： 为了解决 LLM 的幻觉和伪输出问题，每个应用都会使用相同的提示词进行 $N$ 次分析。只有当一个流在至少 $\lfloor N/2 \rfloor + 1$ 次运行中出现时，才被视为有效流。

实验设置

评估的模型： 商业模型 Gemini 3 Flash 和开源模型 Qwen3.5-27B。
基准测试：
- DroidBench (v3.0)： 包含 19 个类别（如 ICC、反射、生命周期）的 190 个测试用例。
- 真实世界应用： 来自 AndroZoo（过去 5 年 Google Play 上的应用）的一组小型应用，用于定性评估。
基线 (Baseline)： 使用默认配置执行的 FlowDroid（黑盒使用方式），以反映常见的应用场景。

核心贡献

新颖视角： 探讨了现成的 LLMs 是否可以在没有显式框架模型或特定任务训练的情况下，对 Android 污点流进行推理。
LLM 驱动的方法： 设计了一种结合反编译代码与基于 MCP 的工具交互（JADX 和 Ghidra）的方案，从而创建一个迭代式分析智能体。
初步实证研究： 证据表明，基于 LLM 的推理可以补充传统分析器，特别是在具有挑战性的场景中，这为未来的混合方法提供了动力。

实验结果

RQ1：在 DroidBench 上的整体性能

基于 LLM 的方法在 F1 分数方面显著优于 FlowDroid。

FlowDroid： F1 分数为 0.55（精确率：0.83，召回率：0.42）。
Gemini 3 Flash： F1 分数为 0.96（精确率：0.96，召回率：0.95）。
Qwen3.5-27B： F1 分数为 0.88。
性能的提升主要由召回率的大幅增加驱动，这表明 LLM 能够检测到 FlowDroid 遗漏的流。

RQ2：不同类别的性能表现

LLM 方法在传统工具难以处理的类别中表现出了显著的优越性：

组件间通信 (ICC)： 0.95 (LLM) vs. 0.17 (FlowDroid)。
隐式流 (Implicit Flows)： 0.94 (LLM) vs. 0.00 (FlowDroid)。
反射 (Reflection)： 1.00 (LLM) vs. 0.50 (FlowDroid)。
原生代码 (Native Code)： 1.00 (LLM) vs. 0.00 (FlowDroid)。
相反，两种方法在动态加载 (Dynamic Loading) 和不可达代码 (Unreachable Code) 方面都遇到了困难，这表明 LLM 并非解决所有静态分析挑战的万灵药。

RQ3：真实世界应用

在 5 个真实世界应用中，LLM 方法（Gemini 3 Flash）识别出了 17 个 FlowDroid 未报告的额外流。

验证： 两名专家标注员对这些流进行了手动逆向工程。17 个中的 16 个被确认为真阳性（实际的数据泄露）。其中 1 个被确定为 LLM 的幻觉。
具体案例： 在一个实例中，源方法是通过反射检索的。FlowDroid 在查找过程中无法解析该源，而 LLM 通过迭代探索成功推理出了该流。
互补性： LLM 遗漏了一些被 FlowDroid 检测到的流，这证实了两种方法捕捉到的污点流类别存在部分差异。

意义与主张

本文将这项工作定位为一项初步研究，而非生产就绪的解决方案。其主要意义在于证明了：

LLM 可以无需模型进行推理： 现成的 LLMs 可以在没有手工构建的 Android 框架模型的情况下，有效地识别非平凡的污点流。
互补而非替代： LLM 在传统建模失效的复杂场景（ICC、反射、原生代码）中特别有效，但在标准场景下可能是不必要或成本过高的。
混合潜力： 研究结果为混合分析流水线提供了动力，即由传统的静态分析器高效处理常见情况，同时在遇到挑战性场景时选择性地触发 LLM，以提高整体的召回率和有效性。

作者承认了局限性，包括 LLM 的非确定性、幻觉以及多次运行的高计算成本。他们总结道，虽然 LLM 不能取代传统的静态分析，但它们提供了一种极具前景的补充技术，用于增强复杂 Android 环境下的污点分析。未来的工作将侧重于设计稳健的混合流水线，并扩大在更大规模真实数据集上的评估。