Ghidra 12.1.x无头批量分析：REA对接与JDK 21配置实战

手上有一批自研的二进制样本要做函数级特征对齐，手工在 Ghidra 里一个个开工程、跑脚本、导报告，一天下来处理二十几个已经算效率高的。后来把批量编排这一层抽出来做了个逆向分析辅助层（Reverse Engineering Assistant，下文统一简称 REA），由它去驱动 Ghidra 12.1.x 做无头分析，人只负责看结果。这套东西真正落地花时间最多的不是写脚本，而是**REA 对接 Ghidra 12.1.x **时的环境配置——JDK 21 的版本基线、Ghidra 的启动参数、无头模式的脚本路径、并发时的内存分配，每一项都能单独卡住你半天。

这篇就把整套流程从头到尾捋一遍：为什么必须锁 JDK 21、REA 侧配置文件每个字段该怎么填、四层验证怎么设计、踩过的坑怎么绕。适合两类人看——刚把 Ghidra 拉下来想跑批量的新手，以及已经在用无头模式但被版本冲突和内存问题折磨过的老手。所有示例都用自己编译的测试二进制，不涉及任何未授权样本。

1. 先把架构想清楚：REA 到底该挂在哪一层

动手装环境之前，得先想明白 REA 和 Ghidra 的边界在哪。这个决定会直接影响后面所有的配置项，选错了后面全是返工。

1.1 从手工点点点说起：痛点到底在哪

Ghidra 的图形界面做得相当完整，反编译、交叉引用、类型恢复都很顺手，但它本质上是为"人盯着看"设计的。一旦样本量上到几十上百，问题就暴露出来了：每个样本都要新建工程、导入、等自动分析跑完、手动跑脚本、导出结果，中间还得盯着进度条别卡死。这套动作重复五十次，人的注意力早就散了，漏跑、错跑、报告覆盖都是常事。

更麻烦的是结果不可复现。今天手动点了一遍，明天想再跑一遍对照，参数可能已经记不清了——分析选项是不是全开了、反编译器超时设了多少、脚本用的是哪个版本。手工流程天然缺乏记录，出了问题只能靠回忆。

REA 要解决的正是这一层。它不碰反编译算法，也不重写分析引擎，只做三件事：调度（什么时候对哪个样本起一个 Ghidra 进程）、注入（把自定义脚本塞进分析流水线的固定位置）、收口（把散落在各处的输出统一成结构化格式）。用生活化的说法，Ghidra 是厨房，REA 是那个帮你排菜单、卡时间、最后统一摆盘的人。

明确了这层定位，配置的重点就很清楚了：REA 需要的不是一个"能打开 Ghidra 界面"的环境，而是一个能被外部进程稳定调用、参数可完全指定、退出码可靠的无头环境。这是后面所有选择的出发点。

1.2 三种对接形态，先选对再动手

REA 和 Ghidra 的对接方式不止一种，实际项目里我见过三种，各有各的适用场景，混着用最容易出事。

我最后选的是无头命令行为主、脚本桥为辅的组合。原因很实际：REA 需要跑在服务器上无人值守，插件常驻模式一旦界面卡住整个流水线就停了；而脚本桥单独用又太弱，拿不到进程级的超时控制和退出码。两者结合，主控负责起进程和判生死，脚本负责在 Ghidra 内部干活，职责分得干净。

提示：不要为了图省事把 REA 直接写成 Ghidra 插件再塞进无头模式。Ghidra 的无头运行虽然也走插件体系，但很多依赖界面组件的插件在无头下会静默失效，出的错还不报，排查起来极其痛苦。

1.3 版本组合为什么卡得这么死

Ghidra 从 11.2 起就把 Java 基线提到了 21，这个不是"建议"而是硬约束。它的 class 文件编译目标是 major version 65，对应 JDK 21。你用 JDK 17 去启动，JVM 在加载第一个类的时候就会抛UnsupportedClassVersionError，报错文本里那个class file major version 65就是线索。

那能不能用 JDK 22、23 甚至更高？理论上 JVM 向下兼容，class 65 在 JDK 23 上能跑。但实际会撞上第二个坑：Ghidra 的support/launch.properties里预设了一串 JVM 参数，其中有几个在更高版本 JDK 上已经被废弃甚至移除，启动脚本会直接报Unrecognized VM option然后退出。除非你愿意逐条改这些参数，否则老老实实待在 21 是最省心的。

