把固件加载与基址修正落到Bootloader升级链路的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
记录输入、环境、时序或操作动作，先保留现场证据。
优先保留日志、返回码、状态位或波形片段。
把命令、配置和日志放到同一时间窗口，再只调整一个会改变链路状态的条件。
把返回码、计数器和吞吐变化分开留存，避免把一次偶然恢复当成结论。
STM32固件在IDA Pro中初次加载时，通常呈现为一段无结构的二进制数据。核心问题在于：固件在芯片上电后从0x08000000（或由BOOT引脚决定的映射地址）开始执行，而IDA默认的加载基址（通常是0x00000000）与实际运行地址不一致，导致所有交叉引用、函数边界和字符串识别全部失效。本节的核心工程判断是：必须通过解析中断向量表（Vector Table）中的初始栈指针（MSP）和复位向量（Reset_Handler），逆向推导出正确的加载基址，并据此修正IDA Pro的段映射（Segment Mapping）。只有完成这一步，后续的Ghidra联合逆向才能基于一致的地址空间进行协同分析
不要依赖固件文件名或猜测地址。STM32向量表的前8字节（MSP + Reset_Handler）是唯一可靠的基址锚点。若复位向量值指向0x0800xxxx区域，则加载基址应为0x08000000
在IDA Pro中执行File → Load file → Raw binary file加载固件后，首先进入二进制加载器（Binary Loader）对话框。此处必须手动指定处理器类型为ARM Little-endian [ARM]，并取消勾选Create ROM section（避免IDA自动创建名为.text的默认段）。点击OK后，IDA会提示输入加载地址（Loading Address）
实操步骤：输入0x0作为临时基址，待后续修正。加载完成后，立即定位到地址0x0处，观察前8字节：
0x20002000）0x08000123）关键检查点：若复位向量的高16位为0x0800，则判定固件实际运行基址为0x08000000。此时执行Edit → Segments → Rebase program，将当前基址0x0调整为0x08000000。IDA会立即重算所有地址，向量表条目将指向正确的Flash地址，函数边界开始显现
在Rebase program对话框中，勾选Rebase all segments和Fix up the program。完成后，跳转到复位向量地址（如0x08000123），按C键强制解析为代码，验证是否出现LDR SP, =__initial_sp等典型启动指令
IDA Pro中修正基址后，需要手动创建与STM32 Flash布局一致的段映射。典型的STM32F4系列固件包含以下段：
| 时间/步骤 | 输入 | 动作 | 输出 |
|---|---|---|---|
| .text | 0x08000000 | 固件大小（如0x20000） | 自动生成，需重命名为 .text |
| .data | 0x20000000 | 由链接脚本决定 | 手动添加： Edit → Segments → Cre… |
| .bss | 0x20000000 + .data_size | 由链接脚本决定 | 同上，属性设为 Uninitialized |
在Ghidra交付物中，导入同一固件时需选择Raw Binary格式，并在Language中选择ARM:LE:32:Cortex。Ghidra会自动解析向量表，但基址默认为0x0。必须手动设置Base Address为0x08000000，确保与IDA Pro的地址空间一致。验证方法：在Ghidra中定位到0x08000000，检查前8字节是否与IDA Pro中的向量表条目完全一致
某工业控制器的固件升级包（STM32F407）在IDA Pro中加载后，所有函数名显示为sub_0。通过向量表解析发现复位向量为0x0800C123，判定基址应为0x08000000。修正后，IDA Pro成功识别出main、HAL_Init等函数。随后在Ghidra中设置相同基址，两工具的函数列表和交叉引用完全对齐，联合逆向得以顺利推进
固件加载与基址修正是否合格，要看固件加载是否进入真实处理链路，以及固件加载能不能说明结果不是偶然通过。如果向量表定位与基址修正和从固件盲区到可分析镜像给出的信息互相矛盾，先暂停扩大范围，把基址修正补成一份能复查的最小材料。继续推进前只保留一个判断重点：哪一项条件最先改变结论，再围绕异常线索复盘决定补测、调参还是重新划定验收边界。下次迁移到新现场时，优先比较固件加载与基址修正和源码结构是否同源；如果固件加载偏离，就回到基址修正补一条可复查证据。第03节适合把固件加载写成一条判断记录，标明触发条件、观察位置和结束标准。