3. 哈希算法在烧录中的应用：SHA-256原理、固件哈希值的计算与比对、哈希碰撞的工程风险

说到量产烧录的安全校验，哈希算法是绕不开的核心。说白了，它就是给固件算一个“数字指纹”。你烧进去的固件对不对、有没有被篡改，全靠这个指纹来确认。

我个人习惯把哈希算法比作“榨汁机”。你把整个固件文件丢进去，出来一杯固定大小的“果汁”——也就是哈希值。哪怕固件里只改了一个 bit，出来的“果汁”味道就完全不一样了。这个特性，正是我们做烧录校验的基础。

3.1 SHA-256 原理：它到底在算什么？

SHA-256 是 SHA-2 家族里最常用的一员。它把任意长度的输入数据，变成一串 256 位（32 字节）的固定输出。我刚开始接触时也觉得这玩意儿很玄乎，其实拆开看，核心就三步：

填充：把数据补到 512 位的整数倍。先补一个“1”，再补一堆“0”，最后 64 位放原始长度。
分块：每 512 位（64 字节）算一个块，依次处理。
压缩：每个块经过 64 轮循环运算，跟 8 个初始向量搅在一起，最后输出 256 位的摘要。

你不需要手写 SHA-256，市面上成熟的库一抓一大把。但理解它的原理，能帮你判断什么时候该用它、什么时候不该用。

SHA-256 的核心特性：

输出固定 32 字节，不管固件是 1KB 还是 1GB
单向性：从哈希值反推原始数据，计算上不可行
雪崩效应：输入改 1 bit，输出大约一半的 bit 会翻转

3.2 固件哈希值的计算与比对：量产线上的实战

量产烧录时，哈希值的计算和比对通常分两段走：上位机侧和下位机侧。我在项目里见过不少团队只做一端校验，结果出问题后互相甩锅。嗯，这里要注意：两端都要算，两端都要比。

3.2.1 上位机侧：烧录前算好“标准答案”

上位机（通常是 PC 或烧录器控制板）在加载固件文件时，先算一次 SHA-256。这个值就是“标准答案”。

// 伪代码示例：上位机计算固件哈希
uint8_t firmware_buffer[FIRMWARE_SIZE];
uint8_t hash_output[32];

// 读取固件文件到 buffer
read_firmware_file("firmware.bin", firmware_buffer, FIRMWARE_SIZE);

// 调用 SHA-256 库计算
SHA256_CTX ctx;
sha256_init(&ctx);
sha256_update(&ctx, firmware_buffer, FIRMWARE_SIZE);
sha256_final(&ctx, hash_output);

// 将 hash_output 存入烧录指令中，发送给下位机
send_to_target(hash_output, 32);

这个“标准答案”会随着烧录指令一起发给目标芯片。我建议把它放在指令包的末尾，单独校验，不要混在固件数据里。

3.2.2 下位机侧：烧录完再算一次

目标芯片（MCU/MPU）收到固件数据后，一边写入 Flash，一边或者写完后，再算一次 SHA-256。然后跟上位机发来的“标准答案”比对。

// 伪代码示例：下位机校验固件哈希
uint8_t received_hash[32];  // 从上位机收到的标准答案
uint8_t calculated_hash[32]; // 本地计算出的哈希

// 假设固件已经烧录到 flash 地址 0x08000000
sha256_calculate(0x08000000, FIRMWARE_SIZE, calculated_hash);

// 比对
if (memcmp(received_hash, calculated_hash, 32) == 0) {
    // 校验通过，标记该芯片为合格
    set_programming_status(PASS);
} else {
    // 校验失败，标记为不良品
    set_programming_status(FAIL);
    // 我习惯在这里加一条日志：记录实际哈希和期望哈希
    log_hash_mismatch(received_hash, calculated_hash);
}

我的实战建议：

量产线上，Flash 写入完成后立刻读回校验，不要等整批烧完再统一校验。我曾经遇到过一个案例，某批次芯片 Flash 有坏块，写入时没报错，读回来才发现数据全乱了。如果当时是批量校验，那批板子就全废了。

3.3 哈希碰撞的工程风险：别拿理论当借口

每次讲到哈希碰撞，总有人问：“SHA-256 会不会碰撞？两个不同的固件算出同一个哈希值怎么办？”

理论上，会的。SHA-256 的输出空间是 2^256，输入空间是无限的，根据鸽巢原理，碰撞必然存在。但工程上，这个概率有多低？

场景	碰撞概率	工程风险
随机碰撞（无恶意攻击）	约 2^(-128) 量级	可忽略
生日攻击（有针对性）	约 2^(-64) 量级	理论可行，工程代价极高
已知公开碰撞实例	SHA-256 至今无公开碰撞	当前无风险

说白了，你在量产线上因为 SHA-256 碰撞导致误判的概率，远低于 Flash 写入时被宇宙射线打中一个 bit 的概率。所以，别拿碰撞当借口不做校验。

真正的风险在哪？

哈希碰撞在量产烧录中不是主要威胁。真正的风险是：

校验代码本身有 bug：比如 memcmp 返回值搞反了，或者只比对了前 4 个字节
哈希值传输过程中被篡改：如果上位机到下位机的通信链路不安全，攻击者可以同时改固件和哈希值
使用了弱哈希算法：比如还在用 MD5 或 SHA-1 做烧录校验的，赶紧换掉

我个人在项目中遇到过最离谱的一次，是某同事把哈希值存成了 ASCII 字符串，比对时又忘了做大小写转换。结果固件明明是对的，校验就是过不去。排查了整整两天，最后发现是 'a' 和 'A' 的问题。嗯，这种低级错误，比哈希碰撞常见一万倍。

3.4 本章知识体系：一张图说清楚

下面这张图把 SHA-256 在烧录校验中的完整流程串起来了。从固件文件到最终判定，每一步都离不开哈希。

从这张图你能看到，整个流程是线性的，但每个环节都可能出问题。我个人建议在量产烧录脚本里，把每一步的哈希中间值都打印出来，方便事后追溯。别嫌麻烦，等你在产线上一晚上烧坏 500 片板子时，就知道这些日志有多救命了。