第三个约束来自 Python 侧。Ghidra 从 11.3 开始引入 PyGhidra，让脚本可以用 CPython 3 写，老的 Jython 2.7 逐步退场。REA 的注入脚本如果按 CPython 3 写，就得保证环境的 Python 版本不要低于 3.9（PyGhidra 的门槛），同时 JDK 21 自带的那套jpackages桥接在 3.12 上验证得最充分。所以最终锁定的组合是：Ghidra 12.1.x + JDK 21 LTS + CPython 3.12。

2. 环境准备：JDK 21 与 Ghidra 12.1.x 的落地细节

环境准备这一步看着最枯燥，但 80% 的后续问题都埋在这里。我习惯把它拆成"装 JDK、验 JDK、装 Ghidra、验 Ghidra、定参数"五小步，每步都有明确的通过判据，不通过绝不往下走。

2.1 JDK 21 的选型与安装

选哪个发行版？我的建议是跟着团队已有的运维体系走。主流的 OpenJDK 21 发行版在 Ghidra 这个场景下差异很小，真正影响体验的是三件事：有没有长期安全更新、装完之后JAVA_HOME指向是否干净、以及带不带 JavaFX（Ghidra 不需要 JavaFX，带了只是浪费体积）。

安装路径上有个小习惯我一直保持：把 JDK 装在版本号明确的目录下，比如/opt/jdk-21.0.5而不是/opt/jdk21。原因是将来升到 21.0.6 时，新目录一放、软链一改就能回滚，/opt/jdk21这种写法一旦覆盖安装，出问题连对照环境都没有。

# 解压到版本化目录 sudo mkdir -p /opt/jdk-21.0.5 sudo tar -xzf openjdk-21.0.5_linux-x64.tar.gz -C /opt/jdk-21.0.5 --strip-components=1 # 建一个稳定的软链，后续所有配置都指向这个软链 sudo ln -sfn /opt/jdk-21.0.5 /opt/jdk-21-current # 校验 /opt/jdk-21-current/bin/java -version

期望输出里必须看到openjdk version "21.0.5"这样的字样。如果看到的是1.8.0或者17.0.x，说明 PATH 上有旧版本抢在前面，这时候别急着改 PATH，先用绝对路径确认新装的是好的，再处理优先级。

注意：不要用系统包管理器装 JDK 再指望 Ghidra 认它。很多发行版的仓库里default-jdk指向的版本往往滞后，而且安装位置散落在/usr/lib/jvm/下多套并存，Ghidra 启动脚本挑错版本的概率很高。宁可手工解压，也不要图这个方便。

2.2 版本校验：别只看 java -version

java -version通过只说明 JVM 能跑，不代表 Ghidra 能找到它。Ghidra 的启动脚本查找 JDK 的顺序大致是：环境变量JAVA_HOME_OVERRIDE→launch.properties里的配置 → 环境变量JAVA_HOME→ PATH 上的java。这个顺序意味着，只要系统里残留一个JAVA_HOME_OVERRIDE，你后面改什么都没用。

我一般会用这几条命令一次性把底摸清：

# 1. 看所有可能影响选择的变量 echo "JAVA_HOME=$JAVA_HOME" echo "JAVA_HOME_OVERRIDE=$JAVA_HOME_OVERRIDE" which -a java readlink -f $(which java) # 2. 确认目标 JDK 的 class 版本能力 /opt/jdk-21-current/bin/javap -verbose java.lang.Object \ | grep -E 'major|minor' | head -2 # 3. 检查是否有多套 JDK 并存 ls -d /usr/lib/jvm/* 2>/dev/null ls -d /opt/jdk-* 2>/dev/null

第二条命令里，javap输出的major version: 65就是 JDK 21 的指纹。这个数字值得记一下：JDK 17 是 61，JDK 21 是 65，JDK 22 是 66。以后看到任何UnsupportedClassVersionError报错，先看报错里写的 major version 是多少，再看自己环境是多少，一比对就知道是版本低了还是高了，比猜快得多。

2.3 Ghidra 12.1.x 解压与首次启动验证

Ghidra 是免安装的，解压即可用，但目录结构得心里有数，因为后面配 REA 要往几个特定位置放东西。

