通过污点分析检测嵌入式系统中的漏洞：一项综述

《ACM Computing Surveys》：Detecting Vulnerabilities in Embedded Systems via Taint Analysis: A Survey

　　摘要
嵌入式系统受到各种安全漏洞的困扰，这些漏洞可能导致严重的攻击。因此，快速准确地检测和缓解这些漏洞至关重要。在本文中，我们调查了嵌入式系统中漏洞检测的现有研究，以污染分析为中心视角。具体来说，我们描述和分类了嵌入式系统，强调了嵌入式系统对污染分析带来的挑战，考察了最先进的技术，并对这一领域的数十种工具进行了分类。我们的目标是让相关方更好地了解提高嵌入式系统安全性和可靠性的潜在解决方案。最后，我们预测并讨论了嵌入式系统中污染分析的一些未来发展方向。

人工智能摘要
此摘要是由自动化工具生成的，并非由文章作者撰写或审阅。它旨在帮助发现、评估相关性，并协助来自相关研究领域的读者理解本文内容。它旨在补充作者提供的摘要，后者仍然是论文的权威版本。点击此处了解有关此摘要的准确性、清晰度和有用性的反馈。您的反馈将有助于改进未来的版本。

1 引言
嵌入式系统包括工业互联网（IIoT）平台、汽车电子控制单元（ECUs）和网络路由器等设备，已成为现代基础设施不可或缺的组成部分。最近的预测表明，到2030年，嵌入式系统的市场价值预计将达到1618.6亿美元[116]，突显了它们的普遍影响。尽管如此，嵌入式/IIoT产品通常在计算、内存、功耗和成本方面受到严格限制，同时还面临紧迫的上市时间压力。这些限制往往导致实际的安全权衡，例如简化的输入处理、在性能关键的代码路径中有限的防御性检查、依赖旧版或第三方组件以及减少的测试和保证覆盖范围。同时，嵌入式设备经常暴露于多种输入通道，包括网络数据包、传感器流和外设I/O，在实际部署中，可信数据与不可信数据之间的界限可能变得模糊。因此，嵌入式系统中大多数实际漏洞和故障都可以归结为不可信数据传播的模式：攻击者控制的（或其他不可信的）输入通过暴露的接口进入，经过内部组件的处理（有时验证或清理不足），最终影响安全敏感的操作。这种视角自然与污染分析（taint analysis）对嵌入式安全的看法一致，其中的核心问题是不可信数据如何流动以及应在何处进行检测或限制。
污染分析（TA）提供了一种以数据流为中心的方法来推理此类故障。早期工作[102]将TA定义为信任分析，提出这样的问题：“给定一些可信和一些不可信的输入，我们在执行某些代码后能否信任某个变量的值？”概念上，TA将不可信的输入标记为受污染的，通过程序数据流（包括指针引起的别名）传播污染，并在不可信值被用于安全相关操作或在未经明确验证的情况下（例如权限检查或敏感内存访问）时发出警告。这种框架通过明确说明为什么一个漏洞是可利用的来补充错误级别的描述（例如“缓冲区越界访问”或“整数溢出”：不安全操作可以通过其可信性尚未确定的数据到达）。

例如OpenSSL中的“Heartbleed”漏洞[5]和gSOAP中的“Devil’s Ivy”问题[6]就可以用这种TA观点精确描述：精心设计的不可信消息字段（源）可以影响边界/长度决策和内存操作（汇），从而导致意外泄露或损坏。在嵌入式部署中，这种视角尤为重要，因为相同的库和协议处理器在各种设备和固件变体中广泛重用。

然而，在嵌入式环境中应用TA比在传统系统中具有更大的挑战性。我们将针对这些嵌入式特定限制定制的TA技术称为嵌入式系统污染分析（ESTA），我们将在以下部分讨论和系统化这些技术。

1.1 ESTA中的挑战
嵌入式系统暴露于各种数据源，包括配套应用程序、传感器和联网设备，其中攻击者控制的输入带来了重大风险。嵌入式固件的短开发周期和闭源性质往往阻碍了彻底的安全测试，从而创建了攻击链，使得未经验证的数据渗透到敏感功能（例如内存操作或协议处理器）中。这类漏洞被称为污染式弱点（CWE-896）[93]，并根据传播路径进一步分为五个子类别，即命令（CWE-990）、环境（CWE-991）、转换（CWE-992）、处理器（CWE-993）和变量（CWE-994）。当受污染的数据未经输入清理就到达memcpy或sprintf等系统调用时，可能会触发缓冲区溢出（CWE-120）、格式字符串漏洞（CWE-134）、命令注入（CWE-78）或SQL注入（CWE-89）等漏洞。检测这些漏洞需要跟踪从不可信来源到敏感汇的数据流，这一过程称为TA。

基于上述引入的TA概念，将其应用于嵌入式系统并非易事，原因包括：
- 硬件依赖性：嵌入式固件通常依赖于专用外设和自定义硬件接口，这使得仿真和动态分析变得复杂。
- 闭源性质：许多固件镜像缺乏源代码，迫使分析在二进制级别进行。
- 协议复杂性：嵌入式设备使用专有或状态化的协议（例如Modbus和蓝牙低功耗（BLE）），需要上下文感知的污染建模。

ESTA还受到异构架构、符号剥离和固件布局、多二进制组合以及设备特定交互的影响。这些因素使得静态推理和动态验证比在传统系统中更加困难。鉴于这些挑战，本调查通过分类静态和动态方法、剖析端到端的工作流程，并总结剩余的开放问题，提供了ESTA的全面综合。

1.2 动机和研究空白
本调查解决了当前文献中的两个关键空白：
(1) 主流方法的不足：传统的漏洞检测技术（如模糊测试）难以识别嵌入式系统中的污染式漏洞，而这些漏洞通常需要对数据流有语义上的理解，而不仅仅是随机输入变异。虽然像SaTC[25]、Arbiter[137]、EMTaint[30]和LARA[171]这样的工具已经提高了嵌入式系统的TA能力，但缺乏对其方法的系统概述。
(2) 缺乏专门的调查：现有的嵌入式安全研究专注于模糊测试[38, 40, 165]或一般漏洞检测[43, 46, 107]，但忽视了TA中的独特挑战和解决方案。本调查通过提供嵌入式系统漏洞检测的全面分类和技术分析来填补这一空白。

1.3 贡献
本调查对ESTA进行了结构化分析，围绕四个研究问题（RQ1–RQ4）展开，并基于2010年至2025年初在顶级会议（例如USENIX Security）和期刊（例如IEEE TDSC）上发表的88篇论文进行了回顾。主要贡献包括：
RQ1 ESTA的关键挑战是什么？（第4节）我们分类了目标识别、流程分析和硬件依赖性等障碍，并区分了静态分析和动态分析面临的挑战。
RQ2 提出了哪些ESTA方法和工具，如何系统地对其进行分类？（第5节）我们将技术分为静态ESTA（例如可达性分析和符号执行）和动态ESTA（例如动态TA和TA辅助模糊测试（TAF）），并比较了代表性工具。
RQ3 一个端到端的ESTA工作流程是什么样的，现有解决方案如何应对每个阶段？（第6节）我们详细描述了ESTA的流程，从固件获取和污染源/汇识别到基于仿真的验证，并总结了每个阶段如何缓解相应的挑战。
RQ4 ESTA的开放问题和未来发展方向是什么？（第7节）我们探讨了定向ESTA、状态化协议TA和大型语言模型（LLM）增强TA等新兴趋势。

通过综合最先进（SOTA）技术并识别开放问题，本调查旨在成为研究人员和从业者通过TA提升嵌入式系统安全性的基础资源。

1.4 结构
本文的其余部分组织如下。第2节提供了相关工作的详细描述和比较，包括通用TA方法和专门为嵌入式系统设计的漏洞检测方法。第3节描述了调查方法论，包括文献收集和总结。第4节介绍了嵌入式系统的背景，比较了传统TA与ESTA，并讨论了ESTA特有的关键挑战。第5节到第6节，我们提供了ESTA研究的详细分类和分析。之后，我们在第7节讨论了未来的研究机会，并在第8节进行总结。

2 相关工作
先前的嵌入式系统安全研究产生了多项关于漏洞检测、模糊测试和支持分析基础设施的调查。我们根据五个维度（领域焦点、挑战的明确讨论、TA范围、可行性推理（解决）和验证实践）对代表性调查进行了比较，并在附录A.1（表S1）中提供了详细矩阵。现有的调查提供了互补的视角。Feng等人[46]为物联网固件漏洞检测提供了分类，但主要将TA视为静态代码分析，而我们的调查进一步系统化了污染目标建模、解决策略和动态验证。Mishra等人[92]调查了实时嵌入式系统的控制流完整性（CFI）技术，强调了CFI机制及其资源、时间和调度性约束。相比之下，我们的调查专注于污染式漏洞，并系统化了它们的识别、传播分析、可行性验证和验证。嵌入式模糊测试调查（例如Muench等人[96]、Joobeom等人[165]、Zhu等人[180]、Eisele[40]和Mallissery等人[87]）提供了广泛的分类和实际见解，但通常没有充分强调对攻击链理解至关重要的污染传播建模和源到汇的推理。专注于固件重宿主和仿真的基础设施工作（例如Wright等人[149]和Fasano等人[43]）澄清了关键系统瓶颈，但没有明确将执行保真度与TA准确性联系起来。Qasem等人[107]总结了漏洞检测流程，但将污染跟踪视为一个组件而不是首要要素。最后，Song等人[128]系统化了通用软件的清理技术，但没有解决我们通过硬件感知仪器（第6.3.2节）讨论的嵌入式特定约束。

