文章总结： 文章介绍了mGPTFuzz，一个基于大语言模型与状态感知的Matter物联网设备自动化模糊测试框架。该框架通过利用GPT-4将1258页的Matter规范文档转化为机器可读的JSON数据，构建了有限状态机(FSM)来指导模糊测试。系统包含五个核心组件：MatterController、FunctionalityExtractor、GPT-4&KnowledgeBase、FuzzingMutator和DeviceStateMonitor。实验表明，该框架在23款真实设备上发现了147个新漏洞，其中142个为非崩溃型漏洞，证明了其相比传统工具的优越性。这项研究为物联网安全测试提供了新的思路，展示了AI辅助自动化测试在确保IoT生态安全方面的重要价值。
综合评分： 88
文章分类： IoT安全,漏洞分析,安全工具,AI安全,渗透测试
论文研读与思考 | mGPTFuzz—基于大语言模型与状态感知的Matter物联网设备自动化模糊测试框架
hkdmh
玄枢战队-Arcane Hub
2025年11月21日 19:10
陕西
原文标题：《From One Thousand Pages of Specification to Unveiling Hidden Bugs: Large Language Model Assisted Fuzzing of Matter IoT Devices》
原文作者：Xiaoyue Ma, Lannan Luo, and Qiang Zeng
第一节 研究背景与核心问题阐述
1.1 物联网互联互通的新时代：Matter协议的崛起
物联网（IoT）行业在过去十年中饱受碎片化的困扰。不同厂商（如Apple, Google, Amazon）、不同通信协议（WiFi, Zigbee, Bluetooth）之间存在着厚重的壁垒，导致智能家居生态处于割裂状态。为了打破这一僵局，连接标准联盟（Connectivity Standards Alliance, CSA）推出了 Matter协议。
Matter不仅仅是一个新的技术标准，它代表了行业的一次重大范式转移。它是一个开放的、免版税的连接标准，得到了包括苹果、谷歌、亚马逊、三星在内的超过200家全球科技巨头的共同背书 。自2022年10月发布以来，Matter迅速成为IoT领域的“通用语”。亚马逊已通过OTA更新使其1亿台Echo设备支持Matter ，谷歌更新了数十亿台Android和Nest设备 ，苹果也在iOS 16.1中全面集成了Matter支持。
Matter协议的架构设计非常复杂，它位于TCP/UDP和IPv6之上，是一个应用层协议，旨在统一底层的WiFi、Thread和Ethernet等不同链路技术。
Figure 1: Protocol stack with Matter.
如图所示，Matter处于最顶层（灰色部分），向下兼容TCP和UDP传输层，并基于IPv6网络层运行。在物理链路层，它同时支持WiFi、Thread和Ethernet，并通过BLE（低功耗蓝牙）进行设备的初始配对（Commissioning）。
这种分层架构虽然实现了极大的互操作性，但也引入了巨大的复杂性。应用层的逻辑错误（如智能锁的状态管理）被封装在多层网络协议之中，且Matter强制要求端到端加密。这意味着传统的网络层Fuzzer（如针对TCP/IP栈的测试工具）很难触及Matter的应用逻辑，因为它们无法解析加密后的应用层负载。这为安全测试提出了第一个难题：如何穿透网络层，直接测试应用层逻辑？
1.2 规范体量的爆炸与“认知过载”
为了实现跨厂商的互操作性，Matter必须对设备行为进行极度标准化的定义。这导致了Matter规范文档的体量极其庞大。Matter 1.0 核心规范与应用簇规范的总页数高达1258页 。对于任何单一的开发人员或测试人员来说，通读并完全理解这一千多页的技术文档，几乎是不可能的任务。这种“认知过载（Cognitive Overload）”直接导致了实现层面的疏漏。
Figure 2: A specification passage ignored by developers.
Figure 2展示了一个极具代表性的案例，生动地说明了“规范过载”带来的安全隐患。
图中截取了一段关于 Groups Cluster 的规范文本。文本中包含一个关键的“负面约束（Negative Constraint）”：“如果被移除的 GroupKey Set ID 为 0（这是与身份保护密钥 IPK 关联的 Key Set），则该命令（KeySet Remove）必须失败，并向发起者返回 INVALID_COMMAND 状态码” 。
这是一个至关重要的安全检查。ID为0的密钥集对应着IPK（Identity Protection Key），它是设备身份认证的基石。如果允许删除它，设备将失去通信能力。然而，由于这段文字淹没在浩瀚的文档海洋中，开发者在实现代码时集体忽视了这一细节。
这直接导致了后续发现的严重通用漏洞（CVE-2023-42189），攻击者可以轻易删除IPK导致设备拒绝服务。这一图表有力地证明了：依靠人工阅读规范来保证代码安全性是完全不可靠的，我们迫切需要一种自动化的手段来提取这些深藏的约束条件。
1.3 现有模糊测试技术的四大挑战
本研究在设计针对Matter设备的Fuzzer时，通过深入调研，识别出了现有技术面临的四大核心挑战（Challenges）。
挑战一：从海量非结构化文本到机器知识的转化 (C1: Sheer volume of specification)。如前所述，1258页的规范主要由自然语言（英语）编写。虽然人类可读，但机器无法直接理解。传统的基于规范的模糊测试（Specification-guided Fuzzing）通常需要专家手工编写测试模型（如SPIKE或Peach的模板）。但在Matter的体量面前，手工建模耗时耗力且极易出错。如何自动化地将这些“人类可读内容”转换为“机器可读信息（如状态机、数据类型定义）”，是首要难题 。
挑战二：深层状态相关性漏洞的挖掘 (C2: Stateful bugs)。物联网设备本质上是状态机。许多命令的有效性严格依赖于设备当前的状态。例如一个智能灯泡，只有在 OnOff 属性为 True（开灯）的状态下，MoveLevel（调节亮度）命令才有实际物理意义。
如果Fuzzer只是随机发送命令（例如在关灯状态下发调节亮度指令），设备可能仅仅是忽略该指令，而不会触发任何深层逻辑。真正的逻辑漏洞往往隐藏在特定的状态序列之后（例如：开灯 -> 调至最低亮度 -> 发送非法速率指令）。
现有的IoT黑盒Fuzzer（如IoTFuzzer , SNIPUZZ ）通常是“无状态”的，它们不维护设备的状态模型，因此难以发现这类深层漏洞。
挑战三：隐蔽的非崩溃型逻辑漏洞 (C3: Non-crash bugs)。在通用软件测试中，Fuzzer通常通过监测程序是否崩溃（Segmentation Fault）来发现漏洞。但在IoT领域，这是一个巨大的误区。
其原因大致有两点，一是硬件隔离，IoT设备通常运行在专有固件上，即使应用层逻辑出错（如状态机死锁），底层RTOS或网络栈可能依然存活，导致外部看起来设备仍然“在线”；二是逻辑错误，许多严重漏洞是逻辑性的。例如，攻击者成功绕过了权限检查，或者将设备设置为了一个规范不允许的非法状态（如将色温设置为负数）。这类错误不会导致崩溃，但在安全上是致命的。
在无法获取固件源码和植入探针的“黑盒”环境下，如何感知这些没有崩溃迹象的逻辑错误？这是本研究要解决的关键痛点。
挑战四：指令覆盖率的极度匮乏 (C4: Command coverage)。要进行全面的测试，Fuzzer必须知道设备支持哪些命令。
像IoTFuzzer通过逆向厂商的手机App来提取指令。但Matter设备旨在脱离特定App运行，且App通常经过加固混淆，逆向成本高且不完整。而像SNIPUZZ依赖厂商公开的测试脚本。但实际上，极少有厂商会公开完整的、包含隐藏调试命令的脚本。
如果Fuzzer不知道某个命令的存在，就不可能去测试它。这导致现有工具的测试覆盖率极低，留下了大量盲区。
第二节 系统架构设计与核心方法论
为了应对上述四大挑战，论文提出了一套全新的解决方案——mGPTFuzz。这是一个结合了大语言模型（LLM）智能与基于模型测试（Model-based Testing）严谨性的自动化框架。
2.1 系统架构：基于控制器的伪装策略
mGPTFuzz并未采用传统的中间人攻击或App模拟方式，而是另辟蹊径，利用Matter协议自身的特性构建了一个“伪装控制器”。 这一架构的设计极其精妙，主要包含五个核心组件。
Figure 3: Architecture of mGPTFuzz.
Matter Controller（核心组件）：是一个基于开源 chip-tool 修改而来的自定义控制器。研究者移除了其中的输入清洗（Sanitization）代码。在Matter协议中，设备（Device）会对控制器（Controller）进行身份认证，但通常不会校验控制器的逻辑行为是否合规。利用这一点，mGPTFuzz可以合法地与设备建立端到端的加密通信通道。这直接解决了加密通信的问题，使得Fuzzer可以发送明文指令，由控制器协议栈负责加密传输。
Functionality Extractor（功能提取器）：利用Matter的配对机制。当设备加入网络时，会广播“设置消息（Setting-Up Messages）”来声明自己的能力。提取器拦截这些消息，自动解析出设备支持的所有Cluster ID、Command ID和Attribute ID。这实现了对设备功能的全自动发现，直接解决了指令覆盖率的问题。
GPT-4 & Knowledge Base（大脑）：统将PDF格式的Matter规范转换为文本，通过Prompt发送给GPT-4。GPT-4提取出的结构化知识（FSM、数据类型）存储在知识库中。这是解决规范体量的关键。
Fuzzing Mutator（变异引擎）：它从知识库中读取FSM，根据预设的Fuzzing Policies生成测试用例，并通过控制器发送给设备 。
Device State Monitor（状态监视器）：它不仅监听网络连接（Crash检测），还主动查询设备状态（Read Attribute），通过对比“预期状态”与“实际状态”来发现逻辑漏洞。这是解决非崩溃漏洞的核心。
2.2 知识提取：LLM驱动的规范形式化
这是本研究最核心的技术突破。研究者利用GPT-4将非结构化的规范文档转化为机器可读的JSON数据。为了保证提取的准确性和稳定性，研究者采用了 Temperature=0 的设置 ，并设计了分层级的Prompt Engineering流程。
步骤一是基础数据类型提取 (Base Datatype Extraction)。Matter规范定义了大量自定义数据类型（如 map8, uint16）。这是理解后续复杂命令的基础。
Figure 4: Prompt for querying base datatypes.
Figure 4 展示了用于提取基础数据类型的Prompt。其中，Prompt明确给出了指令：“请基于以下提供的文本，列出所有数据类型及其取值范围，并以JSON格式返回”。输入为规范中关于“Base Datatypes”的章节文本。输出目标则是获取如 uint8: [0, 255], bool: [0, 1] 这样的基础映射表。这为后续FSM生成提供了原子构件。
步骤二为功能簇信息提取 (Cluster Information Extraction)。Matter的功能被组织为一个个“簇（Cluster）”，如开关簇（OnOff）、亮度簇（LevelControl）。
Figure 5: Prompt template for querying information of a clus ter.
Figure 5展示了查询Cluster信息的通用Prompt模板。模板包含占位符 [Cluster Text]，用于填入具体的规范章节。查询项则明确要求提取五类信息：. 派生数据类型；命令列表；属性列表；命令ID；属性ID。这种结构化的查询迫使LLM从自然语言中抽离出关键的元数据，为Fuzzer提供了测试目标的清单。
Figure 6: Model response for the OnOff cluster.
Figure 6展示了模型对 OnOff 簇的实际响应。如图，模型精准地输出了一个JSON对象。”Commands” 字段下列出了 Off, On, Toggle 等无参数命令，以及 OffWithEffect 这种带参数命令。而对于 OffWithEffect，模型进一步提取了其参数名 EffectIdentifier 和类型 uint8。这一结果证明了GPT-4在零样本或少样本条件下，能够极高精度地理解技术规范的语法结构。
Figure 7: Assembled prompt for querying the information of the Groups cluster.
Figure 7展示了一个完整的、组装后的Prompt实例。如图，它将 Groups Cluster 的具体规范文本（描述了Group Table, GroupID等概念）与查询指令完美融合。这个示例展示了系统在运行时是如何动态构造Prompt的。它不仅要求提取命令，还特别强调了提取“带有Enum和Struct后缀”的复杂数据类型，体现了针对Matter规范特性的优化。
步骤三为有限状态机 (FSM) 生成。这是实现状态感知测试的决胜一步。FSM描述了设备在不同状态下对命令的响应逻辑。
Figure 8: Prompt template for generating an FSM.
Figure 8展示了生成FSM的Prompt模板。这里运用了 思维链（Chain-of-Thought）技术。Prompt并没有直接要求“输出FSM”，而是引导LLM分步骤思考：先提取状态，从“Effect”章节中找出初始状态和目标状态；再提取条件，参考之前提取的数据类型知识，找出触发转移的参数条件；最后提取异常，找出规范中定义的无效参数值和错误消息（如 INVALID_COMMAND）。Prompt中包含了 Shot 1，提供了一个标准的FSM输出示例，规范了LLM的输出格式。
Figure 9: The generated FSM for the LevelControl cluster.
Figure 9展示了最终生成的 LevelControl 簇的FSM图。节点（状态）例如 CurrentLevel: 1, OnOff: False 代表“关灯且亮度最低”；边（转移）例如 StepWithOnOff 命令，附带了参数 StepMode 和 StepSize。该图清晰地展示了，当设备处于“关灯”状态时，接收到 StepWithOnOff 命令会转移到“开灯”状态，并根据 StepSize 改变亮度值。因此，这张图就是Fuzzer的“作战地图”。它告诉Fuzzer：要测试“开灯并调光”的逻辑，必须先构造一个“关灯”的前置状态。这种基于模型的路径规划，是随机Fuzzing无法比拟的。
2.3 模糊测试策略与状态监视机制
基于生成的FSM，mGPTFuzz执行四种变异策略，并配合状态监视器进行漏洞挖掘。
首先是变异策略 (Fuzzing Policies)针对FSM边上的参数，测试其边界值（如uint8的0和255）、范围内的随机值。对于字符串，发送超长字符以测试缓冲区溢出；对于数组，发送空数组或超大数组；之后进行类型混淆，修改参数的数据类型。例如，规范要求参数是整数，Fuzzer发送一个字符串。这用于测试设备固件的解析器是否健壮；下一步参数数量变异发送比规范要求更多或更少的参数，测试参数校验逻辑最后是尝试发送设备声明不支持的命令，或者通过LLM提取到的隐藏调试命令，检查设备的错误处理机制。
非崩溃漏洞检测逻辑是mGPTFuzz区别于传统工具的杀手锏。mGPTFuzz首先根据当前状态（State_A）和发送的命令（Cmd），查询FSM得到预期状态（State_Expected）和预期响应（Response_Expected，如SUCCESS或ERROR）。它会尝试Ping设备，看是否在线，并发送 Read Attribute 命令获取实际状态（State_Actual）。如果 State_Actual != State_Expected，判定为状态转换错误（Unexpected Transition）；如果发送了非法参数，预期响应是 INVALID_COMMAND，但设备返回了 SUCCESS，判定为N1类漏洞（应拒而收）；如果发送了合法参数，设备却返回了错误，判定为N2类漏洞（应收而拒）。
第三节 实验设计与数据分析
为了全面评估mGPTFuzz的有效性，研究团队构建了一个包含真实硬件的测试床，并选取了大量商用设备进行测试。
3.1 实验环境与设备矩阵
Figure 10:IoT devices used in our experiments.
Figure 10详细展示了被测设备的信息。其列出了23款设备的详细参数。涵盖了TP-Link (Kasa/Tapo), Eve, Google, Nanoleaf, Yale, Philips Hue, SwitchBot, Aqara等一线大厂。协议覆盖了 Matter over WiFi (如ID 1-3, 10), Matter over Thread (如ID 4, 6, 7, 14), Matter over Ethernet (如ID 16)。这种全协议覆盖证明了mGPTFuzz架构的通用性。类型包括插座、灯泡、灯带、传感器、门锁、网关等，覆盖了智能家居的主要品类。
Figure 10(b)展示了这23款设备的实物图。这强调了本研究是在真实物理设备上进行的（Real-world Experiment），而非仿真环境，因此发现的漏洞具有极高的真实危害性。
同时，为了测试Thread设备，研究者使用了一个 nRF52840 Dongle 配合 OpenThread Border Router (OTBR) 软件，将PC伪装成Thread边界路由器。这显示了系统对复杂网络环境的适配能力。
3.2 漏洞发现总体情况
mGPTFuzz在所有23款被测设备中均发现了漏洞，总计发现 147个新漏洞。
Table 1:Summary of bugs detected by mGPTFuzz.
Table 1汇总了每个设备的漏洞数据。Crash Bugs仅有5个，Non-crash Bugs高达142个。其中61个漏洞会导致DoS（拒绝服务）或严重功能故障。某些设备（如ID 10 Govee Light Strip）漏洞极其密集（4个Crash，12个Non-crash），说明某些厂商的Matter实现质量堪忧。总测试时间从1小时到4.6小时不等，平均效率极高。
3.3 崩溃漏洞 (Crash Bugs) 深度分析
虽然数量不多，但崩溃漏洞的危害极大，通常意味着内存破坏。
Table 2:Details of discovered crash bugs.
Table 2详细列出了5个Crash漏洞的触发条件。这里举例说明其中两种漏洞。
案例1：Nanoleaf Lightstrip (ID=4, CVE-2023-45955)。漏洞点为Binding 簇中的隐藏命令 Write_Attribute_Binding。触发该命令的参数是一个列表。Fuzzer根据Policy 1发送了一个包含非法嵌套元素 {“0”: {“0”:0}} 的列表。漏洞现象为设备闪烁后崩溃。这是典型的输入解析漏洞，固件未能正确处理畸形的JSON结构。
案例2：Govee Lighting (ID=10, CVE-2023-45956)。漏洞点是LevelControl 簇中的 Move_up 命令。这是一个教科书式的状态相关漏洞。只有当设备处于“最高亮度 (Level=254)”状态时，发送速率为0的 Move_up 命令才会导致Crash。若设备处于其他亮度，该攻击无效。推测在极值状态下，固件计算新亮度时发生了溢出或除零错误。这完美验证了FSM的价值——没有FSM指导，Fuzzer很难恰好在254亮度时发送特定参数。
3.4 非崩溃漏洞 (Non-crash Bugs) 深度分析
这是本研究的一大亮点，揭示了IoT安全的“冰山水下部分”。
Table 3:Summary of non-crashed bugs.
原文 Table 3 对非崩溃漏洞进行了分类。Type N1 (应拒而收)，设备接收了本该拒绝的非法指令。这类漏洞占比很高（如ID 13有9个），意味着安全检查的普遍缺失；Type N2 (应收而拒)，设备拒绝了合法的指令。这通常导致功能不可用。
Table 4:Some of the discovered non-crash bugs.
Table 4展示了具体的漏洞案例。通用漏洞 (CVE-2023-42189)于表格第一行显示，所有设备（All）都受此漏洞影响。攻击者发送 KeySet Remove(0)。根据规范，这必须被拒绝。但所有设备都接受了，导致IPK（身份保护密钥）被删，设备永久离线。这是一个由Matter SDK本身引入的供应链漏洞，波及了所有基于该SDK的厂商。
除此以外还有逻辑错误，Govee设备在收到非法 MoveHue 参数时，不仅没报错，还将色调重置为0。这种非预期的状态跳变可能被攻击者利用来破坏智能家居场景（如将警报红灯变为绿灯）。
3.5 指令覆盖率对比分析
为了证明mGPTFuzz的优越性，研究者与最先进的SNIPUZZ工具进行了对比。
Figure 3: Commands covered by SNIPUZZ vs. mGPTFuzz.
从对比结果可以看出，蓝色柱（SNIPUZZ）非常短，甚至在很多设备上为零。这是因为SNIPUZZ依赖厂商公开脚本，而大多数厂商不公开。绿色柱（mGPTFuzz）非常长，全面覆盖。得益于自动化的功能提取机制，mGPTFuzz发现了包括隐藏命令在内的所有指令。覆盖率是漏洞挖掘的基础。SNIPUZZ在起跑线上就输了。
3.6 测试效率评估
Figure 11: Efficiency results, where a red dot denotes a crash bug and a green dot denotes a non-crash bug.
Figure 11 展示了漏洞发现随时间的变化曲线。Nanoleaf在测试开始后的10分钟内就发现了首个漏洞。在110分钟、3000次测试内发现了全部漏洞。曲线陡峭，说明效率极高。Figure 11(b) Eve Sensor在90分钟、1200次测试内完成了任务。相比于传统Fuzzer动辄数天、数百万次的发包，mGPTFuzz凭借FSM的精确制导，实现了“外科手术式”的精准打击，极大节省了测试时间和算力。
第四节 讨论、局限与未来展望
4.1 讨论：为什么SNIPUZZ发现了0个漏洞？
尽管研究者增强了SNIPUZZ使其能处理加密，但结果依然是0。其核心原因在于 “结构感知（Structure Awareness）”的缺失。 SNIPUZZ基于“消息片段推断”，它盲目地删除或翻转数据包中的字节。然而，Matter消息负载是严格的JSON格式（如 {“0”:1}）。SNIPUZZ的变异破坏了JSON的语法结构（如删除了一个括号），导致数据包在设备的应用层解析阶段（JSON Parser）就被直接丢弃，根本无法进入业务逻辑函数。 相比之下，mGPTFuzz利用LLM生成的知识，构造的是“语法正确但语义非法”的测试包（如合法的JSON结构，但数值越界），因此能够深入固件核心，触发深层逻辑漏洞。
4.2 局限性
尽管成果显著，mGPTFuzz仍存在改进空间：
一是协议绑定，当前的Prompt和提取逻辑深度绑定Matter规范。若要测试Zigbee或蓝牙Mesh，需要重写Prompt。
二是LLM不确定性：尽管设置了 Temperature=0，但LLM在处理极长上下文时仍可能偶发幻觉，需要人工复核。
三是硬件门槛：Thread测试需要特定的Dongle硬件，增加了部署复杂性。
4.3 未来展望
研发通用的“规范驱动测试框架”，只需输入PDF，自动生成适配器，支持更多工业协议（如OPC UA）。
利用LLM的代码生成能力，从发现漏洞延伸至自动生成修复补丁（Patch）或防火墙规则，实现闭环安全。
从单设备测试迈向跨设备场景测试（如“门锁联动灯光”），挖掘IoT生态层面的逻辑漏洞。
4.4 潜在影响与伦理
本研究发现的通用漏洞（CVE-2023-42189）已由Matter SDK官方修复，这直接提升了全球数亿智能设备的安全性。此外，mGPTFuzz为设备厂商提供了一种低成本、高效率的合规性自查手段，有望成为IoT安全测试的新行业标杆。
本报告通过对论文全方位的拆解，详细论述了mGPTFuzz如何利用大模型技术攻克Matter协议测试的四大难关。从系统架构的巧妙设计（伪装控制器），到Prompt Engineering的精细打磨（思维链提取FSM），再到实验结果的震撼展示（147个新漏洞 vs 基准工具的0漏洞），本研究有力地证明了：在面对超大规模、高复杂度的技术规范时，AI辅助的自动化测试不再是辅助选项，而是确保IoT生态安全的必经之路。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：玄枢战队-Arcane Hub hkdmh《论文研读与思考 | mGPTFuzz—基于大语言模型与状态感知的Matter物联网设备自动化模糊测试框架》