SDC2026议题回顾 | 大语言模型驱动的移动软件安全分析实践

刁文瑞

山东大学网络空间安全学院教授、博士生导师

刁文瑞首先介绍了自己的研究方向。他主要从事智能化软件安全分析，包括代码分析与漏洞挖掘，研究对象涉及移动平台、物联网系统和开源代码。

移动生态的安全并不只涉及 Android 操作系统本身。它还包括手机厂商基于 AOSP 进行定制时引入的安全风险、手机应用程序自身的漏洞，以及 4G、5G、Wi-Fi 等网络基础设施的安全问题。本次分享重点讨论移动应用程序的安全分析。

图1：移动生态安全

当前移动应用面临多种安全风险，例如跨组件通信（ICC）漏洞、系统机制与配置缺陷、WebView 混合层攻击，以及凭据泄露和加密缺陷等。静态安全分析是检测这类问题的常用方式，但传统工具仍存在一些实际瓶颈。

一方面，Android 的 API 和系统机制不断更新，旧的检测规则可能逐渐过时；另一方面，应用广泛使用代码混淆，原本有意义的标识符被重命名，分析过程中可利用的语义线索随之减少。这些因素都会影响检测的准确性，并带来误报或漏报。

图2：移动应用程序安全分析面临的挑战

大语言模型具备代码理解和推理能力，但直接将其用于移动应用安全分析仍有几个问题。

首先是全局上下文不足。如果将单个文件或局部代码交给模型分析，模型可能无法掌握完整的调用关系和控制流，从而遗漏必要的上下文。

其次是幻觉与误报。模型可能生成并不存在的调用链，或者将正常代码判断为漏洞。再次是输出不稳定：即使输入相同的代码和提示词，多次分析得到的结果也可能不一致。最后，模型分析还涉及 Token 消耗与执行耗时；对于大型应用或多 Agent 方案，这部分成本可能很高。

因此，刁文瑞提出的思路并不是构建一个完全由大语言模型驱动的分析系统，而是让程序分析与大语言模型协同工作：由静态分析提供精确的调用图、控制流和分析边界，再由大语言模型阅读文档、理解语义并完成适合它的推理任务。

图3：程序分析与大语言模型协同

围绕这一思路，分享介绍了两个案例：其一是漏洞检测工具 RuleDroid，通过 Android 安全文档自动生成静态检测规则；其二是去混淆工具 DeMask，利用静态函数调用图引导大语言模型逐步恢复函数、类和包的语义标识符。

传统 Android 静态分析工具通常依赖专家阅读安全报告或官方文档，再手动编写检测规则。工具随后根据这些规则匹配代码中的特定特征。

但 Android 每年都会更新版本，既有 API 可能被废弃，也会出现新的 API 和新的漏洞。如果规则不能及时更新，工具在分析新应用时就可能产生误报和漏报。持续维护规则，需要专家反复阅读新文档并编写、更新规则，成本较高。

如果直接让大语言模型读取应用代码并输出漏洞报告，同样存在问题：模型可能产生虚假的调用链，且多次运行的结果不一定一致，难以满足批量检测对稳定性和确定性的要求。

RuleDroid 采用了不同的方式：不让大语言模型直接充当漏洞扫描器，而是让它阅读安全文档、生成静态检测规则，最终仍由确定性的静态分析引擎执行检测。

图4：RuleDroid总体设计

RuleDroid 的整体流程分为五个阶段。

第一阶段：数据获取。 系统收集 Android 官方文档、OWASP MASTG 和 Semgrep 规则仓库等安全知识来源，并构建 RAG 知识库，为后续规则生成提供支持。系统采用增量更新机制，尽量只获取发生变化的内容。

第二阶段：文档预处理。 原始 HTML 文档并不能直接作为理想的模型输入。系统会先对文档去噪、分段，再从中提取安全指南，将其整理成结构化且相关性更高的输入。

第三阶段：规则生成。 系统筛选适合转化为静态检测规则的安全指南，再由大语言模型生成规则。如果生成的规则未通过检查，系统会进一步修正，直到满足相应要求或达到设定的尝试次数。

图5：RuleDroid的规则生成流程

第四阶段：规则优化。 系统进一步增强规则、去除重复规则，并依据 OWASP 和 CVSS 等标准进行严重程度分类，以提高规则集的可靠性和可用性。