与以往的调查相比，我们的工作明确了三个区别：(i) 我们提供了一个统一的以ESTA为中心的框架，将嵌入式挑战与以污染为中心的建模和验证联系起来，而不仅仅是关注模糊测试分类或重宿主基础设施；(ii) 我们强调了TA与模糊测试之间的整合——这在以前的工作中通常被视为正交的[38]——并总结了混合设计（第6.3.4节）；(iii) 我们强调了对外设和执行差距的嵌入式特定建模，补充了[149]中发现的局限性。总体而言，尽管现有调查提供了有价值的领域特定见解，但没有一个提供我们这种以嵌入污染为中心的传播约束、仪器选择和验证策略的综合。

3 调查方法
受Harzevili[55]和Joobeom[165]指南的启发，我们提供了关于ESTA的全面调查。在以下部分，我们详细介绍了我们的收集策略和出版物总结。

3.1 收集策略
我们建立了一个包含2010年1月至2025年4月期间131篇ESTA相关出版物的档案，以支持对嵌入式系统的TA进行全面调查。我们首先搜索了主要的学术数字图书馆，包括IEEE Xplore、ACM数字图书馆、USENIX、Internet Society、Elsevier Science Direct、SpringerLink和Wiley Online Library，使用关键词组合如“Embedded/IoT TA”、“Firmware/Embedded/IoT TA”、“Embedded/IoT taint vulnerability”和“Embedded/IoT taint security”。然后我们将搜索范围扩展到在线文献库，重点关注DBLP[73]。作为额外的覆盖检查，我们还检查了主要来源集之外的其他渠道，特别是使用目标关键词查询和反向/正向引用跟踪的短论文出版物和嵌入式系统或实时期刊（例如IEEE Micro、EMSOFT、RTSS和RTAS）。结果，这一步没有发现额外的符合条件的ESTA主要研究。

在收集候选论文后，我们筛选了摘要并排除了明显不相关的工作。当摘要不足时，我们查阅了全文并应用了预定义的纳入标准：
- 计算机科学文献；
- 用英语编写；
- 可在线公开获取；
- 至少4页，由信誉良好的出版物发表。

在审查过程中，我们还进行了参考文献检查和引用跟踪，以识别缺失的论文；新发现的候选论文被添加并使用相同的程序重新评估。最终，我们将候选论文范围缩小到88篇符合我们调查范围的论文，称为主要研究[69]。此外，我们还确定了五篇2010年之前的代表性工作作为方法论基础或先驱。由于这些工作不在2010–2025年的时间范围内，因此将它们从88篇主要研究中排除，并在第4.3节中单独讨论，以提供后续发展的背景。这些论文主要来自IEEE Xplore、ACM数字图书馆、USENIX和Elsevier Science Direct。虽然这个集合可能并不全面，但我们认为它足以描述当前的最佳技术发展（SOTA）并概述ESTA领域的研究趋势。3.2 出版物总结 图1显示了2010年1月至2024年12月（即过去15年）关于ESTA的出版物数量。数据显示，出版物数量呈现出持续上升的趋势，从2010年的相对较低数量开始，随后几年逐渐增加。值得注意的是，2021年之后的出版物数量有了明显的加速。这种上升趋势表明了该领域日益增长的兴趣和研究活动，反映了测试自动化（TA）在嵌入式系统漏洞检测中的重要性。图1. 每年ESTA出版物的数量（过去15年）。表1列出了至少发表了三篇关于ESTA的主要研究的顶级期刊，这表明了该领域日益受到认可和影响。这些研究中的大部分出现在顶级安全相关会议上，如USENIX安全研讨会（14篇）、IEEE安全与隐私研讨会（8篇）和ISOC网络与分布式系统安全研讨会（NDSS）（8篇），表明ESTA已成为系统和软件安全研究社区中的重要课题。其他值得注意的期刊包括CCS（6篇）、Computers and Security（5篇）和ISSTA（3篇），反映了跨软件测试、程序分析和软件工程领域的兴趣增长。表1. 期刊#主要研究数量USENIX安全研讨会（USEC）14篇IEEE安全与隐私研讨会（S&P）8篇网络与分布式系统安全研讨会（NDSS）8篇ACM计算机与通信安全会议（CCS）6篇Computers and Security5篇IEEE可信赖与安全计算交易（TDSC）3篇国际软件测试与分析研讨会（ISSTA）3篇国际软件工程会议（ICSE）3篇顶级ESTA期刊

表2展示了从主要数字图书馆和出版商那里检索到的重要研究数量。ACM数字图书馆和IEEE Xplore分别发表了25篇ESTA研究，其次是USENIX（14篇）、互联网协会（8篇）和Elsevier Science Direct（8篇）。这种分布表明ESTA研究集中在声誉良好且影响力较大的出版平台上。总计，71.2%的研究发表在会议和研讨会上，24.7%发表在期刊上，4.1%发表在工作坊上。会议论文的普及意味着ESTA仍然是一个快速发展的研究领域，前沿思想在这里迅速传播。

表2. 出版商#主要研究数量ACM数字图书馆25篇Elsevier Science Direct8篇IEEE Xplore数字图书馆25篇Springer在线图书馆5篇USENIX14篇其他3篇互联网协会8篇总计88篇

ESTA出版物在顶级期刊和出版商中的普及强调了其在应对资源受限的嵌入式系统固有安全挑战方面的日益重要性。这种方法论的多样性——涵盖26个旗舰会议和期刊——反映了嵌入式生态系统的指数级增长[100]，以及易受日益复杂的污染式攻击影响的攻击面的相应扩展[143]。这种跨学科的进展突显了需要适应架构的技术的重要性，这些技术需要在精度（例如，路径敏感的符号执行[137]）与现实世界部署环境施加的可扩展性约束之间取得平衡[96]。

4 背景与挑战
在本节中，我们讨论了文献中与ESTA相关的背景和特点，以回答RQ1。我们在4.1节中介绍了嵌入式系统和固件的定义，在4.2节中将传统测试自动化（TA）与ESTA进行了比较，并在4.3节中总结了2010年之前的基础，这些基础影响了后来的ESTA发展。最后，我们在4.4节中总结了ESTA面临的关键挑战。

4.1 嵌入式系统的定义
嵌入式系统是专门的计算平台，它们集成了定制的硬件和专用软件，用于执行特定领域的任务，例如汽车[105]、医疗保健[124]和工业物联网[163]。它们的硬件通常包括处理器（例如ARM和MIPS）、ROM/RAM、片上外围设备（例如计时器、ADC/DAC以及时钟/电源/复位/中断控制模块），以及通过总线（I2C、SPI）或网络接口（以太网、Wi-Fi）连接的片外设备[24, 149]，如图2所示。图2. 嵌入式系统的组成。嵌入式设备通常分为三种类型的固件[96]：（i）类型I，基于完整操作系统的系统（例如带有文件系统和协议堆栈的嵌入式Linux）；（ii）类型II，轻量级基于操作系统的系统（例如具有最小资源管理的RTOS）；以及（iii）直接在硬件上运行的裸机固件。启动过程通常包括分阶段的初始化（引导加载程序→内核/RTOS→驱动程序），在此期间，安全敏感的逻辑（如内存操作和协议处理）经常容易受到污染式攻击[44, 75, 113]。例如，攻击者控制的数据到达不安全的例程（如memcpy或sprintf）可能导致缓冲区溢出[29]。

在这项调查中，我们关注的是ESTA文献中频繁出现的嵌入式目标，并符合我们的固件分类（类型I–III）。具体来说，我们强调了图3中谱系上的三个代表性类别：（i）运行裸机或RTOS固件的MCU类控制器（类型II/III），其中数据流由中断、MMIO和外围设备状态决定；（ii）运行嵌入式Linux的网络化物联网设备（类型I），通常具有多组件固件布局（例如脚本/配置加上后端守护进程）和面向网络的攻击面；以及（iii）结合了丰富连接性与硬件接口I/O和长期服务的工业/边缘设备（类型I/II）。附录A.2（表S2）将这些类别映射到分析与相关的特征，并总结了选择和解释ESTA技术时的关键考虑因素。图3. 嵌入式系统类别的谱系。

4.2 传统污染分析与ESTA的比较
4.2.1 架构复杂性和多样性
传统测试自动化通常是针对标准化平台开发的，最常见的是x86[62]，其硬件环境和工具链成熟且一致，因此可以在可预测的操作系统/CPU配置之间实现强大的可移植性。相比之下，嵌入式系统高度异构，涵盖了诸如ARM、MIPS、PowerPC、MSP430、SPARC和RISC-V等多种架构，在指令集、寄存器模型、内存布局和字节序方面存在显著差异。因此，ESTA需要可扩展的分析设计，能够适应不同的指令集架构（ISA/ABI）和执行环境。

4.2.2 外围设备依赖性和安全影响
与主要通过用户空间接口或文件系统接收输入的传统系统相比，嵌入式固件严重依赖于传感器、GPIO、UART[72]、SPI[44]和I2C等外围设备来实现核心功能。这些交互通常通过直接寄存器访问或MMIO进行，并可能形成关键的控制和数据流路径。因此，ESTA必须将硬件引发的状态变化纳入污染跟踪；例如，传感器值可能影响安全决策，但从未出现在传统的输入流中，这就需要对外围设备有意识的污染源识别。此外，在嵌入式环境中，污染传播经常跨越硬件/软件边界：攻击者的影响可能来自外部总线、外围设备状态或固件更新渠道。因此，污染源的概念超出了标准输入API的范畴，包括寄存器值、MMIO观察到的信号和外围事件，迫使ESTA框架将硬件级语义整合到污染跟踪中。

4.2.3 分析目标的闭源性质
传统软件通常提供源代码访问和成熟的工具链，使得符号执行[19]和静态分析[33]能够更直接地使用。然而，嵌入式系统通常以定制的固件形式发布，文档有限且没有源代码，迫使分析师依赖逆向工程（例如IDA Pro [56]和Ghidra [8]）和硬件调试接口（例如JTAG）。因此，ESTA工具[27, 53, 171]必须在非标准化和信息匮乏的条件下操作二进制文件。缺乏源级语义也使得精确识别和 Instrumentation 污染源/汇点变得更加困难。在没有可靠的函数边界或数据结构定义的情况下，定位污染的进入、传播或泄漏的位置更容易出错，而在分支和内存操作之间进行细粒度的 Instrumentation 也更加困难。相比之下，传统系统可以更直接地实现源级污染模型，通常可以获得更高的精度和覆盖范围。

