STM32内存扫描：SWD/DAP调试通路与变量定位实战-平芜编程栈

简介：这是一份面向嵌入式开发与逆向调试学习者的驱动级 Cheat Engine 工具包，侧重解决 Windows 驱动保护环境下的内存访问查看、断点调试与进程分析问题，也可配合 STM32、ARM 相关实验理解底层调试链路。压缩包共 330 个文件，约 14.67MB，类型覆盖 98 个 C/C++ 头文件、50 个 po 本地化文本、43 个 Lua 脚本、29 个 DLL、11 个 C++ 源文件，以及 exe、frm、png、txt、sln 等可运行组件、界面资源、说明文档和工程配置。资源还保留 lib、exp、sig、dat 等编译与运行辅助文件，便于复现实验环境、排查依赖问题。可运行程序、源码工程、脚本与文档相互配套，方便读者从界面操作、脚本调用到底层驱动交互逐层对照，目录层次也便于按模块检索。已有 2995 人学习下载，适合具备一定 Windows 底层与单片机基础、希望深入理解调试器实现与驱动交互的中高级学习者。

1. 在 PC 上给内存扫描工具挂一条能直接读写目标内存的通路，行话里叫“驱动”；做出来的形态就是 CE 那类工具的内核部分。把这套思路原样搬到 stm32 这类 arm 单片机上，通路的形态完全变了：没有进程、没有虚拟地址、没有页保护，取而代之的是一条 SWD 两线、一个 DAP、一个挂在 AHB 总线上的 MEM-AP 地址窗口。所以嵌入式语境里的“驱动 CE”，真正要回答的只有一件事——怎么让上位机在单片机跑着或者被摁停的时候，稳定地读出一段 RAM，再写回去，并且知道自己在读哪个变量。这套东西适合手上已经有 arm 调试探针、又想把固件里的中间量、状态机变量、缓冲区内容翻出来看的嵌入式硬件工程师，也适合从 PC 侧内存调试转过来、第一次碰 Cortex-M 的人。

2. 访问通路拆解：SWD、DAP 与 AHB-AP 是怎么把 4 个字节搬进 RAM 的

在写任何脚本之前，得先搞清楚这条通路上到底有哪几层。搞不清楚层级，后面所有“读出来全是 0”“读出来全是 0xFFFFFFFF”的怪现象都只能靠猜。Cortex-M 的调试访问是一条严格分层的链路：物理层是 SWD 或 JTAG，协议层是 DAP 里的 DP 和 AP，总线层是 MEM-AP 翻译出来的 AHB 读写事务，最后才落到芯片内部的 SRAM 或外设寄存器上。每一层都有可能断，断在不同层，表现出来的症状完全不一样。

2.1 两线时序与 DP/AP 的分层

SWD 只用两根线：SWCLK 和 SWDIO，外加必须共地的 GND 和一根参考电平 VTref。它的报文是打包的，一个 8 位的请求头，跟着 ACK 和若干数据周期，由 SWCLK 同步。这条链路上最容易翻车的是线长和上拉。常见的杜邦线飞 20 厘米以上、SWCLK 跑到 4 MHz 以上，读回来的数据偶尔错一位，表现出来的现象就是扫描结果里随机冒出几个不像话的地址。血泪经验是：先用低频跑通，再逐步往上提。

DAP 这一层拆成 DP（Debug Port）和 AP（Access Port）。DP 管的是调试口本身的状态，比如上电、复位、选择当前要访问哪个 AP；AP 才是真正挂到芯片内部的窗口。Cortex-M 上一般至少有一个 AHB-AP，它把 AP 的寄存器操作翻译成对系统总线的读写，这就是为什么你往 AP 的 DRW 里写一个值，最终会出现在 0x20000000 那块 SRAM 上。有的芯片还会多出 APB-AP，专门访问调试组件（CTI、ETM 之类），做普通变量扫描时基本用不到。

理解这一点很关键：上位机工具从来没有“直接访问内存”的能力，它只能往 AP 寄存器里写地址和数据，剩下的由硬件完成。所有的读写延迟、对齐要求、批量效率问题，根源都在这一层。

2.2 AHB-AP 的 CSW、TAR、DRW 三个寄存器