sudo mkdir -p /opt/ghidra sudo unzip ghidra_12.1_PUBLIC.zip -d /opt/ghidra sudo ln -sfn /opt/ghidra/ghidra_12.1_PUBLIC /opt/ghidra/current # 目录结构速览 tree -L 2 /opt/ghidra/current | head -30

几个关键位置先记住：

• support/analyzeHeadless：无头分析的入口，REA 主要就调它
• support/launch.properties：JVM 参数、内存上限、JDK 覆盖都在这里
• Ghidra/Features/：内置功能模块，反编译器在这里
• Ghidra/Processors/：处理器架构定义，遇到冷门架构要在这里补
• Ghidra/Extensions/：官方扩展，第三方插件一般也放这类目录

首次启动用图形界面验一次是值得的，因为它会把用户配置目录初始化出来：

export JAVA_HOME_OVERRIDE=/opt/jdk-21-current /opt/ghidra/current/ghidraRun

启动成功后，用户配置目录会出现在~/.config/ghidra/.ghidra_12.1_PUBLIC/（Linux 下）。这个目录很关键，脚本目录、工具选项、最近的工程列表都在里面。很多人配完 REA 发现"脚本明明放进去了但列表里没有"，十有八九是放错了目录——放到了这个用户配置目录下的scripts/，而 REA 调无头模式时用的是自己指定的-scriptPath，两边根本不是同一份。

2.4 内存与 JVM 参数：改哪里、改多少

Ghidra 默认的堆内存给得偏保守，小样本够用，稍大一点就 OOM。调整入口在support/launch.properties：

# 只列需要关注的行，其余保持默认 MAXMEM=4G VMARGS=-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Dfile.encoding=UTF-8

关于MAXMEM该给多少，我的经验值是按样本体积粗估：

这里有个容易忽略的点：堆内存不是越大越好。G1 在堆特别大的时候单次 GC 的停顿会变长，而无头分析往往是"分析十分钟、跑完就退"，过大的堆反而让启动时的内存清零拖慢整体吞吐。我实测下来，把 4G 堆改成 16G，对 5MB 样本的单次分析时间几乎没有改善，但并发数被迫从 6 降到 2，总吞吐直接腰斩。

并发的算法很简单：

可用内存 = 物理内存 × 0.7 减去 系统预留 最大并发 = floor(可用内存 / 单进程堆)

举个具体例子：一台 32G 内存的机器，系统和其他服务预留 8G，可用 24G，单进程 4G，那并发就是 6。这个数字要写进 REA 的配置，别让它自己猜。

3. REA 侧配置：让两边真正说上话

环境验完，进入正题。REA 的配置我做成了一份 YAML，好处是层级清晰、方便版本管理，坏处是字段名一多就容易填错。下面逐个字段拆。

3.1 配置文件整体结构与字段含义

# /data/rea/rea.yaml ghidra: home: /opt/ghidra/current java_home: /opt/jdk-21-current headless: support/analyzeHeadless max_mem: 4G max_cpu: 6 workspace: project_dir: /data/rea/projects script_dir: /data/rea/scripts log_dir: /data/rea/logs timeout_sec: 900 keep_project: false bridge: mode: headless python: /usr/bin/python3.12 pyghidra: true env_passthrough: - JAVA_HOME_OVERRIDE - GHIDRA_LANG_EXT analysis: pre_scripts: - rea_prepare.py post_scripts: - rea_export.py no_analysis: false delete_project: true output: format: jsonl sink: /data/rea/out compress: false

几个字段值得单独说清楚：

ghidra.java_home这个字段最终会被 REA 转成JAVA_HOME_OVERRIDE环境变量传给子进程，而不是依赖系统全局配置。这么做的好处是同一台机器上可以并存多个 Ghidra 版本，各自指向不同的 JDK，互不干扰。以前用全局JAVA_HOME的时候，升一次 JDK 全机器所有工具一起遭殃，那滋味不好受。

bridge.pyghidra打开后，脚本会被当作 CPython 3 执行，而不是 Jython 2.7。这个选项一旦打开，所有老脚本里的 Python 2 语法（print "xxx"、except Exception, e）全都会报语法错误，迁移成本要提前评估。

workspace.keep_project和analysis.delete_project这两个字段语义有重叠，容易搞混。我的约定是：keep_project控制整个工程目录在任务结束后是否保留（用于复现问题），delete_project控制单次导入产生的工程是否在分析完立刻删（用于省磁盘）。批量跑的时候两个都开，只在出问题的样本上临时把keep_project打开。