第五阶段：应用安全分析。 系统对输入的 APK 进行反编译和静态分析，将生成的规则应用于目标应用，并输出结构化的漏洞分析结果。大语言模型也可以参与告警过滤，但最终检测仍以静态分析结果为基础。

在这一流程中，复杂任务没有交给模型一次性完成，而是被拆分为多个单一目标的子任务。系统保留中间状态，并对前一步的输出进行核验，以便更准确地传递上下文并及时发现错误。

RuleDroid 的实验使用了多个数据集：Ghera 包含 59 个基础漏洞案例，MASTG 与 PIVAA 共包含 52 个案例，DroidCVE++ 则包含 278 个案例，其中加入了现实世界历史 CVE 的增强数据。实验使用 GPT-5、o4-mini、DeepSeek-V3.2 和 DeepSeek-R1 等模型处理不同阶段的任务。

初始规则生成耗时约 1.2 小时，成本约为 32 美元。多次独立运行的结果显示，规则生成具有较高稳定性；在抽样检查的 300 条规则中，284 条与源文档保持一致，语义一致率为 94.7%

图6：RuleDroid规则生成的稳定性与正确性

在与现有 Android 静态分析工具的对比中，RuleDroid 在多个数据集上表现出较好的检测效果。以 DroidCVE++ 数据集为例，RuleDroid 的一次运行检测召回率达到 90.29%。与直接使用大语言模型进行漏洞检测相比，RuleDroid 在该数据集上的检测召回率也更高，同时避免了直接让模型输出漏洞报告所带来的大量 Token 消耗。

研究团队还从 AndroZoo 中选取了 2019—2025 年的 10 万款真实应用，对 500 个随机采样告警进行人工核查，确认其中 417 个为真实漏洞，准确率为 83.4%。这些漏洞涉及 10 种不同类型，并有 57 个 CVE 编号经官方确认和分配。

图7：真实应用中的漏洞发现结果

其中一个案例是 CVE-2025-7889，涉及 Task-hijacking（任务劫持）。Android 的 taskAffinity 属性用于关联任务栈。攻击者可以在恶意应用的 Activity 中设置相关属性，使其与目标 Activity 的任务栈关联，从而在目标 Activity 启动时触发恶意应用的 Activity。

检测这一问题，需要结合 Activity 是否可导出、taskAffinity 的设置以及 launchMode 等属性进行判断。传统工具出现漏报或误报的一个原因是规则未及时更新：该问题在 Android 11 中已经得到修复，当应用的最低支持版本（minSdkVersion）达到 Android 11 时，相关漏洞条件不再成立。若检测规则缺失或没有考虑这一变化，就可能产生漏报或大量误报。

RuleDroid 基于官方文档生成并增量更新规则，因此能够将这类版本变化纳入检测逻辑，改善规则的正确性与覆盖率。

图8：CVE-2025-7889任务劫持案例

Android 应用发布前，开发者经常使用 R8、ProGuard、DexGuard 等工具进行代码混淆。其中一种常见方式是标识符重命名：将原本具有明确含义的类名、方法名和变量名，改成 a、b、c 等缺乏语义的信息。

这种处理会让代码更难阅读，也会妨碍安全分析人员审计漏洞、识别隐私相关业务逻辑或分析恶意行为。

传统去混淆方法通常依赖先验知识。一类方法根据代码相似度，在已有代码库中寻找匹配项；另一类方法利用统计学习模型，根据代码特征推测标识符。这些方法在已有语料或已知 API 上可能有效，但面对应用特有的私有业务逻辑、未收录的代码或演进后的 API 时，就可能难以恢复正确语义。

直接使用大语言模型猜测标识符，也有局限。模型看到的局部代码可能不足以支撑准确命名，容易生成 updateState 这类较为笼统的名称；如果缺乏全局约束，还可能破坏方法重写、继承关系和多态调用的一致性。对大型应用进行全量分析时，Token 消耗和运行时间也可能很高。

DeMask 将静态程序分析与大语言模型结合起来。静态分析负责构建应用的函数调用图（FCG）和类依赖等结构信息，大语言模型则负责理解局部代码语义。系统利用程序结构引导模型自底向上推导，从方法层逐步扩展到类和包层级，最终恢复具有全局一致性的标识符。

图9：DeMask的双向融合思路

DeMask 的流程可以概括为五个阶段。

第一阶段：第三方库映射。 系统先识别应用中已知的第三方库，为后续推理提供确定的语义锚点。这样可以将无需大语言模型推断的代码分离出来，避免模型在第三方库代码上消耗不必要的 Token。

