Ghidra BSim 实战指南：跨编译器、跨架构的函数相似性匹配与 BSim 数据库操作

本文以 Ghidra 官方 BSim 教程（GhidraDocs/GhidraClass/BSim/README.md）为主线，系统讲解 BSim 插件的工作原理、H2 后端数据库的创建与填充、GUI 与命令行两种查询/入库方式、匹配结果评估与"信息回写"操作、可执行文件级聚合结果、Overview 查询、过滤器以及脚本化扩展。读完后，你可以独立建立并查询一个 BSim 数据库，用行为相似度匹配识别不同编译器、不同架构或不同源代码版本之间的同一函数，并把匹配到的名称与签名安全地应用到被逆向的程序中。

1. BSim 是什么：行为相似度（Behavioral Similarity）

BSim 是 Ghidra 的一个插件，用于在（可能是大规模的）二进制集合中查找结构上相似的函数。它基于 Ghidra 的反编译器（decompiler）工作，能够跨越编译器、目标架构乃至源代码的小幅修改找到匹配。BSim 旨在帮助回答如下逆向工程问题（引自 BSimTutorial_Intro.md）：

• 这个可执行文件静态链接了哪些库？
• 这个可执行文件是否与我之前分析过的另一个可执行文件共享代码？
• 同一可执行文件的版本 1 和版本 2 之间有什么差异？
• 这个可执行文件是否在一个大型二进制集合中的某个程序里共享代码？
• 这个函数是否来自某个开源库？

1.1 工作原理：特征向量 + 余弦相似度 + LSH 索引

BSim 的核心思想是为每个函数生成一个特征向量（feature vector）：

• 向量由 Ghidra 反编译器生成，每个特征表示该函数一小段数据流和/或控制流；
• 反编译器会归一化特征向量表示，使得不同但功能等价的代码常常产生相同的特征；
• 常量值、寄存器名、数据类型等属性被刻意排除在特征之外。

向量之间用**余弦相似度（cosine similarity）**比较。由编译器差异、目标架构差异和/或源代码小改动引起的向量差异，通常表现为"接近但不相同"的向量。

向量可以存入专用数据库。能容纳大量向量的 BSim 数据库维护一个基于**局部敏感哈希（locality-sensitive hashing, LSH）**的索引，该索引大幅减少所需的向量比较次数，从而快速检索结果。

关于数据库模板，教程原文有两点值得注意：

• 建库需要一个数据库模板（database template），它决定索引的具体细节；
• 当前 Ghidra 提供 medium（面向最多 1000 万个唯一向量）与 large（面向最多 1 亿个唯一向量）两种模板。

查询 foo 通常返回若干潜在匹配，每个匹配可以在并排（side-by-side）视图中与 foo 对比，且函数名等信息可快速从匹配拷贝到 foo。这些向量常被称作函数的 BSim 签名（BSim signature）。名称 "BSim" 即 Behavioral Similarity——每个特征近似函数行为的一小段，向量接近的函数"行为相似"。

1.2 三大组件与三种后端

使用 BSim 涉及三类组件：

• BSim 客户端（BSim Client）：即启用了 BSim 插件的 Ghidra 实例，逆向工程在这里发生；
• BSim 数据库（BSim Database）：存储 BSim 签名以及每个函数与其所属可执行文件的部分元数据，特别是关联 Ghidra 程序的 ghidra:// URL；不存储反汇编或反编译代码；
• Ghidra 项目（Ghidra Project）：存储用于填充 BSim 数据库的被分析程序。给定一个 BSim 匹配，客户端可通过 ghidra:// URL 从 Ghidra 项目取回程序进行并排比较；单个 BSim 数据库可引用多个 Ghidra 项目。

支持的数据库后端有三种：

