单片机固件提取与逆向分析：从调试接口到侧信道攻击的工程实践

1. 固件提取与逆向的底层逻辑拆解

1.1 为什么“破解”这个词在嵌入式圈子里其实是个中性词

刚入行那会儿，听到“破解单片机固件”这几个字，第一反应就是搞破坏、抄板子、盗代码。后来在产线上摸爬滚打几年才明白，固件提取和逆向分析在正经工程里出现的频率，远比想象中高得多。产品要做竞品分析、老设备要维护但原厂已经跑路、自己画的板子烧录后忘了留源码备份、二手设备要解绑或者恢复出厂设置，这些场景都需要把固件从芯片里“请”出来看看里面到底装了什么。

所以这里说的“破解”，准确讲应该叫固件提取与逆向分析。它的核心目标不是搞破坏，而是搞清楚三件事：芯片里跑的是什么、数据存在哪里、保护机制是怎么设计的。只有把这三件事摸透了，你才能决定下一步是直接读、绕过保护读、还是从外部信号里抓。

从技术路径上分，单片机固件的获取方式大致可以归为四类：调试接口直读、Bootloader协议利用、侧信道与故障注入、存储介质离线读取。这四类方法覆盖了从最基础的STC单片机到带安全启动的ARM Cortex-M系列，难度从“插上线就能读”到“需要电子显微镜和激光切割机”不等。下面我会把每一类的原理、适用场景、实操步骤和踩坑经验逐一拆开讲。

1.2 读保护机制到底在保护什么

在动手之前，必须先理解芯片厂商设计的保护机制。以常见的STM32为例，它的读保护（RDP）分为Level 0、Level 1、Level 2三个等级。Level 0就是完全不保护，用ST-Link直接就能把Flash内容读出来。Level 1会禁止通过调试接口读取Flash，但SRAM和寄存器还能访问，而且可以通过整片擦除的方式降回Level 0——代价是Flash内容全丢。Level 2则是永久性保护，一旦设置就再也无法通过任何调试接口访问，连整片擦除都不行。

很多新手会问：那我直接降级不就行了？问题就在于，Level 1降级会触发Mass Erase，你想要的固件在降级完成的瞬间就被擦干净了。所以针对Level 1的保护，常规思路是在降级之前先把SRAM里的关键数据抓出来，或者利用Bootloader的漏洞在擦除前跳转到用户代码。这些操作需要配合特定的时序和电压控制，后面会详细展开。

另一个常见误区是认为“读了保护就绝对安全”。实际上，很多国产单片机（比如某些STC型号）的读保护只是通过ISP下载软件层面做了限制，芯片本身并没有硬件熔丝。这种情况下，用第三方的编程器或者自己写时序就能绕过。所以判断保护类型是第一步，选错方法后面全是白费功夫。

1.3 方法选型决策树：从芯片型号到最优路径

面对一块未知的单片机板子，我通常会按下面的顺序做判断：

这个决策树的核心逻辑是：从成本最低、破坏性最小的方法开始试，逐步升级到需要拆焊、打磨、化学腐蚀的手段。很多时候，一块板子的调试接口根本没禁用，只是被外壳挡住了或者引脚没引出，飞两根线就能解决，根本用不着上高级设备。

2. 调试接口直读与Bootloader利用实操

2.1 SWD/JTAG接口的识别与连接

SWD接口是ARM Cortex-M系列最常用的调试接口，只需要SWCLK和SWDIO两根信号线加上GND和VCC就能工作。识别方法很简单：用万用表蜂鸣档测板子上的测试点，找到与芯片对应引脚导通的焊盘。常见封装下，SWCLK通常在PA14（STM32）或PA14（GD32），SWDIO在PA13。如果丝印被磨掉了，可以查同型号芯片的Pinout图，或者用示波器看上电瞬间哪个引脚有周期性脉冲。

连接时有个细节容易被忽略：调试器的电平必须与目标板一致。3.3V的STM32用5V的J-Link直接怼，轻则通信失败，重则烧毁调试口。我一般会先用万用表确认目标板的工作电压，然后选择对应的电平跳线。另外，如果目标板有低功耗设计，调试接口可能在上电后被软件关闭，这时候需要在复位释放后的极短时间内连接，或者用“Connect under Reset”模式。