4.2.4 嵌入式系统对于分析的积极方面
在某些方面，嵌入式目标也有利于分析。许多系统为可预测性和时序保证而设计（例如WCET驱动的设计），这抑制了高度动态的行为，并简化了控制流推理和验证[148]。此外，像MISRA C这样的受限编码标准减少了容易出错的语言构造和未定义的行为，可以提高静态检查的适用性并简化语义假设[91]。最后，嵌入式固件通常具有更有限的功能集和较少的第三方依赖项，可能会减少行为变异性并缩小分析范围（尽管这因设备类别和领域而异）。

4.3 基础和前身（2010年之前）
本小节并不旨在全面覆盖所有内容。我们重点介绍了一小部分2010年之前的系统安全工作，它们的核心思想和机制后来直接与嵌入式和固件测试自动化相关，尤其是在可见性有限且仅提供二进制文件的情况下。
静态ESTA的基础。早期的工作表明，即使在代码结构部分未知或具有对抗性的情况下，也可以应用污染式推理。STILL [145]通过盲目反汇编输入、恢复部分控制流，并应用静态污染和初始化分析来检测嵌入在数据流中的攻击代码，暴露出自修改行为或混淆的间接控制传输等模式。IntScope [144]进一步展示了如何将污染式推理与高级程序分析相结合，包括在中间表示（IR）上的符号执行，以检测可能引发内存安全违规的不受信任整数的使用。这些工作共同建立了一个可重用的模板：首先恢复足够的结构进行分析，然后跟踪不受信任的值如何影响安全相关的计算。

动态ESTA的基础。在动态方面，2010年之前的系统为二进制文件上的细粒度污染跟踪建立了运行时机制。TaintCheck [99]通过标记不受信任的输入、在运行时跟踪传播并在污染数据到达危险操作时报告，普及了商业软件的动态测试自动化，而无需源代码。TaintTrace [31]探索了影子状态映射和传播的优化方法，以减少开销的同时保持字节级语义。Panorama [157]在QEMU中实现了系统范围的污染跟踪，维护CPU执行以及内存和I/O相关对象的影子状态，使得能够端到端重建复杂软件堆栈中的数据流。这些工作共同提供了核心的运行时构建块，包括影子状态设计、传播策略和整个系统的可见性，后来的ESTA工作在此基础上适应了固件仿真和外设密集型环境。

4.4 ESTA的关键挑战
ESTA面临着由于嵌入式硬件的异构性、固件的闭源性质以及复杂的数据流而产生的挑战。以下是这些挑战的分类，区分了适用于静态和动态ESTA的情况。此外，由于动态ESTA经常依赖于静态ESTA技术或分析结果，它也继承了一些静态ESTA面临的相同挑战。

4.4.1 静态和动态ESTA的常见挑战
- C1 目标确定：识别污染源（例如，网络输入函数如recv()）和汇点（例如，不安全的系统调用）是基础性的，但也容易出错。传统方法依赖专家的手动识别[17, 52]，这对于大型固件图像来说效率低下。虽然AI驱动的方法如LATTE [79]使用LLM自动化这一过程，但由于训练数据有限和二进制代码中的语义模糊，假阳性仍然是一个问题。
- C2 流分析复杂性：流分析可以分为控制流分析（CFA）和数据流分析（DFA），其分析对象分别是调用图（CG）、控制流图（CFG）和数据流图（DFG）。CG是程序中函数之间调用关系的图形表示，节点代表函数，边代表函数调用。CFG是一个图，其节点是基本指令块，边代表它们之间的控制关系。DFG依赖于CFG，并关注不同基本块中变量可能的值和状态。流分析的挑战可以根据其工作流程分为以下几类：
C2.1 代码混淆：供应商经常对固件进行混淆以防止逆向工程，移除符号表或使用不透明的谓词。这复杂化了CFG和DFG的重建，这对于污染传播分析至关重要[125]。
- C2.2 间接跳转：嵌入式固件经常使用间接跳转来实现虚拟表、多态性或动态加载，需要在运行时解析来自寄存器或内存的跳转目标[27, 46]。像angr [125]这样的工具使用符号执行来跟踪可能的目标地址，但这增加了计算开销。
- C2.3 动态行为：运行时事件（例如，动态内存分配和通过POSIX的进程间通信）需要建模上下文敏感的数据流。例如，Android固件中的组件间通信涉及跨应用程序边界的意图跟踪[11]。例如，IoTFlow [118] 试图通过应用价值集分析（VSA）来解决这一挑战。— C3 约束求解和可达性：确定污染源和污染汇之间的可行路径在计算上非常密集，特别是在运行时可观察性有限的固件中。像可达性分析 [125] 这样的静态方法缺乏路径敏感性，导致高误报率，而符号执行 [25] 在复杂的二进制文件中会遇到路径爆炸问题。结合静态分析与动态仿真的混合方法（例如 SHFuzz [75]）试图在准确性和可扩展性之间找到平衡，但需要复杂的约束求解器。— C4 结果验证：手动验证威胁分析（TA）结果容易出错且耗时。像有界模型检测（BMC）[39, 53] 这样的自动化方法需要专家知识来制定约束条件，而基于模糊测试的验证 [151] 受限于仿真器的保真度（例如 QEMU 的不完整外设建模）或 real-device 可扩展性问题。

4.4.2 动态 ESTA 的特定挑战。— C5 仪器开销：动态污染分析（DTA）[42, 162] 和结合 TA 的模糊测试 [109, 111] 通常依赖于运行时仪器来跟踪数据流。然而，在嵌入式固件环境中，仪器技术的选择在很大程度上受到实际因素的限制，如源代码可用性、硬件访问性和工具支持。实际上，动态二进制仪器（例如 PIN [82]）和字节码仪器 [42, 162] 是最常用的方法，部分原因是它们可以通过仿真和/或管理运行时应用于仅包含二进制文件的程序。当有源代码或合适的硬件特性可用时，也可以使用源代码级仪器 [142] 或 HIFT [58, 138]，但这些选项经常受到闭源固件、专有工具链或硬件设置的成本和可用性的限制。静态二进制重写（例如 SHFuzz [75]）为仅包含二进制文件的场景提供了另一种选择。无论选择哪种机制，仪器都会引入额外的性能和资源成本，这对于资源受限的设备来说可能特别具有破坏性。— C6 硬件依赖性：嵌入式系统依赖于专业的外设（例如 UART）和特定于硬件的协议，需要进行精确的仿真才能进行动态分析。像 HALucinator [32] 这样的工具可以抽象硬件交互，但建模外设行为（例如寄存器配置）仍然是一个重大挑战，经常导致仿真间隙 [149]。— C7 输入生成：嵌入式系统中的污染源通常与专有或有状态协议（例如 Modbus 和 BLE）相关。生成符合协议规范的有效测试输入（例如路由器的 HTTP 请求格式）并非易事。像 UCRF [109] 这样的黑盒模糊测试工具使用静态分析从固件中提取参数关键字，但有状态协议的转换（例如 FTP 会话状态）很少被建模，从而限制了模糊测试或分析的覆盖范围。— C8 崩溃检测限制：TAF 依赖于可观察到的崩溃作为执行中的故障指标。然而，嵌入式系统通常缺乏崩溃报告机制（例如基于 MMU 的分段故障），这在桌面操作系统中是存在的。像 AFL++ [47] 这样的工具依赖信号处理（例如 SIGSEGV）进行崩溃检测，但在资源受限的环境中，无声的故障或微妙的数据损坏可能无法被检测到，导致误报 [96]。

4.5 挑战总结
附录 A.3 中的表 S3 提供了八个反复出现的挑战的定性总结，并指出了它们如何不同地影响静态和动态 ESTA。总体而言，目标确定、流分析和约束求解主要通过建模工作和可扩展性限制来考验静态流程，而动态流程则受到执行方面因素的更多限制，如仪器开销、硬件依赖性、有状态的输入生成以及崩溃/异常的可观察性。这些观察结果激发了结合精确的静态推理与强大的执行基础和反馈驱动测试的混合解决方案，以提高覆盖率和验证可靠性。

5 ESTA 分类
图 4 展示了现有的 ESTA 方法的分类，按照两个维度进行组织：执行依赖性（静态 vs. 动态分析）和连接性级别（直接交互、仿真或独立固件分析）。该分类框架区分了操作静态固件二进制文件的技术和那些需要运行时执行或仿真的技术，同时解决了嵌入式系统异构性的独特挑战。

表 3 和表 4 分别总结了静态 ESTA 和动态 ESTA 的最新技术，其中 Target 描述了分析目标，Arch 描述了目标的架构，Open Access (OA) 表示研究工作是否开源，Challenge(s) Overcome 指的是克服的挑战。