workspace.timeout_sec是硬超时，超过就 kill 进程。这个值的设定有个小技巧：先用一批典型样本跑一遍，记录 P95 耗时，然后乘以 2 作为超时值。设太紧会误杀正常的长尾样本，设太松会让卡死的任务占着并发槽位不放。

3.2 脚本目录约定与注入点选择

REA 的脚本放在workspace.script_dir下，通过-scriptPath传给 Ghidra。目录结构建议按功能分层：

/data/rea/scripts/ ├── rea_prepare.py # 分析前：设置选项、注册钩子 ├── rea_export.py # 分析后：导出函数、字符串、交叉引用 └── lib/ ├── rea_common.py # 公共函数 └── rea_schema.py # 输出格式定义

注入点有两个：-preScript和-postScript。这两个名字容易让人以为是"分析前"和"分析后"，实际上更准确的理解是导入完成但自动分析之前和自动分析全部完成之后。

preScript适合做这些事：设置分析选项（比如关掉用不上的分析器提速）、给程序打标记、按文件特征决定要不要跳过分析。postScript才是主力，导出结果基本都在这里。

# rea_export.py 骨架，PyGhidra / CPython 3 写法 from ghidra.program.model.listing import Function import json, os def main(): program = currentProgram out_dir = os.environ.get("REA_OUT_DIR", "/tmp") name = program.getName() funcs = [] fm = program.getFunctionManager() for f in fm.getFunctions(True): funcs.append({ "entry": f.getEntryPoint().toString(), "name": f.getName(), "params": f.getParameterCount(), "is_thunk": f.isThunk(), "body_size": f.getBody().getNumAddresses(), }) path = os.path.join(out_dir, f"{name}.jsonl") with open(path, "w", encoding="utf-8") as fh: for item in funcs: fh.write(json.dumps(item, ensure_ascii=False) + "\n") if __name__ == "__main__": main()

这段骨架看着简单，但有两个细节决定了它能不能跑通。第一，currentProgram是 Ghidra 注入到脚本作用域的全局变量，在 PyGhidra 下它的生命周期由分析流程管理，脚本里千万别自己调program.save()，会破坏后续流程。第二，环境变量REA_OUT_DIR得由 REA 在起子进程时通过env_passthrough或者直接注入传递，脚本本身不该硬编码输出路径，否则并发跑的时候所有进程往同一个文件写，结果一定是乱的。

3.3 环境变量的传递链路

这一块是最容易出隐性 bug 的地方。REA 起子进程时，环境变量的传递有三条路径：REA 自己的配置、操作系统的全局环境、Ghidra 启动脚本内部的默认值。三者的优先级得心里有数，否则会出现"我明明配了但没生效"。

# REA 侧构造子进程环境的示意 env -i \ PATH=/usr/local/bin:/usr/bin:/bin \ JAVA_HOME_OVERRIDE=/opt/jdk-21-current \ REA_OUT_DIR=/data/rea/out \ REA_TASK_ID=batch-20250310-001 \ /opt/ghidra/current/support/analyzeHeadless \ /data/rea/projects \ proj_001 \ -import /data/samples/sample_001.bin \ -scriptPath /data/rea/scripts \ -preScript rea_prepare.py \ -postScript rea_export.py \ -max-cpu 6 \ -deleteProject \ -log /data/rea/logs/sample_001.log \ -logLevel INFO

用env -i清空环境再按需注入，是我强烈推荐的做法。它牺牲了一点点便利，换来的是完全可复现——同一个任务在任何机器上跑，子进程看到的环境变量集合都是一模一样的。不用env -i的话，机器 A 上碰巧有个全局变量影响了行为，机器 B 上没有，问题就变成了"只在我的机器上复现"。

注意：analyzeHeadless的参数顺序有讲究，项目路径和项目名必须紧跟在脚本名后面，且都是位置参数。顺序错了它不会报"参数错误"，而是把后面的东西当成项目名的一部分，创建出一个奇怪的目录，等你发现的时候磁盘上已经躺了一堆垃圾工程。

3.4 参数计算：并发、超时、内存三者怎么配平

这三个参数是联动的，单独调任何一个都会出问题。我用一套固定的推算流程：

第一步，定单进程堆。从 2.4 节的表里按典型样本体积取，比如 4G。