实操步骤（以STM32+OpenOCD为例）：

# 1. 安装OpenOCD和对应驱动 sudo apt install openocd # 2. 编写配置文件stm32f1.cfg source [find interface/stlink.cfg] transport select hla_swd source [find target/stm32f1x.cfg] reset_config srst_only # 3. 启动OpenOCD openocd -f stm32f1.cfg # 4. 另开终端连接telnet telnet localhost 4444 # 5. 读取Flash内容 dump_image firmware.bin 0x08000000 0x10000

如果遇到“Target not halted”或者“Read protected”的报错，说明读保护已经生效。这时候不要急着放弃，先试试stm32f1x unlock 0命令，它会触发整片擦除并解除保护。虽然原固件没了，但至少芯片可以重新烧录。如果连解锁都失败，那就得考虑下面要讲的Bootloader方法了。

2.2 利用系统Bootloader读取Flash的骚操作

STM32系列在出厂时预置了一段系统Bootloader，存放在独立的信息块中，用户无法擦除。这段代码支持通过UART、CAN、USB、I2C等接口进行固件更新。关键在于：系统Bootloader的读保护检查逻辑与调试接口是独立的。在某些早期型号（如STM32F103）上，即使RDP设为Level 1，系统Bootloader仍然可以读取Flash内容并通过串口发送出来。

具体操作流程：

1. 将BOOT0引脚拉高，BOOT1拉低，复位芯片进入系统存储器启动模式。
2. 用USB转TTL连接芯片的USART1（通常是PA9/PA10）。
3. 使用官方Flash Loader Demonstrator或者开源的stm32flash工具。
4. 尝试执行读操作，如果返回数据正常，说明漏洞存在。

# 使用stm32flash读取 stm32flash -r firmware.bin -S 0x08000000:0x10000 /dev/ttyUSB0

这个方法的成功率取决于芯片型号和Bootloader版本。ST在后期的芯片中修补了这个漏洞，所以新片子基本行不通。但如果你面对的是老设备，这招值得一试。我去年修一台2012年的工业控制器，就是靠这个方法把原厂固件完整读出来的，省了买新设备的钱。

2.3 ISP下载协议的逆向与重放

很多国产单片机（STC、GD、中颖等）使用厂商自研的ISP协议，通过串口进行下载和校验。这些协议通常没有加密，只是做了简单的校验和。用逻辑分析仪抓一次正常下载的波形，就能把协议格式分析清楚。

以STC单片机为例，它的ISP协议流程大致是：

• 上位机发送同步字节0x7F
• 单片机回复握手信息（芯片型号、固件版本）
• 上位机发送擦除命令
• 逐帧发送数据，每帧包含地址、长度、数据和校验
• 最后发送校验命令

逆向的关键是找到读Flash的命令码。厂商的下载软件通常只开放了写和擦除，但芯片内部往往保留了读命令用于产线测试。通过枚举命令码（0x00到0xFF逐个尝试），有概率触发读操作。我试过在某款STC15上枚举出0x8E命令可以连续读取Flash，速度虽然慢，但胜在不需要拆焊。

注意：枚举命令码有风险，错误的命令可能导致芯片进入未知状态甚至锁死。建议先在废旧片子上做实验，确认安全后再上目标板。

3. 侧信道攻击与故障注入的工程化落地

3.1 电压毛刺攻击的原理与实操参数

电压毛刺（Voltage Glitching）是目前绕过读保护最常用的故障注入手段。原理是在芯片执行保护检查指令的瞬间，人为拉低核心电压，导致指令执行出错，从而跳过保护分支。听起来很玄乎，但用一块ChipWhisperer或者自己搭的MOSFET电路就能实现。

核心参数有三个：毛刺深度、毛刺宽度、触发时机。毛刺深度指电压被拉低到多少伏，通常从正常工作电压的50%开始试，逐步降低到30%。毛刺宽度在几十纳秒到几微秒之间，太窄没效果，太宽直接复位。触发时机最考验经验，需要结合芯片的启动时序，在保护检查代码执行的前后窗口内扫描。