AHB-AP 上真正干活的就三个寄存器，这是整条链路的核心黑匣子：

寄存器	作用	关键位
CSW	控制/状态字，决定传输宽度和自增方式	Size[2:0] 选 8/16/32 位，AddrInc 选单次或自增
TAR	目标地址寄存器，放要访问的 32 位地址	直接写物理地址
DRW	数据读写寄存器，读它触发一次总线读，写它触发一次总线写	读写后 CSW 的 WDATAERR/STICKYERR 会置位

一段典型的传输流程是：写 TAR 设定地址，写 CSW 设定 32 位宽、单次传输，然后读或写 DRW。如果 CSW 里开了地址自增（AddrInc = 0b01），那么每访问一次 DRW，TAR 自动 +4，连续读 DRW 就能把一整块 RAM 顺序搬出来。这就是“块读”比“逐字读”快一个数量级的原因——省掉的是每次重新设地址的开销。

还有一个细节值得记住：CSW 里的 STICKYERR 一旦置位，说明上一次访问在总线上出错了（比如地址没映射、访问了被保护的区域），这个位是粘滞的，不清掉后面所有访问都会报错。很多工具读越界地址之后“再也读不出东西”，就是没清这个位。

2.3 用 OpenOCD 验证通路是否真的打通

在写 Python 脚本之前，先用 OpenOCD 把自己手上的探针和目标板跑通，这一步能把“工具问题”和“板子问题”彻底分开。

# 以 CMSIS-DAP 探针 + 某 F4 系列目标为例 # interface 选探针类型，target 选芯片系列，两个 cfg 缺一不可 openocd -f interface/cmsis-dap.cfg \ -f target/stm32f4x.cfg \ -c "adapter speed 1000" \ -c "init; reset halt"

启动成功会看到两个端口在监听：3333 给 GDB 用，4444 是 telnet 命令行。先用 telnet 直连，绕开 GDB 这层中间件：

telnet localhost 4444 > reset halt > mdw 0x20000000 8 > mww 0x20000000 0x12345678 > mdw 0x20000000 1

mdw是 memory display word，按 32 位读并打印；mww是 memory write word。第二条命令写完立刻回读，如果读回来的不是 0x12345678，那问题一定在硬件链路或目标状态上，跟你的扫描算法没有半点关系。

提示：reset halt之后 CPU 停在复位向量，此时 SRAM 里是上一次运行的残留内容，不是全 0。如果你看到一片 0x00，先怀疑是 halt 没生效、CPU 还在跑，或者读的地址压根没映射。

到这里，通路的物理层和协议层就算验证完了。剩下的事情才是“往哪个地址读、读多少、怎么判断读到的值有意义”，那是软件层面的活。

3. 环境搭建：OpenOCD、GDB、pyOCD 三件套的可复现配置

OpenOCD 适合手动验证和排错，但做扫描这种需要循环几百上千次的操作，得靠脚本。pyOCD 是纯 Python 实现，直接调 libusb 跟探针通信，不用挂后台进程，做批量和自动化最顺手。GDB 则介于两者之间，适合单点精确定位和符号级调试。三件套各管一段，不要指望一个工具干完所有事。

3.1 接口配置与 target 选择：一行 cfg 决定成败

