[i=s] 本帖最后由 hbzjt2011 于 2025-6-20 16:16 编辑 [/i]<br />
<br />
#申请原创#@21小跑堂
嵌入式开发领域，固件代码往往承载着开发者几个月甚至几年的心血。尤其在 MCU（微控制器单元）项目中，一个功能完整、逻辑严密、稳定高效的固件，不仅仅是技术成果，更可能是企业核心竞争力的体现。然而，在“复制粘贴就能开工”的今天，固件被拷贝、反编译甚至商用的事件屡见不鲜。如何保护 MCU 固件代码的安全，成了开发者绕不开的重要议题。
本文结合本人在工业控制系统开发中的实际经历，分享一套多层次的 MCU 固件保护方案，并欢迎大家一同探讨和分享各自“护码不被偷”的招数与教训。
那一年，我的代码被扒了个底朝天
时间回到2021年，我和团队开发了一套智能水泵控制器，基于 STM32F103 系列 MCU，固件主要实现水压自动检测、流量计算、异常报警和远程 OTA 升级等功能，核心算法调试了近 3 个月。由于项目周期紧张，前期并没有特别关注固件加密防护，甚至连 Flash 的读保护（RDP）都没开启。
出货没多久，一家“合作客户”突然反馈说设备异常，希望获取一份原始固件协助调试。我们谨慎地拒绝了，结果几周后，该客户竟拿出了一模一样的设备，还宣称“自己重新开发的”，甚至连操作界面都没改。
后续通过固件反汇编对比，我们发现他们完全是“拆壳装芯”，用 ISP 工具直接把 bin 文件读出后重新烧录的。可以说，我们的防护“几乎为零”，付出的技术劳动就这样打了水漂。
这次事件之后，我们痛定思痛，建立起一套系统性的固件保护机制，并在不同项目中进行实践与优化。
多层防护：不是一个锁，而是一整套门禁系统
保护 MCU 固件不能靠“单点防御”，而应形成“硬件 + 软件 + 加密算法 + 管理机制”的多层体系。我们最终形成如下防护架构：
1. 硬件级：启用 MCU Flash 读保护（RDP/LDRA）
- STM32系列提供 RDP Level 1/2 功能。我们默认开启 RDP1，禁止外部读取 Flash 内容；
- 在敏感项目中启用 RDP Level 2，彻底锁死读取和调试接口，唯一的“代价”是芯片将无法再擦写升级；
- 对于 PIC 或其他架构，使用厂家提供的 Code Protection Lock 位，确保基本硬件防读。
2. 软件级：固件片段加密与自解密执行
- 将核心算法代码段提取出来，以 XOR 或 AES 混合方式加密；
- 在启动后由 bootloader 解密加载至 RAM，再跳转执行；
- 即便整段固件被导出，关键逻辑也无法直接执行。
3. 设备绑定：硬件信息 + 固件校验码组合
- 每台设备写入唯一 SN 与芯片 UID 绑定，固件运行时必须验证一致；
- 固件中加入 CRC 校验逻辑与版本检测机制，非法升级直接拒绝执行。
4. Bootloader + OTA 更新机制
- 自研 Bootloader 实现安全升级通道；
- 加入数字签名认证机制，仅允许受信固件镜像写入；
- 所有更新包加入时间戳、版本号、签名等验证字段，拒绝“低版本覆盖”与“恶意包注入”。
实战经验总结：防住9成的“小白复制”，也要提防1成的“灰帽高手”
这套机制运行两年多，虽然不能说“百分百安全”，但至少能防止大多数复制行为，尤其是通过烧录器一键导出重烧的“小白式”抄袭。
当然，我们也尝试过更激进的防护方式，比如代码混淆、执行跳转链、甚至通过控制 GPIO 驱动“软炸*”（非法固件触发 IO 重置系统），但这些方式往往会带来维护困难或设备误报，最终被逐步取舍。
我们始终认为，保护措施应当“足够安全 + 可维护 + 不影响设备运行稳定性”。如果一套加密机制让开发和升级流程复杂十倍，反而会伤害产品本身。
固件安全无小事，护码如护命。希望本文能引发更多 MCU 开发者的共鸣与讨论，也希望我们在创新之余，也能守住代码的尊严与价值。 | 
楼主
标题置顶
标题高亮
