04 Ghidra 10.4 ARM加载器与自动分析脚本：固件导入与初始反编译

⭐固件导入前的准备：对齐IDA Pro与Ghidra的分析基线

模块边界与接口契约的验收口径

在开始联合分析之前，一个常见的工程困惑是：为什么同一份ARM固件，在IDA Pro（Interactive Disassembler Pro）和Ghidra中看到的入口点、段地址甚至指令解码结果会不一致？这通常不是工具错误，而是加载器（Loader）对固件基地址（Base Address）和镜像类型（Raw Binary vs. ELF）的默认假设不同。本节的核心目标是建立一条从“固件文件”到“可对比反汇编视图”的标准化导入链路，确保后续的交叉验证建立在相同的地址空间和段映射基础上

操作的第一步是确认固件类型。对于裸机ARM固件（如STM32、NXP LPC系列），文件通常为 .bin 或 .hex 格式，不包含段表信息。在Ghidra中，选择 File → Import File，在Language对话框中选择 ARM → little-endian → ARMv7-M (Thumb)（根据目标芯片调整）。关键步骤在于 Options 中的 Base Address 字段——必须与IDA Pro中设定的基地址一致。例如，若IDA Pro中固件加载地址为 0x08000000（常见于STM32 Flash起始地址），则Ghidra的 Base Address 也应设为 0x08000000

⭐Ghidra 10.4 自动分析脚本：从加载到初始反编译

导入完成后，Ghidra会弹出 Analyze 对话框，这是与IDA Pro自动分析（Auto-Analysis）最直接的对比点。Ghidra的默认分析器（Auto Analysis）包含 ARM Disassembler、Function ID、Data Reference 和 Decompiler 四个核心模块。与IDA Pro不同，Ghidra在分析ARM Thumb代码时，需要显式启用 ARM Thumb Switch Recovery 分析器，否则大量Thumb/ARM混合代码的函数边界会识别失败

分析完成后，对比IDA Pro的反汇编结果，重点关注以下三个维度：

• 函数识别率：Ghidra的 Function ID 分析器对标准库函数（如memcpy、memset）的识别率通常低于IDA Pro的FLIRT签名库，但Ghidra允许用户手动导入自定义签名文件（.sig）来弥补
• 栈变量布局：Ghidra的 Decompiler 在分析ARM PUSH/POP指令时，对栈帧的恢复比IDA Pro更激进，有时会错误合并局部变量。需要手动检查 Function Graph 中的栈偏移
• 字符串交叉引用：Ghidra默认不扫描非对齐的字符串引用，而ARM固件中字符串常以4字节对齐方式存储。需在 Search → Memory 中手动搜索ASCII字符串，然后通过 Create Strings 建立引用

对比表：IDA Pro 与 Ghidra 初始反编译差异

⭐Ghidra 10.4的技术资产与验证方式

为了复现一致的联合分析环境，需要将Ghidra的自动分析配置固化为脚本。以下是一个用于批量导入ARM裸机固件并执行标准分析的Python脚本片段，它直接对应 步骤 中的“分析后处理”阶段：

# Ghidra 10.4 自动分析脚本：导入与初始反编译
from ghidra.app.script import GhidraScript
from ghidra.program.model.lang import LanguageID
from ghidra.util.task import ConsoleTaskMonitor
def run_analysis(program, base_addr):
    # 设置基地址
    addr_factory = program.getAddressFactory()
    base = addr_factory.getAddress(base_addr)
    program.setImageBase(base, True)
    # 启动默认分析器
    monitor = ConsoleTaskMonitor()
    options = program.getOptions("Analysis")
    options.setBoolean("ARM Thumb Switch Recovery", True)
    options.setBoolean("ARM Function ID", True)
    # 执行分析
    from ghidra.app.plugin.core.analysis import AutoAnalysisManager
    mgr = AutoAnalysisManager.getAnalysisManager(program)
    mgr.initializeOptions(options)
    mgr.reAnalyzeAll(monitor)
    # 输出分析统计
    print("函数数量: %d" % program.getFunctionManager().getFunctionCount())
    print("指令数量: %d" % program.getListing().getNumInstructions())
# 使用示例：run_analysis(currentProgram, "0x08000000")

这段配置属于“问题代码/原始配置”，核对键名、默认值、取值范围和修改后影响的行为。

该脚本的关键字段包括 setImageBase（对齐基地址）、ARM Thumb Switch Recovery（解决Thumb/ARM混合代码）和 reAnalyzeAll（触发全量分析）。执行后，应验证 Function Graph 中每个函数的入口地址是否与IDA Pro中的地址一致

⭐异常信号与处理边界：避免联合分析中的假阳性误判

联合分析最大的风险在于：两个工具对同一段二进制数据给出不同的反编译结果，而分析者倾向于相信更“熟悉”的那个。以下是判断标准：

• 指令解码不一致：如果IDA Pro将某段数据解码为 LDR R0, [R1, #0x10]，而Ghidra解码为 MOVS R0, #0x10，应优先检查该地址的字节序（Endianness）和Thumb/ARM模式。Ghidra的 ARM Thumb Switch Recovery 有时会错误地将ARM指令识别为Thumb
• 函数边界错位：当Ghidra识别出一个函数，而IDA Pro未识别时，不要立即判定Ghidra更优。应检查该函数是否以 BX LR 或 POP {PC} 结尾，以及调用该函数的指令是否为 BL 或 BLX。若IDA Pro未识别，通常是因为函数入口地址被嵌入在数据段中
• 字符串引用丢失：Ghidra的 Data Reference 分析器对非对齐字符串的引用建立不完整。若发现IDA Pro中有字符串交叉引用而Ghidra没有，应在Ghidra中手动创建字符串并重新运行 Analyze → One Shot → Data Reference

最终验收标准：在Ghidra中打开 Window → Listing，定位到固件入口点（如Reset_Handler），逐条对比IDA Pro中同一地址的指令。若前20条指令完全一致，且函数边界、字符串引用数量差异在5%以内，则说明联合分析基线已对齐，可以进入后续的漏洞挖掘与逻辑分析阶段