1. 启动校验基础：什么是启动校验、启动校验的目的、常见的启动校验类型

各位同学，咱们今天聊点实在的。启动校验，说白了就是设备开机时做的一连串「安全检查」。你想想看，一个系统从按下电源键到进入桌面，中间要加载多少代码？BootROM、Bootloader、内核、驱动……任何一个环节被篡改，整台机器就可能变成别人的傀儡。

我入行那会儿，遇到过一台工控设备反复重启。查了三天，最后发现是Bootloader被植入了挖矿脚本。从那以后，我对启动校验这件事就特别较真。

1.1 什么是启动校验

启动校验，就是在系统启动的每个阶段，验证即将执行的代码是否「可信」。它不是一个单一的动作，而是一条完整的信任链。

举个例子：手机开机时，芯片内部固化的BootROM会先校验下一级Bootloader的签名。签名通过，才把控制权交出去。Bootloader再校验内核，内核再校验系统分区……每一环都扣死，这就是所谓的「安全启动链」。

1.2 启动校验的目的

为什么要做启动校验？我总结了三个最根本的目的：

• 防篡改：阻止恶意代码在启动阶段注入。比如Bootkit、Rootkit这类东西，专挑系统加载前下手。
• 防降级：防止攻击者把系统回滚到有已知漏洞的旧版本。我记得有个案例，攻击者就是利用降级攻击绕过了Android的验证。
• 防伪造：确保所有启动镜像来自合法厂商，不是第三方编译的带后门版本。

嗯，这里要注意：启动校验不是万能的。它解决的是「启动时」的安全问题，系统跑起来之后的事，得靠别的机制管。

1.3 常见的启动校验类型

实际项目中，常见的校验方式有三种。我按使用频率排个序：

校验类型	原理	典型场景	我踩过的坑
完整性校验	对比当前值与预期值是否一致	CRC32校验、文件大小比对	CRC32碰撞率其实不低，别单独用
哈希校验	用哈希函数计算摘要，比对摘要	SHA-256校验固件包	曾经用MD5，后来发现太容易碰撞了
签名校验	用私钥签名，公钥验签	安全启动链、UEFI Secure Boot	公钥存储位置没锁死，等于白做

1.3.1 完整性校验

这是最基础的一种。说白了就是检查文件有没有「缺斤少两」。比如嵌入式设备里经常用CRC32校验Bootloader的二进制文件，确保烧录过程中没丢数据。

但你要明白，完整性校验只能发现「意外损坏」，防不了「蓄意篡改」。攻击者完全可以改完文件后重新计算CRC值，你根本看不出来。

// 一个简单的CRC32校验示例（伪代码）
uint32_t crc = calculate_crc32(bootloader_image, image_size);
if (crc != EXPECTED_CRC) {
    panic("Bootloader integrity check failed!");
}

1.3.2 哈希校验

哈希校验比完整性校验进了一步。它用SHA-256这类单向函数计算摘要，只要原文改了一个比特，摘要就完全不一样。

我建议你在项目中至少用SHA-256。SHA-1虽然还没被彻底攻破，但已经出现理论碰撞攻击了。至于MD5——嗯，我十年前就不用了。

# 计算固件包的SHA-256哈希
$ sha256sum firmware_v2.1.bin
a3f8b2c9d1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0  firmware_v2.1.bin

哈希校验有个局限：它只能验证「文件没变」，但验证不了「文件是谁签发的」。这时候就需要签名校验出场了。

1.3.3 签名校验

签名校验是启动校验的「终极形态」。它用非对称加密：厂商用私钥对镜像签名，设备用公钥验签。只要私钥不泄露，攻击者就伪造不了合法镜像。

我曾经帮一个客户排查问题，发现他们的公钥竟然放在可读写的Flash分区里。攻击者直接把自己的公钥写进去，然后用自己的私钥签名恶意镜像——整个安全启动链形同虚设。

// 签名校验核心逻辑（伪代码）
public_key_t *pub_key = read_from_efuse();
signature_t *sig = extract_signature(bootloader_image);

if (rsa_verify(bootloader_image, sig, pub_key) != OK) {
    halt_system("Signature verification failed!");
}

1.4 三种校验的对比与选择

实际项目中怎么选？我一般按这个思路来：

• 只防意外损坏：完整性校验就够了，比如CRC32
• 防篡改但不防伪造：哈希校验，配合安全存储的预期哈希值
• 既要防篡改又要防伪造：签名校验，这是唯一靠谱的方案

但话说回来，签名校验也不是银弹。私钥管理、密钥轮换、验签性能……这些都是头疼的事。我见过一个项目，验签一次要花3秒钟，用户开机体验极差。

1.5 启动校验的整体逻辑

为了让你更直观地理解，我画了一张图。这张图展示了从硬件根信任到操作系统加载的完整校验链条：

你看这张图，信任是从最底层的硬件根信任开始，一级一级往上传递的。每一层只信任经过它校验的下一层代码。这就是安全启动的「链式信任」模型。

1.6 小结

启动校验不是什么高深莫测的技术，但它确实是系统安全的第一道防线。我见过太多项目，花大价钱做应用层安全，结果启动链上全是漏洞——就像给金库装了指纹锁，但后门根本没锁。

记住三个关键点：

• 完整性校验防意外，哈希校验防篡改，签名校验防伪造
• 信任链必须从硬件根开始，不能凭空信任任何软件
• 公钥存储是签名校验的命门，一定要锁死在硬件里

嗯，这一章就到这里。内容不多，但都是基本功。后面的章节我们会深入每个校验类型的具体实现和绕过手法。