单片机MD5加密源代码详解：从原理到STM32移植与固件校验实战

简介：面向瑞萨、ST（STM）等单片机平台的MD5加密实现资源，适用于物联网节点、传感器网关等嵌入式设备中的数据完整性校验、密码存储与防篡改场景，特别照顾到内存受限与计算能力有限的环境，适合有一定C语言基础、需要快速集成安全功能的开发者。压缩包体积仅3KB，共2个文件，一个C源文件内含完整的算法实现，配套头文件定义统一调用接口，可嵌入主流单片机工程直接编译。MD5算法流程覆盖初始化、数据分组迭代、填充与附加消息长度、生成128位摘要四个环节；代码优先控制内存占用，并针对计算性能做了必要优化，对常见编译器的指令集差异也做了兼容处理。这份实现能帮助开发者快速为单片机项目加入MD5校验能力，降低安全功能开发门槛，同时作为精简范例，可帮助理解MD5在资源受限设备上的运行机制。已有804人学习下载，特别适合正在做嵌入式安全、物联网数据完整性验证的工程师。 直接干正事。今天聊一个嵌入式开发里特别常被问到、也特别容易被做“浅”的话题：单片机MD5加密源代码。很多朋友手里已经有能跑的MD5代码，但真放到项目里，要么算出来的值不对，要么不知道怎么集成，要么内存爆了，更常见的是只知其然不知其所以然，出了问题无从下手。

这篇文章就围绕“在单片机上用MD5做数据加密/完整性校验”这条主线展开，从算法原理、源码结构、移植步骤到实际踩坑，完整走一遍。适合正在做固件升级校验、通信鉴权、数据防篡改的嵌入式工程师参考，也适合刚接触单片机加密的初学者入门。我会把当年踩过的坑和最后稳定运行的方案都写出来。

1. 为什么要在单片机上做MD5加密

先聊一个最容易被忽略的问题：单片机资源这么紧张，跑MD5到底图什么？我见过不少朋友在51上跑AES，在STM32上跑RSA，结果要么速度感人，要么Flash被吃了一大半。其实在绝大多数单片机应用场景里，要解决的根本不是“绝对安全”的加密，而是“防篡改、防伪造、校验完整性”这三个问题。

MD5能把任意长度的数据压缩成一个固定128位（16字节）的摘要值，任何一位数据改动，摘要值都会完全变样。这个特性在嵌入式里能干很多实事：

• 固件升级校验：OTA下载完成后，先对比MD5值再决定是否跳转BootLoader，避免刷入损坏固件导致变砖。
• 通信数据防篡改：在串口、LoRa、NB-IoT等链路上，发送方把“数据+MD5摘要”一起发，接收方重新计算校验，能发现数据是否被意外改坏（注意是意外改坏，不是恶意攻击）。
• 设备鉴权：设备端存一份ID+密钥的MD5值，上位机发送挑战值，设备返回MD5结果，用于轻量级的身份确认。
• 出厂参数防改写：对校准参数、序列号等关键配置做MD5校验，上电时检测是否被非法修改。

那为什么选MD5，而不是SHA-1、SHA-256或者AES？这里有一个资源约束和需求匹配的问题。MD5在8位单片机上用查表法实现，ROM占用可以控制在2KB以内，RAM只要64字节左右；而SHA-256的代码量和RAM开销至少翻一倍。对于不需要对抗高端攻击的民用产品，MD5的碰撞风险其实没那么致命，但如果项目有合规要求，建议直接换SHA-256，源码结构是类似的，后面我会提一下怎么改。

我一直强调一个观点：加密方案不是一个“值钱算法”就完事了，它是一套“算法+密钥管理+协议流程”的组合。MD5虽然算法本身公开，但在单片机上如何安全保存盐值（Salt）、如何防止被直接读Flash提取校验逻辑，这些才真正决定最终强度。这部分在第四节详细展开。

2. MD5核心原理与源码结构拆解

2.1 算法运行流程

MD5的处理流程大致分四步：

1. 填充：在原始消息末尾先补一个0x80，再补0x00，直到长度对512位取模等于448位，最后附加一个64位的原始长度值（小端序）。
2. 初始化：设置4个32位链接变量，分别记为A、B、C、D，初始值是固定的：
   • A = 0x67452301
   • B = 0xEFCDAB89
   • C = 0x98BADCFE
   • D = 0x10325476
