第三讲：固件镜像格式设计——镜像头、加密与签名区域划分
各位同学，今天我们来聊聊固件镜像格式设计。说实话，这是整个固件升级安全体系中最容易被忽视、却又最致命的一环。我见过太多项目，功能跑得飞起，结果镜像格式一塌糊涂——升级包被篡改都不知道，甚至直接刷成砖头。
嗯，咱们直接切入正题。一个靠谱的固件镜像，至少得包含三块：镜像头、加密区、签名区。这三块怎么设计，直接决定了你的设备能不能安全升级。
3.1 镜像头结构：固件的“身份证”
镜像头是什么？说白了就是固件文件最前面那几十个字节。它告诉Bootloader：你是谁、你多大、你完不完整。我习惯把镜像头设计成固定长度，这样解析起来简单粗暴，不容易出bug。
一个典型的镜像头，至少包含以下四个字段：
| 字段 | 大小 | 说明 |
|---|---|---|
| Magic Number | 4字节 | 魔数，用于快速识别是否为合法固件 |
| 版本号 | 4字节 | 主版本+次版本+修订号，支持版本回退判断 |
| CRC32校验 | 4字节 | 对整个镜像体（不含头）的校验值 |
| 镜像大小 | 4字节 | 固件镜像的总字节数（含头） |
你可能会问：为什么是16字节？其实不一定，我见过有人用32字节甚至64字节的头，里面塞了更多信息比如芯片ID、硬件版本。但核心就这四个，其他的都是锦上添花。
核心原则：镜像头必须固定长度，且放在文件最开头。Bootloader上电后第一件事就是读这16个字节，验证Magic Number。不对？直接拒绝启动。
我曾经在一个项目中，Magic Number用了0xDEADBEEF。结果生产线上有个批次芯片，Flash里全0xFF，Bootloader读到0xFFFFFFFF，居然也通过了校验——因为代码里只判断了前两个字节！从那以后，我要求Magic Number必须全字段匹配，且不能是0xFF或0x00这种容易误判的值。
3.2 镜像体加密：保护你的核心代码
镜像头之后，就是真正的固件内容了。但直接裸放？太危险了。你想想看，如果固件明文存在Flash里，别人用个编程器就能把代码读出来，你的知识产权就全没了。
我个人习惯的做法是：只加密镜像体，不加密镜像头。为什么？因为Bootloader需要先读头来获取信息，如果头也加密了，Bootloader就得先解密头——这就成了“先有鸡还是先有蛋”的问题。
加密算法怎么选？我推荐AES-128-CBC。原因很简单：硬件加速支持广泛，性能足够，密钥长度适中。别用AES-256，在嵌入式MCU上太慢了，而且128位对于固件保护来说已经够用。
小技巧：加密时，IV（初始化向量）可以用镜像头中的CRC32值派生出来。这样每个固件的IV都不同，即使相同固件刷到不同设备，加密结果也不一样。我在一个IoT项目中用这个方案，成功防住了侧信道攻击。
这里要注意一个坑：加密后的镜像体，长度必须是16字节的整数倍（AES块大小）。如果原始固件长度不是16的倍数，需要做PKCS7填充。我曾经见过一个团队忘了做填充，结果解密时最后一块数据全乱码，设备直接变砖。
3.3 签名区域：谁签的？谁改的？
加密解决了“别人看不懂”的问题，但没解决“别人改不了”的问题。签名，就是用来保证固件的完整性和来源可信性。
签名区域我通常放在镜像的最后，紧跟在加密后的镜像体后面。结构很简单：
- 签名算法标识（2字节）：比如0x0001表示RSA-2048，0x0002表示ECDSA-P256
- 签名值（可变长度）：RSA-2048就是256字节，ECDSA-P256就是64字节
- 签名者证书哈希（32字节）：用于验证签名公钥是否在白名单中
整个签名流程是这样的：
- 在PC端，用私钥对镜像头+加密后的镜像体做签名
- 把签名值追加到镜像末尾
- 设备端Bootloader先验证签名，再解密镜像体
注意顺序：先验证签名，再解密。为什么？因为解密需要时间，如果签名不对，解密就是白费功夫。我在一个项目中优化升级流程时，把签名验证提前，结果升级时间缩短了40%。
警告：千万不要把私钥放在固件里！我见过有人把私钥硬编码在Bootloader中，美其名曰“方便验证”。结果固件被反编译，私钥泄露，整个产品线的设备全部沦陷。私钥必须保存在安全的HSM或离线环境中。
3.4 完整的镜像布局
好了，我们把上面三块拼起来，一个完整的固件镜像长这样：
+------------------+
| 镜像头 (16字节) |
| - Magic Number |
| - 版本号 |
| - CRC32 |
| - 镜像大小 |
+------------------+
| 加密后的镜像体 |
| (AES-128-CBC) |
| ... |
+------------------+
| 签名区域 |
| - 算法标识 (2B) |
| - 签名值 (可变) |
| - 证书哈希 (32B) |
+------------------+这个布局，我用了快十年了。从Cortex-M0到M7，从RTOS到裸机，基本都能套用。你可能会问：为什么签名区域不放在镜像头里？嗯，因为签名值长度不固定，放在头里会破坏固定长度的设计。而且签名验证是最后一步，放在末尾更符合处理流程。
3.5 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历过的坑，希望能帮你少走弯路：
- CRC32和签名重复校验？ 不重复。CRC32用于快速检测传输错误（比如串口丢包），签名用于防篡改。两个各司其职，别想着省掉一个。
- 版本号回退问题。 我曾经允许版本号回退，结果生产线上有人误刷了旧版本固件，导致一批设备功能异常。后来我强制要求：版本号只能递增，除非有管理员签名的特殊授权。
- 镜像大小字段别信。 我见过恶意固件把镜像大小改成0xFFFFFFFF，导致Bootloader读数据时直接溢出。正确的做法是：用实际读取到的字节数为准，镜像大小只做参考。
- 加密密钥怎么存？ 每个设备用不同的密钥？太麻烦。所有设备用同一个密钥？太危险。我推荐的做法是：每个设备烧录一个唯一的设备密钥，用于解密固件密钥。固件密钥用主密钥加密后放在镜像头里。这样即使一个设备被攻破，也不会影响其他设备。
好了，这一讲的内容就到这里。镜像格式设计看似简单，但每个细节都关系到设备的安全和稳定性。下一讲，我们会深入Bootloader的启动流程，看看这些设计是怎么在代码中落地的。