第二步，算并发。并发 = floor((物理内存 × 0.7 - 系统预留) / 单进程堆)。32G 机器：(32 × 0.7 - 4) / 4 = 4.6，取 4。这里我比 2.4 节保守一点，因为无头模式下 Ghidra 还会额外占用堆外内存（反编译器是 native 的，不归 JVM 管），留点余量更稳。

第三步，反推超时。用并发数跑一批 20 个典型样本，记录总耗时 T，单样本平均耗时就是T × 并发 / 20。超时设为平均值的 3 倍，一般落在 600 – 1200 秒。

第四步，跑一轮压测看曲线。用pidstat或dstat盯内存和 CPU，如果内存曲线一路向上不回落，说明有泄漏或者堆不够；如果 CPU 长期低于 50%，说明并发还能加，或者瓶颈在磁盘 I/O。

# 压测时的观测命令 pidstat -r -u -p ALL 5 60 > /data/rea/logs/pressure.log & dstat -tcmnd --output /data/rea/logs/dstat.csv 5 60

这套流程跑两三轮，参数基本就稳了。我见过太多人拍脑袋把并发放到 16，结果机器内存撑爆触发 OOM Killer，一堆进程被系统干掉，日志里全是Killed，还以为是 Ghidra 的 bug。

4. 四层验证：从冒烟测试到批量跑通

配置写完不等于能用。我习惯用四层验证逐步收紧，每层都有明确的通过判据，任何一层不过就停下排查，绝不带着问题上生产。

4.1 第一层：环境自检清单

这一层不碰 REA，只验 Ghidra 本身能不能被无头调用。

# 1. JDK 版本 /opt/jdk-21-current/bin/java -version 2>&1 | head -1 # 2. 无头入口是否可执行 test -x /opt/ghidra/current/support/analyzeHeadless && echo OK # 3. 帮助信息能否正常输出（说明 JVM 起来了） /opt/ghidra/current/support/analyzeHeadless 2>&1 | head -20 # 4. 反编译器模块是否存在 ls /opt/ghidra/current/Ghidra/Features/Decompiler/os/linux_x86_64/

第 3 步是最有价值的自检。只要帮助信息能打出来，就说明 JDK 找到了、主类加载了、依赖解析了，一大半低级错误在这一步就能暴露。如果这里报UnsupportedClassVersionError，回去看 2.2 节；如果报Could not find or load main class，检查路径里是不是有空格或者中文；如果报Unrecognized VM option，说明 JDK 版本偏高，回去换成 21。

4.2 第二层：最小样本跑通

用一个自己编译的、逻辑极简的二进制做冒烟测试，别拿真实样本。这么做的原因是：最小样本排除了分析复杂度带来的干扰，能跑通就说明链路是通的，跑不通一定是配置问题，不用怀疑样本。

# 造一个最小测试样本 cat > /tmp/hello.c <<'EOF' #include <stdio.h> int add(int a, int b) { return a + b; } int main(void) { printf("%d\n", add(2, 3)); return 0; } EOF gcc -O0 -o /tmp/hello /tmp/hello.c # 手工跑一次无头分析 /opt/ghidra/current/support/analyzeHeadless \ /tmp/ghidra_smoke \ smoke_proj \ -import /tmp/hello \ -postScript rea_export.py \ -scriptPath /data/rea/scripts \ -deleteProject

通过判据有三条：进程退出码为 0；日志里出现REPORT: Analysis succeeded类似的字样；输出目录下生成了对应的 jsonl 文件，且行数不为零。三条缺一不可，尤其是最后一条——我遇到过退出码 0、日志也正常，但脚本因为lib/下的模块导入失败而静默跳过导出的情况，只看退出码会被骗过去。

4.3 第三层：脚本与插件加载验证

这一层验的是 REA 的注入链路是不是真的生效。

# rea_prepare.py —— 用来验证注入点是否命中 import os, time def main(): marker = os.environ.get("REA_TASK_ID", "no-task") print(f"[REA] prepare hook hit, task={marker}") print(f"[REA] program={currentProgram.getName()}") print(f"[REA] lang={currentProgram.getLanguageID()}") # 打印当前启用的分析器数量，确认选项可改 opts = currentProgram.getOptions("Analyzers") print(f"[REA] analyzer options keys={len(list(opts.getOptionNames()))}") if __name__ == "__main__": main()