OpenOCD 的配置分两半：interface/*.cfg描述探针，target/*.cfg描述芯片。前者决定用什么协议跟探针说话，后者决定芯片的 Flash 算法、内存映射、复位方式。

最常踩的坑是 target 选错系列。同一个厂商的不同系列，Flash 起始地址、SRAM 大小、复位行为都可能不同。选了一个 SRAM 只有 64K 的 target 去读 128K 的边界，后半段读回来的全是总线错误。稳妥的做法是显式写死自己要读的范围，不依赖 cfg 里的默认值：

# 显式声明扫描范围，避免依赖 target cfg 的默认内存映射 openocd -f interface/cmsis-dap.cfg -f target/stm32f4x.cfg \ -c "adapter speed 2000" \ -c "init" \ -c "reset halt" \ -c "echo {RAM start = 0x20000000, size = 128K}"

adapter speed的单位是 kHz，写 2000 就是 2 MHz。长排线降到 1000 以下更稳。这个参数在批量扫描时值得单独调，因为它直接决定全 RAM 快照的耗时。

3.2 GDB 侧的内存读写与 halt 时机

GDB 的价值在于它能解析符号，能设断点和观察点，还能在 halt 状态下精确地读一个变量。

# 连上 OpenOCD 暴露的 gdb server target extended-remote :3333 monitor reset halt # 按符号读，前提是加载了带调试信息的 elf file build/firmware.elf print g_state print &g_state # 按地址读一段，x 后面跟数量、格式、单位 x/16xw 0x20000000 # 直接写一个 32 位值回去 set {unsigned int}0x20000000 = 0xDEADBEEF

monitor开头的命令是透传给 OpenOCD 的，不归 GDB 管。monitor reset halt是复位并停机，monitor reset run是复位后继续跑。这两条的区别在扫描场景里极其重要：CPU 在跑的时候读内存，读到的是一个撕裂的快照，可能出现半新半旧的 64 位变量；先 halt 再读，才能拿到一致的视图。

x/16xw里的三段分别表示数量 16、十六进制、字（4 字节）。想按字节看就换成xb，按半字就xh。这个命令在用得顺手之后，排查“这个结构体到底占多少字节”非常快。

3.3 pyOCD 脚本化：把读写做成可循环的函数

批量扫描必须脚本化。下面这段是最小可运行版本，做三件事：连上探针、复位停机、把整块 RAM 一次性读出来。

from pyocd.core.helpers import ConnectHelper # options 里的 frequency 是 SWD 时钟，单位 Hz session = ConnectHelper.session_with_chosen_probe(options={"frequency": 2000000}) session.open() target = session.target RAM_START = 0x20000000 RAM_SIZE = 128 * 1024 # 按实际型号改，小容量型号可能只有 64K RAM_WORDS = RAM_SIZE // 4 # 复位并停在复位向量，保证 RAM 内容处于一致状态 target.reset_and_halt() # 块读：一次事务搬一整段，比逐字读快一个数量级 words = target.read_memory_block32(RAM_START, RAM_WORDS) print("first word:", hex(words[0])) print("total words:", len(words)) session.close()

参数上有三点值得说明。frequency设 2 MHz 是个折中值，探针质量好、排线短可以提到 4 MHz 以上，读全 128K RAM 的时间能从几百毫秒压到一百毫秒出头。read_memory_block32的第二个参数是字数量而不是字节数，写错一个倍数就会读到越界地址，然后触发粘滞错误。reset_and_halt之后再读，读到的是复位时刻的 RAM，如果目标是热复位（不掉电），SRAM 内容会保留，这时候读到的其实是上一次运行的现场，做差分扫描时要特别注意这一点。

3.4 目标端要配合：留一个不会被优化掉的观测变量

扫描算法再好，目标端没留观测点也是白搭。编译器优化会把只写不读的变量直接删掉，把频繁访问的变量提到寄存器里，你在 RAM 里根本找不到它。

/* 强制放到 RAM、禁止优化掉、禁止被塞进寄存器 */ static volatile uint32_t g_probe_a __attribute__((used, section(".data"))); static volatile uint32_t g_probe_b __attribute__((used, section(".data"))); /* 一个中等复杂度的结构体，用来练结构体定位 */ typedef struct { uint16_t id; uint16_t flags; uint32_t counter; uint8_t payload[16]; } probe_record_t; volatile probe_record_t g_record __attribute__((used)); void probe_update(void) { static uint32_t tick; tick++; g_probe_a = tick; g_probe_b = tick * 3u; g_record.counter = tick; g_record.flags = (uint16_t)(tick & 0xFFFFu); }

volatile保证每次访问都真的走内存，编译器不会把它缓存进寄存器；__attribute__((used))保证链接器不因为“没被引用”把它扔掉。这两个属性少一个，扫描结果里就少一个目标。用-O0编译也能达到类似效果，但那不是长久之计，工程里不可能为了调试把优化全关掉。

目标端准备好之后，RAM 里就至少有了三个已知形状的观测点：两个 32 位标量、一个带固定字段排列的结构体。后面所有扫描技巧，都是拿这几个已知答案去验证方法对不对。

4. 内存扫描落地：从全 RAM 快照到变量地址收敛