第二阶段：构建带上下文的函数调用图。 系统为应用构建细粒度的函数调用图，剪除无关节点，并注入必要的上下文信息，让模型聚焦于真正需要恢复的核心方法。第三方库、系统 API 和资源命名等，都可以作为推导语义时的锚点。

例如，如果一段调用关系显示某个方法先读取图片，再通过网络发送数据，结合相关上下文，就有机会推导出该方法与发送图片有关，而不是仅仅给它一个通用的名称。

第三阶段：恢复方法与字段语义。 系统根据被调用者（Callee）的上下文，推导当前方法的名称和行为描述，并通过自底向上的语义传递逐步扩大分析范围。在命名过程中，还需要考虑一致性和唯一性，避免同一类方法或重写关系出现冲突。

第四阶段：恢复类与包的语义。 在方法级结果的基础上，系统继续恢复类名，再重建包级结构。通过全局命名约束，保证同一个包中的类名唯一，并尽量维持子包与父包之间的逻辑一致性。

第五阶段：验证并重建 APK。 大语言模型生成的结果可能出现格式错误或不符合语法的命名，因此系统会进行格式和一致性检查，在 Smali 字节码层面完成批量重命名，再使用 Apktool 重新打包构建 APK，生成可以继续运行和审计的应用版本。

DeMask 的原型系统约有 9,100 行 Java 代码，后端使用 GPT-5.4-mini。实验数据包括 50 个来自 F-Droid 的开源良性应用、30 个来自 AndroZoo 的真实恶意应用，以及 741 个高频第三方库。研究团队将 DeMask 与 Androidmeda 和 DOBF 等工具进行了比较。

在大语言模型评估中，DeMask 的语义恢复率（ERR）为 88.6%，Androidmeda 为 44.7%，DOBF 为 26.3%；在用户研究中，DeMask 的 ERR 达到 96.7%。在多工具横向比较中，用户研究的最佳结果率（BRR）为 73.1%，也高于对比工具。

效率方面，每处理 1,000 个方法，DeMask 平均耗时约 3.2 秒，Androidmeda 为 95.5 秒，DOBF 为 694.2 秒。DeMask 的平均 Token 消耗约为 4.8K，而 Androidmeda 为 714.1K。

图10：DeMask与现有工具的效果及开销对比

研究团队还将 DeMask 用于恶意应用分析。实验从 AndroZoo 中选取了 30 个经过混淆的恶意应用，并比较它们在去混淆前后被 VirusTotal 检测为恶意软件的引擎数量。

去混淆前，平均有 32 个引擎将样本判定为恶意；去混淆后，这一数字下降到 15。这个结果看起来有些反直觉。研究团队分析认为，部分基于机器学习的恶意软件检测器可能过度依赖“随机、无意义的混淆字符”这一浅层特征，并将代码混淆行为本身当成恶意软件的判断依据。去混淆后，这一特征消失，反而导致部分检测器不再报警。

这说明，去混淆不仅能帮助分析人员更清楚地理解代码，也能暴露某些检测方法对表面特征的依赖。

在具体恶意样本中，恢复后的语义标识符可以帮助分析人员梳理其行为流程，例如入口隐藏、将行为委派给 Service，以及动态加载 DEX 等。相比于只看到无意义的混淆名称，语义恢复后的代码更容易呈现这些行为之间的关系。

配图11：去混淆对恶意软件检测结果的影响

分享最后，刁文瑞总结了将程序分析与大语言模型结合时的三个要点。

第一，静态分析是 AI 的骨架。 AST、函数调用图等传统结构化分析技术并没有过时，它们能够为大语言模型提供明确的逻辑边界、调用关系和确定性锚点。

第二，复杂任务需要模块化。 对于复杂的安全分析任务，不宜只依赖端到端的一次性推理，而应根据代码结构拆分为多个阶段的小任务，并持续检查中间状态。

第三，需要强制性的确定性验证。 不能把整个流程都交给大语言模型。对于生成结果，应通过编译器、语法检查器和其他确定性机制进行验证，过滤模型可能产生的幻觉，尽量保证结果稳定、可复现。

图12：程序分析与大语言模型协同的三个要点

通过 RuleDroid 和 DeMask 两项工作，分享展示了同一思路在移动应用漏洞检测与代码去混淆中的实践：利用程序分析提供结构和约束，让大语言模型承担语义理解与推理，再通过规则执行或确定性验证保证结果的可靠性。