表 3.
| 名称 | 年份 | 目标 | 架构 | 开源状态 (OA) | 克服的挑战 |
|------|------|-----------------|-------------|------------------|
| [DidFail] | 2014 | Android 应用 | ARM | NC | |
| FlowDroid [11] | 2014 | Android 应用 | ARM | NC | |
| Firmalice [124] | 2015 | 二进制文件 | ARM | PPC, X86 | NC | |
| IccTA [74] | 2015 | Android 应用 | ARM | NC | |
| DFlow [60] | 2015 | Android 应用 | ARM | NC | |
| DroidSafe [52] | 2015 | Android 应用 | ARM | NC | |
| angr [125] | 2016 | 二进制文件 | ARM | MIPS, PPC, X86 | NC | |
| Zheng et al. [172] | 2016 | 二进制文件 | ARM | MIPS | NC | |
| StubDroid [10] | 2016 | Android 应用 | ARM | NC | |
| BOOTSTOMP [113] | 2017 | 二进制文件 | ARM | NC | |
| DIALDroid [17] | 2017 | Android 应用 | ARM | NC | |
| Cheetah [36] | 2017 | Android 应用 | ARM | NC | |
| Amandroid [146] | 2018 | Android 应用 | ARM | NC | |
| REPRODROID [103] | 2018 | Android 应用 | ARM | NC | |
| SAINT [22] | 2018 | 源代码 | ARM | NC | |
| DTA [29] | 2018 | 二进制文件 | ARM | MIPS | NC | |
| COVA [84] | 2019 | Android 应用 | ARM | NC | |
| Elix [59] | 2019 | Android 应用 | ARM | NC | |
| CRIPTOREX [169] | 2019 | 二进制文件 | ARM | MIPS, PPC | NC | |
| BLESCOPE [181] | 2019 | Android 应用 | ARM | NC | |
| Cryptracer [127] | 2019 | Android 应用 | ARM | NC | |
| FirmXRay [147] | 2020 | 二进制文件 | ARM | NC | |
| FIRMSCOPE [41] | 2020 | 二进制文件 | ARM | NC | |
| KARONTE [114] | 2020 | 二进制文件 | ARM | AARCH64, PPC | NC | |
| SelectiveTaint [27] | 2021 | 二进制文件 | ARM | NC | |
| Cheng et al. [28] | 2021 | 二进制文件 | ARM | MIPS | NC | |
| SaTC [25] | 2021 | 二进制文件 | X86, ARM, MIPS | NC | |
| FastDroid [167] | 2021 | 二进制文件 | ARM | NC | |
| FBI [78] | 2022 | 二进制文件 | X86, ARM, MIPS | NC | |
| CSChecker [54] | 2022 | 二进制文件 | ARM | NC | |
| Zhang et al. [168] | 2022 | 二进制文件 | ARM | NC | |
| SPENDER [159] | 2022 | 二进制文件 | X86, ARM, AARCH64 | NC | |
| Zhan et al. [166] | 2022 | 源代码 | ARM, X86 | NC | |
| HEAPSTER [53] | 2022 | 二进制文件 | ARM, X86 | NC | |
| Arbiter [137] | 2022 | 二进制文件 | ARM | NC | |
| IoTFlow [118] | 2023 | Android 应用 | ARM | NC | |
| IoTProfiler [97] | 2023 | Android 应用 | ARM | NC | |
| EMTaint [30] | 2023 | 二进制文件 | X86, ARM, MIPS | NC | |
| TaintSA [133] | 2023 | Android 应用 | ARM | NC | |
| FITS [80] | 2023 | 二进制文件 | ARM, MIPS, X86 | NC | |
| Hermescan [49] | 2024 | 二进制文件 | ARM, MIPS, X86 | NC | |
| SLFHunter [156] | 2024 | 二进制文件 | X86, ARM, MIPS | NC | |
| LARA [171] | 2024 | 二进制文件 | X86, ARM, MIPS | NC | |
| OctopusTaint [106] | 2024 | 二进制文件 | ARM, MIPS | NC | |
| Mango [50] | 2024 | 二进制文件 | X86, AMD64, ARM, AARCH64, MIPS, PPC | NC | |
| ChkUp [150] | 2024 | 二进制文件 | ARM, MIPS | NC | |
| FIRMREC [151] | 2024 | 二进制文件 | ARM, MIPS | NC | |
| LATTE [79] | 2025 | 二进制文件 | ARM, MIPS | NC | |
| SinkTaint [161] | 2025 | 二进制文件 | ARM, MIPS | NC | |

表 S3 提供了八个反复出现的挑战的定性总结，并说明了它们如何不同地影响静态和动态 ESTA。总体而言，目标确定、流分析和约束求解主要通过建模工作和可扩展性限制来考验静态流程，而动态流程则受到执行方面因素的更多限制，如仪器开销、硬件依赖性、有状态的输入生成以及崩溃/异常的可观察性。这些观察结果促使人们开发出结合精确的静态推理与强大的执行基础和反馈驱动测试的混合解决方案，以提高覆盖率和验证可靠性。

5 ESTA 分类
图 4 展示了现有的 ESTA 方法的分类，按照两个维度进行组织：执行依赖性（静态 vs. 动态分析）和连接性级别（直接交互、仿真或独立固件分析）。这种分类框架区分了操作静态固件二进制文件的技术和需要运行时执行或仿真的技术，同时解决了嵌入式系统异构性的独特挑战。

表 3 和表 4 分别总结了静态 ESTA 和动态 ESTA 的最新技术，其中 Target 描述了分析目标，Arch 描述了目标的架构，Open Access (OA) 表示研究工作是否开源，Challenge(s) Overcome 指的是克服的挑战。

