刷写协议(TODO)

📅 2026/7/6 13:22:50 👁️ 阅读次数 📝 编程学习
刷写协议(TODO)

1 刷写协议定义

最近发现很多时候,固件开发都是要破解刷写协议,然后写一些自己的固件进去。所以了解一下这些协议还是很有必要,所以今天也是写一下这个。

根据应用场景的不同,常用的刷写协议主要可以分为汽车电子领域和通用消费电子/芯片级开发两大阵营。刷写协议主要是由Bootloader提供,一般来说有两个阶段。

1.1 1阶段升级

第一阶段/硬件级(ROM Bootloader / Primary Bootloader)。

这部分的升级固化在芯片内部的 ROM 中(Mask ROM),出厂后任何人都无法修改。协议一般是厂商特有协议(如 USB DFU、高通的 EDL 模式/紧急下载模式、STM32 的串口 ISP 协议)。EDL就是说的高通的9008升级。

当后面的所有固件全部损坏时,通过物理引脚(或特定的寄存器状态)强行进入这一层,可以用最底层的协议把引导程序重新救回来(“救砖”)。

1.2 2阶段升级

第二阶段/软件级(Flash Bootloader / Second Bootloader)。

这部分的升级存放在 Flash 的特定受保护区域(如 /bootloader 分区,汽车 ECU 的 FBL)。它是可以被升级的,但平时绝对不允许擦除。

协议一般是工业标准或业务级刷写协议(如汽车里的 UDS 协议 / DoIP 协议;手机/嵌入式里的 Fastboot 协议)。

一般日常研发调试、售后线刷、或者 OTA 升级时,真正负责接收大数据、擦除 Flash 分区、校验签名并写入 Flash 的,就是这一层 Bootloader。

2 刷写协议的流程

车载这块我确实不熟悉了,所以还是以IOT设备来写吧。

阶段传统线刷流(旧)后台无感流(新)
1. 触发发送指令,立刻重启发送指令,后台开工
2. 传输在 Bootloader 阶段挂机传输(手机变砖在 App 正常运行阶段后台下载(用户无感
3. 握手与校验开头握手(对齐波特率/解锁安全域)结尾握手(验明正身,写入引导标志位)
4. 重启升级完后,重启进入新系统重启不传数据,仅做引导切换,直接开机

目前最新的其实是无感升级,但是考虑到项目的实际需要,所以还是写老的。

2.1 升级指令

这是升级的起点。当手机、汽车 ECU 或 MCU 还在正常运行日常业务(App 状态)时,上位机或 OTA 服务器会发送一个特定的诊断命令或通信包。

比如说:adb reboot bootloader 或 adb reboot edl。

此时强行打断App的正常运行,告诉系统暂停现在的业务了,准备重启去升级。 正式固件收到这个指令后,写好标志位,然后重启。

此时会往特定的内存/寄存器里写一个标志位(Flag),然后执行软件复位(Reset)。

2.2 握手

系统重启后,正式进入 Bootloader 状态。这时候,Bootloader 和上位机之间必须进行握手(Handshake)。

此时握手的主要意义是:

1 Bootloader必须确保物理链路(USB、CAN、串口)的另一头是一个合规的刷写软件,而不是一堆杂讯或者普通的通信。

2 波特率/速率同步:尤其是串口(UART)或 CAN 总线,双方需要通过握手来对齐传输速率。

3 安全和版本校验:防止发错固件或者被恶意刷机。

这里的握手协议非常多,不同的协议,握手的方式也是林林总总。举两个例子。

STM32

Bootloader刚启动时,会在几十毫秒内死等一个固定字节。上位机疯狂发送 0x7F。Bootloader 收到 0x7F 后,回复一个 0x79(ACK)。这就是握手成功。 接下来上位机才能发擦除、写入指令。

高通的EDL

手机黑屏连电脑,会枚举出一个高通 9008 端口。上位机会通过底层协议向 Bootloader 发送一段特殊的配置包(包含芯片 ID),Bootloader回应握手成功后,上位机才能加载Firehose(刷机引导算法)。

此外还有很多厂商专用自研协议,如恩智浦(NXP)的blhost/mfgtools,乐鑫(Espressif)的 esptool(通过UART进行握手、同步、分段下载和校验)。

2.3 升级

这里就是正式传输数据(下载、擦除、写入 Flash),可能涉及到AB分区,暂时就不多写了。

3 破解刷写协议

1 查找升级命令

很多设备的升级命令不是单发的,而是一个“组合”。例如:可能需要你先发一条“请求进入测试模式” 0x01,收到确认后,再发一条“解锁闪存” 0x02,最后发“重启至引导” 0x03。

2 查找握手协议

设备重启进入 Bootloader 后,你直接发数据它是不会收的,必须完成握手。这一步是防错、防呆、甚至防黑客的关键。

模拟上位机发握手,直到黑盒设备能给你返回 ACK(表示它承认你这个上位机了)。

3 传输数据包时候的包头和校验字

$$\text{Packet} = \text{Frame Header} + \text{Length} + \text{Cmd ID} + \text{Address/Index} + \text{Payload (Firmware Chunk)} + \text{Checksum}$$

  • 包头(Frame Header):通常是固定的 1~2 个字节(如0xAA 0x550x02STX等),用来让设备捕获一个完整帧的开始。

  • 指令字(Cmd ID):紧跟在包头或长度后面。比如:0x11代表擦除,0x12代表写入,0x13代表传输结束。

  • 索引/地址(Index / Address):大固件会被拆成几百个包。数据包里一定会带一个参数,要么是当前包的序号(Packet ID: 1, 2, 3...),要么是这批数据要写入 Flash 的绝对物理地址(如0x08004000

  • 校验字(Checksum)这是最容易卡壳的地方。如果你改了固件内容,但没有更新包尾的校验字,设备会直接拒绝。它可能是简单的累加和(Checksum)、CRC16-Modbus、CRC32,或者是厂商自己对数据做异或(XOR)。在黑盒状态下,可以把数据段抠出来,扔进在线 CRC 计算器里,把各种标准的 CRC 模型都试一遍,看看能不能对上抓包里的尾部字节。