使用 Binary Ninja 反虚拟化 C++
在我的第一篇博客文章中,我介绍了 Binary Ninja 的 Low Level IL (LLIL) 的基本结构,以及如何使用 Python API 遍历和操作它。现在,我们将做一些更有趣的事情。
逆向工程由面向对象语言编译的二进制文件可能具有挑战性,尤其是在处理虚函数时。在 C++ 中,调用虚函数涉及在虚表(vtable)中查找函数指针,然后进行间接调用。在反汇编中,你只能看到类似 mov rax, [rcx+0x18]; call rax 的指令。如果你想知道对于给定的类对象它将调用什么函数,你必须找到虚表,然后确定该偏移处的函数指针。
或者,你可以使用这个插件!
示例插件:导航到虚函数
vtable-navigator.py 是一个示例插件,可以从调用指令导航到给定类的虚函数。首先,插件使用 LLIL 在构造函数中引用时识别指定类的虚表。接下来,它将预处理调用指令的基本块,以跟踪寄存器赋值及其对应的 LLIL 表达式。最后,插件将处理调用的 LowLevelILInstruction 对象,并通过递归访问寄存器赋值表达式来计算要调用的函数的偏移量。
发现虚表指针
图 1:两个类继承自一个基虚类。每个类的虚表指向其各自的虚函数实现。
在最简单的形式中,类构造函数将指向其虚表的指针存储在内存中的对象结构中。存储虚表指针的两种最常见方式是直接引用虚表指针的硬编码值,或将虚表指针存储在寄存器中,然后将该寄存器的值复制到内存中。因此,如果我们查找从寄存器写入内存地址且没有偏移的情况,那么它可能就是虚表。
一个示例构造函数。高亮显示的指令将虚表存储在对象结构中。
我们可以通过查找构造函数 LowLevelILFunction 对象(如第一部分所述)中的 LLIL 指令来检测第一种虚表指针赋值,该指令将常量值存储到包含在寄存器中的内存地址。
根据 API,LLIL_STORE 指令有两个操作数:dest 和 src。两者都是 LLIL 表达式。对于这种情况,我们寻找由寄存器提供的目标值,因此 dest 应该是 LLIL_REG 表达式。要存储的值是一个常量,因此 src 应该是 LLIL_CONST 表达式。如果我们匹配这个模式,那么我们假设该常量是虚表指针,读取该常量指向的值(即 il.src.value),并再次检查那里是否有函数指针,以确保它确实是一个虚表。
|
|
相当直接,但让我们看看第二种情况,即值首先存储在寄存器中。
对于这种情况,我们搜索 LLIL_STORE 的 dest 和 src 操作数都是 LLIL_REG 表达式的指令。现在我们需要仅基于寄存器来确定虚表的位置。
这就是事情变得酷的地方。这种情况不仅展示了 LLIL 的使用,还展示了在 LLIL 上执行的数据流分析有多么强大。如果没有数据流分析,我们将不得不解析这个 LLIL_STORE 指令,找出被引用的寄存器,然后向后步进以找到分配给该寄存器的最后一个值。有了数据流分析,寄存器的当前值可以通过单次调用 get_reg_value_at_low_level_il_instruction 轻松获得。
|
|
寄存器赋值的传播
现在我们知道虚表的位置了,让我们找出调用的偏移量。要确定这个值,我们需要从调用指令回溯程序状态到从内存中检索虚表指针的时刻,计算虚表中的偏移量,并发现正在调用的函数。我们通过实现一个基本的数据流分析来完成这种跟踪,该分析预处理包含调用指令的基本块。这个预处理步骤将让我们查询基本块中任何点的寄存器状态。
|
|
在基本块的每条指令处,我们维护一个寄存器状态表。当我们遍历每个 LowLevelILInstruction 时,遇到 LLIL_SET_REG 操作时会更新此表。对于每个被跟踪的寄存器,我们存储负责更改其值的 LowLevelILInstruction。之后,我们可以查询该寄存器的状态并检索 LowLevelILInstruction,并递归查询 src 操作数的值,这是寄存器当前代表的表达式。
此外,如果遇到 LLIL_CALL 操作,则从该点开始清除寄存器状态。被调用的函数可能会修改寄存器,因此最安全的假设是调用后的所有寄存器都具有未知值。
现在我们拥有了所有需要的数据来模拟虚表指针解引用并计算虚函数偏移量。
计算虚函数偏移量
在深入计算偏移量的任务之前,让我们考虑如何模拟行为。回顾图 1,分发虚函数可以概括为四个步骤:
- 从内存中的对象结构读取指向虚表的指针(LLIL_LOAD)。
- 如果要分发的函数不是第一个函数,则向指针值添加偏移量(LLIL_ADD)。
- 在计算出的偏移量处读取函数指针(LLIL_LOAD)。
- 调用函数(LLIL_CALL)。
因此,分发虚函数可以通过评估 LLIL_CALL 指令的 src 操作数表达式来模拟,递归访问每个表达式。当遇到步骤 1 的 LLIL_LOAD 指令时,达到递归的基本情况。该 LLIL_LOAD 的值是指定的虚表指针。虚表指针值被返回,并通过先前的递归迭代传播回去,用于这些迭代的评估。
让我们逐步评估一个示例,看看模型如何工作以及如何在 Python 中实现。以下是在 x86 中的虚函数分发。
|
|
这段汇编将被翻译成以下 LLIL。
|
|
为这两个 LLIL 指令构建树结构会产生以下结构。
图 2:示例虚表分发汇编的 LLIL 树结构。
LLIL_CALL 的 src 操作数是一个 LLIL_LOAD 表达式。我们根据其操作使用处理程序评估 LLIL_CALL 的 src 操作数。
|
|
因此,我们递归评估此虚函数分发的第一次迭代是调用 handle_load。
|
|
handle_load 首先增加遇到的 LLIL_LOAD 表达式计数。回想一下,我们解引用虚表的模型期望两个 LLIL_LOAD 指令:虚表指针,然后是我们想要的函数指针。向后跟踪程序状态意味着我们将首先遇到函数指针的加载,然后是虚表指针的加载。此时计数为 1,因此递归不应终止。相反,LLIL_LOAD 的 src 操作数由 src 表达式的处理程序函数递归评估。当此处理程序调用完成时,addr 应包含指向要分发的函数指针的地址。在这种情况下,src 是一个 LLIL_ADD,因此调用 handle_add。
|
|
handle_add 递归评估 LLIL_ADD 表达式的左侧和右侧,并将这些值的总和返回给其调用者。在我们的示例中,左操作数是一个 LLIL_REG 表达式,因此调用 handle_reg。
|
|
这就是我们的数据流分析发挥作用的地方。使用当前寄存器状态(由 current_defs 描述),我们识别代表此 LLIL_REG 表达式当前值的 LLIL 表达式。基于上面的示例,current_defs[‘eax’] 将是表达式 [ecx].d。这是另一个 LLIL_LOAD 表达式,因此再次调用 handle_load。这次,load_count 增加到 2,满足基本情况。如果我们假设在我们的示例中用户选择的类的构造函数位于 0x1000,那么 handle_load 将返回值 0x1000。
左操作数评估完成后,现在轮到 handle_add 评估右操作数。这个表达式是一个 LLIL_CONST,非常容易评估;我们只需返回表达式的值操作数。左右操作数都评估完成后,handle_add 返回表达式的和,即 0x1004。handle_load 接收从 handle_add 返回的值,然后从 BinaryView 读取位于该地址的函数指针。然后,我们可以通过调用 BinaryView 对象中的 bv.file.navigate(bv.file.view, function_pointer) 来更改当前显示的函数。
回到之前的 LLIL 树结构,我们可以注释这些结构以可视化递归和具体数据传播是如何发生的。
图 3:示例虚表分发汇编的 LLIL 树结构,注释了处理程序调用和具体值沿调用链传播。
示例:矩形和三角形
对于一个真实世界的示例,我使用了这个 C++ 教程的略微修改版本,你可以在这里找到。以下是插件运行的演示:
如果你为 x86-64 和 ARM 编译 virtual-test.cpp,并在安装了插件的 Binary Ninja 中打开二进制文件,你会发现它可以在两种架构上工作,而无需任何架构特定的代码。这就是中间表示的美妙之处!
前进并分析
Binary Ninja 的 LLIL 是一个强大的功能,使跨平台程序分析能够轻松开发。正如我们所看到的,它的结构简单,但允许表示甚至最复杂的指令。Python API 是一个高质量的接口,我们可以有效地使用它来遍历指令并轻松处理操作和操作数。更重要的是,我们已经看到了简单的示例,说明由 LLIL 启用的数据流分析如何允许我们开发跨平台插件来执行程序分析,而无需实现复杂的启发式方法来计算程序值。你还等什么?拿起一份 Binary Ninja,开始用 LLIL 编写你自己的二进制分析,别忘了参加 Sophia 在 INFILTRATE 2017 上使用 Binary Ninja LLIL 进行的“Next-level Static Analysis for Vulnerability Research”演讲。
如果你喜欢这篇文章,请分享: Twitter LinkedIn GitHub Mastodon Hacker News
页面内容 示例插件:导航到虚函数 发现虚表指针 寄存器赋值的传播 计算虚函数偏移量 示例:矩形和三角形 前进并分析 最近文章 我们构建了 MCP 一直需要的安全层 利用废弃硬件中的零日漏洞 Inside EthCC[8]:成为智能合约审计员 使用 Vendetect 大规模检测代码复制 构建安全消息传递很难:对 Bitchat 安全辩论的细致看法 © 2025 Trail of Bits。 使用 Hugo 和 Mainroad 主题生成。