表 3.
| 名称 | 年份 | 目标 | 架构 | 开源状态 (OA) | 克服的挑战 |
|------|------|-----------------|-------------|------------------|
| [DidFail] | 2014 | Android 应用 | ARM | NC | |
| FlowDroid [11] | 2014 | Android 应用 | ARM | NC | |
| Firmalice [124] | 2015 | 二进制文件 | ARM, PPC, X86 | NC | |
| IccTA [74] | 2015 | Android 应用 | ARM | NC | |
| DFlow [60] | 2015 | Android 应用 | ARM | NC | |
| DroidSafe [52] | 2015 | Android 应用 | ARM | NC | |
| angr [125] | 2016 | 二进制文件 | ARM, MIPS, PPC, X86 | NC | |
| Zheng et al. [172] | 2016 | 二进制文件 | ARM | MIPS | NC | |
| StubDroid [10] | 2016 | Android 应用 | ARM | NC | |
| BOOTSTOMP [113] | 2017 | 二进制文件 | ARM | NC | |
| DIALDroid [17] | 2017 | Android 应用 | ARM | NC | |
| Cheetah [36] | 2017 | Android 应用 | ARM | NC | |
| Amandroid [146] | 2018 | Android 应用 | ARM | NC | |
| REPRODROID [103] | 2018 | Android 应用 | ARM | NC | |
| SAINT [22] | 2018 | 源代码 | ARM | NC | |
| DTA [29] | 2018 | 二进制文件 | ARM, MIPS | NC | |
| COVA [84] | 2019 | Android 应用 | ARM | NC | |
| Elix [59] | 2019 | Android 应用 | ARM | NC | |
| CRYPTOEX [169] | 2019 | 二进制文件 | ARM, M68K, PPC | NC | |
| BLESCOPE [181] | 2019 | Android 应用 | ARM | NC | |
| Cryptracer [127] | 2019 | Android 应用 | ARM | NC | |
| FirmXRay [147] | 2020 | 二进制文件 | ARM | NC | |
| FIRMSCOPE [41] | 2020 | 二进制文件 | ARM | NC | |
| KARONTE [114] | 2020 | 二进制文件 | ARM, AARCH64, PPC | NC | |
| SelectiveTaint [27] | 2021 | 二进制文件 | ARM | NC | |
| Cheng et al. [28] | 2021 | 二进制文件 | ARM | MIPS | NC | |
| SaTC [25] | 2021 | 二进制文件 | X86, ARM, MIPS | NC | |
| FastDroid [167] | 2021 | 二进制文件 | ARM | NC | |
| FBI [78] | 2022 | 二进制文件 | X86, ARM, MIPS | NC | |
| CSChecker [54] | 2022 | 二进制文件 | ARM | NC | |
| Zhang et al. [168] | 2022 | 二进制文件 | ARM | NC | |
| SPENDER [159] | 2022 | 二进制文件 | X86, ARM, AARCH64 | NC | |
| Zhan et al. [166] | 2022 | 源代码 | ARM, X86 | NC | |
| HEAPSTER [53] | 2022 | 二进制文件 | ARM, X86 | NC | |
| Arbiter [137] | 2022 | 二进制文件 | ARM | NC | |
| IoTFlow [118] | 2023 | Android 应用 | ARM | NC | 诸如binwalk [115]之类的工具，结合Capstone [21]反汇编引擎，有助于从二进制签名和操作码模式中识别与架构相关的元数据，从而实现与后续分析（例如QEMU和angr）的兼容性。6.1.2 漏洞数据库的获取。漏洞数据库为验证检测到的问题提供了真实情况和背景信息。CVE数据库[1]提供了带有唯一标识符（例如CVE-2023-41563）的标准化漏洞记录，支持一致的交叉引用。其他资源如Exploit Database [2]和Secunia Research [4]提供了漏洞详细信息、补丁和特定软件的风险信息。这些来源通常被用来提取与嵌入式系统相关的漏洞集合，这些集合可以用于生成污染源/汇的定义，并支持评估。例如，SaTC [25]利用CVE记录来描述固件中常见的输入处理漏洞，并指导基于关键词的威胁分析（TA）。总体而言，在预处理阶段收集固件和漏洞元数据可以为后续的静态和动态ESTA阶段提供准确且背景丰富的输入。6.2 通过静态分析检测漏洞。通过静态分析检测漏洞依赖于对固件二进制文件或源代码的结构分析，以追踪从不受信任的输入（污染源）到安全敏感操作（污染汇）的数据流。如图5所示，工作流程包括五个模块，每个模块都解决了第4.4节中概述的特定挑战：二进制提升（C2.1）、污染源/汇的识别（C1）、流分析（C2.2, C2.3）、约束解决（C3）和验证（C4）。我们在表5中总结了ESTA中的静态方法，并在后续章节中详细讨论了它们。表5. 名称 IRFlow 分析工具 目标识别 RC1Veri2DidFail [70] JimpleSoot 手动RMEFlowDroid [11] JimpleSoot 手动RMEFirmalice [124] VEX-IR 自实现启发式R,SMEIccTA [74] JimpleFlowDroid 手动RMEDFlow [60] JimpleFlowDroid 手动RMEDroidSafe [52] JimpleFlowDroid 手动RMEZheng等人 [172] VEX-IR,C类IRIDA Pro, angrAI驱动R,S,VMEStubDroid [10] JimpleFlowDroid 启发式, 手动RMEBOOTSTOMP [113] VEX-IRangr启发式, 手动R,S,VMEDIALDroid [17] JimpleFlowDroid 手动RMECheetah [36] JimpleFlowDroid 手动RMEAmandroid [146] JimpleFlowDroid 手动RMEREPRODROID [103] JimpleFlowDroid 手动RMESAINT [22] 自实现 自实现启发式SMEDTaint [29] VEX-IRangr启发式R,S,VMECOVA [84] JimpleFlowDroid 手动R,SMEElix [59] JimpleFlowDroid 手动R,SMECRYPTOREX [169] VEX-IRangr启发式, 手动R,S,VMEBLESCOPE [181] JimpleSoot 手动R,VMEBLESCryptracer [127] 未指定Androguard 手动R,VMEFirmXRay [147] P-codeGhidra启发式RMEFIRMSCOPE [41] 自实现 自实现手动RMEKARONTE [114] VEX-IRangr,BootStomp启发式R,S,VMEMordahl等人 [94] JimpleFlowDroid 手动RMESelectiveTaint [27] VEX-IRangr启发式R,S,VMECheng等人 [28] VEX-IR,C类IRIDA Pro, angr启发式R,S,VMESaTC [25] P-code,VEX-IRGhidra, KARONTE手动R,S,VMEFastDroid [167] JimpleFlowDroid 手动RMEFBI [78] VEX-IRangr, KARONTE启发式, 手动R,S,VMECSChecker [54] C类IRIDA Pro代码相似性, 手动RMEZhang等人 [168] JimpleFlowDroid 手动RMESPENDER [159] VEX-IR,C类IRIDA Pro,angr启发式R,S,VMEZhan等人 [166] LLVM-IR自实现启发式R,S,VMEHEAPSTER [53] VEX-IRangr启发式R,S,VBMCArbiter [137] VEX-IRangr启发式R,S,VFuzzingIoTFlow [118] JimpleFlowDroid启发式R,VMEIoTProfiler [97] JimpleFlowDroidA,启发式RMEEMTaint [30] C类IR,VEX-IRIDA Pro, angr启发式R,S,VMETaintSA [133] JimpleFlowDroid 手动RMEFITS [80] C类IR,VEX-IRIDA Pro, angrAI驱动,启发式R,S,VDBGHermeScan [49] C类IR,VEX-IRIDA Pro, angr启发式R,S,VMELFHunter [156] C类IR,VEX-IRIDA Pro, angrAI驱动,启发式R,S,VMEMOctopusTaint [106] P-code,VEX-IRGhidra,angr启发式R,S,VMELARA [171] C类IRIDA ProAI驱动,启发式RMEMango [50] VEX-IRangr启发式R,S,VMEChkUp [150] VEX-IR,P-codeangr,Ghidra启发式,代码相似性R,S,VME,EMTFIRMREC [151] P-code,VEX-IRGhidra,angrAI驱动,启发式R,S,VFuzzingSAMBA [77] C类IRIDA Pro启发式RFuzzingLATTE[79] P-codeGhidraAI驱动,启发式R,LLMsMESinkTaint [161] P-code,VEX-IRGhidra, angr启发式R,S,VMETechnique Matrix for Static ESTA1可达性分析和约束解决：(R: 可达性分析, S: 符号执行, V: 值集分析。)2验证：(ME: 手动工作量, BMC: 有界模型检查, DBG: 在模拟器/真实设备上调试, EMT: 基于模拟器的测试。)6.2.1 二进制提升。二进制提升是一个基础步骤，它将目标固件二进制文件转换为与平台无关的中间表示（IR），从而实现与架构无关的分析。流行的IR框架包括：—P-code (Ghidra [8])：它是一种灵活的寄存器传输语言，可以抽象出特定处理器的指令，便于跨架构的控制流建模。—VEX-IR (angr [140] 和 Valgrind [121])：它将机器代码规范化为统一格式，支持在ARM、MIPS和X86架构上进行符号执行[29]和DFA[80]。—Jimple (FlowDroid [15])：它是Android字节码的三地址代码表示，简化了基于Java的应用程序中的TA。—C类IR (IDA Pro [56])：它将汇编代码转换为高级语言（即C语言）的近似形式，有助于人类阅读混淆的二进制文件[49, 80, 159]。这些IR抽象了低级细节（例如，字节序和寄存器宽度），使工具能够重建CFG和DFG以进行后续的污染传播分析。例如，angr的VEX-IR通过将每条指令表示为一系列IR操作来实现动态符号执行，而Ghidra的P-code支持固件二进制文件的静态分析。6.2.2 污染源/汇的识别。识别污染源（不受信任的输入来源）和汇（安全敏感操作）是有效ESTA的先决条件：不正确的目标会使得后续的传播和报告不可靠。在嵌入式固件中，源通常包括网络接收函数（例如recv()和recvfrom()）和面向外设的接口，而汇通常涉及不安全的内存/字符串操作（例如memcpy()和sprintf()）或协议处理逻辑。由于源代码是封闭的、架构多样性以及混淆的存在，这项任务具有挑战性，因此需要多种识别策略。手动识别依赖于专家知识来枚举源/汇并制定规范[60, 74]。对于众所周知的危险库（例如strcpy和sprintf），这种方法可能是精确的，但扩展性较差，且难以适应定制的固件和命名约定[11, 52]。代码相似性匹配通过搜索具有已知模式的函数（例如，关联的CFG）或模糊哈希[45, 48]来提高重用率。这减少了手动工作量，但跨架构的相似性和有限的参考语料库可能会限制其鲁棒性。启发式分析利用来自内存操作或组件间行为的轻量级线索来触发候选者[109, 160]。HEAPSTER [53]从内存操作行为推断汇，并追溯到源；RSFUZZER [158]使用符号执行来检查与内存相关的操作（例如memcpy）是否依赖于攻击者控制的指针。SaTC [25]进一步利用前端工件和后端代码（例如，用户和密码）之间的关键词重叠来支持跨组件识别。启发式方法效率高，但可能会错过依赖于上下文的情况或在高度定制的固件中引入误报。AI驱动的识别利用基于学习的推理来提高自动化[17, 154]。FITS [80]通过对CFG/DFG风格的特征应用相似性聚类[3]来检测类似源的行为，通过与已知的内存相关函数（例如strcpy, memcmp和strstr）进行比较。最近，基于LLM的系统（例如LARA [171], SLFHunter [156]和LATTE [79]）使用GPT-4 [101]等模型来解释反汇编或注释，并提出候选的源/汇；例如，LARA将前端URI映射到后端处理器以减少对纯关键词匹配的依赖。这些方法可以扩展到大型代码库，但对训练多样性和二进制文件中的语义歧义仍然敏感。附录A.5中的表S5提供了代表性识别策略在性能和实用性方面的定性比较。由于引用的研究使用不同的数据集、真实情况定义、评估单元和实验设置，高级/中级/低级标签表示相对趋势，而不是来自统一阈值的汇总指标值或类别。我们根据真正例率（TPR）、假正例率（FPR）和假负例率（FNR）[30, 49, 50, 79, 103, 106, 151, 171]来描述检测行为，其中\(\mathrm{TPR}=\frac{TP}{TP+FN}\)，\(\mathrm{FNR}=1-\mathrm{TPR}\)，\(\mathrm{FPR}=\frac{FP}{FP+TN}\)。“成本”包括人工努力（例如，策划和规则维护）和计算资源（例如，分析运行时间和模型推理/API使用）。手动规范由于规则保守而往往能实现较低的FPR，但受到覆盖范围限制和更新开销的影响[49]。基于相似性的方法通过检索扩大了覆盖范围，但容易受到重构和跨架构差异的影响[45, 48]。启发式方法保持了低成本，但在复杂的控制流或框架抽象下可能会增加FNR[25, 30, 114]。AI驱动的方法可以通过填补语义空白来降低FNR，但需要强大的下游验证来控制FPR和管理计算成本[79, 171]。6.2.3 流分析。静态ESTA中的流分析重建并分析固件结构，以近似从源到汇的污染传播。它通常结合了CG、CFG和DFG分析：CG捕获程序间调用关系，CFG模拟指令级控制转移，DFG跟踪定义-使用依赖关系。这些表示有助于候选污染路径的推理，但受到混淆、间接控制转移和嵌入式固件中运行时动态的影响。混淆和图重建。固件会删除符号或引入不透明的谓词，使CG/CFG的恢复变得复杂。angr [125]和Ghidra [8]通过启发式和模式匹配来缓解这个问题，以推断边界并恢复调用。angr进一步使用迭代分析（结合强制执行和符号执行）来细化CFG，以解决间接控制流。尽管如此，激进的转换（例如，控制流扁平化）仍可能降低重建质量，这促使了高级去混淆和学习驱动的恢复（例如，Calle [179]）。间接跳转和动态控制流。间接转移（例如，虚拟调用和动态调度）非常普遍，必须解决以避免遗漏污染路径。常见策略包括（i）符号执行，其中angr [125]使用Z3 [34]解决可行的目标；DTaint [29]结合符号推理和定义-使用链来解决由指针驱动的目标；（ii）切片和需求驱动的别名分析，例如FlowDroid [11]使用向后切片来近似组件间链接，而EMTaint [30]集成正向/反向分析和定义-使用链来按需恢复别名；以及（iii）学习辅助的恢复，其中Calle [179]使用对比学习重建CFG，而LATTE [79]使用LLM来协助反汇编中的别名识别。运行时动态和上下文敏感性。嵌入式固件涉及组件间通信、动态分配和状态交互，这需要超越单一二进制视图的营养建模。KARONTE [114]使用二进制依赖图来建模IPC（例如，文件和套接字），以跟踪攻击者控制的数据在组件之间的传递。SaTC [25]引入了跨进程入口查找（CPEF），后来CINDY [160]和HermeScan [49]将其扩展到NVRAM/环境变量通道；ChkUp [150]进一步针对固件更新流。在Android/IoT生态系统中，IoTFlow [118]使用值集分析来通过Intents重建应用程序间通信，而BLESCOPE [181]在协议状态转换期间跟踪污染（例如，BLE），尽管状态建模仍然成本高昂。外围语义也是一个瓶颈；HALucinator [32]通过硬件抽象提高了可移植性，但仍需要手动配置。总体而言，ESTA中的静态流分析必须在精确性和可扩展性之间取得平衡：符号推理和学习可以提高准确性，但面临路径爆炸和数据/覆盖范围的限制。6.2.4 可达性分析和约束解决。通过流分析构建CFG和DFG之后，下一步是可达性分析和约束解决，以确定是否存在从已标识的源到汇的可行污染传播路径。这些过程对于区分真实漏洞和假阳性至关重要，但由于嵌入式系统中有限的运行时可见性和复杂的逻辑，它们面临计算和语义挑战。可达性分析。在这项调查中，我们使用可达性来指代在控制流和数据依赖性约束下的源到汇的句法、路径无关的可达性：如果（i）它可以从CFG中的源达到，并且（ii）在DFG中存在相应的定义-使用/污染依赖链（或通过切片）可以从源将污染传递到汇，则认为汇是可达的。这种公式没有解决分支条件或计算具体输入，因此不保证可行性。可达性分析通过遍历CFG/DFG依赖关系提供轻量级的筛查信号，而不解决分支条件或具体输入[80, 113, 127]。例如，Firmalice [124]通过检查不受信任的输入是否可以到达特权敏感的汇而检测认证绕过候选者，而不通过验证节点。然而，当报告的路径在语义上不可行时，它的路径无关性可能会导致高FPR。SAINT [22]和Zheng等人 [172]通过基于切片的细化来缓解这一点，尽管在不完整的上下文中仍然存在歧义。符号执行。符号执行通过符号化表示输入并使用SMT求解器（例如Z3 [34]）解决路径条件来引入路径敏感性。angr [125]被用于各种固件分析[25, 30, 49, 137]；Arbiter [137]采用欠约束的符号执行（UCSE）来深入探索，而KARONTE [114]使用符号执行来模拟多二进制IPC行为。限制是路径爆炸和重复的约束解决开销。值集分析。VSA应用抽象解释来计算保守的值范围，并支持在没有完整路径枚举的情况下进行语义化的传播。BLESCOPE [181]使用VSA来推断有效的BLE UUID值，而IoTFlow [118]应用VSA来模拟组件间意图数据。与纯可达性相比，VSA通常可以降低FPR，但在大型、指针密集型和高度动态的代码上可能会变得保守或成本高昂。大型语言模型。最近的工作探索了LLM（例如，GPT-4）作为片段级语义消歧和验证的助手。LATTE [79]使用LLM来检查反汇编并推理沿着污染路径的缺失检查，而SLFHunter [156]将函数语义与漏洞模式进行匹配以识别命令注入候选者。尽管结果很有前途，但LLM辅助的验证仍然容易受到低级语义覆盖和可重复性问题的影响。附录A.6中的表S6提供了用于验证污染类型发现的约束解决家族的定性比较，考虑了（i）路径敏感性，（ii）明确的可行性推理，以及（iii）时间成本[77, 79, 167, 171]。这些属性在实践中主要决定了精度-可扩展性之间的权衡，其中可行性检查可能是一个主要瓶颈，而轻量级数据流筛查对于大规模分析仍然很有吸引力[20, 49, 50]。总之，可达性提供快速但粗略的验证；VSA增加了可行性推理，但可能无法在大型二进制文件上扩展[12, 68]；符号执行提供明确的可行性检查，但由于路径爆炸而成本例如，HEAPSTER [53] 应用 BMC 分析单体固件中的动态内存分配器。BMC 系统地探索所有执行（或可达状态），直到用户指定的限制（例如，有限的步骤数或循环展开次数）。如果在限制范围内找到反例，它就能够确定存在与内存相关的漏洞，如“使用后释放”（use-after-free）。如果没有找到反例，BMC 仅确认在探索的范围内不存在此类漏洞，而不是证明在无限制系统中它们全局不存在。要确定全局不存在通常需要额外的保证，即所选的限制足够全面，能够覆盖被分析系统的所有相关行为。基于模拟器/真实设备的动态验证在第 6.3.6 节中有详细描述。