1. PostgreSQL：Ghidra 发行版包含 PostgreSQL 源码、BSim 的 PostgreSQL 插件以及构建脚本（构建脚本见 make-postgres.sh）。只能从共享 Ghidra 项目（即需要 Ghidra 服务器）填充；服务器不支持 Windows（客户端无限制）。
2. Elasticsearch：BSimElasticPlugin 扩展包含 BSim 的 Elasticsearch 插件（见 Ghidra/Extensions/BSimElasticPlugin），需安装到已存在的 Elasticsearch 数据库中，从共享 Ghidra 项目填充。
3. H2：最简单的方式——由用户本地文件支撑（无需安装数据库服务器）、创建和填充快、全平台支持；不适合大规模二进制集合或多用户；可从非共享（本地）或共享 Ghidra 项目填充。

本教程（下文）全程采用 H2 后端。

对应源码侧的实现证据：GUI 入口插件为 BSimSearchPlugin.java，命令行工具的实现与命令定义位于 BSimLaunchable.java 等 ghidra.features.bsim.query 包中，详细参考文档见内置帮助 CommandLineReference.html 与 IngestProcess.html。

2. 启动 Ghidra 并启用 BSim 插件

1. 启动 Ghidra；
2. 为本教程新建一个非共享（non-shared）项目；
3. 启动 Code Browser。

启用 BSim 的步骤：

1. 在 Code Browser 中选择 File → Configure；
2. 点击 BSim 条目上的 Configure 链接；
3. 在弹出的对话框中，确保 BSimSearchPlugin 复选框被勾选。

3. 从 GUI 创建并填充 H2 BSim 数据库

3.1 创建数据库

先在文件系统上建一个目录用于存放数据库，然后在 Code Browser 中：

1. 运行 Ghidra 脚本 CreateH2BSimDatabaseScript.java；
2. 在对话框中：Database Name 填 example；Database Directory 选择刚才创建的目录；其余字段保持默认；
3. 点击 OK。

3.2 填充数据库

教程用 Ghidra 发行版自带的可执行文件来填充数据库：

1. 以默认分析选项导入并分析 <ghidra_install_dir>/GPL/DemanglerGnu/os/linux_x86_64/demangler_gnu_v2_41（Ghidra 的 GNU 反修饰器，其源代码位于 GPL/DemanglerGnu/src 下，教程还对比了 demangler_gnu_v2_24 与 demangler_gnu_v2_41 两个版本的 c/argv.c）；
2. 保存该分析后的程序；
3. 在该程序上运行 Ghidra 脚本 AddProgramToH2BSimDatabaseScript.java：脚本会让你选择 H2 数据库文件，选择数据库目录中的 example.mv.db；
4. 之后你随时可以把其他程序跑一遍该脚本，把它们的签名加入此数据库。

4. 基本 BSim 查询

4.1 注册 BSim 数据库（Server Manager）

如果建库时未勾选 Add New Server to Server Manager 选项，则需手动注册：

1. Code Browser 中选择 BSim → Manage Servers；
2. 在 BSim Server Manager 对话框中点击绿色加号按钮；
3. 选择 File 单选按钮，通过选择器选中 example.mv.db；
4. 点击 OK，再点击 Dismiss 关闭对话框。

4.2 发起查询

发起 BSim 查询的方式包括：

• Code Browser 的 BSim → Search Functions...；
• 在 Listing 中右键选择 BSim → Search Functions...；
• 点击 Code Browser 工具栏上的 BSim 图标。

被查询的函数取决于当前选择：没有选择时查询包含当前地址的函数；有选择时查询所有入口点落在选择范围内的函数。在 Listing 窗口按 Ctrl-A 全选后发起查询，即可一次性查询整个程序的所有函数。

也可以从反编译器窗口发起：右键单击函数名 token 并选择 BSim...，即可查询对应函数。该操作在反编译函数签名中的名称 token 以及被调用者名称 token 上均可用。

以上所有入口都会打开 BSim Search Dialog（BSim 搜索对话框），在其中可以：选择要查询的 BSim 数据库、设置查询阈值、限制每个函数返回的结果数、设置过滤器。

4.3 关键概念：Similarity 与 Confidence

