4、Bootloader核心功能：固件校验（CRC/哈希）、固件解密、跳转到应用区
好，咱们接着聊。上一章我们把Bootloader的启动流程捋了一遍，这一章我打算深入聊聊它的三个核心功能：固件校验、固件解密、跳转到应用区。
这三个功能，说白了就是Bootloader的“看门人”职责。你想想看，固件从云端下载下来，或者从本地烧录进去，中间会不会被篡改？会不会因为传输错误导致数据损坏？如果固件是加密的，Bootloader能不能正确解开？解开之后，又怎么安全地把控制权交给应用？
嗯，这些问题，就是这一章要解决的。
核心观点：Bootloader不是简单的“跳一跳”，它必须确保跳转之前，应用固件是完整、可信、且可执行的。
4.1 固件校验：CRC还是哈希？
先说说校验。我个人习惯把校验分成两类：完整性校验和真实性校验。
- 完整性校验：检查固件有没有被改过，或者传输过程中有没有丢包。常用CRC32、CRC16。
- 真实性校验：检查固件是不是来自合法的发布者。常用SHA256 + 签名验证。
我在项目中遇到过不少团队，只做了CRC校验，觉得够了。结果有一次，固件被人恶意篡改，CRC虽然能检测到数据变了，但无法阻止攻击者重新计算CRC值并替换掉。嗯，这就是典型的“防君子不防小人”。
所以我的建议是：量产产品，至少用SHA256做哈希校验。如果资源实在紧张，CRC32可以用于快速检查，但绝不能替代哈希。
4.1.1 CRC校验示例
CRC校验，说白了就是一个多项式除法。硬件上很多MCU自带CRC计算模块，速度极快。软件实现也不复杂，我贴一段常用的CRC32代码：
// 常见的CRC32查表法实现
uint32_t crc32(const uint8_t *data, uint32_t len) {
uint32_t crc = 0xFFFFFFFF;
for (uint32_t i = 0; i < len; i++) {
crc = crc_table[(crc ^ data[i]) & 0xFF] ^ (crc >> 8);
}
return crc ^ 0xFFFFFFFF;
}注意：CRC校验值通常放在固件末尾。Bootloader先读取整个固件，计算CRC，再与末尾存储的CRC值比对。一致则通过，不一致则拒绝启动。
4.1.2 哈希校验（SHA256）
哈希校验比CRC更安全。SHA256输出256位（32字节）的摘要，几乎不可能碰撞。我在一个OTA项目中，就用了SHA256 + RSA签名验证，确保固件既完整又可信。
不过要注意，SHA256计算量比CRC大得多。如果你的MCU主频只有几十MHz，算一个几百KB的固件可能要好几秒。这时候可以考虑硬件加速模块，或者只在关键区域做哈希。
小技巧：如果Flash空间允许，可以把固件分成多个块，每块单独计算哈希。这样校验时不用一次性加载整个固件到RAM，适合资源受限的MCU。
4.2 固件解密：安全启动的最后一道防线
固件解密，是很多工程师容易忽略的一环。你想想看，如果固件是明文存储的，攻击者直接读Flash就能拿到你的代码。那校验做得再好，也白搭。
解密算法常见的有：AES-128/256、XOR简单加密（不推荐）、国密SM4（国内项目常用）。
我个人习惯用AES-128-CBC模式。为什么？因为CBC模式需要IV（初始化向量），每次解密结果都不一样，能有效防止重放攻击。
4.2.1 解密流程
- Bootloader从Flash读取加密的固件数据。
- 使用预置的密钥（通常存储在OTP或安全区域）进行解密。
- 解密后的数据写入RAM或直接原地解密（如果Flash支持XIP）。
- 解密完成后，再对明文固件进行哈希校验。
这里有个坑：密钥怎么存？ 我曾经见过有人把AES密钥直接写在代码里，编译进固件。嗯，这等于把钥匙挂在门上。正确的做法是：
- 使用MCU内置的唯一ID（UID）派生密钥。
- 或者存储在OTP（一次性可编程）区域，只能写入，不能读出。
- 更高级的，用安全元件（SE）或TPM。
警告：千万不要把解密密钥硬编码在Bootloader的固件中！攻击者一旦拿到你的固件，就能逆向出密钥，整个安全体系就崩塌了。
4.2.2 解密性能优化
解密是个耗时的操作。我记得在一个项目中，固件有2MB，AES-128解密花了将近3秒。用户等得不耐烦，差点退货。
后来怎么优化的？只解密关键代码段。比如只解密中断向量表和核心初始化函数，其余部分在运行时按需解密。这样启动时间从3秒降到了0.5秒。
4.3 跳转到应用区：最后一公里
校验通过，解密完成，接下来就是跳转了。这一步看似简单，但稍有不慎，系统就会跑飞。
跳转的核心动作：
- 关闭全局中断。
- 禁用外设时钟（尤其是定时器、DMA）。
- 重置堆栈指针（SP）为应用区的栈顶地址。
- 跳转到应用区的复位向量（Reset_Handler）。
代码实现通常是这样：
typedef void (*app_entry_t)(void);
void jump_to_app(uint32_t app_addr) {
// 1. 关闭中断
__disable_irq();
// 2. 禁用所有外设时钟（根据具体MCU实现）
disable_all_peripheral_clocks();
// 3. 设置主栈指针
__set_MSP(*(volatile uint32_t *)app_addr);
// 4. 获取应用入口地址（向量表偏移4字节处）
app_entry_t app_entry = (app_entry_t)(*(volatile uint32_t *)(app_addr + 4));
// 5. 跳转
app_entry();
}这里有个细节：向量表重映射。很多MCU（比如STM32）在跳转后，需要把向量表基地址重新指向应用区。否则中断来了，CPU会去Bootloader的向量表找中断服务函数，那就乱套了。
重要：跳转前，一定要确保所有外设处于复位状态。尤其是DMA和定时器，它们可能在后台偷偷修改内存，导致跳转后应用崩溃。
4.3.1 跳转后的状态清理
跳转后，Bootloader的代码就不再执行了。但有些状态需要清理：
- 全局变量：Bootloader的全局变量占用的RAM，应用可以复用。但要注意，如果Bootloader用了BSS段，跳转前最好清零。
- 堆栈：跳转后，应用会重新初始化自己的堆栈。Bootloader的堆栈数据可以丢弃。
- 外设状态：比如UART、SPI的配置寄存器，最好恢复默认值，避免应用误判。
我曾经遇到一个bug：Bootloader用了UART打印日志，跳转后没有关闭UART。应用启动时，UART中断还在触发，导致应用卡死在中断处理里。排查了整整一天，最后发现是UART没关。嗯，从那以后，我写了个deinit_all_peripherals()函数，跳转前必调。
4.4 总结与避坑指南
这一章的内容，我总结成一张表，方便你对照：
| 功能 | 常用算法 | 注意事项 |
|---|---|---|
| 固件校验 | CRC32 / SHA256 | CRC只防误码，SHA256防篡改 |
| 固件解密 | AES-128-CBC / SM4 | 密钥不能硬编码，建议用UID派生 |
| 跳转到应用 | 重置SP + 跳转向量 | 关闭中断、禁用外设、重映射向量表 |
避坑指南：
- 我曾经在跳转前忘了关看门狗，结果应用刚启动就被狗咬复位了。所以，跳转前务必喂狗并关闭看门狗。
- 如果应用区是加密的，先解密再校验，顺序不能反。先校验再解密，校验的是密文，没有意义。
- 跳转后，如果应用跑不起来，先检查向量表偏移是否正确。很多新手栽在这个坑里。
好了，这一章就到这里。下一章我会聊聊Bootloader的升级策略，包括双备份、回滚机制等。这些在实际产品中非常关键，咱们到时候细说。