6.3.6 动态分析在 ESTA 中的漏洞检测
通过动态分析进行漏洞检测涉及执行程序以观察运行时行为、追踪数据流，并实时触发漏洞。这种方法通过提供脆弱/可利用路径的具体证据来补充静态分析。工作流程通常包括入口点识别（C7）、仪器化（C5）、执行/模拟（C6）、动态数据跟踪（DTA，C7）、测试用例生成（TAF，C7）和崩溃/异常检测（C8），如图 5 所示。与静态分析不同，动态方法通过观察实际数据传播和系统响应来提供较低的误报率（FPR），尽管它们严重依赖于模拟器的保真度和输入生成质量。

分析过程通常从识别目标固件或二进制文件中的适当入口点开始。一旦找到入口点，就应用仪器化来插入监控钩子或分析逻辑。一旦执行了被仪器化的代码，就可以应用两种方法：DTA 和 TAF。DTA 跟踪数据流以检测从源到汇的潜在污染流，而 TAF 则涉及输入随机/异常输入以触发漏洞。然后使用崩溃/异常检测来识别导致异常行为或系统故障的任何漏洞。

表 6 总结了当前最先进的动态漏洞检测方法。Instr 表示使用的仪器化方法，Execution 代表使用的模拟器，Entry points 表示测试用例的输入接口，Monitoring 描述收集的监控信息类型，Category 表示研究的类别。我们接下来将详细讨论它们。

表 6
| 名称 | Instr | Execution | Entry points | Monitoring | Category |
|------|--------------|--------------|-------------|-------------------|
| FlexCore [35] | HIFT | Device | Startup component | Flow of sensitive data | DTA |
| TaintEraser [175] | DBI | Device | Files, network | Crash, flow of sensitive data | DTA |
| Hwang et al. [61] | NID | Device | Files, network | Crash |
| GSDCF [170] | DBI | DynamoRIO | Startup component | Code coverage, crash | DTA |
| ScrubDroid [117] | BIART | Startup component | Crash, flow of sensitive data | DTA |
| HYBit [176] | DBI | Device | Startup component | BB coverage, crash | DTA |
| AppCaulk [119] | BIART | Startup component | Crash, flow of sensitive data | DTA |
| DYBS [177] | DBI | DynamoRIO | System library API | Crash |
| Kastner et al. [58] | HIFT | Device | Peripheral, network | Flow of sensitive data | DTA |
| TaintPipe [90] | DBI | Device | Startup component | Crash |
| STRAIGHTTAINT [89] | DBI | Device | Startup component | Crash |
| TaintART [131] | BIART | Startup component | Flow of sensitive data | DTA |
| IFTU [123] | HIFT | Device | Flow of sensitive data | DTA |
| ARMHEx [138] | HIFT | Device | Flow of sensitive data | DTA |
| ContexIoT [64] | SCI | Device | Logs, crash | DTA |
| VUzzer [111] | DBI | Device | Startup component | Logs, crash |
| GIoTFuzzer [24] | NID | Device | Companion App | Response | BProv |
| Things [142] | SCI | Device | Startup component | Logs, crash |
| Angora [26] | DBI | Device | BB coverage, crash | DTA |
| GNDroid [155] | DBIQEMU | Startup component | Flow of sensitive data | DTA |
| FirmFuzz [129] | DBIQEMU | Network | Crash, emulator logs | GNeut |
| TaintMan [162] | BIART | Startup component | Flow of privacy-sensitive data | DTA |
| Mousse [81] | DBIQEMU | Startup component | Crash |
| WAFLPro [63] | DBIQEMU | Startup component | Branch coverage, crash | DTA |
| Diane [112] | NID | Device | Companion app | Response | BAafer |
| GShrivastava et al. [126] | DBI | Device | Startup component | Crash |
| GSHADOWFUZZER [153] | NID | Device | Network Response | \(\mu\)Dep |
| UCRF [109] | NID | Device | Network Response | B |
| RSFUZZER [158] | DBIQEMU | Peripheral | Branch coverage, crash | GJemin |
| GFFXE [136] | DBI | Unicorn | Peripheral | Crash |
| WSHFuzz [75] | SBRQEMU | Network Service handler | Coverage |
| GFFXE [136] | DBI | Unicorn | Peripheral | Crash |
| WFIAL [85] | NID | Device | Companion App | Response | B |
| Technique Matrix for Dynamic ESTA | | | | |

6.3.1 入口点识别
在动态漏洞检测中，入口点是测试用例到达目标固件/应用程序的接口。它们决定了不受信任的数据进入系统的位置，从而直接指导污染跟踪和模糊测试。
对于物联网（IoT）设备和工业控制器来说，网络接口是最常见的入口点。IoTSCOPE [152] 静态地枚举固件中的隐藏网络端点（例如，CGI/PHP/JSP），以揭露未记录的 Web 接口。UCRF [109] 和 SHFuzz [75] 进一步利用面向网络的服务来模糊测试路由器/交换机（例如，HTTP 和 Modbus）。这样的入口点支持黑箱测试 [24]，但本质上仅限于外部可访问的服务，遗漏了非联网或内部组件。
伴随应用程序为通过蓝牙、Wi-Fi 或 Zigbee 通信的设备提供入口点。IoTFuzzer [24] 和 DIANE [112] 分析应用程序以推断协议和有效的消息格式；例如，IoTFuzzer 追踪从用户界面输入到传输功能的流程，以生成真实的模糊测试输入。当设备端接口较少时，这种策略是有效的，但取决于应用程序的可用性和拦截加密或混淆通信的能力 [112]。
外围接口（例如，UART、I2C、GPIO 和 SPI）对于深度嵌入的目标至关重要，特别是对于没有网络暴露的纯硬件固件。Avatar2 [95] 推断外围接口模型以支持硬件在系统（HIL）执行，从而实现超出纯软件重新托管的动态测试。然而，由外围驱动的入口点通常需要物理访问和对专有协议（通常是未记录的）的了解。
启动组件代表在启动或初始化期间自动触发的内部入口点，包括 main() [111]、固件处理器（如 _start 和 Reset_Handler），以及事件/生命周期回调（例如，在 SmartThings [64, 142] 中的 installed() 和相关生命周期方法 [162]）。虽然无法通过外部输入直接到达，但它们对于分析默认状态、持久机制和早期行为非常重要，通常通过静态或混合分析进行检验。
调试接口主要是辅助性的，而不是直接的入口点。像 Avatar2 [95] 这样的框架使用 JTAG 来桥接模拟器和真实设备，通过转发外围 I/O 来提高复杂目标的保真度。同样，调试访问可以在测试期间暴露 CPU 和内存状态 [71, 96]，但它需要专门的硬件，并且通常在商业产品中被禁用。