Similarity（相似度） 和 Confidence（置信度） 是评估两个向量关系的两类分数，对话框中对应字段为它们设置下限：

• Similarity：形式上即两向量夹角的余弦值；对 BSim 向量总在 0.0～1.0 之间；分数越高向量越接近；
• Confidence：直觉上衡量匹配的"分量"。共有特征提高该分数，差异特征降低该分数；共享稀有特征的贡献大于共享常见特征；对所有向量对而言没有上界，但固定向量 v 时，与自身比较得到最大置信度，该值称为 v 的 self-significance（自显著性）。

Confidence 用于判断匹配是否"有意义"。例如许多可执行文件都含一个只返回常量的函数，两者对应向量相似度为 1.0，但匹配置信度会很低——说明这两个程序"共享"这段代码并不重要。

阈值设置是一个权衡：阈值更低，数据库越可能返回存在显著差异的合法匹配，但也更可能返回仅因偶然共享某些特征的匹配。由于查询结果可按 similarity 和/或 confidence 排序，常见做法是把阈值设得相对低，然后按降序查看匹配。

Matches per Function 控制单个函数返回的结果数；在大型集合中，某些小函数或常见函数可能有大量完全相同的匹配。

4.4 练习：函数识别（跨编译器）

数据库 example 含一个 Linux 可执行文件的向量（Ghidra GNU 反修饰器用的），而 Ghidra 还附带该可执行文件的其他版本，正好用来演示 BSim 能力：

1. 导入并分析 <ghidra_install_dir>/GPL/DemanglerGnu/os/win_x86_64/demangler_gnu_v2_41.exe——它基于与库中相同的源码，但用 Visual Studio 而非 GCC 编译；
2. 检查该二进制，确认原始函数名不存在（而库中的 Linux 版本有函数名）；
3. 用默认查询选项查询地址 140006760 处的函数；
4. 应恰好得到一个匹配：similarity 为 1.0，且匹配函数带有非默认名（并不总是这么顺利）。结果窗口有两张表：上表是函数级结果，下表是可执行文件级结果（见第 7 节）；
5. 在匹配行上右键执行 Compare Functions 打开并排比较：Listing View 页签显示反汇编，Decompiler View 页签显示反编译代码，代码差异自动以青色高亮，视图可切换水平/垂直分割；
6. 检查 diff 视图确认匹配有效；
7. 在 BSim Search Results 表中用 Apply Name 把匹配结果的名字应用到被查询函数上。

4.5 练习：源代码变更

1. 导入并分析 <ghidra_install_dir>/GPL/DemanglerGnu/os/linux_x86_64/demangler_gnu_v2_24——它基于比库中版本更早的源码；
2. 在 demangler_gnu_v2_24 中导航到函数 expandargv 并发出 BSim 查询；
3. 观察唯一匹配的反编译代码差异（教程答案：dupargv 的调用现在位于 if 分支中，反编译器为此生成了相关局部变量，且新增了两处 free 调用）；
4. 发行版附带的相关源码可对照验证：
   • GPL/DemanglerGnu/src/demangler_gnu_v2_24/c/argv.c
   • GPL/DemanglerGnu/src/demangler_gnu_v2_41/c/argv.c

4.6 练习：跨架构匹配

1. 导入并分析 <ghidra_install_dir>/GPL/DemanglerGnu/os/mac_arm_64/demangler_gnu_v2_41——同源代码、不同架构。注意它与填充数据库的文件同名，导入时需给 Ghidra 程序另起名字或导入到不同目录；
2. 导航到 _expandargv，以 similarity 下限 0.5 发起 BSim 查询；
3. 教程解释：arm64 版本中编译器把 memmove/memcpy 替换为 __memmove_chk/__memcpy_chk（后者多一个防缓冲区溢出的参数）。被调用者的名称和函数体不进入 BSim 签名，但调用实参进入，这解释了为何两个向量不完全相同；
4. 查看 Listing View 页签确认架构确实不同。

