使用Binary Ninja逆向C++虚拟函数调用

本文详细介绍了如何使用Binary Ninja的Low Level IL(LLIL)和Python API来逆向分析C++虚拟函数调用，包括vtable指针发现、寄存器赋值传播和虚拟函数偏移计算等技术实现细节。

使用Binary Ninja逆向C++虚拟函数调用

在我的第一篇博客文章中，我介绍了Binary Ninja的Low Level IL（LLIL）的基本结构，以及如何使用Python API遍历和操作它。现在，我们将做一些更有趣的事情。

逆向工程从面向对象语言编译的二进制文件可能具有挑战性，特别是在处理虚拟函数时。在C++中，调用虚拟函数涉及在虚拟表（vtable）中查找函数指针，然后进行间接调用。在反汇编中，你只能看到类似mov rax, [rcx+0x18]; call rax的内容。如果你想了解给定类对象将调用什么函数，你必须找到虚拟表，然后确定该偏移处的函数指针。

或者你可以使用这个插件！

示例插件：导航到虚拟函数

vtable-navigator.py是一个示例插件，可以从调用指令导航到给定类的虚拟函数。首先，插件使用LLIL在构造函数中引用时识别指定类的vtable。接下来，它将预处理调用指令的基本块，以跟踪寄存器赋值及其相应的LLIL表达式。最后，插件将处理调用的LowLevelILInstruction对象，并通过递归访问寄存器赋值表达式来计算要调用的函数的偏移量。

发现vtable指针

图1：两个类继承自一个基虚拟类。每个类的虚拟表指向其各自的虚拟函数实现。

在最简单的形式中，类构造函数在内存中的对象结构中存储指向其vtable的指针。存储vtable指针的两种最常见方式是直接引用vtable指针的硬编码值，或将vtable指针存储在寄存器中，然后将该寄存器的值复制到内存中。因此，如果我们查找从寄存器写入内存地址且没有偏移的情况，那么它可能是vtable。

一个示例构造函数。高亮显示的指令在对象结构中存储vtable。

我们可以通过在构造函数的LowLevelILFunction对象中查找LLIL指令（如第1部分所述）来检测第一种vtable指针赋值，该指令将常量值存储到包含在寄存器中的内存地址。

根据API，LLIL_STORE指令有两个操作数：dest和src。两者都是LLIL表达式。对于这种情况，我们寻找由寄存器提供的目标值，因此dest应该是LLIL_REG表达式。要存储的值是一个常量，因此src应该是LLIL_CONST表达式。如果我们匹配这个模式，那么我们假设常量是vtable指针，读取常量指向的值（即il.src.value），并再次检查那里是否有函数指针，以确保它实际上是vtable。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 如果不是内存存储，则不是vtable。
if il.operation != LowLevelILOperation.LLIL_STORE:
    continue

# vtable被直接引用
if (il.dest.operation == LowLevelILOperation.LLIL_REG and
        il.src.operation == LowLevelILOperation.LLIL_CONST):
    fp = read_value(bv, il.src.value, bv.address_size)

    if not bv.is_offset_executable(fp):
        continue

    return il.src.value

相当直接，但让我们看看第二种情况，即值首先存储在寄存器中。

对于这种情况，我们搜索LLIL_STORE的dest和src操作数都是LLIL_REG表达式的指令。现在我们需要仅基于寄存器确定虚拟表的位置。

这就是事情变得酷的地方。这种情况不仅展示了LLIL的使用，还展示了在LLIL上执行的数据流分析有多么强大。没有数据流分析，我们将不得不解析这个LLIL_STORE指令，找出被引用的寄存器，然后向后步进以找到分配给该寄存器的最后一个值。有了数据流分析，寄存器的当前值可以通过单次调用get_reg_value_at_low_level_il_instruction轻松获得。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# vtable首先加载到寄存器中，然后存储
if (il.dest.operation == LowLevelILOperation.LLIL_REG and
        il.src.operation == LowLevelILOperation.LLIL_REG):
    reg_value = src_func.get_reg_value_at_low_level_il_instruction(
        il.instr_index, il.src.src
    )

    if reg_value.type == RegisterValueType.ConstantValue:
        fp = read_value(bv, reg_value.value, bv.address_size)

        if not bv.is_offset_executable(fp):
            continue

    return reg_value.value

寄存器赋值的传播

现在我们知道了vtable的位置，让我们找出调用的偏移量。要确定这个值，我们需要从调用指令回溯程序状态到从内存检索vtable指针的时刻，计算虚拟表中的偏移量，并发现正在调用的函数。我们通过实现一个基本的数据流分析来完成这个回溯，该分析预处理包含调用指令的基本块。这个预处理步骤将让我们查询基本块中任何点的寄存器状态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

def preprocess_basic_block(bb):
    defs = {}
    current_defs = {}

    for instr in bb:
        defs[instr.instr_index] = copy(current_defs)

        if instr.operation == LowLevelILOperation.LLIL_SET_REG:
            current_defs[instr.dest] = instr

        elif instr.operation == LowLevelILOperation.LLIL_CALL:
            # 清除先前的定义，因为我们不能保证调用没有修改寄存器。
            current_defs.clear()

    return defs