6.3.2 仪器化
仪器化将监控逻辑插入固件/二进制文件中，以捕获执行跟踪或追踪运行时数据流，是动态数据跟踪（DTA）和基于覆盖率的模糊测试（coverage-guided fuzzing）的关键实现手段。由于嵌入式目标通常是闭源的，ESTA 仪器化通常在二进制或运行时级别操作，以牺牲精度来换取便携性和可部署性。
源代码仪器化（SCI）在源代码可用时在编译时插入监控钩子。它对仪器化点（例如，函数入口、循环和安全关键检查）提供细粒度的控制，在实践中通常相对轻量。ContexIoT [64] 和 ProvThings [142] 使用 SCI 以最小侵入的方式收集设备数据和控制消息的来源。虽然 SCI（以及更广泛的，源级别污染/信息流分析）在嵌入式软件开发工作流中可能很重要，但在这里调查的 ESTA 文献中出现的频率较低，因为许多代表性研究针对部署后或第三方评估的闭源商业固件，其中源代码通常不可用。这一实际限制使大多数动态 ESTA 流程倾向于二进制级别重写/仪器化或基于运行时的技术。
字节码仪器化（BI）将监控插入字节码（例如,.class/.dex）而不需要访问源代码。TaintART [131] 和 TaintMan [162] 修改 Dalvik/ART 字节码以跟踪跨 Android 应用程序组件的污染流。BI 对基于 Android 的 IoT 设备有效，但仅限于托管运行时平台，并且需要字节码级别的知识。
静态二进制重写（SBR）在执行前修改本地二进制文件以插入仪器化桩（stub）[37]。SHFuzz [75] 重写固件二进制文件以仪器化服务处理器和敏感 API（例如，memcpy），并引导模糊测试朝着与安全相关的行为进行。SBR 可以实现精确的位置，但如果没有仔细的二进制工程可能会出错并导致不稳定 [37]。
动态二进制仪器化（DBI）在运行时通过 JIT/trampolines 仪器化二进制文件而不重写原始文件。PIN [82] 和 DynamoRIO [18] 是用于 DBI 的框架：QSYM [164] 通过 PIN 收集覆盖率，AFL-Dyninst [14, 51] 仪器化目标以指导模糊测试；NDroid [155] 仪器化 JNI 边界（例如，JNI 入口/出口）以跟踪跨语言的流程。DBI 对闭源固件灵活，但在资源受限的设备上可能会产生相当大的开销。
硬件辅助信息流跟踪（HIFT）通过硬件支持传播标签来减少对软件仪器的依赖。硬件 IFT 调查 [57] 总结了两种部署形式：(i) 与 SoC 紧密耦合的片上监视器用于运行时标签传播，以及 (ii) 通过系统总线/互连连接的离核/外部模块。代表性设计包括 FlexCore [35]、GLIFT [135]、ARMHEx [138] 和 IFTU [123]，而 Kastner 等人 [58] 在跨外围设备和网络接口的设备上展示了硬件污染跟踪。
仪器化还支持模糊测试反馈和跨层跟踪。TaintPipe [90] 在真实设备上应用 DBI 风格的跟踪，NDroid [155] 结合基于 QEMU 的仪器化来跟踪 Java 和 C 层之间的流程。AFL++ [47] 和 Angora [26] 利用仪器化来实现覆盖率和指导；例如，Angora 仪器化 cmp 指令以推断与约束相关的字节并提高变异效率。总体而言，报告的开销差异很大：基于 DBI/仿真的污染跟踪可能会导致多倍的减速，而在托管运行时/字节码仪器化通常更轻量，除非虚拟化占主导（例如，NDroid [155]）。源级别仪器化通常报告为相对轻量（例如，ProvThings [142]），尽管一些系统报告的是延迟中心指标而不是减速（例如，ContexIoT [64]）。静态二进制重写在许多控制传输或内存操作被重写时可能会产生较高的开销；例如，E9Patch [37] 报告跳跃写和堆写仪器化的开销大幅增加，表明成本随重写指令的比例而增加。硬件辅助信息流跟踪（HIFT）可以在报告的设置中减少软件端的减速，但通常会将成本转移到额外的硬件资源和监控器-CPU 通信上。

6.3.3 执行
在动态 ESTA 中，执行在受控环境中运行固件或应用程序，以观察运行时行为，用于污染跟踪、模糊测试和漏洞验证。实际上，ESTA 主要依赖仿真来实现可扩展性和安全性，而在需要外围设备保真度时使用硬件辅助执行。
基于仿真的执行是设备不可用或操作风险较高的默认选择，因为它允许在不同架构之间进行可重复的测试。
- 系统模式仿真。QEMU [13] 支持跨架构（例如，ARM/MIPS/x86）的全系统执行，并在固件测试流程中被广泛采用；例如，FirmFuzz [129] 仿真网络服务并收集 IoT 固件的崩溃日志以进行分析。然而，系统模式仿真通常受到不完整外围模型的限制，导致重新托管的差距 [149]。衍生引擎如 Unicorn [110] 和 Qiling [108] 提供灵活的分析钩子，并已被用于 ESTA 研究 [136, 158] 作为执行后端。Simics [86] 为多种指令集架构（ISA）提供更高保真度的全系统仿真，并在安全关键环境中使用，尽管计算成本较高。
- 用户模式仿真。用户模式重新托管在不进行完整操作系统仿真的情况下执行目标用户空间服务，提高了以服务为中心的测试的吞吐量；Greenhouse [134] 为此模式在基于 Linux 的固件二进制文件中进行了演示。对于基于 Android 的嵌入式系统，JVM/Dalvik/ART 在独立的运行时中执行字节码 [66]。ART 的预先编译在受限设备上提高了性能 [130]，TaintART 仪器化 ART 以支持运行时污染传播跟踪 [130, 131]。
- 混合模式仿真。混合执行结合了系统模式兼容性和加速的用户空间执行。FIRMAFL [173] 以本地方式执行用户空间代码，同时将内核和外围交互委托给系统模式仿真，但需要仔细同步内存和系统调用语义以避免不一致 [174]。
当漏洞依赖于设备特定的外围设备或仿真无法忠实再现的定时行为时，就需要硬件辅助执行。Avatar2 [95] 和 SURROGATES [71] 通过在前置模拟器和物理设备之间转发外围 I/O 来启用 HIL 测试。真实设备验证对于安全关键系统特别相关，但它增加了成本和操作复杂性，并可能受到商业产品访问限制的约束。

6.3.4 动态污染分析和 TA 辅助的模糊测试
DTA 和 TAF 是动态 ESTA 的核心技术，能够实时跟踪不受信任的数据传播并智能生成测试用例。DTA 将外部输入标记为“受污染”的，并监控它们在系统中的流动，而 TAF 利用污染信息来指导模糊测试，提高嵌入式系统中漏洞发现的效率。
动态污染分析：DTA [42, 122, 130, 131, 155, 162] 在程序入口点将输入数据（例如，网络数据包和传感器读数）标记为污染源，并追踪它们在内存、寄存器和函数调用中的传播。为了在运行时实现污染传播，DTA 依赖于维护和更新污染标签的仪器化后端，包括 DBI、字节码/虚拟机级别修改和 HIFT [123, 138]。例如，TaintDroid [42] 修改 Dalvik 虚拟机以跟踪 Android 应用程序中的数据流，而 NDroid [155] 仪器化 QEMU 以跟踪跨 JNI 边界的污染。相比之下，HIFT 风格的设计利用硬件支持传播标签，通常实现为 (i) 利用架构支持的片上跟踪器（例如，片上跟踪特性）进行运行时跟踪，或 (ii) 通过系统互连连接到主机处理器的离核/总线附加的跟踪单元 [58, 123, 138]。这些硬件基板可以减少对纯软件工具的依赖，将部分成本从纯粹的运行时减速转移到硬件资源和监控通信上，同时在外围设备和硬件依赖行为占主导时潜在地提高检测的准确性。总体而言，数据流分析（DTA）在检测细粒度的数据流违规（例如，未经验证的输入以攻击者控制的长度到达memcpy）方面是有效的，但其实际准确性和成本仍与所选择的工具基板相关，尤其是在存在硬件依赖外围设备的情况下。TAF将TA与模糊测试（fuzzing）集成，以生成有针对性的测试输入，超越随机变异，优先考虑通过易受污染路径传播的输入。这对于嵌入式系统尤为重要，因为专有协议和状态依赖的交互需要上下文感知的输入生成。TAF根据系统可见性的级别进行分类：