日志里能搜到[REA] prepare hook hit就说明注入成功。这一步还顺带验了两件事：REA_TASK_ID环境变量穿透成功了（说明env_passthrough配置对），以及currentProgram在 PyGhidra 下可用（说明 Python 桥接正常）。

如果日志里什么都搜不到，按这个顺序查：脚本文件名是否和配置里一致（注意.py后缀别漏）；-scriptPath指向的目录里是否真有这个文件；脚本是否有语法错误（PyGhidra 下语法错误有时候不会打印到主日志，得看application.log）；bridge.pyghidra是否真的开了（关掉的话会用 Jython 2.7 去解析，f-string直接报错）。

4.4 第四层：批量与稳定性验证

前三层都过了，才轮到批量。批量验证的目的不是"看能不能跑完"，而是看跑完之后结果是否一致、资源是否可控、失败是否可定位。

# 批量驱动示意 for f in /data/samples/*.bin; do base=$(basename "$f" .bin) timeout 900 /opt/ghidra/current/support/analyzeHeadless \ "/data/rea/projects/$base" \ "proj_$base" \ -import "$f" \ -scriptPath /data/rea/scripts \ -preScript rea_prepare.py \ -postScript rea_export.py \ -max-cpu 6 \ -deleteProject \ -log "/data/rea/logs/$base.log" \ -logLevel INFO \ || echo "FAIL $base" >> /data/rea/logs/failed.txt done

跑完之后我做三件事。第一，抽样复跑三个样本，把两次输出的函数列表做 diff，确认结果稳定；第二，统计失败率，超过 5% 就说明参数或者样本覆盖有问题，得回头调；第三，看磁盘，-deleteProject开了之后工程目录应该基本是空的，如果还在膨胀，说明删除逻辑没生效，长期跑下去迟早撑爆盘。

4.5 验证结果判读对照表

把四层的判据整理成一张表，出问题的时候直接对号入座：

5. 踩坑实录：那些让你卡一整晚的问题

下面这些都是真实撞过的，按"启动阶段"和"运行阶段"分开列，方便按症状检索。

5.1 启动阶段就挂掉的三类问题

第一类：JDK 版本不对。报错长这样：Error: LinkageError occurred while loading main class ghidra.GhidraLauncher / java.lang.UnsupportedClassVersionError: ... class file major version 65。看到major version 65，意思是"这个类是用 JDK 21 编译的，你现在这个 JVM 版本低"。解法是设JAVA_HOME_OVERRIDE指向 JDK 21。反过来，如果报的是Unrecognized VM option 'XXX'，那是 JDK 版本偏高，降回 21。

第二类：路径里有空格或非 ASCII 字符。这个问题在 Windows 上特别常见，用户名带中文的话用户目录下全是中文路径，Ghidra 的启动脚本有些地方没做引号包裹，直接崩。判断方法：把 Ghidra 挪到/opt/ghidra这种纯英文短路径下再试，能跑就是路径问题。长期方案是把用户配置目录也挪出来，通过启动参数指定。

第三类：权限不足。analyzeHeadless需要可执行权限，解压工具不同可能丢掉这个位。chmod +x support/analyzeHeadless一下就好。另外工程目录要可写，别用 root 创建的目录去跑普通用户任务，会报Unable to create project。

提示：排启动问题时养成一个习惯——先把-logLevel调到DEBUG再跑一次。默认的 INFO 级别会吞掉很多初始化阶段的细节，尤其是 JDK 探测过程，只有 DEBUG 下才能看到它到底选了哪个 java。

5.2 起来了但结果不对的四类问题

第一类：脚本没执行，但一切看起来正常。这个最坑，因为退出码 0、日志无错、输出目录空空如也。根因通常是脚本入口函数名不对——PyGhidra 下脚本要么用模块级的main()约定，要么直接写顶层代码，两种混写会出问题。排查方法：在脚本第一行加一句print("[REA] script loaded")，看日志里有没有这行。有，说明脚本加载了但入口没进；没有，说明加载都没发生。

第二类：结果和手工跑的不一致。常见原因是分析选项不同。手工在界面里跑的时候，Ghidra 用的是持久化的用户选项；无头模式下每次都从默认值开始。要对齐，在preScript里显式设置。

