Ghidra BSim 可执行结果表Executable Results详解从函数匹配聚合到可执行文件级归因【免费下载链接】ghidraGhidra is a software reverse engineering (SRE) framework项目地址: https://gitcode.com/GitHub_Trending/gh/ghidra在 Ghidra 的 BSimBinary Similarity Matching工作流中查询一个二进制库例如本教程使用的example数据库后得到的搜索结果窗口包含两张表上方的Function Matches表记录函数级匹配下方的Executable Results表则把这些函数级匹配按可执行文件聚合。本篇以 Ghidra 官方教程 From Matching Functions to Matching Executables 为主体完整讲解 Executable Results 表的结构、两个右键动作Load Executable、Filter on this Executable的用法与底层实现并带你做完教程中的四个练习用 Function Count 与 Confidence 两列排序解释高匹配数但低置信度的现象理解小函数/通用函数如何污染批量查询结果并通过提高 Confidence 阈值验证归因结论。Executable Results 表的定位与结构BSim 搜索结果窗口由 BSimSearchResultsProvider 构建分为上下两部分上表Function Matches每一行是一次被查询函数 ↔ 库中某函数的匹配携带 Similarity 与 Confidence 两个分数下表Executable Results每一行对应数据库中的一个可执行文件按 MD5 去重的可执行记录该行内容是该可执行文件内所有函数级匹配的聚合。从 BSimExecutablesSummaryModel 的列定义可以看到下表默认包含这些信息列列名含义源码取值可执行信息名称、类别、日期等数据库中登记的可执行记录元数据ExecutableRecord对应字段Architecture该可执行文件的目标架构getArchitecture()Compiler编译器信息getNameCompiler()Function Count有多少个被查询函数在该可执行文件里至少有一个匹配rowObject.getFunctionCount()Confidence该可执行文件内所有匹配的显著度significance/confidence总和rowObject.getSignificanceSum()URL可执行文件在数据库中的来源地址无则为 nonegetURLString()理解这张表的关键在于Function Count 和 Confidence 的计数规则教程原文强调练习 1、2 都依赖它Function Count如果查询函数foo在某个可执行文件里有 2 个及以上匹配它对该行的 Function Count 也只贡献1Confidence如果foo在同一可执行文件里有多个匹配只有置信度最高的那一个函数级置信度参与该行的可执行级置信度求和。这两条规则在 ExecutableResult 的静态方法generateFromMatchRows中有直接对应的实现约 L103-L133该方法遍历过滤后的匹配行按被查询函数分组对每个查询函数先在其命中过的可执行文件集合里保留max(sumsignif, signif)即只保留最高置信度随后在finalizeExecutableResult中把该最大值累加进全局表的sumsignif同时funccount 1。源码注释也明确写道 Function Count 是 number of functions with matches into this executable、Significance Sum 是 sum of significance scores for all matching functions。另外Executables 表可以隐藏/显示工具栏上有Show Executables Table切换按钮ToggleDockingAction且任何过滤变化见下文 Filter Results都会重新调用ExecutableResult.generateFromMatchRows(filteredrows)重建下表——也就是说下表的行数与内容永远由上表当前可见的匹配行推导而来。右键动作一Load Executable只读加载匹配的可执行文件在 Executable Results 表中选中一行后右键菜单提供Load Executable动作在 Code Browser 中打开一个该程序的只读副本方便你直接查看/导航到匹配函数所在的库端程序。对应实现在 BSimSearchResultsProvider.loadExecutable取出所选行的ExecutableRecord读取其URLString数据库里登记的可执行文件来源地址然后调用openRemoteProgramInTool(programUrl)在工具中打开远程程序。动作注册处约 L163-L170可以看到它被限定在ExecutableTableActionContext上下文、且仅当getSelectedRowCount() 1恰好选中一行时可用。右键动作二Filter on this Executable把函数匹配表限定到该可执行文件第二个右键动作Filter on this Executable会施加一个过滤器使 Function Matches 表只显示发生在这一个可执行文件内的匹配。这是教程练习 3 的核心操作用于聚焦到单个可执行文件后逐条审查其匹配。从 BSimSearchResultsProvider.filterOnExecutable 的实现看它的机制非常具体ExecutableRecord exerecord c.getSelectedExecutableResult().getExecutableRecord(); Md5BSimFilterType filterType new Md5BSimFilterType(); postFilters.removeAll(filterType); postFilters.addEntry(filterType, List.of(exerecord.getMd5())); updateTableData();即以选中可执行文件的MD5构造一个Md5BSimFilterType过滤器写入结果级过滤器集合postFilters再调用updateTableData()用该过滤器重新过滤上表匹配行、重建下表。由于下表由上表推导过滤后其他可执行文件也会从 Executable Results 中消失实现只看这一个可执行文件的效果。教程还提示点击结果窗口工具栏的Filter Results图标可以移除该过滤器。该图标动作在 BSimSearchResultsProvider 中注册为 Filter Results点击后弹出BSimSearchResultsFilterDialog让你查看/清除当前的结果级过滤条件。更多过滤技巧见教程 BSim Filters 一节。教程练习用 Function Count 与 Confidence 解释匹配归因以下四个练习直接来自官方教程前提是你已按 Basic BSim Queries 一节对postgres的全部函数完成了对example数据库的查询example库包含 Ghidra 随附的 GNU demangler 可执行文件demangler_gnu_v2_41的 BSim 签名且随发行版还有demangler_gnu_v2_24等其它版本源码位于 GPL/DemanglerGnu。你的具体表格数值可能因编译器而异。练习 1按 Function Count 降序排序。按 Function Count 降序排列 Executable Results。回忆该列的定义——有多少个被查询函数在该可执行文件中至少有一个匹配同一查询函数有多个匹配也只计 1。然后观察在你的表里demangler_gnu_v2_41排在什么位置通常它会因为命中了大量被查询函数而排名靠前。练习 2按 Confidence 降序排序解释排名落差。Confidence 列是该可执行文件中所有匹配的置信度总和且每个被查询函数只贡献其最高置信度匹配。按 Confidence 降序排序后你会观察到demangler_gnu_v2_41明显沉底了。教程给出的解释是如果一个可执行文件有很多函数匹配、但置信度总和却相对偏低很可能是许多匹配来自小函数或具有常见 BSim 签名的函数——它们彼此结构相似但每个匹配的置信度都很低。练习 3过滤 抽样验证。在 Executable Results 表中右键demangler_gnu_v2_41执行Filter on this Executable把 Function Matches 表按 Confidence 降序排序。从顶部开始检查若干条匹配用右键Compare Functions打开并排反编译对比视图亲自确认练习 2 的解释是成立的——靠前的匹配确实对应真实的功能重复而大量低置信度匹配来自小函数/通用函数。验证完毕后可用工具栏Filter Results图标移除过滤器。练习 4用置信度阈值排除误报可执行文件。找出demangler_gnu_v2_41中置信度最高的那条匹配记下其数值然后重新对postgres的所有函数发起查询这次把Confidence 下界设置为略高于该值的数。验证此时 Executable Results 表中不再出现demangler_gnu_v2_41——因为库中所有能超过该阈值的匹配都不存在整个可执行文件从结果中消失。注意练习 4 中 Confidence 阈值是在BSim Search Dialog查询对话框里设置的与练习 3 的结果表级 MD5 过滤是两个不同层面的机制前者在查询时就约束返回的匹配后者在拿到结果后对两张表做显示过滤。从练习到结论小函数/通用函数会污染批量查询这组练习的核心结论是批量blanket query例如一次查询整个程序的所有函数查询中互不相关的函数之间也可能互为重复——要么因为它们足够小要么因为它们执行的是某种常见通用动作如只返回一个常量值的小函数。这类低置信度但高相似度的匹配会污染整体结果使某个可执行文件在 Function Count 排序中虚高。从源码结构看BSim 对这种情况的防御正是分数分离 多级聚合的设计Similarity向量夹角余弦衡量结构接近程度Confidence/significance 衡量匹配的含金量共享稀有特征加分、共享常见特征加分少而 Executable Results 表按每函数取最高置信度再求和的规则聚合使得聚合分数天然偏向拥有若干高显著度匹配的可执行文件而不是被一堆 1.0 相似度低显著度匹配推高。实操上因此有两条常用策略查询时把 Similarity/Confidence 阈值设得相对宽松然后按置信度降序人工审查Basic Queries 教程给出的通用实践对聚合结果可疑的可执行文件用Filter on this Executable下钻到函数级逐条核实本篇练习 3 的做法或用略高的 Confidence 阈值复查以确认其整体可排除练习 4 的做法。教程最后指出正因为无关的小函数会互相匹配裸的全库查询需要约束手段。下一节 Overview Queries 将介绍一种把查询限制到更可能有意义匹配的函数子集上的技术配合 BSim Filters 中的过滤条件可显著降低批量查询中的噪声。【免费下载链接】ghidraGhidra is a software reverse engineering (SRE) framework项目地址: https://gitcode.com/GitHub_Trending/gh/ghidra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ghidra BSim 可执行结果表（Executable Results）详解：从函数匹配聚合到可执行文件级归因
Ghidra BSim 可执行结果表Executable Results详解从函数匹配聚合到可执行文件级归因【免费下载链接】ghidraGhidra is a software reverse engineering (SRE) framework项目地址: https://gitcode.com/GitHub_Trending/gh/ghidra在 Ghidra 的 BSimBinary Similarity Matching工作流中查询一个二进制库例如本教程使用的example数据库后得到的搜索结果窗口包含两张表上方的Function Matches表记录函数级匹配下方的Executable Results表则把这些函数级匹配按可执行文件聚合。本篇以 Ghidra 官方教程 From Matching Functions to Matching Executables 为主体完整讲解 Executable Results 表的结构、两个右键动作Load Executable、Filter on this Executable的用法与底层实现并带你做完教程中的四个练习用 Function Count 与 Confidence 两列排序解释高匹配数但低置信度的现象理解小函数/通用函数如何污染批量查询结果并通过提高 Confidence 阈值验证归因结论。Executable Results 表的定位与结构BSim 搜索结果窗口由 BSimSearchResultsProvider 构建分为上下两部分上表Function Matches每一行是一次被查询函数 ↔ 库中某函数的匹配携带 Similarity 与 Confidence 两个分数下表Executable Results每一行对应数据库中的一个可执行文件按 MD5 去重的可执行记录该行内容是该可执行文件内所有函数级匹配的聚合。从 BSimExecutablesSummaryModel 的列定义可以看到下表默认包含这些信息列列名含义源码取值可执行信息名称、类别、日期等数据库中登记的可执行记录元数据ExecutableRecord对应字段Architecture该可执行文件的目标架构getArchitecture()Compiler编译器信息getNameCompiler()Function Count有多少个被查询函数在该可执行文件里至少有一个匹配rowObject.getFunctionCount()Confidence该可执行文件内所有匹配的显著度significance/confidence总和rowObject.getSignificanceSum()URL可执行文件在数据库中的来源地址无则为 nonegetURLString()理解这张表的关键在于Function Count 和 Confidence 的计数规则教程原文强调练习 1、2 都依赖它Function Count如果查询函数foo在某个可执行文件里有 2 个及以上匹配它对该行的 Function Count 也只贡献1Confidence如果foo在同一可执行文件里有多个匹配只有置信度最高的那一个函数级置信度参与该行的可执行级置信度求和。这两条规则在 ExecutableResult 的静态方法generateFromMatchRows中有直接对应的实现约 L103-L133该方法遍历过滤后的匹配行按被查询函数分组对每个查询函数先在其命中过的可执行文件集合里保留max(sumsignif, signif)即只保留最高置信度随后在finalizeExecutableResult中把该最大值累加进全局表的sumsignif同时funccount 1。源码注释也明确写道 Function Count 是 number of functions with matches into this executable、Significance Sum 是 sum of significance scores for all matching functions。另外Executables 表可以隐藏/显示工具栏上有Show Executables Table切换按钮ToggleDockingAction且任何过滤变化见下文 Filter Results都会重新调用ExecutableResult.generateFromMatchRows(filteredrows)重建下表——也就是说下表的行数与内容永远由上表当前可见的匹配行推导而来。右键动作一Load Executable只读加载匹配的可执行文件在 Executable Results 表中选中一行后右键菜单提供Load Executable动作在 Code Browser 中打开一个该程序的只读副本方便你直接查看/导航到匹配函数所在的库端程序。对应实现在 BSimSearchResultsProvider.loadExecutable取出所选行的ExecutableRecord读取其URLString数据库里登记的可执行文件来源地址然后调用openRemoteProgramInTool(programUrl)在工具中打开远程程序。动作注册处约 L163-L170可以看到它被限定在ExecutableTableActionContext上下文、且仅当getSelectedRowCount() 1恰好选中一行时可用。右键动作二Filter on this Executable把函数匹配表限定到该可执行文件第二个右键动作Filter on this Executable会施加一个过滤器使 Function Matches 表只显示发生在这一个可执行文件内的匹配。这是教程练习 3 的核心操作用于聚焦到单个可执行文件后逐条审查其匹配。从 BSimSearchResultsProvider.filterOnExecutable 的实现看它的机制非常具体ExecutableRecord exerecord c.getSelectedExecutableResult().getExecutableRecord(); Md5BSimFilterType filterType new Md5BSimFilterType(); postFilters.removeAll(filterType); postFilters.addEntry(filterType, List.of(exerecord.getMd5())); updateTableData();即以选中可执行文件的MD5构造一个Md5BSimFilterType过滤器写入结果级过滤器集合postFilters再调用updateTableData()用该过滤器重新过滤上表匹配行、重建下表。由于下表由上表推导过滤后其他可执行文件也会从 Executable Results 中消失实现只看这一个可执行文件的效果。教程还提示点击结果窗口工具栏的Filter Results图标可以移除该过滤器。该图标动作在 BSimSearchResultsProvider 中注册为 Filter Results点击后弹出BSimSearchResultsFilterDialog让你查看/清除当前的结果级过滤条件。更多过滤技巧见教程 BSim Filters 一节。教程练习用 Function Count 与 Confidence 解释匹配归因以下四个练习直接来自官方教程前提是你已按 Basic BSim Queries 一节对postgres的全部函数完成了对example数据库的查询example库包含 Ghidra 随附的 GNU demangler 可执行文件demangler_gnu_v2_41的 BSim 签名且随发行版还有demangler_gnu_v2_24等其它版本源码位于 GPL/DemanglerGnu。你的具体表格数值可能因编译器而异。练习 1按 Function Count 降序排序。按 Function Count 降序排列 Executable Results。回忆该列的定义——有多少个被查询函数在该可执行文件中至少有一个匹配同一查询函数有多个匹配也只计 1。然后观察在你的表里demangler_gnu_v2_41排在什么位置通常它会因为命中了大量被查询函数而排名靠前。练习 2按 Confidence 降序排序解释排名落差。Confidence 列是该可执行文件中所有匹配的置信度总和且每个被查询函数只贡献其最高置信度匹配。按 Confidence 降序排序后你会观察到demangler_gnu_v2_41明显沉底了。教程给出的解释是如果一个可执行文件有很多函数匹配、但置信度总和却相对偏低很可能是许多匹配来自小函数或具有常见 BSim 签名的函数——它们彼此结构相似但每个匹配的置信度都很低。练习 3过滤 抽样验证。在 Executable Results 表中右键demangler_gnu_v2_41执行Filter on this Executable把 Function Matches 表按 Confidence 降序排序。从顶部开始检查若干条匹配用右键Compare Functions打开并排反编译对比视图亲自确认练习 2 的解释是成立的——靠前的匹配确实对应真实的功能重复而大量低置信度匹配来自小函数/通用函数。验证完毕后可用工具栏Filter Results图标移除过滤器。练习 4用置信度阈值排除误报可执行文件。找出demangler_gnu_v2_41中置信度最高的那条匹配记下其数值然后重新对postgres的所有函数发起查询这次把Confidence 下界设置为略高于该值的数。验证此时 Executable Results 表中不再出现demangler_gnu_v2_41——因为库中所有能超过该阈值的匹配都不存在整个可执行文件从结果中消失。注意练习 4 中 Confidence 阈值是在BSim Search Dialog查询对话框里设置的与练习 3 的结果表级 MD5 过滤是两个不同层面的机制前者在查询时就约束返回的匹配后者在拿到结果后对两张表做显示过滤。从练习到结论小函数/通用函数会污染批量查询这组练习的核心结论是批量blanket query例如一次查询整个程序的所有函数查询中互不相关的函数之间也可能互为重复——要么因为它们足够小要么因为它们执行的是某种常见通用动作如只返回一个常量值的小函数。这类低置信度但高相似度的匹配会污染整体结果使某个可执行文件在 Function Count 排序中虚高。从源码结构看BSim 对这种情况的防御正是分数分离 多级聚合的设计Similarity向量夹角余弦衡量结构接近程度Confidence/significance 衡量匹配的含金量共享稀有特征加分、共享常见特征加分少而 Executable Results 表按每函数取最高置信度再求和的规则聚合使得聚合分数天然偏向拥有若干高显著度匹配的可执行文件而不是被一堆 1.0 相似度低显著度匹配推高。实操上因此有两条常用策略查询时把 Similarity/Confidence 阈值设得相对宽松然后按置信度降序人工审查Basic Queries 教程给出的通用实践对聚合结果可疑的可执行文件用Filter on this Executable下钻到函数级逐条核实本篇练习 3 的做法或用略高的 Confidence 阈值复查以确认其整体可排除练习 4 的做法。教程最后指出正因为无关的小函数会互相匹配裸的全库查询需要约束手段。下一节 Overview Queries 将介绍一种把查询限制到更可能有意义匹配的函数子集上的技术配合 BSim Filters 中的过滤条件可显著降低批量查询中的噪声。【免费下载链接】ghidraGhidra is a software reverse engineering (SRE) framework项目地址: https://gitcode.com/GitHub_Trending/gh/ghidra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考