**TA辅助的黑盒模糊测试（TA-assisted black-box fuzzing）：** 在执行过程中，目标设备仍被视为黑盒，同时利用固件工件或更常见的伴随应用程序的程序分析信号来提取有用的测试生成指导。提取的知识可能包括触发接口、协议相关字段和变异点，然后用于构建符合协议或交互一致的测试种子，而无需依赖设备的内部反馈。例如，UCRF [109] 分析路由器固件以识别请求入口点（例如，操作处理程序），并推导出输入约束来合成格式良好的测试种子。IoTFuzzer [24] 在伴随应用程序上使用污染跟踪来识别协议字段，然后挂接相应的运行时参数以生成探测消息，而崩溃分类则依赖于设备端的响应监控。DIANE [112] 结合对伴随应用程序的静态和动态分析来定位模糊测试触发点，并生成能够绕过应用程序限制但仍被设备接受的输入。尽管这种黑盒设置对设备端来说是非侵入性的，但它通常对设备内部状态的可见性有限；因此，它可能难以处理状态依赖的协议和深度状态转换，并可能错过那些触发条件依赖于内部状态变化的漏洞。

**TA辅助的灰盒模糊测试（TA-assisted grey-box fuzzing）：** 灰盒TAF结合动态污染跟踪和覆盖度反馈来探索更深的代码路径 [178]。VUzzer [111] 对cmp和lea指令进行仪器化处理，以识别输入验证点，通过修改影响这些检查的特定字节来绕过约束。Angora [26] 使用字节级TA来定位谓词（例如，if (x == 0x41)），并优先考虑满足这些条件的输入，从而提高二进制固化件的代码覆盖率。SHFuzz [75] 采用服务处理程序感知的方法，使用静态TA来识别敏感的API调用，并动态地对触发这些处理程序的输入进行模糊测试，有效地针对嵌入式设备中的内存损坏漏洞。

**TA辅助的白盒模糊测试（TA-assisted white-box fuzzing）：** 白盒TA利用程序分析（例如，符号执行和协同测试）来解决由TA得出的路径约束。Mousse [81] 结合具体执行和符号变量来探索数据依赖性，例如固件中的指针算术。通过通过符号状态跟踪污染，这些工具生成同时满足控制流和数据流约束的输入，揭示在很少执行的代码路径中的深层漏洞，如堆栈溢出。然而，由于需要穷举路径探索，白盒方法面临计算开销，这限制了它们在大型固化件图像上的可扩展性。

DTA和TAF代表了嵌入式系统安全领域中精确性与可扩展性之间的实际平衡。随着设备变得更加互连和复杂，将它们与先进的输入生成和机器学习集成在一起对于发现新兴的污染风格漏洞至关重要。

**6.3.5 崩溃/异常检测（Crash/Exception Detection）**
崩溃/异常检测是动态ESTA中的一个步骤，提供了DTA或污染辅助模糊测试已经触发漏洞的证据。与桌面系统相比，嵌入式目标可能缺乏崩溃信号（例如，MMU强制的分段故障），因此检测器必须同时覆盖崩溃和无声故障，如挂起或数据损坏。

**内存清理器和红区技术（Memory sanitizers and redzone techniques）**
像ASAN [120] 和KASAN这样的清理器通过在内存对象周围放置红区来检测内存损坏（例如，缓冲区溢出和越界使用）。RSFUZZER [158] 将红区监控应用于UEFI固件，而CHARM [132] 使用KASAN来检测Android内核错误。这些方法很有效，但通常需要编译器支持或模拟器工具，这限制了它们在闭源固件上的使用。

**模糊测试中的信号处理（Signal handling in fuzzing）**
基于覆盖度的模糊测试器，如AFL++ [47]，通过进程终止信号（例如，SIGSEGV和SIGABRT）来检测崩溃，并保留触发输入。这种机制在针对物联网设备的网络导向模糊测试中得到广泛使用 [75, 178]，其中格式错误的的数据包可能导致缓冲区溢出或空指针解引用。然而，裸机固件或最小操作系统环境可能不会显示此类信号，从而增加了表现为挂起或非崩溃损坏的漏洞的假阴性率。

**针对网络设备的基于响应的检测（Response-based detection for networked devices）**
对于暴露于网络的固件，异常检测可以基于协议响应和会话行为。IoTFSCOPE [152] 和UCRF [109] 通过发送格式错误请求后监控异常的HTTP响应（例如，意外错误代码）来验证漏洞。对于状态依赖的协议（例如，FTP或Modbus），检测故障可能需要跟踪异常的会话终止或无效的协议级响应 [104]。

**日志分析和心跳机制（Log analysis and heartbeat mechanisms）**
当明确的语言崩溃信号不可用时，日志和活动检查提供了实用的替代方案。FirmFuzz [129] 监控模拟器日志中的运行时错误信息，而Aafer等人 [7] 从真实的Android智能电视中挖掘系统日志以定位验证失败。基于心跳的监控通过随时间测量响应性来进一步检测重启或挂起；Muench等人 [96] 将结果分类为可观察到的崩溃、重启、挂起、延迟崩溃、故障和无效果，以改进模糊测试的反馈。

**总体而言，动态ESTA中的强大崩溃/异常检测必须结合多种信号来捕捉明显的故障和微妙的异常，特别是在嵌入式系统多样化并在安全关键和安全关键环境中运行的情况下。**

**7 未来工作（Future Work）**
为了使未来的研究方向能够追溯到调查结果，我们总结了四个反复出现的差距：**

- **（G1）可扩展的、基于证据的探索（Scalable, evidence-driven exploration）：** 在资源受限的情况下，动态ESTA面临着持续的覆盖度与成本之间的张力。
- **（G2）协议感知和状态感知的建模（Protocol-aware and state-aware modeling）：** 许多漏洞依赖于序列，但交互通常被视为无状态的。
- **（G3）大语言模型辅助的ESTA的信任和验证（Trust and verification for LLM-assisted ESTA）：** LLM的输出必须基于可检查的证据和可复制的流程。
- **（G4）执行准确性和外围设备真实性（Execution fidelity and peripheral realism）：** 模拟器的准确性和外围设备/SoC的真实性仍然是常见的瓶颈。这些差距激发了第7.1至7.4节（按顺序为G1-G4）的内容。

**7.1 有向ESTA（Directed ESTA）**
有向模糊测试在桌面软件上已经证明有效 [16, 76, 83]，但在嵌入式环境中的采用仍然有限（例如，SHFuzz [75]）。有向ESTA旨在将TA与目标导向的探索结合起来，在严格的执行预算下 reach 敏感区域（例如，认证逻辑和更新处理程序）。一个实际的方向是使用静态依赖性和污染可达性来定义目标，并计算轻量级的“距离”信号来指导模糊测试或协同执行。主要挑战包括在不完整代码恢复的情况下定义稳健的距离启发式方法，以及在可见性和反馈受限时保持可扩展性。

**7.2 状态依赖协议的污染分析（Stateful Protocol Taint Analysis）**
许多嵌入式目标依赖于状态依赖的协议（例如，FTP、Modbus和BLE），其中消息顺序决定了权限和语义。将这些交互视为无状态的可能会错过只有在特定状态转换后才会出现的流量（例如，认证门或初始化阶段）。虽然AFLNet [104] 和StateAFL [98] 研究了状态感知的模糊测试/建模，但它们与TA的集成仍然有限。一个有前景的方向是将DTA与推断的有限状态机（FSM）结合起来，在传播和验证过程中强制执行状态约束；形式化检查（例如，模型检查）可能进一步帮助确保受污染的输入无法通过非法或意外的转换到达安全敏感的状态。

**7.3 用于ESTA的大语言模型（LLMs for ESTA）**
大语言模型（例如，GPT-4）可以帮助代码理解和总结以进行安全分析 [141]，早期的ESTA系统探索了LLM对源/汇点识别的支持 [79, 156, 171]。然而，在安全关键的环境中，LLM的输出应被视为假设而不是证据：只有当它们得到独立可检查的工件和可复制的验证的支持时才具有可操作性。因此，一个保守且实际的方向是将LLM的辅助限制在生成可审计的中间工件上，并要求基于工具的验证：
- **二进制分析提示（Binary analysis hints）：** 提出候选边界或CFG修复，由反汇编启发式和可用的执行跟踪进行验证。
- **约束辅助（Constraint assistance）：** 建议或简化候选路径条件，然后使用SMT求解器和回放确认满足性和一致性。
- **补丁候选（Patch candidates）：** 提出最小的验证/清理编辑，通过重新运行分析和回归测试来确认风险降低。

**7.4 嵌入式系统的智能仿真（Intelligent Emulation for Embedded Systems）**
仿真对于动态ESTA仍然至关重要，但当前的框架 [32, 65, 67, 134] 经常需要大量的手动工作来进行外围设备建模和性能调优。智能仿真旨在通过自动化抽象和推理来减少人为干预并提高准确性：
- **自动外围设备建模（Automatic peripheral modeling）：** 如P2IM [44] 和VeRa [139] 等技术推断外围设备的行为，但扩展到多样化的设备仍然是一个挑战。
- **跨架构的鲁棒性（Cross-architecture robustness）：** 基于传输或合成的方法可以减少每个ISA的工程开销，并提高对新兴架构的移植性。

**在这些方向上的进展将加强动态ESTA结果在异构嵌入式系统中的有效性和可移植性。**

**8 结论（Conclusions）**
嵌入式系统是现代关键基础设施的基础，但它们仍然容易受到由跨异构软件-硬件边界的意外数据传播引起的污染风格漏洞的影响。本调查总结了ESTA的现状，并弥合了传统污染分析（TA）与嵌入式特定约束（如有限的可见性、外围设备依赖和协议依赖的行为以及执行基底的准确性）之间的差距。我们将88项主要研究（2010年至2025年初）系统化为静态和动态ESTA的统一分类，并将动态方法分解为常见的工作流阶段（入口点、仪器化、执行/仿真、监控和漏洞预言）。我们的综合突出了向结合静态推理和动态验证的混合流程的明显转变，同时也揭示了可扩展性、状态依赖交互、辅助分析的可靠性以及模拟器/外围设备真实性的反复出现的瓶颈。这些观察结果为第7节中讨论的未来方向提供了基础。总体而言，这项调查提供了ESTA设计空间的结构化映射，旨在提高可比较性和可复现性，并指导为实际中的嵌入式系统开发更有效和可防御的TA流程。