有了通路和环境，扫描本身反而变成最机械的一步。核心思想跟 PC 上那类工具完全一致：先拍一张全量快照，让目标改变某个值，再拍第二张，取差集。区别在于嵌入式里 RAM 小、快照便宜，可以直接全量对全量，不需要那套分代扫描的复杂结构。128K 的 RAM 一次快照几百毫秒，扫三轮也就一两秒，效率压力远没有 PC 侧那么大。

4.1 首次快照：读全 RAM 的边界与耗时

第一次快照的目的是拿到基线。这里有个容易忽略的前提：快照必须在 CPU 停机状态下拍，否则你拍到的是一张正在被改写的画面。

import time from pyocd.core.helpers import ConnectHelper RAM_START = 0x20000000 RAM_SIZE = 128 * 1024 def take_snapshot(target, start=RAM_START, size=RAM_SIZE): """停机拍一张全 RAM 快照，返回 32 位字列表""" target.halt() t0 = time.time() data = target.read_memory_block32(start, size // 4) cost = (time.time() - t0) * 1000 print("snapshot: %d words, %.1f ms" % (len(data), cost)) return data session = ConnectHelper.session_with_chosen_probe(options={"frequency": 2000000}) session.open() target = session.target target.reset_and_halt() base = take_snapshot(target) print("非零字数量:", sum(1 for w in base if w != 0))

“非零字数量”这个统计很有用。复位后如果这个数字接近 0，说明你的目标板压根没跑起来，或者读的地址范围不对；如果它接近总字数的三分之一，说明 RAM 里堆了东西，可以继续。这个数字在每次换板子、换工程时都值得看一眼，属于成本极低的自检。

耗时打印出来是为了建立体感。2 MHz 下读 128K 通常在 300 到 600 毫秒之间，如果飙到好几秒，八成是探针时钟没生效，或者块读被拆成了单字循环。

4.2 变动过滤：两次快照做 diff

有了基线，让目标跑一小段，再拍第二张，然后逐字比。

def diff_snapshots(old, new, start=RAM_START, max_hits=64): """逐字比对两次快照，返回 (地址, 旧值, 新值) 列表""" hits = [] for i, (a, b) in enumerate(zip(old, new)): if a != b: hits.append((start + i * 4, a, b)) if len(hits) >= max_hits: break return hits target.resume() time.sleep(0.5) # 让固件跑一会儿，产生变化 snap2 = take_snapshot(target) hits = diff_snapshots(base, snap2) for addr, old, new in hits[:20]: print("0x%08X: 0x%08X -> 0x%08X" % (addr, old, new))

max_hits是个实用参数。不设上限的话，一个正在跑 RTOS 的目标可能有几千个地址在变——栈指针附近、堆管理结构、各种计数器，全打出来根本看不过来。先限制到 64 条，看快速浏览一下模式，再决定要不要放开。

比完之后你会发现，变化最剧烈的一般是栈区。栈上全是局部变量和函数返回地址，每次调用都在动。真正有价值的全局变量往往混在中间，变化幅度小、地址固定。怎么把它们挑出来？靠第二轮。

4.3 从地址到结构体：按步长和类型二次收敛

两轮 diff 之后候选地址会少很多，但仍然不够。第二轮的策略是：让目标再跑一次，用相同的候选地址集合重新比对，把“只变了一次”的噪声过滤掉。

# 第三张快照，仍然只保留之前命中的地址 target.resume() time.sleep(0.5) snap3 = take_snapshot(target) candidates = [addr for addr, _, _ in hits] still_hit = [] for addr in candidates: idx = (addr - RAM_START) // 4 if snap2[idx] != snap3[idx]: still_hit.append((addr, snap2[idx], snap3[idx])) print("连续两轮都在变:", len(still_hit), "/", len(candidates))

连续两轮都在变的地址，基本就是真正的计数器或者状态变量了。这时候再回头对照固件里那几个volatile观测点，验证方法是否有效——如果你读到的地址跟&g_probe_a完全一致，说明整条链路是干净的；如果不一致，先别怀疑算法，去看编译产物里的符号地址。

结构体的定位稍微麻烦一点。思路是先找到其中一个字段的地址，然后按已知的结构体布局反推起点。比如你发现某个地址每 500 毫秒 +1，而结构体里counter在偏移 4 的位置，那么结构体起点就是该地址 - 4。往下再验证flags是否等于counter & 0xFFFF，两个字段都对得上，基本可以确认。

def find_struct_base(hit_addr, field_offset, ram_start=RAM_START): """由字段地址反推结构体起始地址""" return hit_addr - field_offset

这个函数简单到只有一行，但它代表了扫描工作的收尾动作：从“一个在变的地址”变成“一个我能解释的结构”。

4.4 硬件观察点：DWT 比较器的正确用法

扫描是被动的，得反复拍快照。硬件观察点是主动的：只要 CPU 访问了某个地址，立刻停下来或者打标记。这在追“谁改了这个变量”的时候无可替代。

Cortex-M 的数据观察点靠 DWT（Data Watchpoint and Trace）里的比较器实现。不同内核数量不一样，M3/M4 上通常有 4 个，M0+ 上少一些甚至没有，具体要看芯片对应的参考手册。用之前必须先开 TRCENA：

/* 在固件侧配置：DWT 比较器 0 监控对 g_record.counter 的写访问 */ CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; /* 总开关，不开后面全白搭 */ /* COMP0 放目标地址，低两位必须清零（按字对齐） */ DWT->COMP0 = ((uint32_t)&g_record.counter) & ~0x3u; DWT->MASK0 = 0; /* 0 表示精确匹配全部 32 位 */ DWT->FUNCTION0 = 0x6u; /* FUNCTION=0b0110：数据写访问命中时产生调试事件 */

FUNCTION0 = 0x6这个值是按 Cortex-M3/M4 的 DWT 定义写的，0b0110 表示“数据地址写匹配”。改成 0b0101 就是只监控读，0b0111 是读写都管。写错成 0b0001 的话只会产生 trace packet，不会停下来，现象就是“设了观察点但什么都没发生”，这种错误最难查。

注意：DWT 比较器是稀缺资源，用完记得把 FUNCTION0 清 0 释放。同时开着多个比较器还开着 ITM，容易互相挤占，最后表现出来的现象是观察点时灵时不灵。

GDB 侧的watch g_record.counter底层走的就是这套机制，但它需要目标在 halt 状态下设好再 continue，而且不同 OpenOCD 版本的翻译质量参差不齐。真正要追复杂时序问题时，直接在固件里写 DWT 更可控。

5. 避坑与排查：五条让扫描结果全错的细节

5.1 现象、原因、解决

现象一：整片 RAM 读回来全是 0x00 或全是 0xFF。原因基本不在扫描代码，而在链路层。全 0 通常是读的地址没有映射到任何存储体，总线返回 0 且置了 STICKYERR；全 0xFF 一般意味着 DAP 没连上，工具在读一个悬空的默认值。解决顺序是固定的：先用 telnet 的mdw直读 0x20000000，通了再上脚本；不通就把时钟降到 500 kHz，缩短排线，检查 VTref 有没有接、目标有没有供电。这一步没通，后面所有调试都是自欺欺人。

现象二：变量明明改了，扫描却找不到。最常见的原因是编译器把这个变量提到了寄存器里，或者干脆优化掉了。判断方法很直接：看 map 文件和 elf 符号表，如果nm出来的地址在 0x20000000 范围内，它就在 RAM；如果压根找不到符号，那就是被优化没了。解决是加volatile和__attribute__((used))，重新编译再看。别指望关掉优化能解决根本问题，工程里迟早要开回-O2。

现象三：两次快照之间只隔了几十毫秒，却有一大片地址在变。这是扫码时 CPU 没停。很多工具在resume之后拍快照，或者 halt 请求还没生效就开始读。表现出来的特征是一片连续的高位地址在跳，那通常是栈指针附近。解决是强制 halt 并确认状态，读完再 resume。另外注意低功耗模式：目标进了 sleep 之后 DAP 可能掉线，读回来的数据是陈旧的，需要在固件里打开调试保持位（比如__HAL_DBGMCU_ENABLE_DBGSLEEP），让内核在睡眠时仍保持调试连接。

现象四：连续三轮都在变的地址，最后发现是个栈上临时变量。栈上变量的地址在每次函数调用时都可能不同，但因为栈指针相对固定，同一个偏移位置会被反复复用，看起来就像“一个稳定的地址在变”。区分方法很简单：看这个地址是不是落在 SP 附近。把当前 SP 读出来，落在 SP 到 SP+1K 范围内的，一律先当噪声处理。真正的全局变量地址通常远离栈区，或者干脆查符号表确认。

现象五：块读的时候报对齐或者越界错误，读到一半就断。块读对起始地址和长度都有对齐要求。read_memory_block32的起始地址必须是 4 字节对齐，长度按字数算。更隐蔽的是跨区域读取：从 0x20000000 连读 128K，如果芯片的 SRAM 只有 96K 且后面接着一段未映射区间，读到最后会触发总线错误，前面读到的数据也一起废掉。解决办法是先查芯片手册确认连续可读区间的长度，分段读，每段读之前清一次错误标志。

5.2 一份最小自检清单

遇到“读出来不对”的时候，按固定顺序走一遍，比东摸西摸快得多：

探针能不能枚举到（工具里的 probe list 有没有设备）。
reset halt之后能不能读到复位向量所在地址的对齐值。
读一个已知常量地址（比如 Flash 起始），值是否正确。
写一个值到已知 RAM 地址，立刻回读是否一致。
加载 elf，用符号地址读一个已知变量，跟预期值比对。
最后才跑快照和 diff。

前五步任何一步失败，都不要往下走。这套顺序看起来笨，但能省掉大量“怀疑算法”的时间——绝大多数“扫描算法不准”的问题，根子都在第三步或第四步。

6. 进阶：用符号表和 DWT 计数器替代盲目扫描

扫描这套方法威力大，但它本质上是启发式的：你通过“值在变”去猜“这是哪个变量”，猜对了靠运气，猜错了得重来。真正成熟的工程做法是反过来——先知道变量在哪，再去观测它。地址从哪来？从编译产物里来。

elf 文件里带着完整的符号表，nm能列出来，Python 侧用pyelftools也能读。把这个环节接上，扫描就从“搜索”变成“校验”：

from elftools.elf.elffile import ELFFile def load_symbols(elf_path, ram_low=0x20000000, ram_high=0x20040000): """从 elf 里提取落在 RAM 范围内的全局符号名与地址""" syms = {} with open(elf_path, "rb") as f: elf = ELFFile(f) table = elf.get_section_by_name(".symtab") if table is None: return syms for sym in table.iter_symbols(): addr = sym["st_value"] size = sym["st_size"] if ram_low <= addr < ram_high and size > 0: syms[sym.name] = (addr, size) return syms syms = load_symbols("build/firmware.elf") for name, (addr, size) in list(syms.items())[:10]: print("%-24s 0x%08X size=%d" % (name, addr, size))

这段跑完，你手上就有一张“变量名到地址”的表。之后读g_record.counter根本不需要扫描，直接syms["g_record"][0] + 4就拿到了。扫描在这里的角色退化成了兜底手段——用于那些编译器生成的匿名符号、栈上对象、或者运行时动态分配的缓冲区。

再进一步，把周期采样和变化率判断结合起来，就得到了一个“常驻观测器”：每隔固定时间读一次候选变量的值，算差值，差值稳定说明是计数器，差值随机说明是状态量，长期不变说明是配置项。这个分类自动化之后，调试一个陌生的固件就不再是从零开始翻。

手段	需要什么	适用场景	局限
全 RAM 快照 diff	只要探针，无需 elf	完全不了解固件时摸底	噪声多，栈区干扰大
elf 符号表 + 地址直读	需要带符号的 elf	有源码、有构建产物	优化后符号可能被合并或消除
DWT 观察点	内核带 DWT 比较器	追“谁改了这个值”	比较器数量有限，M0 上可能没有
周期采样 + 变化率	探针 + 时间窗口	长时间挂机观测	采样间隔内的高频变化会漏掉

我自己现在的习惯是：新拿到一块板子，先花十分钟把符号表跑出来，能直接读的变量就直接读，读不到的才退回快照扫描。这个顺序反过来之后，调试时间大概能砍掉一半。从那以后我每次接新固件，都强制先导一遍.symtab再动手——省下的不是那十分钟，而是后面反复怀疑“是不是扫描算法写错了”的几个小时。希望帮到你。

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