# 显式固定分析选项，保证可复现 from ghidra.framework.options import Options def main(): opt = currentProgram.getOptions("Analyzers") # 关掉耗时且对本场景无用的分析器 for name in ["Decompiler Parameter ID", "Stack", "Embedded Media"]: if opt.contains(name): opt.setBoolean(name, False) if __name__ == "__main__": main()

这条经验来之不易：之前有一批样本，界面里跑出来 1200 个函数，无头跑出来 1180 个，差了 20 个。查了两天才发现是Decompiler Parameter ID这个分析器在界面里是开着的、无头默认关了，而这个分析器会额外识别出一些函数。

第三类：并发时输出串了。多个进程共用一个输出目录，如果文件名只用了程序名而没用任务 ID，同名样本直接互相覆盖。解法是把REA_TASK_ID拼进文件名，或者每个任务一个子目录。我在 3.2 节给的脚本示例用了program.getName()，这在单任务下没问题，并发下必须改。

第四类：编码问题。样本里的字符串是 UTF-8，导出来变成乱码，通常是 JVM 的file.encoding没设。在launch.properties的VMARGS里加-Dfile.encoding=UTF-8就能解决。顺带把-Dsun.jnu.encoding=UTF-8也加上，处理文件路径更稳。

5.3 性能与稳定性问题速查

最后一条值得展开说说。有段时间我把并发从 4 加到 8，结果总吞吐反而降了 15%。查了半天 CPU 和内存都正常，最后用iostat发现磁盘 util 长期 95% 以上——每个 Ghidra 进程在导入时都要写工程文件，并发一高全挤在磁盘上。后来把工程目录挪到独立 SSD，并发提到 8 才真正吃到收益。这个教训是：无头分析不是纯 CPU 密集型，工程文件的读写量被严重低估了。

5.4 一个容易被忽略的清理问题

批量跑久了，project_dir下会积累一堆.lock和.lock~文件。正常情况下进程退出会清理，但如果进程被 kill 或者超时强杀，这些锁就留下了。下一次再跑同名工程，Ghidra 会报Project is locked，然后等在那里直到超时。

# 清理残留锁（确认没有正在跑的进程后再执行） find /data/rea/projects -name "*.lock*" -mtime +1 -delete # 更稳的做法：每次任务用唯一工程名，从根上避免冲突 PROJ_NAME="proj_${TASK_ID}_${BASE_NAME}"

我更推荐后一种做法，用唯一工程名。清理残留锁是个治标的方案，万一误删了正在用的锁，反而制造新问题。唯一命名虽然会让目录里堆一些一次性工程，但配合-deleteProject其实也不占空间，而且天然支持并发。

6. 让它跑得更稳的几条个人经验

配置能跑通和能长期稳定跑，中间还差一截。这几条是我在连续跑了几万次分析之后总结出来的，不写在任何文档里，但确实省了不少事。

第一条，把版本号写进日志。每次任务开始，先记录 Ghidra 版本、JDK 版本、脚本的 git commit、REA 配置文件的哈希。这些信息在半年后复盘"为什么当时这批结果和现在不一样"的时候，价值千金。我现在的做法是让preScript第一件事就是把这些写到输出文件的首行，跟着结果走。

第二条，给每个样本留一条可复现的命令行。REA 在起进程的同时，把完整命令行 append 到一个commands.log里。遇到问题样本，从日志里捞出那行命令，手工跑一遍就能复现，不用去猜 REA 当时传了什么参数。这个小动作排查效率提升非常明显。

第三条，不要追求 100% 的成功率。二进制分析这个领域，总有一小部分样本会因为格式不标准、加壳、损坏而失败。我现在的做法是把失败样本单独归档，每周集中看一次，找出共性问题再决定要不要改配置。为了把最后 3% 的失败率干掉而把超时调到两小时，整体吞吐会掉一半，不划算。

第四条，先用小规模验证再放量。任何配置改动，哪怕只是改了max_mem，也先用 20 个样本跑一轮。Ghidra 的参数之间耦合比想象中紧，改一个地方经常在别处冒出新问题，小步快跑比一把梭稳得多。

第五条，定期重新校验 JDK。系统更新、包管理器的清理脚本、甚至某些运维自动化都可能悄悄改掉/opt/jdk-21-current这个软链的指向。我现在的监控脚本每天跑一次 2.2 节里那几条校验命令，major version不是 65 就告警。这个检查成本几乎为零，但拦下过两次因为软链被改导致的批量失败。