1. 固件校验概述：什么是固件镜像校验、为什么需要校验、常见的校验场景

大家好，欢迎来到《从零掌握固件镜像校验》的第一章。

固件镜像校验，说白了就是给固件做一次「身份验证」和「完整性检查」。你想想看，嵌入式设备跑的程序，本质上就是一堆二进制数据。这些数据在传输、存储、烧录的过程中，会不会被篡改？会不会因为存储介质老化而出现比特翻转？会不会被恶意植入后门？

嗯，这就是固件校验要解决的问题。

固件镜像校验，是指对固件二进制文件进行一系列数学运算和验证，确保它的完整性和真实性。完整性是指固件没有被意外损坏，真实性是指固件来自可信的源头。

我个人习惯把校验分成两个层面：

常见的校验手段包括 CRC、MD5、SHA 系列哈希算法，以及 RSA、ECDSA 等数字签名算法。这些我会在后面的章节详细展开。

核心概念：固件校验不是可选项，而是嵌入式系统的安全基石。没有校验的固件，就像没有锁的门。

我在项目中遇到过不少因为忽略校验而翻车的案例。有一次，某款 IoT 设备在 OTA 升级过程中，网络传输丢包导致固件损坏，设备直接变砖。客户投诉电话打爆了售后。从那以后，我负责的项目都把校验作为强制流程。

具体来说，校验的必要性体现在以下几个方面：

避坑提醒：我曾经见过一个团队，只用了简单的 CRC 校验就上线了。结果攻击者伪造了固件，CRC 值也重新计算了，设备毫无防备地被刷入了恶意程序。记住，CRC 只能防意外损坏，防不了恶意攻击。

校验不是只在烧录时才做。实际上，固件从开发到运行，每个环节都需要校验。我把它归纳为三个核心场景。

OTA 升级是最容易出问题的场景。固件要通过网络传输，网络环境不可控。你想想看，一个 10MB 的固件包，在 2G 网络下传输，丢包率可能高达 5%。

典型的 OTA 校验流程是这样的：

这里有个细节：我建议在下载过程中就做分块校验，而不是等全部下载完再校验。这样能尽早发现错误，避免浪费带宽和时间。

生产线上烧录固件，讲究的是效率和可靠性。我见过一条产线，每天要烧录 5000 块板子。如果每块板子烧录后不做校验，一旦出现批量问题，损失就是巨大的。

烧录校验通常有两种方式：

我的经验：量产项目我倾向于两种方式都用。产线做快速校验（比如只校验前 1KB 和关键区域），Bootloader 做完整校验。这样既保证了效率，又确保了安全。

安全启动是嵌入式安全的最后一道防线。它的核心逻辑是「信任链」：从芯片内部的只读存储器（ROM）开始，逐级校验，确保每一级代码都是可信的。

典型的信任链是这样的：

每一级校验通过后，才把执行权交给下一级。任何一级校验失败，系统都会进入安全状态（比如停止启动、进入恢复模式）。

下面这张图展示了安全启动的信任链结构：

这张图展示了安全启动的信任链。每一级都依赖上一级的校验结果。ROM 代码是信任的根，它不可篡改。从 ROM 开始，逐级向下，形成一条完整的信任链。

关键点：安全启动不是可选项。如果你的产品要过 CE、FCC 认证，或者要接入云平台（如 AWS IoT、阿里云 IoT），安全启动是强制要求。

固件镜像校验，是嵌入式安全的基础。它解决三个问题：固件有没有坏、固件是不是真的、固件能不能安全运行。

三个核心场景——OTA 升级、固件烧录、安全启动——覆盖了固件从发布到运行的全生命周期。每个场景的校验策略不同，但目标一致：确保设备运行的是可信、完整的固件。

后面的章节，我会带大家深入每种校验算法的原理和实现。从 CRC 到 SHA，从 RSA 到 ECDSA，一步步把固件校验吃透。