我自己的实验数据（STM32F103，RDP Level 1）：

成功率不高，但通过自动化脚本反复尝试，一般几分钟内就能命中一次。命中后的现象是芯片没有触发Mass Erase，但调试接口可以正常读取Flash了。

3.2 时钟毛刺与电磁注入的适用场景

电压毛刺对电源设计敏感，有些板子有大量去耦电容，毛刺很难作用到核心。这时候可以尝试时钟毛刺：在芯片的外部晶振或者内部RC时钟上注入短脉冲，打乱指令流水线。时钟毛刺的好处是不需要控制电源，但需要精确知道芯片的时钟来源和频率。

电磁注入则是用线圈在芯片表面产生强磁场，干扰内部信号。这种方法设备成本高（需要高压脉冲发生器和精确定位台），但对付BGA封装和带有金属屏蔽罩的芯片特别有效。我见过有人用改造的相机闪光灯电路加手工绕制的线圈，成功绕过了某款汽车ECU的读保护，成本不到两千块。

提示：故障注入属于破坏性实验，操作不当可能永久损坏芯片。务必在目标板副本上先做验证，确认参数窗口后再上原板。

3.3 从SRAM残留数据中恢复固件

如果故障注入成功绕过了保护，但Flash读取仍然受限，可以转而读取SRAM。芯片复位后，SRAM中可能残留上一次运行时的代码片段或数据。通过调试接口反复复位并快速dump SRAM，有可能拼凑出完整的固件镜像。

具体做法是写一个脚本，控制调试器在复位释放后立即暂停内核，读取整个SRAM区域，然后重复几百次。每次读取的数据会有细微差异，通过比对和拼接，可以恢复出大部分代码。这个方法对Bootloader阶段的代码特别有效，因为那部分代码在每次启动时都会完整加载到SRAM中执行。

4. 存储介质离线读取与固件重组

4.1 SPI NOR Flash的夹取与拆焊读取

很多单片机系统会把固件存放在外部SPI NOR Flash中，比如W25Q系列。这种情况下，根本不需要碰单片机本身，直接读Flash芯片就行。如果板子上有SOIC-8或SOP-16封装的Flash，可以用测试夹（如Pomona 5250）在线读取，不需要拆焊。

在线读取的步骤：

1. 确认Flash的引脚定义（VCC、GND、CLK、MOSI、MISO、CS）。
2. 用测试夹连接Flash和编程器（如CH341A）。
3. 编程器软件选择对应型号，执行读取。
4. 如果读取失败，检查板子上是否有其他器件拉低了信号线，必要时断开单片机与Flash之间的连线。

在线读取的缺点是可能受到单片机干扰，导致数据不稳定。如果遇到校验错误，最稳妥的方法还是用热风枪把Flash吹下来，放到编程器上离线读取。拆焊时注意温度控制在350度以下，避免损坏焊盘和芯片。

4.2 BGA封装芯片的打磨与化学腐蚀

对于BGA封装的芯片，引脚在底部，无法直接飞线。这时候有两种选择：X光定位后打孔，或者化学腐蚀开封。X光定位需要设备，成本较高；化学腐蚀用发烟硝酸逐层去除封装材料，直到露出引线框架，然后用导电银胶引出引脚。

这个过程极其考验耐心和防护措施。发烟硝酸有强腐蚀性和毒性，必须在通风橱中操作，佩戴防酸手套和护目镜。我做过几次BGA开封，成功率大概七成，失败的主要原因是腐蚀过度导致引线断裂。如果芯片价值不高，建议直接放弃，换一块新板子更划算。

4.3 固件镜像的拼接与校验

从不同来源获取的固件片段需要拼接成完整镜像。常见的情况是：从调试接口读到了部分Flash，从外部Flash读到了文件系统，从SRAM残留中恢复了Bootloader。拼接时需要注意地址对齐和字节序。

我通常用binwalk做初步分析，识别出各个段的位置和类型：