4.7 关于查询阈值与索引的说明

问：把 similarity 和 confidence 阈值都设为 0.0，查询会返回库中所有函数吗？答：不会，因为：

• 对于有索引的数据库（PostgreSQL 与 Elasticsearch），索引被设计为只在"可能相近"的向量之间做向量比较，大多数向量根本不会被列为候选；
• 无论何种后端，只有 confidence 高于查询置信度阈值的匹配才会显示。界面不允许设置负的置信度阈值，但置信度分数可以是负数；
• Matches per Function 参数同样限制返回的函数数量。

5. 命令行分析：构建 PostgreSQL 目标文件并用 Headless 分析器批量分析

后续练习需要向 BSim 数据库批量填充二进制。教程的做法：BSim 插件自带构建 PostgreSQL 后端的脚本，构建过程会生成数百个目标文件，于是构建 PostgreSQL 并"收割"所需目标文件即可（教程继续用 H2 后端，不运行任何 PostgreSQL 代码，只是分析构建 PostgreSQL 时产生的文件）。

注意：这些文件必须在 Linux 或 macOS 机器上构建；Windows 用户可在 Linux 虚拟机中构建。

在 shell 中执行（若构建失败，错误信息通常很有提示性，见 make-postgres.sh 中的注释）：

cd <ghidra_install_dir>/Ghidra/Features/BSim
export CFLAGS="-O2 -g"
./support/make-postgres.sh
mkdir ~/postgres_object_files
cd build
find . -name p*o -size +100000c -size -700000c -exec cp {} ~/postgres_object_files/ \;
cd os/linux_x86_64/postgresql/bin
strip -s postgres

继续的 Windows 用户需把 ~/postgres_object_files 目录和被 strip 后的 postgres 可执行文件拷贝到 Windows 机器。

6. 用 Headless 分析器导入并分析这些文件

Headless 分析器（analyzeHeadless，独立于 BSim 的工具）是分析大量二进制的唯一可行方式。其文档位于发行版 support 目录的 analyzeHeadlessREADME.html。在 Linux 上执行：