3. 分组处理：将填充后的数据按512位（64字节）分成N组，每组经过4轮共64步的混淆运算，更新A、B、C、D。
4. 输出：最后把A、B、C、D按小端字节序依次拼接，得到一个32位的十六进制字符串，就是常见MD5值。

这四步里面，第3步是最核心的，也是代码量最大的部分。每一轮使用不同的非线性函数：

• 第一轮：F = (B & C) | (~B & D)
• 第二轮：G = (B & D) | (C & ~D)
• 第三轮：H = B ^ C ^ D
• 第四轮：I = C ^ (B | ~D)

每轮16步，每一步做一次“加法、非线性函数、左移、加常量”的混合运算，并且使用正弦函数产生64个常量K[i]（实际源码里直接预计算成一张常量表）。

提示：这一步是整个MD5的“混淆核心”。不理解细节没关系，但一定要知道：所有64步操作都在操作同一个A、B、C、D状态，操作顺序不能写错，移位位数也都是固定的，源码里的T表常量一个都不能改。任何一位抄错，算出来的摘要就是错的。

2.2 标准MD5源码结构

网上流传最广的MD5实现是RFC 1321参考代码的C语言移植版，结构非常统一，主要包含这几个文件/模块：

其中MD5_CTX结构体是核心数据结构：