binwalk -e firmware.bin

然后手动或用脚本按地址拼接：

# 简单的固件拼接示例 with open('bootloader.bin', 'rb') as f: boot = f.read() with open('app.bin', 'rb') as f: app = f.read() # 假设bootloader在0x08000000，app在0x08008000 firmware = bytearray(0x8000) firmware[0:len(boot)] = boot firmware[0x8000:0x8000+len(app)] = app with open('full_firmware.bin', 'wb') as f: f.write(firmware)

拼接完成后，用校验和或者已知的启动向量表验证完整性。如果芯片能正常启动，说明拼接基本正确。

5. 常见问题排查与避坑经验实录

5.1 连接失败与读保护误判

问题现象：调试器能识别到芯片ID，但读取Flash时报“Read protected”或者直接超时。

排查思路：

• 先确认是不是真的读保护。有些芯片在低功耗模式下会关闭调试接口，需要先唤醒。
• 检查复位电路。如果复位引脚被电容拉低太久，调试器可能来不及连接。
• 尝试降低调试速度。SWD在高速下对信号质量要求高，降到1MHz试试。
• 如果是国产芯片，确认调试器固件是否支持。某些型号需要厂商专用的调试器。

避坑技巧：我习惯在连接前先用示波器看SWCLK和SWDIO的上电波形。如果完全没有信号，说明调试接口被禁用了；如果有信号但通信失败，多半是电平或时序问题。

5.2 读取数据全为0xFF或0x00

问题现象：读取成功，但数据全是0xFF或0x00，没有有效内容。

原因分析：

• 0xFF通常表示Flash为空或者读取地址错误。
• 0x00可能是芯片处于复位状态，或者读取的是保留区域。
• 如果只有部分区域异常，可能是Flash有坏块或者读取过程中被中断。

解决方法：

• 确认起始地址是否正确。STM32的Flash通常从0x08000000开始，但有些型号有偏移。
• 检查芯片是否真的在运行。测量晶振是否起振，电源是否稳定。
• 尝试分段读取，每次读4KB，对比结果。

5.3 固件加密与混淆的识别

问题现象：读出的固件用反汇编工具打开后，代码逻辑混乱，大量无效指令。

原因分析：固件可能经过了加密或混淆处理。常见的保护手段包括：

• 代码压缩：启动时解压到RAM执行。
• 指令加密：每条指令与密钥异或。
• 控制流平坦化：打乱代码执行顺序。

应对策略：

• 先找解密函数。通常在启动代码的最前面，会有一段循环对Flash内容做异或或AES解密。
• 用动态分析工具（如QEMU）模拟执行，在解密完成后dump内存。
• 如果加密算法复杂，考虑从RAM中直接提取解密后的代码。

注意：分析加密固件时，务必在隔离环境中进行，避免恶意代码感染主机。我一般用虚拟机加快照，分析完直接回滚。

5.4 常见问题速查表

5.5 个人实操心得与工具推荐

干了这么多年，我最深的体会是：耐心比设备重要，记录比技术重要。每次操作前把芯片型号、保护状态、尝试的方法、参数、结果都记下来，失败的经验往往比成功的更有价值。我有个本子专门记这些，现在翻回去看，很多当年搞不定的问题，其实就是某个参数差了一点点。

工具方面，入门推荐ST-Link V2加OpenOCD，便宜且通用。进阶可以上J-Link，速度快且支持芯片多。故障注入入门用ChipWhisperer-Nano，几百块就能玩。逻辑分析仪必备，Saleae或者国产的DSLogic都行，抓协议分析问题离不开。

最后说一个容易被忽视的点：法律和道德边界。固件提取技术本身是中性的，但用在哪里决定了它的性质。分析自己的设备、做兼容性开发、恢复丢失的数据，这些都是正当需求。但未经授权提取他人商业产品的固件并用于复制生产，那就是另一回事了。技术人心里得有杆秤，知道什么该做什么不该做。

这个领域更新很快，新芯片的保护机制越来越强，但攻击手段也在进化。保持学习，保持敬畏，比掌握某个具体方法更重要。