📚 课程目录第2章固件获取与初步分析

2. 固件获取与初步分析：从Flash/Hex/Bin文件中提取固件

拿到一块RA系列MCU的板子，第一件事是什么？不是急着上调试器，而是先把固件搞到手。我个人习惯先做一次完整的固件转储，再开始逆向分析。这一步要是搞砸了，后面全是白费功夫。

2.1 固件的三种常见形态

RA系列MCU的固件，通常以三种形式存在：

形态	说明	典型场景
Flash 原始镜像	直接从芯片Flash读出的二进制数据，包含完整代码段、数据段、中断向量表	通过J-Link、ST-Link等调试器读取
Hex 文件	Intel HEX格式，带地址信息和校验，可分段存储	IDE编译输出、量产烧录文件
Bin 文件	纯二进制，无地址信息，从起始地址连续排列	OTA升级包、Bootloader加载的固件

你想想看，这三种格式各有各的坑。Hex文件带地址，但解析不对容易把数据放错位置。Bin文件最简单，可你不知道它该从哪个地址开始加载。Flash镜像最完整，但读取方式不对可能漏掉保护区域。

⚠ 注意：RA系列MCU的Flash读取，要特别留意安全位（Security Bit）和ID Code保护。我曾经遇到过一块板子，J-Link能识别芯片，但死活读不出Flash内容——后来发现是ID Code没解锁。如果你也遇到类似情况，先检查芯片是否被锁定。

2.2 从Flash中提取固件

最直接的方式，就是用调试器读Flash。以J-Link为例，我常用的命令是：

# 连接RA系列MCU
JLinkExe -device R7FA6M4AF -if SWD -speed 4000

# 读取整个Flash区域（假设Flash起始0x00000000，大小2MB）
savebin flash_dump.bin 0x00000000 0x200000

# 或者分段读取，先读代码区
savebin code_region.bin 0x00000000 0x100000

# 再读数据区
savebin data_region.bin 0x01000000 0x100000

这里有个细节：RA系列MCU的Flash通常从0x00000000开始，但不同型号的Flash大小不一样。R7FA6M4AF是2MB，R7FA4M1AB只有512KB。读之前一定先确认芯片型号和Flash容量，不然读出来的数据要么不全，要么包含无效区域。

💡 小技巧：如果你不确定Flash大小，可以先用J-Link的mem命令读一下Flash末尾的几个字节，看看是不是全0xFF。如果是，说明已经读到空白区域了，可以适当缩小读取范围。

2.3 Hex与Bin文件的转换

很多时候，你拿到的不是Flash镜像，而是Hex文件。Hex文件是文本格式，每行以冒号开头，包含长度、地址、类型、数据和校验。我习惯先用工具把它转成Bin，再分析。

常用的转换工具有：

srec_cat：开源，功能强大，支持多种格式互转
objcopy：GNU工具链自带，适合嵌入式开发环境
hex2bin：轻量级，简单粗暴

举个例子，用srec_cat把Hex转成Bin：

# Hex转Bin，指定起始地址
srec_cat firmware.hex -intel -o firmware.bin -binary

# 如果Hex文件包含多个段，可以合并输出
srec_cat firmware.hex -intel -o firmware_merged.bin -binary -address-length 4

嗯，这里要注意：Hex文件可能包含非连续地址段。比如代码在0x00000000-0x00010000，数据在0x01000000-0x01001000。直接转成Bin，中间会填充大量0xFF，导致文件体积膨胀。我建议先分析Hex文件的地址分布，再决定是否分段转换。

2.4 使用binwalk进行初步分析

拿到固件后，我第一件事就是跑binwalk。这工具能快速识别固件里嵌入了哪些文件系统、压缩数据、或者已知的固件头。

# 扫描固件，识别已知签名
binwalk firmware.bin

# 提取所有识别的文件
binwalk -e firmware.bin

# 只显示签名信息，不提取
binwalk -s firmware.bin

binwalk的输出会告诉你：

是否有LZMA、gzip等压缩段
是否有SquashFS、JFFS2等文件系统
是否有U-Boot、RT-Thread等Bootloader签名
是否有证书、密钥等结构化数据

对于RA系列MCU，我经常看到的是：固件里嵌入了LZMA压缩的应用程序段，或者包含FATFS格式的配置文件分区。binwalk能帮你快速定位这些区域。

    🔍 实战案例：有一次我分析一个RA6M4的固件，binwalk扫描后发现0x10000处有一个LZMA压缩段。解压后，里面是一个完整的文件系统，包含Web服务器的静态页面和配置文件。如果没有binwalk，我可能要在IDA里翻半天才能找到这些数据。

2.5 用strings提取可读信息

binwalk看结构，strings看内容。这俩是黄金搭档。

# 提取所有可打印字符串，长度至少4个字符
strings firmware.bin > strings_output.txt

# 按编码提取（UTF-8、UTF-16等）
strings -e l firmware.bin > strings_utf16.txt

# 只提取特定长度的字符串
strings -n 8 firmware.bin > strings_long.txt

strings的输出里，你能找到什么？

函数名、变量名（如果固件没strip）
日志输出、错误信息
文件路径、配置项
IP地址、URL、API密钥
版本号、编译时间

我个人习惯先跑一次strings，然后grep一些关键词，比如"password"、"key"、"secret"、"http"、"debug"。这些往往是突破口。

⚠ 注意：strings的输出里可能包含大量无意义数据，比如代码段里的指令编码被误识别为字符串。我建议设置最小长度（-n 6或8），减少噪音。另外，有些固件会使用XOR或简单编码混淆字符串，strings直接扫是看不到的——这个后面章节会讲怎么处理。

2.6 固件分析的整体流程

把上面这些步骤串起来，就是固件初步分析的完整流程。我画了一张图，方便你理解：

这个流程看起来简单，但每一步都有坑。比如格式转换时地址不对，binwalk扫描时签名库不全，strings提取时编码不匹配。我建议你每次分析都按这个流程走一遍，慢慢就会形成自己的套路。

2.7 实战：分析一个RA6M4的固件

最后，我拿一个实际案例来演示。假设你拿到了一个RA6M4的固件文件 firmware.hex，按以下步骤操作：

格式转换：用srec_cat转成Bin文件
binwalk扫描：看看有没有压缩段或文件系统
strings提取：找关键字符串
交叉验证：把binwalk识别的区域和strings的结果对应起来

# 步骤1：Hex转Bin
srec_cat firmware.hex -intel -o firmware.bin -binary

# 步骤2：binwalk扫描
binwalk firmware.bin

# 步骤3：strings提取
strings -n 6 firmware.bin | grep -i "key\|password\|secret\|http\|debug"

我遇到过的情况是：binwalk在0x8000处识别出一个LZMA压缩段，strings在0x8000附近找到了一些HTTP相关的字符串。解压后，发现里面是一个Web服务器的固件更新模块。这个信息对后续的逆向分析非常有价值。

💡 经验之谈：RA系列MCU的固件，Bootloader和应用程序通常分开存放。Bootloader在Flash起始地址，应用程序在偏移地址。binwalk扫描时，如果发现两个不同的压缩段或文件系统，很可能就是Bootloader和App的分界线。