把课程导论落到模块边界与接口契约的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
想象一个典型的嵌入式现场：一块基于 Cortex-M4 的工业控制器，在批量部署后需要通过固件升级修复一个定时器中断的竞态条件。现场工程师通过 UART 刷入了官方补丁，但设备在重启后直接进入了 HardFault 死循环。没有源码、没有 JTAG 日志、只有一份 .bin 文件和一颗变砖的板子。这个场景暴露了通用技能类工程师最核心的痛点：目标不清——不知道固件里哪些模块被修改了；路径不明——没有一套标准流程去定位异常向量表、中断服务函数和关键全局变量；结果不可检查——无法验证补丁是否真的解决了竞态条件，还是引入了新的内存越界
本课程正是为解决这类真实问题而设计。你将学会如何从零开始，对 Cortex-M0/M3/M4/M7 固件执行系统化的逆向工程，而不是依赖“试错+盲猜”。本节作为导论，将为你建立完整的全景视图：从固件加载、环境检查到工具链选型，并明确后续每一节课的输入输出与检查点
某 IoT 网关设备（Cortex-M7）在 OTA 升级后频繁死机。逆向团队通过 environment_check 脚本发现：新固件的 .text 段起始地址偏移了 0x200，导致中断向量表重映射错误。本课程将教你如何用 readelf 和 objdump 在 5 分钟内完成这类检查
本课程将逆向工程拆解为四个可重复的工序，每一道工序都包含明确的触发条件、关键检查点和判定标准。你不需要一次性掌握所有细节，而是按工序逐步建立能力
memcpy、printf）的调用约定、定位中断服务函数入口。判定标准：如果超过 30% 的调用指令目标地址指向未定义区域，则需考虑固件是否被混淆拿到一份固件后，第一件事不是打开 IDA Pro 或 Ghidra，而是运行 arm-none-eabi-objdump -h firmware.elf 查看段分布。如果 .text 段起始地址不是 0x08000000（STM32 默认 Flash 基址），立即检查是否开启了 Bootloader 或加密
在 Cortex-M 固件逆向中，IDA Pro 和 Ghidra 是两大主流方案。选型不应基于“哪个更强大”，而应基于你的具体工序需求。下表从工程实践角度给出对比与判断建议
不要因为 Ghidra 免费就盲目选择。如果你的工作流依赖硬件调试（如通过 SWD 读取 Cortex-M 寄存器），IDA Pro 的 GDB 集成是唯一成熟方案。Ghidra 更适合静态分析为主的“黑盒”场景
实战课第一节操作路线：Cortex-M启动流程与向量表逆向分析对应工程入口，ARM Thumb/Thumb-2指令集快速识别与反汇编基础对应可运行材料，固件加载与内存映射重建：从二进制到可分析镜像对应后续验收或排错位置。后面使用讲义、配置、清单或示例时，可以把固件逆向的起点、从一次失败的现场升级说起和常见偏差与修正动作放在同一张检查线上，判断成果能否复现。读者不必在开头完成练习，但要知道换到新环境时要确认对象边界、输入输出和证明材料，判断任务是否已经落地。