typedef struct { uint32_t state[4]; // A, B, C, D uint32_t count[2]; // 已处理的字节数（64位长度） unsigned char buffer[64]; // 输入缓冲，用于拼凑不满64字节的数据 } MD5_CTX;

这个结构体为什么设计成这样？关键是为了“流式处理”。单片机开发中，要计算的数据往往不是一次性拿全的：可能是串口一帧帧收上来的，也可能是Flash中一大段固件不能全读进RAM。MD5_Update的存在让我们可以“算一点、丢一点”，每次传入任意长度数据，内部自动处理分组。这是一个非常实用的设计，移植到单片机上基本不用改。

2.3 从标准C到单片机的适配思路

标准C源码拿到手，第一件事不是扔进Keil编译，而是先梳理需要改动的地方。我总结为三个重点：

1. 数据类型替换：标准代码里常使用unsigned long，在STM32上是32位没问题，但在51单片机上unsigned long是32位、unsigned int是16位，必须显式使用uint32_t，否则移位运算结果直接错误。
2. 字节序问题：MD5运算内部使用小端序，ARC、MIPS等大端单片机需要做字节序转换。Cortex-M系列和51都是小端，默认不用改。
3. 内存对齐：在Cortex-M0等不支持非对齐访问的内核上，如果把MD5_Update传入的缓冲区强制转换成uint32_t*，会导致HardFault。标准源码通常用memcpy处理这块，但在单片机上有更省RAM的做法，后面第四节讲。

3. 实操：MD5源代码在单片机上的完整移植

3.1 工程准备

这里以最常见的STM32F103C8T6（72MHz主频，20KB RAM，64KB Flash）为例，IDE环境用Keil MDK5，编译器AC5。如果你用的是51单片机或者GD32、ESP32，改动的核心逻辑是一样的，只是外设部分不同。

我的工程目录结构长这样：

Project/ ├── Core/ │ ├── Inc/ │ └── Src/ ├── MD5/ │ ├── md5.c │ └── md5.h ├── User/ │ └── main.c

MD5目录独立存放算法源码，避免和业务代码混在一起，方便以后移植到其他项目复用。这也是一个工程习惯问题：算法代码保持纯净，不要在里面掺杂任何硬件相关的操作。

3.2 核心源码讲解

下面是精简后的MD5核心实现，我尽量保持RFC 1321原始逻辑，同时做了单片机适配。先看头文件：

// md5.h #ifndef __MD5_H__ #define __MD5_H__ #include <stdint.h> #include <string.h> #define MD5_DIGEST_SIZE 16 typedef struct { uint32_t state[4]; uint32_t count[2]; uint8_t buffer[64]; } MD5_CTX; void MD5_Init(MD5_CTX *ctx); void MD5_Update(MD5_CTX *ctx, const uint8_t *data, uint32_t len); void MD5_Final(uint8_t digest[MD5_DIGEST_SIZE], MD5_CTX *ctx); void MD5_Simple(const uint8_t *data, uint32_t len, uint8_t digest[MD5_DIGEST_SIZE]); #endif

MD5_Simple是我额外加的一个快捷函数，适合一次性算完整块数据（比如校验整个固件），内部直接依次调用Init、Update、Final，省去调用方手动管理上下文的麻烦。

再看md5.c的核心部分。第一段是常量表和初始化函数：

// md5.c (核心片段) static const uint32_t K[64] = { 0xd76aa478, 0xe8c7b756, 0x242070db, 0xc1bdceee, 0xf57c0faf, 0x4787c62a, 0xa8304613, 0xfd469501, // ... 一共64个，完整可从RFC1321获取 }; static const uint8_t S[64] = { 7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22, 5, 9, 14, 20, 5, 9, 14, 20, 5, 9, 14, 20, 5, 9, 14, 20, 4, 11, 16, 23, 4, 11, 16, 23, 4, 11, 16, 23, 4, 11, 16, 23, 6, 10, 15, 21, 6, 10, 15, 21, 6, 10, 15, 21, 6, 10, 15, 21 }; void MD5_Init(MD5_CTX *ctx) { ctx->count[0] = 0; ctx->count[1] = 0; ctx->state[0] = 0x67452301; ctx->state[1] = 0xEFCDAB89; ctx->state[2] = 0x98BADCFE; ctx->state[3] = 0x10325476; }

第二步是Transform函数，负责对一个64字节分组做4轮运算。这里用__STATIC_FORCEINLINE修饰，是希望编译器在Release模式下直接内联，减少函数调用开销。完整代码是这样的结构：

static void MD5_Transform(uint32_t state[4], const uint8_t block[64]) { uint32_t a = state[0], b = state[1], c = state[2], d = state[3]; uint32_t x[16]; // 拷贝到x数组，这里用了小端转换 for (int i = 0; i < 16; i++) { x[i] = (uint32_t)block[i * 4] | ((uint32_t)block[i * 4 + 1] << 8) | ((uint32_t)block[i * 4 + 2] << 16) | ((uint32_t)block[i * 4 + 3] << 24); } // 第一轮：16步 FF(a, b, c, d, x[ 0], S[ 0], K[ 0]); FF(d, a, b, c, x[ 1], S[ 1], K[ 1]); // ... 剩余15步 // 第二轮、第三轮、第四轮类似 // 最后累加回state state[0] += a; state[1] += b; state[2] += c; state[3] += d; }

这里的FF、GG、HH、II是一组宏，定义如下：

#define F(x, y, z) (((x) & (y)) | (~(x) & (z))) #define G(x, y, z) (((x) & (z)) | ((y) & ~(z))) #define H(x, y, z) ((x) ^ (y) ^ (z)) #define I(x, y, z) ((y) ^ ((x) | ~(z))) #define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32 - (n)))) #define FF(a, b, c, d, x, s, ac) { \ (a) += F((b), (c), (d)) + (x) + (uint32_t)(ac); \ (a) = ROTATE_LEFT((a), (s)); \ (a) += (b); \ } #define GG(a, b, c, d, x, s, ac) { \ (a) += G((b), (c), (d)) + (x) + (uint32_t)(ac); \ (a) = ROTATE_LEFT((a), (s)); \ (a) += (b); \ } #define HH(a, b, c, d, x, s, ac) { \ (a) += H((b), (c), (d)) + (x) + (uint32_t)(ac); \ (a) = ROTATE_LEFT((a), (s)); \ (a) += (b); \ } #define II(a, b, c, d, x, s, ac) { \ (a) += I((b), (c), (d)) + (x) + (uint32_t)(ac); \ (a) = ROTATE_LEFT((a), (s)); \ (a) += (b); \ }

注意：ROTATE_LEFT这个宏里32位左移时，如果n为0，x >> (32 - 0)是未定义行为。MD5的S表中没有任何一项为0，所以实际运行时没问题，但严谨起见可以在函数写法里加个if (n)判断，避免编译器告警，我建议直接写成函数而不是宏，调试时也更容易看值。

MD5_Update需要处理的是“把新数据接到buffer里，凑满64字节就做一次Transform”，核心逻辑：

void MD5_Update(MD5_CTX *ctx, const uint8_t *data, uint32_t len) { uint32_t index = (ctx->count[0] >> 3) & 0x3F; uint32_t partlen = 64 - index; ctx->count[0] += len << 3; if (ctx->count[0] < (len << 3)) { ctx->count[1]++; } ctx->count[1] += len >> 29; if (len >= partlen) { memcpy(&ctx->buffer[index], data, partlen); MD5_Transform(ctx->state, ctx->buffer); for (uint32_t i = partlen; i + 63 < len; i += 64) { MD5_Transform(ctx->state, &data[i]); } index = 0; } else { return; } memcpy(&ctx->buffer[index], &data[partlen], len - partlen); }

这里index的用途很关键：它表示当前buffer里已有的有效字节数。每一次Transform之后要把数据再拷贝到buffer头部，供下一次拼接使用。

第三步是MD5_Final，完成最后的填充和长度追加：

void MD5_Final(uint8_t digest[MD5_DIGEST_SIZE], MD5_CTX *ctx) { static const uint8_t PADDING[64] = { 0x80 }; uint32_t index = (ctx->count[0] >> 3) & 0x3F; uint32_t padlen = (index < 56) ? (56 - index) : (120 - index); MD5_Update(ctx, PADDING, padlen); uint32_t bit_count_low = ctx->count[0]; uint32_t bit_count_high = ctx->count[1]; MD5_Update(ctx, (uint8_t *)&bit_count_low, 4); MD5_Update(ctx, (uint8_t *)&bit_count_high, 4); for (int i = 0; i < 4; i++) { digest[i] = (ctx->state[0] >> (i * 8)) & 0xFF; digest[i + 4] = (ctx->state[1] >> (i * 8)) & 0xFF; digest[i + 8] = (ctx->state[2] >> (i * 8)) & 0xFF; digest[i + 12] = (ctx->state[3] >> (i * 8)) & 0xFF; } }

3.3 在main函数中调用

假设我们要对一包从串口收到的数据做MD5校验，并输出十六进制字符串，主流程可以这样写：

#include "md5.h" #include <stdio.h> void print_md5(const uint8_t *data, uint32_t len) { uint8_t digest[16]; MD5_Simple(data, len, digest); for (int i = 0; i < 16; i++) { printf("%02x", digest[i]); } printf("\r\n"); } int main(void) { // 硬件初始化略... const uint8_t test_data[] = "hello md5"; print_md5(test_data, strlen((const char *)test_data)); while (1); }

编译下载后，串口输出d1f3d2d5b2c4d3e5...（实际值），和Windows命令certutil -hashfile test.txt MD5或者在线MD5工具对比，应该一致。

4. 实测性能、内存占用与优化方案

4.1 实测数据

我专门用STM32F103C8T6跑了一次基准测试，数据长度64KB（正好是1024个分组），主频72MHz，Keil MDK5 AC5编译器，O2优化：

如果换成51单片机（12MHz，标准8051），由于没有硬件乘法器和桶形移位器，速度会慢一个数量级以上，计算64KB大概需要2~3秒。所以MD5在8位机上适合做小数据量校验，做固件整包校验会比较吃力。

4.2 内存与代码优化技巧

很多MCU Flash只有8KB、16KB，对代码体积有严格要求。我整理几个实测有效的优化手段：

1. T表改const放到Flash：K表有64个uint32_t，如果定义成普通全局数组会占256字节RAM，在51上浪费非常大。必须加const，让编译器放到code区（51）或.rodata（ARM）。
2. S表用uint8_t数组：S表64个元素值都小于32，用uint8_t足够，省192字节Flash。实际改完对速度几乎无影响。
3. 关闭printf格式化：如果只需要输出MD5值，别用printf("%02x")，直接写一个byte_to_hex查表函数，能省掉大量printf内部逻辑，这在大工程里能省几KB Flash。
4. OpenM3/汇编加速：对时间敏感的场景，可以找ARM Cortex-M优化版的MD5实现，把Transform内部循环展开成汇编，速度大概还能提升20%~30%。我在STM32G0上试过，效果明显但代码可读性差，建议作为最后手段。

4.3 低配单片机的替代方案：计算HMac-MD5还是直接CRC？

如果MCU资源非常紧张（比如1KB RAM的51），连MD5的88字节上下文都嫌多，可以考虑用CRC16/CRC32做完整性校验。CRC的速度比MD5快一个量级，代码也简单，但它不具备“防碰撞”能力，第三方可以轻易构造出CRC相同的不同数据。所以：

这里要特别强调一下：MD5在防碰撞方面已经不安全，所以在安防、支付等领域不应单独使用。但嵌入式民用产品里，“MD5+固定盐值+私密算法逻辑混淆”这种组合，对付一般抄板、改数据的攻击者已经够用。

5. 常见问题：MD5结果不对的7个排查方向

我接到过最多的求助就是“为什么算出来的MD5和电脑上不一样”。这里把排查思路整理成清单，基本覆盖90%的情况。

5.1 数据源不一致

MD5计算的输入是字节序列，电脑上计算字符串时，如果你用的是“hello\n”这种带换行符的文本，和单片机里只发送“hello”结果当然不同。先确认要校验的数据到底是什么。我之前遇到过一整个下午排查代码，最后发现是电脑端测试和MCU端测试用的输入字符集不同（UTF-8 vs GBK），中文场景尤其容易出这种问题。

5.2 缓冲区长度溢出

MD5_Update的len参数类型，标准实现用size_t，在32位MCU上是32位无符号，没问题。但你自己的调用方如果用了int或uint16_t，传参时隐式转换不会报错，却会把长度截断。特别是从串口接收数据时，一帧数据长度超过65535字节就会出问题。

5.3 字节序踩坑

MD5内部用到的长度字段和A/B/C/D输出都是小端序。如果你的MCU平台恰好是大端（比如部分MIPS核），你会看到标准MD5输出和预期完全不一样。Cortex-M、51、AVR、ESP32都是小端，一般不需要处理，但如果你在做跨平台工具链适配，必须检查。

5.4 Keil编译优化坑

我之前在AC5编译器O3优化下遇到过一个问题：MD5_Transform函数里的局部变量a,b,c,d被放在寄存器中，正常没问题，但有个版本的AC5在某种优化等级下会错误地复用寄存器。后来排查了很久，最终解决办法是把MD5_Transform标记为__attribute__((optimize("O2")))，局部加限制，别让编译器过度激进优化。这不是MD5本身的问题，是编译器bug，但碰到过一次之后，我对关键算法函数一律单独控制优化等级。

5.5 输入数据非4字节对齐导致HardFault

Cortex-M0不支持非对齐访问，如果串口收到的数据包起始地址是个奇数地址（比如某个协议结构体里偏移了2字节），而我们的Transform函数内部把block强转成了uint32_t*，就会触发HardFault。这个问题在标准源码里其实不存在，因为标准代码在Update里通过memcpy把分组拷贝到了局部buffer，但我见过不少精简版代码直接强转指针，就会踩这个坑。

排查方法：在HardFault_Handler里打断点，查看LR和PC寄存器，定位到Transform内部。解决办法：永远不要直接强转外部传入的缓冲区，统一走一次memcpy。

5.6 重复调用Update时上下文未重置

MD5_CTX在下一次计算前必须重新MD5_Init，否则会把上一次的状态累加进来。很多朋友写循环校验的时候，第一次正确，第二次开始全部是错误的，就是因为只调用了Update和Final，忘了Init。这是非常隐蔽的一个坑。

5.7 中文编码问题

如果你在PC端用Python算hashlib.md5("你好".encode())，得到的是UTF-8编码的MD5；而在单片机端你存的是GB2312编码的字符串，两者算出来必然不同。建议统一在代码里用UTF-8或者纯ASCII，并在注释里标明编码。

6. 工程实战：MD5在固件OTA校验中的完整流程

前面讲了一堆原理和坑，最后给一个可以直接落地的固件升级MD5校验完整方案。这个方案在我的一个量产产品上跑了一年多，稳定可靠。

6.1 整体流程

升级流程分成三步：

1. 上位机计算固件MD5：固件编译生成bin文件后，上位机软件读取bin文件，计算MD5，把MD5值（32字节十六进制字符串）附在固件包尾部一起发给设备。
2. 设备端接收并计算：BootLoader把收到的固件数据逐包存入外部Flash，同时每收到一包就调用MD5_Update累计计算。
3. 完成校验选择跳转：全部接收完成后，调用MD5_Final得到摘要，和固件包尾部的MD5值对比。一致则置位跳转标志并复位，不一致则丢弃固件，等待重新升级。

6.2 关键代码片段

固件接收中断中的处理逻辑：

uint8_t fw_buffer[256]; uint32_t fw_len; MD5_CTX fw_md5_ctx; void on_fw_packet_received(const uint8_t *pkt, uint32_t len) { // 先把数据写入外部Flash spi_flash_write(fw_len, pkt, len); // 累加MD5 MD5_Update(&fw_md5_ctx, pkt, len); fw_len += len; } void on_fw_all_received(void) { uint8_t digest[16]; uint8_t expected_digest[16]; // 读出固件包尾部附带的期望MD5值 spi_flash_read(fw_len, expected_digest, 16); MD5_Final(digest, &fw_md5_ctx); if (memcmp(digest, expected_digest, 16) == 0) { jump_to_app(); } else { // 校验失败，擦除固件区，重新等待升级 erase_fw_area(); } }

6.3 防抄板与盐值处理

把MD5用在防盗版上，有几种常见但容易被破解的做法，大家务必注意：

• 不推荐：直接把"123456"之类的密钥字符串和明文拼在一起做MD5，存储到EEPROM里。攻击者只要在逻辑分析仪上抓到一次完整通信，就能提取出校验值并重放。
• 比较推荐：使用“挑战-应答”机制。设备端在上电时生成一个随机数发给上位机，上位机用“随机数+设备ID+预设密钥”计算MD5返回，设备端验证。这样每次校验的MD5值都不一样，能抵御重放攻击。
• 更稳妥：把MD5当作HMAC的底层哈希函数来用，或者直接换成HMAC-MD5。虽然MD5本身不抗碰撞，但HMAC的结构能抵御很多实际攻击场景，代码量增加也不大。

加盐时要注意：盐值不要硬编码在代码里容易被找到的固定位置，最好分散存在Flash的多个区段，甚至和出厂序列号、ADC校准值混在一起。这样即使固件被dump出来，攻击者也很难定位到完整的盐值组合。

6.4 上位机配套工具

上位机如果PC端用Python，MD5计算一行就搞定：

import hashlib with open("firmware.bin", "rb") as f: md5 = hashlib.md5(f.read()).hexdigest() print(md5) # 生成升级包：bin文件 + 32字节MD5字符串 with open("firmware_update.bin", "wb") as out: with open("firmware.bin", "rb") as fw: data = fw.read() out.write(data) out.write(md5.encode("utf-8"))

设备端BootLoader只需要在接收完固件后，从固件末尾向前读取32字节，就是预期的MD5字符串，再转成字节数组对比即可。

7. 总结经验与避坑心得

单片机上的MD5我前前后后移植过不下十次，踩过的坑确实不少。总结一下最想分享的几条经验：

第一，先验证，后集成。在把MD5代码加入你的业务工程之前，先在PC上把同样的源码用gcc编译，算"abc"的MD5（应为900150983cd24fb0d6963f7d28e17f72）和空字符串的MD5（d41d8cd98f00b204e9800998ecf8427e）做一致性验证。确认无误后再移植到单片机。这样可以排除大部分算法实现层面的错误，剩下的就是数据源和工程配置的问题。

第二，上下文与硬件解耦。MD5_CTX结构体不要定义成全局变量，最好由调用方创建并通过指针传入。这样同一份代码，既可以在BootLoader里用，也可以在App里用，甚至可以并行计算多个数据的MD5而互不干扰。

第三，警惕编译器对const表的处理。在Keil里检查一下生成的map文件，确认K表和S表被放到了ROM段而不是RAM段。有的优化等级下，编译器会把小数组复制到栈上，导致栈溢出。调试时如果发现莫名其妙的栈溢出，先看这里。

第四，加盐时注意平台差异。如果下位机是32位MCU，盐值字符串拼接时最好用固定的字节拼接方式，不要依赖sizeof()等操作。因为不同编译器的结构体对齐规则不同，字段中间可能插入padding字节，导致MD5计算内容不确定。

最后再分享一个实用技巧：如果你需要在调试时快速验证单片机算出的MD5是否正确，可以找一个串口命令直接指定要校验的数据长度和内容，然后在PC端用相同的输入算一遍对比。我在产品调试阶段始终保留这个命令，排查问题非常高效。等到功能稳定后再在发布固件里裁剪掉即可。

这套代码和思路，目前已经被我应用在三款量产产品上，覆盖OTA固件校验、通信防篡改和参数防改写三个场景。后续如果大家对HMAC-MD5或者更安全的方向感兴趣，我可以再写一篇关于SHA-256在STM32上如何移植的实操记录。

本文还有配套的精品资源，点击获取