cd <ghidra_install_dir>/support
./analyzeHeadless <ghidra_project_dir> postgres_object_files -import ~/postgres_object_files/*

（Windows 上使用 analyzeHeadless.bat 并相应调整路径。）

该命令会在 <ghidra_project_dir> 下创建一个名为 postgres_object_files 的本地 Ghidra 项目。

7. BSim 命令行工具：generatesigs / commitsigs / createdatabase

位于 Ghidra 发行版 support 目录的 bsim 命令行工具用于创建、填充和管理 BSim 数据库，适用于所有后端。不带参数运行 bsim 会打印详细用法说明（完整参考见内置帮助 CommandLineReference.html）。

7.1 生成签名文件

签名文件是包含 BSim 签名及 BSim 服务器所需元数据的 XML 文件。

重要：执行下列步骤前建议先退出 Ghidra，因为：H2 数据库同一时刻只能被一个进程访问；如果 Ghidra 中打开了 postgres_object_files 项目，签名生成会失败——非共享项目打开时会被加锁。

cd <ghidra_install_dir>/support
mkdir ~/bsim_sigs
./bsim generatesigs ghidra:/<ghidra_project_dir>/postgres_object_files ~/bsim_sigs --bsim file:/<database_dir>/example

• ghidra:/ 参数是保存已分析二进制的本地项目；注意本地项目的 URL 中只有一个正斜杠；
• --bsim 参数是 BSim 数据库的 URL。此命令不向数据库添加签名，但会查询数据库的设置。

7.2 提交签名文件

./bsim commitsigs file:/<database_dir>/example ~/bsim_sigs

签名提交后，重新启动 Ghidra。

7.3 建库（Aside）

若当时不是用 CreateH2BSimDatabaseScript.java 建的库，也可以直接：

./bsim createdatabase file:/<database_dir>/example medium_nosize

• medium_nosize 是数据库模板：
  • "medium"（对比 "large"）影响向量索引，对 H2 数据库无实际意义；
  • "nosize" 表示不小于 4 字节的 varnode 大小差异不进入 BSim 特征，这是允许 32 位与 64 位代码互相匹配所必需的；
• createdatabase 命令同样可用于在已配置好的 PostgreSQL 或 Elasticsearch 服务器上建库。

7.4 可执行文件类别与函数标签（Aside）

BSim 数据库可以记录用户自定义元数据：关于可执行文件的类别（categories）和关于函数的标签（tags），两者都可作为 BSim 查询的过滤元素。例如把查询限定在类别为 "OPEN_SOURCE" 的可执行文件内，或限定在标签为 "COMPRESSION_FUNCTIONS" 的函数上。

BSim 中的可执行文件类别由 program properties 实现，函数标签对应 Ghidra 的函数标签；属性和标签在 Ghidra 中另有独立于 BSim 的用途，因此想让 BSim 数据库记录某个类别或标签必须显式声明，例如登记 ORIGIN 类别：

./bsim addexecategory file:/<database_dir>/example ORIGIN

可执行文件的类别可用脚本 SetExecutableCategoryScript.java 设置。

8. 评估匹配并把信息回写（Evaluating Matches and Applying Information）

经过前述各节，我们手上有：一个被 strip 的 postgres 可执行文件、一个包含带调试信息目标文件的 Ghidra 项目、一个包含目标文件签名的 BSim 数据库。下面用 BSim 协助逆向 postgres（注意：调试信息并非 BSim 必需，但很便利；应用调试信息可能改变 BSim 签名，从而对带/不带调试信息函数之间的匹配产生不利影响）。

导入并分析 strip 后的 postgres 到教程项目，然后：

1. 在 Listing 中 Ctrl-A 全选函数；
2. 对数据库 example 发起 BSim 查询（后续几个练习复用本次查询结果，不关结果窗口即可）；
3. 按 confidence 排序，找到匹配函数为 grouping_planner 的行，postgres 中对应函数应为默认名；
4. 在并排反编译器视图中查看——匹配方因调试信息有更好的数据类型信息；
5. 教程设问：为什么 double 参数的位置在两个函数中不同？答案是浮点值与整型/指针值通过不同的寄存器组传递，两种顺序都与各自指令一致；调试信息记录了具体的函数签名（及参数顺序）并由 Ghidra 应用，无调试信息的版本则是反编译器用启发式推断的签名。

8.1 反编译器 Diff 视图中的高亮颜色

差异较多时，diff 面板会非常"花哨"。术语：点击反编译器面板中的某个 token，该 token 成为聚焦 token（focused token）。颜色含义：

• 青色（Cyan）：高亮两个函数之间的差异；
• 粉色（Pink）：高亮聚焦 token 及其匹配 token；
• 薰衣草色（Lavender）：聚焦 token 没有匹配时的高亮；
• 橙色（Orange）：聚焦 token 不适配（ineligible）匹配时的高亮——如空白 token、变量声明中的 token 等永远不会被分配匹配。

8.2 滚动锁定/解锁

Diff 窗口默认同步滚动：在一个窗口滚动会带动另一个窗口。反编译器 Diff 窗口通过"左函数某行 ↔ 右函数某行"的匹配来实现对齐，初始以函数签名对齐；在任一侧点击时，若聚焦 token 有匹配，滚动会以包含匹配 token 的行重新居中；若无匹配，则用离聚焦 token 最近的有匹配的 token 对齐。同步滚动可用工具栏上的锁/解锁图标切换。

8.3 Apply 三种"信息回写"动作

在左侧面板右键，Apply From Other 菜单下有三个动作，安全程度递增：

1. Function Name：应用右侧函数的名称和命名空间；
2. Function Signature：应用名称、命名空间和"骨架"数据类型；结构体和联合体数据类型不迁移，而是创建空占位结构体；
3. Function Signature and Data Types：应用名称和签名以及完整数据类型——可能导入大量数据类型（考虑引用其他结构的结构体）。

警告：应用完整数据类型前必须绝对确认两侧数据类型完全相同。若某数据类型定义有任何改动，即便 similarity 为 1.0 的 BSim 匹配也可能把错误数据类型带进程序；跨架构匹配应用完整数据类型同样有问题。

BSim Search Results 窗口的 Function Matches 表行上也有同名的动作；Status 列显示哪些行已应用过匹配。

8.4 Compare Matching Callees（比较被调用者）

token 匹配算法通过考虑 CALL 指令的输入/输出数据流来匹配两边的函数调用，但不处理被调用者的函数体。给定一对匹配调用，可用 Compare Matching Callees 动作打开被调用者的新比较窗口。练习步骤：在左面板按 Ctrl-F 搜索 FUN_，找到左侧为默认名、右侧为非默认名（且非外部函数）的匹配调用，对匹配 token 右键执行 Compare Matching Callees，把右侧函数的签名与数据类型应用到左侧函数，并验证更新反映在调用者的 diff 视图中。

8.5 多重比较

面板顶部下拉菜单控制当前显示的函数，便于对同一函数的多个匹配逐一评估。练习：在 BSim Search Results 窗口右键列名 → Add/Remove Columns 启用 Matches 列，找两个各有恰好 2 个匹配的 postgres 函数，选中对应 4 行执行 Compare Functions，然后试验各面板的下拉菜单。

9. 从函数匹配到可执行文件匹配（Executable Results 表）

结果窗口下表（Executable Results）每行对应数据库中的一个可执行文件，其信息是把所有函数级匹配聚合到该行可执行文件的结果。行右键动作：

• Load Executable：在 Code Browser 中以只读副本打开该程序；
• Filter on this Executable：应用过滤器，使 Function Matches 表只显示出现在该可执行文件中的匹配。

关键列语义（教程练习中要求亲手验证）：

• Function Count：在该行可执行文件中至少有 1 个匹配的被查询函数个数（foo 在同一可执行文件有 2 个以上匹配也只计 1）；
• Confidence（可执行文件级）：所有进入该可执行文件的匹配置信度之和；若 foo 对某可执行文件有多个匹配，只有函数级置信度最高的那个参与可执行文件级置信度分数。

练习引导你观察：按降序 Function Count 排，demangler_gnu_v2_41 名次靠前；按降序 Confidence 排则名次后移——这说明匹配多但置信度和偏低时，往往是许多小函数/通用函数的"常见签名"匹配。用 Filter on this Executable 过滤（可通过工具栏 Filter Results 图标移除）后逐条检查即可验证。最后，找出 demangler_gnu_v2_41 中最高置信度匹配，把 Confidence 下限略调高于该值再查一次全部 postgres 函数，验证 demangler_gnu_v2_41 不再出现在可执行文件匹配列表中。

结论：无关函数可能彼此重复（因为小或因为执行通用动作），这类函数会"污染"整体查询结果——下一节的 Overview 查询就是治理手段。

10. Overview 查询：命中计数、自显著性与向量哈希

Overview Query 查询 BSim 数据库中每个函数的匹配数量，但不返回匹配函数本身；可以设置 Similarity/Confidence 阈值，但没有 "Matches per Function" 上限、也不支持过滤器。入口：BSim → Perform Overview...。

练习要点：

1. 对 postgres 用默认阈值做 Overview 查询（结果窗口见下图风格），按 Hit Count 升序排序——通常命中数最多的函数 self-significance 最低，可在表中验证；
2. 命中数最高的函数都是 PostgreSQL 错误报告函数：函数体高度相似且 BSim 签名相同；
3. 用选择驱动查询：在 Overview 表中选中所有命中数 ≤ 2 的函数，右键执行 Search Selected Functions，按降序 Confidence 排序可发现 demangler_gnu_v2_41 排在很后面——这就是"排除高命中（通用）函数"的实用技巧；
4. Vector Hash 列：若 foo 与 bar 命中数相同，可能是特征向量不同但碰巧命中数相同，也可能是特征向量完全相同。启用 Overview 表的 Vector Hash 可选列即可区分；找到两个哈希相同的函数后，用 BSim Overview 工具栏的"转移选择到 Listing"图标把选择带回 Listing，右键 Function → Compare Function(s)，即可确认这两个函数应当拥有相同的 BSim 签名。

11. BSim 过滤器（Filters）

BSim 查询支持涉及名称、架构、编译器、入库时间、用户自定义可执行文件类别等属性的多种过滤器，分两类：

• 服务端（server-side）过滤器：作用于从 BSim 服务器返回给 Ghidra 的查询结果，通过 BSim Search 对话框中的 Filters 下拉框设置；撤销服务端过滤器只能不带该过滤器重新发起查询；
• 客户端（client-side）过滤器：作用于 BSim Search 结果表，可通过 Filter Results 图标随加随删。

练习：全选 postgres 函数并打开 BSim Search 对话框，加一条 Executable name does not equal demangler_gnu_v2_41 的过滤器，查询后确认 demangler_gnu_v2_41 不在有匹配的可执行文件列表中；用结果窗口工具栏的 Search Info 图标可查看本次查询实际应用的服务端过滤器，再用 Filter Results 图标试验客户端过滤器的添加与移除。

12. 脚本化与特征可视化

• 脚本化：BSim 脚本类别下提供了若干示例脚本，演示如何以编程方式与 BSim 交互（BSim 相关脚本集中在 Ghidra/Features/BSim/ghidra_scripts 目录，如前述建库、入库脚本）。

• 特征可视化：如果想看某函数具体有哪些 BSim 特征，可用 BSim Feature Visualizer（扩展位于 Ghidra/Extensions/BSimFeatureVisualizer）。先在 File → Configure 中启用 BSimFeatureVisualizerPlugin，然后经 BSim → BSim Feature Visualizer 打开。该插件可在反编译代码上高亮对应某特征的区域，并显示代表该特征的图。

13. 小结与要点回顾

• BSim 用反编译器生成的行为特征向量 + 余弦相似度 + LSH 索引实现跨编译器/架构/源码小改动的函数匹配；常量、寄存器名、数据类型不进特征；
• 三个组件：BSim 客户端（Ghidra 实例）、BSim 数据库（签名 + 元数据 + ghidra:// URL）、Ghidra 项目；三种后端：PostgreSQL / Elasticsearch / H2（本地、全平台、适合单用户与中小规模）；
• 关键分数：Similarity（0~1，向量接近度）与 Confidence（无固定上界，共享稀有特征贡献更大；与自身比较得 self-significance）；实践上低阈值 + 降序排序是推荐策略；
• 批量入库的标准流水线：analyzeHeadless 批量分析 → bsim generatesigs 生成 XML 签名（注意 H2 单进程访问与非共享项目文件锁）→ bsim commitsigs 提交；
• 模板后缀 medium/large（索引规模）与 nosize（≥4 字节 varnode 大小差异不进特征，使 32/64 位代码可互配）；
• 结果评估：反编译 diff 视图的颜色语义、滚动锁定、Apply Name / Function Signature / Function Signature and Data Types 三级回写（完整数据类型需高度谨慎）、Compare Matching Callees、多重比较；
• 治理"通用函数污染"：Executable Results 表的 Function Count/Confidence 聚合语义、Overview 查询的 Hit Count 与 Vector Hash 列、服务端/客户端过滤器。

完整教程章节文档位于 GhidraDocs/GhidraClass/BSim 目录，Ghidra 内置帮助中的 "BSim" 条目（帮助主题源码见 Ghidra/Features/BSim/src/main/help/help/topics/BSim）则提供本教程未展开的详细信息（如 PostgreSQL/Elasticsearch 的数据库配置与命令行完整参考）。