在基本块的每条指令处，我们维护一个寄存器状态表。当我们遍历每个LowLevelILInstruction时，遇到LLIL_SET_REG操作时会更新此表。对于每个跟踪的寄存器，我们存储负责更改其值的LowLevelILInstruction。稍后，我们可以查询此寄存器的状态并检索LowLevelILInstruction，并递归查询src操作数的值，这是寄存器当前代表的表达式。

此外，如果遇到LLIL_CALL操作，则从该点开始清除寄存器状态。被调用的函数可能会修改寄存器，因此最安全的假设是调用后的所有寄存器都具有未知值。

现在我们拥有了建模vtable指针解引用和计算虚拟函数偏移量所需的所有数据。

计算虚拟函数偏移量

在深入计算偏移量的任务之前，让我们考虑如何建模行为。回顾图1，分发虚拟函数可以概括为四个步骤：

  1. 从内存中的对象结构读取指向vtable的指针（LLIL_LOAD）。
  2. 如果分发的函数不是第一个函数，则向指针值添加偏移量（LLIL_ADD）。
  3. 在计算的偏移量处读取函数指针（LLIL_LOAD）。
  4. 调用函数（LLIL_CALL）。

因此，可以通过评估LLIL_CALL指令的src操作数表达式来建模分发虚拟函数，递归访问每个表达式。当遇到步骤1的LLIL_LOAD指令时，达到递归的基本情况。该LLIL_LOAD的值是指定的vtable指针。vtable指针值被返回并通过先前的递归迭代传播回来，用于这些迭代的评估。

让我们逐步评估一个示例，看看模型如何工作以及如何在Python中实现。以x86中的以下虚拟函数分发为例。

1
2

mov eax, [ecx] ; 检索vtable指针
call [eax+4]   ; 调用vtable偏移4处的函数指针

这个汇编将被翻译成以下LLIL。

1
2

0: eax = [ecx].d
1: call ([eax + 4].d)

为这两个LLIL指令构建树会产生以下结构。

图2：示例vtable分发汇编的LLIL树结构。

LLIL_CALL的src操作数是LLIL_LOAD表达式。我们基于其操作使用处理程序评估LLIL_CALL的src操作数。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 这让我们以更通用的方式处理表达式。
# 操作处理程序接受以下参数：
#   vtable (int): 类vtable在内存中的地址
#   bv (BinaryView): 传递给插件回调的BinaryView
#   expr (LowLevelILInstruction): 要处理的表达式
#   current_defs (dict): 当前寄存器定义状态
#   defs (dict): 所有指令的寄存器状态表
#   load_count (int): 遇到的LLIL_LOAD操作数
operation_handler = defaultdict(lambda: (lambda *args: None))
operation_handler[LowLevelILOperation.LLIL_ADD] = handle_add
operation_handler[LowLevelILOperation.LLIL_REG] = handle_reg
operation_handler[LowLevelILOperation.LLIL_LOAD] = handle_load
operation_handler[LowLevelILOperation.LLIL_CONST] = handle_const

因此，我们递归评估此虚拟函数分发的第一次迭代是调用handle_load。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

def handle_load(vtable, bv, expr, current_defs, defs, load_count):
    load_count += 1

    if load_count == 2:
        return vtable

    addr = operation_handler[expr.src.operation](
        vtable, bv, expr.src, current_defs, defs, load_count
    )
    if addr is None:
        return

    # 读取指定地址的值。
    return read_value(bv, addr, expr.size)

handle_load首先增加遇到的LLIL_LOAD表达式计数。回想一下，我们解引用vtable的模型期望两个LLIL_LOAD指令：vtable指针，然后是我们想要的函数指针。向后追踪程序状态意味着我们将首先遇到函数指针的加载，然后是vtable指针的加载。此时计数为1，因此递归不应终止。相反，LLIL_LOAD的src操作数由src表达式的处理程序函数递归评估。当此处理程序调用完成时，addr应包含指向要分发的函数指针的地址。在这种情况下，src是LLIL_ADD，因此调用handle_add。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

def handle_add(vtable, bv, expr, current_defs, defs, load_count):
    left = expr.left
    right = expr.right

    left_value = operation_handler[left.operation](
        vtable, bv, left, current_defs, defs, load_count
    )

    right_value = operation_handler[right.operation](
        vtable, bv, right, current_defs, defs, load_count
    )

    if None in (left_value, right_value):
        return None

    return left_value + right_value

handle_add递归评估LLIL_ADD表达式的左右两侧，并将这些值的总和返回给其调用者。在我们的示例中，左操作数是LLIL_REG表达式，因此调用handle_reg。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

def handle_reg(vtable, bv, expr, current_defs, defs, load_count):
    # 检索此寄存器当前代表的LLIL表达式。
    set_reg = current_defs.get(expr.src, None)
    if set_reg is None:
        return None

    new_defs = defs.get(set_reg.instr_index, {})

    return operation_handler[set_reg.src.operation](
        vtable, bv, set_reg.src, new_defs, defs, load_count
    )

这就是我们的数据流分析发挥作用的地方。使用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：示例vtable分发汇编的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

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次