把STM32固件结构解析落到Bootloader升级链路的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
STM32固件结构解析涉及源码、函数、脚本或 API 时，应先确认代码对象、调用条件和结果信号是否对应。
本节用Bootloader升级链路的真实调用点说明代码变化会影响哪一个操作结果。
在逆向分析STM32固件时，首要挑战并非反汇编指令本身，而是如何从二进制文件中精准定位程序入口点与中断服务例程（ISR）的基地址。STM32基于Cortex-M内核，其启动机制依赖位于Flash起始地址的中断向量表（Interrupt Vector Table, IVT）。向量表的首项（偏移0x00）存放栈顶指针（MSP），第二项（偏移0x04）存放复位向量（Reset Vector），即程序入口点。Ghidra在加载固件时，若未正确配置基地址与向量表偏移，将无法自动识别入口函数，导致反汇编结果从地址0x00000000开始，而非真正的Reset_Handler
在Ghidra中加载STM32固件时，手动设置基地址为0x08000000（Flash起始地址），并在“Memory Map”中确认向量表区域已正确映射。随后，通过“Symbol Tree”窗口搜索Reset_Handler或检查地址0x08000004处的4字节数据，该数据即为复位向量地址
本节的核心意图是构建一套可复用的固件结构解析（Firmware Structure Analysis）流程，使分析者能够通过Ghidra识别中断向量表（Ghidra Interrupt Vector Table Identification），并逆向推导出链接脚本（Linker Script）中的内存布局约束。一个典型的STM32固件二进制布局包含：向量表（通常占用0x400字节）、.text代码段、.rodata只读数据段、.data初始化的全局变量段、.bss未初始化数据段以及堆栈区域。启动文件（startup_*.s）负责初始化这些段，并调用main()函数
STM32的向量表重定位机制（VTOR, Vector Table Offset Register）允许运行时将向量表从Flash映射到SRAM，这在Bootloader升级场景中至关重要。分析固件时，需检查SCB->VTOR寄存器的写入操作，以判断是否存在多级启动流程。例如，一个支持A/B分区的固件，其启动流程通常包含以下检查点：
| 检查项 | 标准 | 是否通过 |
|---|---|---|
| 向量表基地址 | Flash起始0x08000000或SRAM起始0x2… | 未检查VTOR寄存器写入值 |
| 复位向量有效性 | 地址在Flash范围内且为奇数（Thumb指令对齐） | 直接使用偶数地址作为入口 |
| 栈顶指针值 | 指向SRAM有效区域，通常为0x20000000 +… | 未验证栈空间是否与链接脚本一致 |
| CRC校验入口 | 在跳转前调用CRC32校验函数 | 忽略校验失败后的回滚标志处理 |
| 回滚标志位 | 位于备份寄存器或特定Flash扇区 | 未识别标志位导致误判启动分区 |
在逆向分析时，通过Ghidra的“Data Type Manager”导入Cortex-M内核头文件，可以自动解析向量表结构。随后，定位到Reset_Handler函数，分析其内部调用的SystemInit()（时钟与外设初始化）和__main()（C运行时初始化）函数。若固件包含Bootloader，则会在main()中检测升级请求，并通过修改VTOR后跳转到APP分区
某工业控制器固件升级后无法启动。通过Ghidra加载固件，发现向量表第二项（复位向量）指向地址0x0800A001，但该地址位于Flash的APP分区起始处。进一步分析发现，Bootloader在跳转前未正确设置VTOR，导致中断响应异常。修复方式为在跳转指令前添加SCB->VTOR = APP_BASE_ADDRESS，并验证栈顶指针值是否与APP分区链接脚本匹配
为了精确还原固件的内存布局，需要逆向推导链接脚本（Linker Script）中的关键参数。以下是一个基于Ghidra脚本的自动化检查片段，用于提取向量表并验证分区边界：
# Ghidra Python脚本：提取向量表并验证分区边界
from ghidra.program.model.listing import Program
from ghidra.program.model.address import AddressSet
def analyze_vector_table(program):
flash_base = program.getAddressFactory().getAddress("0x08000000")
# 读取栈顶指针和复位向量
msp = program.getMemory().getInt(flash_base)
reset_vector = program.getMemory().getInt(flash_base.add(4))
print(f"栈顶指针 (MSP): 0x{msp:08X}")
print(f"复位向量 (Reset): 0x{reset_vector:08X}")
# 检查复位向量是否为奇数（Thumb指令）
if reset_vector % 2 == 0:
print("警告：复位向量地址为偶数，可能不是有效的Thumb代码入口")
# 遍历向量表，识别中断服务例程
for i in range(16): # 系统异常向量
addr = flash_base.add(4 * (i + 2))
isr_addr = program.getMemory().getInt(addr)
if isr_addr != 0:
print(f"异常向量[{i}]: 0x{isr_addr:08X}")
return reset_vector
# 执行分析
entry = analyze_vector_table(currentProgram)这段配置属于“问题代码/原始配置”，核对键名、默认值、取值范围和修改后影响的行为。
该脚本验证了两个关键边界：栈顶指针必须指向SRAM有效区域，复位向量地址必须为奇数（Thumb指令对齐）。若复位向量为偶数，则表明Ghidra的基地址设置错误，或固件使用了非标准的启动方式。通过对比Flash分区中的CRC校验值与回滚标志位，可以进一步确认当前启动分区是否为预期版本
当复位向量地址指向Flash末尾或SRAM区域时，极大概率存在Bootloader二次跳转。此时应重点分析SCB->VTOR的写入时机，以及跳转前是否关闭了全局中断（__disable_irq()）
这一节的机制判断可以从STM32固件结构解析切入：它出现在哪里、由STM32固件结构解析还是固件结构解析触发、最终怎样影响启动文件。把结论写成关系而不是定义，会更容易迁移；因为新场景里名称可能不同，但前提、边界和结果材料仍需要重新对应。复习时用启动文件检查自己是否能说明“为什么成立”和“什么时候不成立”，再决定是否继续扩展到向量表与链接脚本。保留一条最小证据线：STM32固件结构解析说明对象，概念联动说明约束，STM32固件结构解析说明状态，最后用启动文件判断能否继续推进。第02节留下的风险提示是知识结构不要脱离概念联动单独判断，否则容易把现象误当成原因。