[论文学习]百分之一的Token，百分之百的策略：LLM辅助的IoT与嵌入式固件漏洞挖掘

One Percent of the Tokens, All of the Strategy: LLM-Assisted Vulnerability Discovery in IoT and Embedded Firmware论文重点这篇论文直击一个尴尬的现实把二十台IoT设备交给大模型让它“找出RCE”换来的往往不是二十份漏洞报告而是满屏的误报、重复侦察和因上下文压缩而丢失的线索。研究者在107小时的自治运行中只确认了8个有效问题关键攻击链直到第33小时才被人为提醒组合出来。论文的核心结论并非字面上的“只需1% Token”而是揭示了一个更根本的命题容量正在商品化真正的瓶颈在于如何切分搜索空间、保存能力状态、提供可观测反馈以及选择适合机器验证的目标。核心研究内容问题定义当前LLM辅助漏洞挖掘面临一个结构性困境模型可以读反编译代码、写脚本、识别芯片、跑扫描器却难以在数十小时的长程任务中维持“全局视野”。第13个发现泄露了控制通道第37个发现提供了提权路径第148个发现补齐了远程发布能力——三者本可组成完整攻击链但模型无法主动将它们关联起来。这暴露了两个层面的问题一是搜索空间缺乏边界agent在每台设备上重复执行端口扫描、默认凭据测试、Web路由枚举等基础操作Token迅速被低价值工具输出耗尽二是缺乏有效的“能力状态保持”机制关键发现随上下文压缩而丢失。创新方法论文提炼出三条核心策略Scaling规模调度、Observability可观测性、Target Selection目标选择。规模调度的核心思想是把“在二十台设备中找到任意RCE”这样开放式的任务重构为“固定资产能力目标停止条件”的可执行单元。研究者对48,174条CWE分类问题做了粗粒度分层Tier 1是命令注入、硬编码凭据、缺失认证等直接产生能力的问题Tier 2是需要一两步利用工程的栈溢出、XSSTier 3是UAF、堆溢出、类型混淆等高工程量问题。2025年数据中64.4%的问题落在较低利用难度区域说明“容易验证的问题足够多”关键在于让verifier能够判定结果。可观测性强调agent需要输出“假设—证据—验证动作”的三元组而非直接给结论。在硬件识别场景中模型可以从PCB照片推断SoC、Flash、UART、JTAG等信息并提出探测顺序但视觉标注只是annotation不能混入事实字段。研究台账必须保留原始照片、测量值、固件hash和设备序列号。目标选择则是一个常被忽视但决定成败的维度选择适合机器验证的目标比选择“看起来难”的目标更有价值。研究成果实验覆盖NAS、路由器、OT网关和移动设备管理组件。Device A实验在约二十个目标启动初始结果多数无效研究者凭经验选中一台设备后107小时中记录8个问题其中1个高价值问题、3个中等价值问题。另一组实验在三天内产生了156条finding但经历了设备被跑坏和误报泛滥的困境。关键攻击链的组装直到第33小时才因人工提醒而完成——这个数据点恰恰说明了当前agent在长程关联推理上的根本性短板。实际落地应用的可能性论文的方法论具有较高的工程可操作性。三条策略——搜索空间切分、能力状态保持、可验证目标选择——不依赖于特定模型能力而是编排层面的设计原则。这意味着即使用户使用的是中等能力的模型只要编排得当也能获得可用的结果。论文建议的“研究台账”机制保留原始照片、测量值、固件hash直接可以嵌入现有的漏洞研究流程。不过需要明确的是所有流程仅适用于自有设备、厂商授权测试、漏洞奖励明确范围或隔离实验室环境不涉及真实设备凭据或可直接利用的payload。技术细节搜索空间的切分逻辑论文的Tier分层是一个研究调度启发式而非通用漏洞严重性标准。Tier 1问题的共同特征是验证成本低、利用路径短、能力产出直接。这使得agent可以在有限的Token预算内完成“假设生成→验证→记录”的闭环。对于Tier 2和Tier 3问题需要引入更复杂的验证器如符号执行引擎或fuzzer作为agent的“工具调用”而非让LLM直接推理。硬件识别的agent工作流PCB照片分析被定位为“假设生成器”而非“事实来源”。agent的输出格式应为{ hypothesis: SoC可能是MT7621UART位于J4测试点, evidence: 丝印显示MT7621AJ4有4个焊盘, verification_action: 用万用表测量J4各引脚对地电压确认TX/RX/GND/VCC }这种结构化输出确保了模型的不确定性被显式记录后续人工或自动化验证可以逐条处理。Token效率的实际含义论文标题的“1% Token”并非字面意义上的成本削减指标而是一个修辞性框架真正的策略价值不在于省了多少Token而在于把Token花在了正确的地方。当搜索空间被合理切分、能力状态被有效保持时agent不必反复执行相同的侦察操作也不必在无关目标上浪费推理预算。研究设定硬件配置实验涉及约二十台真实IoT设备覆盖NAS、路由器、OT网关和移动设备管理组件。设备来源包括自有设备和授权测试环境。硬件提取环节涉及UART、SPI Flash和JTAG接口的物理访问使用逻辑分析仪和万用表进行信号验证。软件环境agent编排层需要具备工具调用能力反编译工具、扫描器、fuzzer、结构化输出解析、研究台账管理、以及跨会话的能力状态保持机制。论文未指定具体使用的LLM版本但提到“多代大模型”的对比使用。实验设计实验采用开放式自治运行与人工干预相结合的混合模式。Device A的107小时运行包含了初始侦察、目标选择、二进制逆向和漏洞记录四个阶段。三天156条finding的实验则暴露了无边界搜索的典型问题设备被跑坏、误报淹没有效信号。综合分析这篇工作的最大价值不在于它发现了什么具体漏洞而在于它诚实地记录了一次“失败”的实验并从中提炼出了可操作的方法论。在LLM安全应用被过度渲染的当下这种“从误报和无效运行中学习”的研究态度本身就值得关注。三条策略中目标选择最容易被低估。选择适合机器验证的目标本质上是在利用LLM的强项结构化推理、模式匹配而规避其弱项长程因果推理、不确定性管理。Tier 1问题之所以适合agent不是因为它们“简单”而是因为它们的验证信号是清晰的、可自动判定的。可观测性的深层含义是agent不仅需要产生发现还需要产生“关于发现的元信息”。一个没有记录hypothesis-evidence-verification三元组的finding对于后续的人工复核和自动化关联来说几乎没有价值。研究台账的概念借鉴了传统漏洞研究中的“研究日志”实践但在agent时代有了新的意义它是模型能力状态的外部化存储。规模调度则触及了一个更根本的问题LLM agent的“工作记忆”是有限的而漏洞挖掘本质上是长程任务。解决方案不是让模型记住更多而是让编排层负责状态管理——模型只负责在给定上下文下做出局部判断全局关联由外部机制完成。一个需要警惕的局限是论文的实验规模仍然较小二十台设备级别其方法论在大规模部署中的可扩展性尚未验证。此外论文未讨论多agent协作场景下的状态同步问题而这在实际生产环境中可能成为一个关键瓶颈。实践应用对于漏洞研究团队建议从Tier 1问题入手建立agent工作流。先在小规模目标集3-5台设备上验证“切分-验证-记录”的闭环确认误报率和有效发现率后再逐步扩展。研究台账的结构化格式应从第一天就确立避免事后补录。对于安全产品团队论文的“目标选择”原则可以直接映射到产品设计——不是所有漏洞类型都适合agent化优先覆盖验证信号清晰的类别。可观测性要求意味着产品需要内置“假设管理”界面让分析师能够追踪每条finding的证据链。对于研究者107小时发现8个问题的数据提示了一个重要方向agent的“疲劳”问题——长程运行后模型的有效推理能力是否衰减关键链在第33小时才被人工提醒组合说明agent可能在第20-30小时区间已经进入了“低效运行”状态。这是一个值得量化的研究问题。安全边界提醒论文中所有流程仅适用于自有设备、厂商授权测试、漏洞奖励明确范围或隔离实验室环境。不提供真实设备凭据、MQTT控制topic、命令执行报文或可直接利用的固件payload。参考资料原始论文https://www.blackhat.com/us-26/briefings/schedule/#one-percent-of-the-tokens-all-of-the-strategy-llm-assisted-vulnerability-discovery-in-iot-53075