刷写协议（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设备来写吧。

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

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 0x55，0x02 STX等），用来让设备捕获一个完整帧的开始。

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

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

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