2、嵌入式系统与IoT基础：硬件架构、固件类型、通信协议与安全挑战
在深入固件Fuzzing之前，必须建立对嵌入式系统与IoT设备的整体认知。绝大多数固件漏洞的根源，都隐藏在硬件资源约束、固件运行模式以及通信协议实现这三者的交叉地带。本章将系统梳理MCU/SoC的硬件架构差异、IoT设备的典型组成、裸机/RTOS/Linux三类固件的特征，以及UART/SPI/I2C/以太网/WiFi/BLE等通信协议的攻击面，最后总结嵌入式安全面临的独特挑战。理解这些基础，是后续进行固件提取、模拟执行、变异测试与漏洞利用的前提。
2.1 嵌入式硬件架构：MCU与SoC的差异及安全影响
核心原理：MCU与SoC的边界
嵌入式硬件架构主要分为MCU（Microcontroller Unit）和SoC（System on Chip）两大阵营。MCU通常集成CPU核心、Flash、SRAM以及丰富的外设接口于单一芯片，典型代表为ARM Cortex-M系列、RISC-V内核（如ESP32-C3）以及老旧的8051。MCU的设计目标是低成本、低功耗、确定性实时响应，其程序通常直接在Flash中执行（XIP，Execute in Place），或拷贝到SRAM中运行。而SoC则更复杂，往往包含应用处理器（如ARM Cortex-A系列）、GPU、DSP、ISP以及外部存储控制器（DDR、eMMC），运行完整的操作系统（如Linux）。在安全测试视角下，MCU固件通常为单一二进制镜像，无文件系统概念，而SoC固件则包含Bootloader、内核、根文件系统、应用层等多个独立组件。
| 维度 | MCU（如STM32F4） | SoC（如全志V3s） |
|---|---|---|
| CPU核心 | Cortex-M4，无MMU | Cortex-A7，带MMU |
| 存储 | 内部Flash 1MB，SRAM 192KB | 外部DDR2 128MB，eMMC/NAND |
| 操作系统 | 裸机/RTOS | Linux |
| 固件提取难度 | 低（JTAG/SWD直接读） | 高（需拆焊NAND或分析Bootloader） |
| Fuzzing目标 | 协议栈、驱动回调 | 用户态服务、内核驱动 |
判断方法：识别目标设备架构
在Fuzzing前，必须准确识别硬件架构。操作流程如下：
- 拆解设备，观察主芯片丝印，查询数据手册确认核心型号。
- 使用
file命令检查固件二进制格式，例如ARM或MIPS。 - 连接调试器（ST-Link/J-Link），尝试通过SWD读取IDCODE寄存器。
- 若为Linux设备，通过串口进入Bootloader（U-Boot），执行
bdinfo查看内存布局。
案例拆解：某智能插座固件提取
某智能插座使用乐鑫ESP8266（Tensilica Xtensa LX106，属于SoC但资源接近MCU）。初始现象：通过UART串口输出乱码，无法进入交互。分析过程：首先用逻辑分析仪抓取UART TX/RX波形，确认波特率为74880（ESP8266 Boot ROM默认）。随后使用esptool.py读取Flash内容，但发现Flash加密已启用。进一步分析：该设备支持OTA升级，通过抓取手机App与设备的通信，截获了未加密的固件升级包（因固件未启用签名校验）。最终通过OTA包直接获得了完整固件镜像。复盘经验：IoT设备常因业务功能（OTA）而引入安全短板，Fuzzing前应优先分析无线升级链路。
常见误区与总结
- 误区1：认为所有MCU固件都运行在Flash中。部分MCU（如nRF52832）支持从内存映射外部Flash执行，提取时需注意地址映射。
- 误区2：忽略SoC中的BootROM。BootROM中通常包含USB下载模式（如全志的FEL模式），这可能是获取固件的最便捷途径。
- 总结：硬件架构决定了固件的组织方式和提取路径。MCU固件分析重点在于外设寄存器操作和中断处理，SoC固件分析重点在于文件系统解析和系统调用。
2.2 固件类型：裸机、RTOS与Linux的Fuzzing差异
核心原理：三种固件的运行时模型
裸机固件是一个无限循环，所有任务顺序执行，无优先级抢占，变量通常存储在全局区。RTOS（如FreeRTOS）引入任务调度、信号量、消息队列，任务间通过IPC通信。Linux固件则拥有完整的进程地址空间隔离、虚拟内存管理、文件系统和网络协议栈。从Fuzzing角度看，裸机固件难以进行插桩（Instrumentation），因为缺少操作系统支持；RTOS可以通过修改调度器代码或使用硬件断点进行插桩；Linux固件则可以直接使用QEMU用户态模拟，配合AFL++进行高效的覆盖率引导Fuzzing。
操作流程：针对不同固件的Fuzzing策略
- 裸机：使用Unicorn Engine进行全系统模拟，将外设访问（如UART寄存器）映射为回调函数，对目标解析函数（如AT指令解析器）进行变异输入。
- RTOS：使用QEMU的
-machine参数模拟特定开发板（如STM32F407），通过GDB脚本设置断点，捕获崩溃现场。 - Linux：解包文件系统，提取目标二进制（如boa服务器），使用QEMU用户态模式运行，配合AFL++的
-Q参数进行Fuzzing。
案例拆解：某路由器RTOS固件漏洞挖掘
某家用路由器使用RTL8197FS（MIPS架构）运行VxWorks RTOS。初始目标：其Web管理界面的formLogin函数存在命令注入。关键输入数据：HTTP POST请求中的user_name参数。分析过程：由于VxWorks不支持动态链接，无法直接使用AFL++。我们采用硬件调试器（BDM接口）在strcpy函数处设置断点，记录PC返回地址。通过分析栈回溯，定位到formLogin函数地址。随后编写Python脚本，通过UART串口将构造的Payload注入到内存中，调用该函数并传入畸形参数。结果：成功触发栈溢出，覆盖返回地址，跳转到ROP链执行任意命令。复盘：RTOS固件Fuzzing的关键在于找到稳定的插桩点和输入注入通道。
常见误区与总结
- 误区：直接对RTOS固件运行AFL++。AFL++依赖fork()系统调用，而RTOS无此概念，必须使用持久模式（Persistent Mode）或定制化变异器。
- 总结：固件类型决定了Fuzzing工具链的选择。裸机适合Unicorn，RTOS适合硬件在环（HIL），Linux适合QEMU+系统调用模拟。
2.3 通信协议：攻击面与Fuzzing切入点
核心原理：协议分层与攻击面
IoT设备通信协议分为板级总线（UART/SPI/I2C）和网络协议（以太网/WiFi/BLE）。UART常用于调试控制台，SPI/I2C用于连接传感器和Flash芯片，以太网/WiFi承载TCP/IP协议栈，BLE用于低功耗设备互联。攻击面不仅存在于应用层（如MQTT的Topic解析），更存在于协议栈底层（如WiFi的Beacon帧解析、BLE的ATT协议处理）。Fuzzing时，应优先选择解析复杂、输入长度可变、且直接处理外部数据的函数。
| 协议 | 典型应用 | Fuzzing输入构造 | 常见漏洞类型 |
|---|---|---|---|
| UART | 调试控制台、AT指令 | 字符串、转义字符 | 命令注入、缓冲区溢出 |
| SPI/I2C | Flash读取、传感器数据 | 寄存器地址、数据块 | 越界读写、状态机混乱 |
| 以太网 | Web服务、云连接 | HTTP请求、TCP分段 | 整数溢出、格式化字符串 |
| WiFi | AP/STA模式 | Beacon帧、Probe Response | 堆溢出、越界访问 |
| BLE | 智能锁、健康设备 | ATT Read/Write请求 | 认证绕过、内存破坏 |
操作流程：协议Fuzzing的通用步骤
- 嗅探正常通信流量（使用Wireshark、Ellisys或逻辑分析仪）。
- 识别协议字段边界（长度字段、校验和、类型标识）。
- 编写协议模板（如使用Scapy或Boofuzz定义消息结构）。
- 对可变字段（如Payload、Name、URI）进行变异，固定其他字段。
- 监控目标设备状态（串口日志、LED指示灯、网络连通性）。
案例拆解：BLE智能灯泡的ATT漏洞
某智能灯泡使用Nordic nRF52832芯片，支持BLE连接。初始现象：手机App可以控制灯泡颜色，但无法修改设备名称。分析过程：通过nRF Connect App扫描服务，发现设备提供Device Name特征值（UUID 0x2A00），属性为可写。使用Python的bluepy库发送超长名称（500字节），灯泡立即断开连接并重启。进一步分析：固件在写入名称时使用memcpy到固定大小缓冲区，未检查长度。通过构造包含ROP链的BLE写入请求，成功在设备上执行任意代码。复盘：BLE的ATT协议允许客户端写入任意长度数据，开发者常忽略GATT规范中的最大长度限制（默认512字节），导致栈溢出。
常见误区与总结
- 误区：只关注应用层协议，忽略链路层（如WiFi的802.11管理帧）。
- 总结：协议Fuzzing的核心是理解状态机。例如，BLE的配对过程、WiFi的4次握手、TCP的3次握手，这些状态转换处往往是逻辑漏洞的高发区。
2.4 嵌入式安全挑战与Fuzzing应对策略
核心原理：安全挑战的本质
嵌入式安全面临四大核心挑战：资源受限（CPU频率低、内存小，无法运行重量级安全工具）、攻击面物理暴露（调试接口、UART引脚、Flash芯片均可被物理接触）、固件更新机制薄弱（缺乏签名校验或加密）、异构性（不同架构、不同RTOS、不同协议栈导致漏洞无法通用）。Fuzzing作为动态分析手段，必须适应这些约束。
应对策略：轻量化与硬件辅助
- 轻量级插桩：使用ARM的ETM（Embedded Trace Macrocell）或RISC-V的N-Trace，在不修改代码的情况下获取执行轨迹。
- 硬件加速：利用FPGA原型验证平台，将固件运行速度提升10倍以上。
- 选择性Fuzzing：通过静态分析（如Ghidra）定位危险函数（strcpy、memcpy、sprintf），仅对这些函数周边进行变异。
- 远程Fuzzing：对于无法物理接触的设备，通过OTA接口或网络服务进行黑盒Fuzzing，但需控制速率避免设备过载。
QEMU -m 512模拟，并开启-enable-kvm（若宿主机支持），同时将目标二进制编译为静态链接，减少内存碎片。最终在3小时内发现了一个位于SNMP解析器中的堆溢出。案例拆解：从UART控制台到完整Shell
某IP摄像头使用海思Hi3518E SoC，运行Linux。初始现象：UART引脚暴露，连接后获得root shell，但文件系统为只读。目标：持久化后门。分析过程：通过mount命令查看分区，发现/dev/mtdblock3为可写分区（存放配置）。使用dd备份该分区，修改/etc/init.d/rcS添加反向Shell命令，再通过mtd write写回。结果：重启后后门生效。复盘：该设备未启用Secure Boot，且U-Boot环境变量可修改，导致固件完整性校验被绕过。Fuzzing在此案例中并非主要手段，但暴露了硬件调试接口的严重风险。
常见误区与总结
- 误区：认为Fuzzing可以替代人工代码审计。嵌入式固件中许多漏洞（如逻辑错误、竞态条件）难以通过随机输入触发。
- 总结：嵌入式Fuzzing应遵循“硬件先行、协议聚焦、轻量插桩”的原则。先通过硬件手段获取固件和调试通道，再针对暴露的协议栈进行定向变异，最后结合静态分析验证崩溃点。