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 0x55，0x02STX等），用来让设备捕获一个完整帧的开始。指令字（Cmd ID）：紧跟在包头或长度后面。比如：
0x11代表擦除，0x12代表写入，0x13代表传输结束。索引/地址（Index / Address）：大固件会被拆成几百个包。数据包里一定会带一个参数，要么是当前包的序号（Packet ID: 1, 2, 3...），要么是这批数据要写入 Flash 的绝对物理地址（如
0x08004000）。校验字（Checksum）：这是最容易卡壳的地方。如果你改了固件内容，但没有更新包尾的校验字，设备会直接拒绝。它可能是简单的累加和（Checksum）、CRC16-Modbus、CRC32，或者是厂商自己对数据做异或（XOR）。在黑盒状态下，可以把数据段抠出来，扔进在线 CRC 计算器里，把各种标准的 CRC 模型都试一遍，看看能不能对上抓包里的尾部字节。