浅谈逆向 Unity WebGL Il2Cpp 中 WebAssembly 函数的方法

简介

在使用 Il2CppDumper 解包 Unity WebGL 程序后可以得到包含 C# 方法信息的 dump.cs 文件。

但是 dump.cs 文件中给出的函数偏移 offset 既不是 wasm 文件中的偏移，也不是 WebAssembly.Table 表项的偏移，这给我们逆向 Unity 的过程带来了许多不便。

本文将探讨如何通过 dump.cs 文件中给出的 offset 来定位 wasm 文件中对应的函数实现。

方法

检查导出表，可以看到 wasm 文件中导出了许多形如 dynCall_iiii 的函数：

这些函数是 Binaryen 生成用来帮助动态调用 wasm 内部 C# 方法的辅助函数。

接下来以 dynCall_iiii 函数为例进行说明辅助函数的工作方式。

通过 dynCall_iiii 函数可以调用接受三个整型参数的内部 C# 方法，函数名称 iiii 中的第一个 i 代表目标 C# 方法的返回类型为 int，后面三个 i 代表目标 C# 方法接受三个 int 类型作为参数。

dynCall_iiii 函数接收四个参数，其中第一个参数用来指示目标 C# 方法在 iiii 子表的编号，即 dump.cs 文件中给出的 offset，后面的参数会依次传递给指定的 C# 方法。

dynCall_iiii 函数实现如下：

undefined4 export::dynCall_iiii(uint param1,undefined4 param2,undefined4 param3,undefined4 param4)
{
  undefined4 uVar1;
  
  uVar1 = (**(code **)((longlong)(int)((param1 & 0xfff) + 0x2b70) * 8))(param2,param3,param4);
  return uVar1;
}

辅助函数通过基址加偏移的方式在 WebAssembly.Table 表项中定位目标 C# 方法的地址，其中基址 0x2b70 对应 iiii 子表在 WebAssembly.Table 中的起始地址，而偏移量则对应目标 C# 方法在 iiii 子表的编号。

还有许多形如 dynCall_vijfd 的函数，具体的含义以及命名方法可以参考下面的表格：

字符	C++ 类型	C# 类型
v	void	void
i	int	int
j	long long	long
f	float	float
d	double	double

实例

下面以 N1CTF 2021 中的题目 Nu1L Hotel Checkin 为例说明如何定位 C# 方法在 wasm 中的函数实现。

通过 Il2CppDumper 解包 global-metadata.dat 和 wasm 文件得到的 dump.cs 内容如下：

// Namespace: 
public class N1CTFChecker : MonoBehaviour // TypeDefIndex: 2380
{
	// Methods

	// RVA: 0x90F Offset: 0x90F VA: 0x90F
	private void Start() { }

	// RVA: 0x910 Offset: 0x910 VA: 0x910
	private void Update() { }

	// RVA: 0x635 Offset: 0x635 VA: 0x635
	public bool check(string flag) { }

	// RVA: 0x911 Offset: 0x911 VA: 0x911
	public void OnClick() { }

	// RVA: 0x912 Offset: 0x912 VA: 0x912
	public void .ctor() { }
}

现在我们要定位 N1CTFChecker::check 方法在 wasm 文件中的位置。

首先在 Il2CppDumper 解包得到的 script.json 中找到 N1CTFChecker::check 方法在经过 Il2Cpp 转换后的函数声明：

    {
      "Address": 1589,
      "Name": "N1CTFChecker$$check",
      "Signature": "bool N1CTFChecker__check (N1CTFChecker_o* __this, System_String_o* flag, const MethodInfo* method);"
    },

根据返回类型以及参数类型可以判断对应的辅助函数为 dynCall_iiii。

接着使用 Ghidra 的 ghidra-wasm-plugin 插件对 wasm 文件进行反编译，查看 dynCall_iiii 函数实现：

undefined4 export::dynCall_iiii(uint param1,undefined4 param2,undefined4 param3,undefined4 param4)
{
  undefined4 uVar1;
  
  uVar1 = (**(code **)((longlong)(int)((param1 & 0xfff) + 0x2b70) * 8))(param2,param3,param4);
  return uVar1;
}

得到对应的基址为 0x2b70，加上 N1CTFChecker::check 方法的偏移量 0x635 得到索引 0x2b70 + 0x635 = 0x31a5。

然后在控制台中使用 js 索引 WebAssembly.Table 的第 0x31a5 项即可得到目标 C# 方法在 wasm 文件中的函数编号 30814：

table = UnityLoader.Blobs["blob:https://n1ctf-hotel-checkin.misty.workers.dev/9de00924-0574-43d8-a65f-a7992b7d289e"].Module.asmLibraryArg.table
table.get(0x31a5)

或者在 wasm2wat 解析得到的 wat 文件中搜索 (elem，也可以查看 WebAssembly.Table 的内容：

(elem (;0;) (global.get 0) func 33703 16150 16157 33703 33704 16142 ...)

最后在 Ghidra 中定位到 unnamed_function_30814 即可找到 N1CTFChecker::check 方法在 wasm 中的函数实现：

undefined4 unnamed_function_30814(undefined4 param1,undefined4 flag,undefined4 param3)

{
  int index;
  int index2;
  int iVar1;
  undefined4 uVar2;
  int index3;
  int table_;
  int target_;
  int buffer;
  int *flag__;
  int length;
  undefined4 uStack00000000;
  undefined4 uStack00000004;
  undefined4 uStack00000008;
  
  if (cRam0028289f == '\0') {
    unnamed_function_31565(PTR_DAT_ram_00001536_ram_00065510);
    cRam0028289f = '\x01';
  }
  uVar2 = unnamed_function_27012(0);
  index3 = unnamed_function_13755(0xf,uVar2,flag);
                      /* 54*54 */
  table_ = malloc_int(_DAT_ram_001fbaec,&DAT_ram_00000b64);
  uStack00000004 = _DAT_ram_00201408;
  uStack00000008 = _DAT_ram_00201408;
  unnamed_function_14607(table_,&stack0x00000008,0);
                      /* 54 */
  target_ = malloc_int(_DAT_ram_001fbaec,0x36);
  uStack00000000 = _DAT_ram_00201478;
  uStack00000008 = _DAT_ram_00201478;
  unnamed_function_14607(target_,&stack0x00000008,0);
  flag__ = (int *)(index3 + 0xc);
                      /* cmp length
                         *(flag_ + 0xc)==*(target + 0xc) */
  if (*flag__ == *(int *)(target_ + 0xc)) {
    buffer = malloc_int(_DAT_ram_001fbaec,*flag__);
    for (index = 0; length = *flag__, index < length; index = index + 1) {
                      /* transform */
      iVar1 = 0;
      for (index2 = 0; index2 < length; index2 = index2 + 1) {
         iVar1 = *(int *)(table_ + 0x10 + (index2 + *flag__ * index) * 4) *
                  (uint)*(byte *)(index3 + 0x10 + index2) + iVar1;
         length = *flag__;
                      /* :transform_inner
                         int table[54*54]
                         char flag[54]
                         var1 += table[index2+length*index] * flag[index2] */
      }
      *(int *)(buffer + 0x10 + index * 4) = iVar1;
    }
    for (index3 = 0; index3 < length; index3 = index3 + 1) {
                      /* :compare
                         int code[54]
                         buffer[index3] == code[index3] */
      if (*(int *)(buffer + 0x10 + index3 * 4) != *(int *)(target_ + 0x10 + index3 * 4)) {
         return 0;
      }
      length = *flag__;
    }
                      /* right */
    uVar2 = 1;
  }
  else {
                      /* wrong */
    uVar2 = 0;
  }
  return uVar2;
}

至此，我们成功在 Il2Cpp 转换后的 wasm 中找到了 N1CTFChecker::check 方法的位置。

后记

Wasm 动态调用

由于 wasm 设计中的安全限制，wasm 内部无法直接通过变量中的函数地址进行跳转，所以只能通过辅助函数调用 call_indirect 指令结合 WebAssembly.Table 来实现函数的动态调用。

接下来以 VirtFuncInvoker 函数为例进行说明动态调用在 x86-64 和 wasm 中的区别。

VirtFuncInvoker 在 x86-64 下，先从 klass->vtable 中获取函数地址，再通过函数指针进行调用：

graph LR VirtFuncInvoker-->VTable VTable-->call call-->VirtFunc

VirtFuncInvoker 在 wasm 下，先从 klass->vtable 中获取函数编号，加上一个与目标 C# 方法的返回类型以及参数类型有关的基址后，再通过 call_indirect 指令结合 WebAssembly.Table 进行调用：

graph LR VirtFuncInvoker-->VTable Signature-->WebAssembly.Table VTable-->WebAssembly.Table WebAssembly.Table-->call_indirect call_indirect-->VirtFunc

Unity Il2Cpp 中相关代码：

FORCE_INLINE const VirtualInvokeData& il2cpp_codegen_get_virtual_invoke_data(Il2CppMethodSlot slot, const RuntimeObject* obj)
{
    Assert(slot != kInvalidIl2CppMethodSlot && "il2cpp_codegen_get_virtual_invoke_data got called on a non-virtual method");
    return obj->klass->vtable[slot];
}

关于 ghidra-wasm-plugin

在 Unity WebGL 中 Element 段的加载位置依赖于外部变量 tableBase：

(import "env" "table" (table (;0;) 51716 51716 funcref))
(import "env" "tableBase" (global (;0;) i32))
...
(elem (;0;) (global.get 0) func 33703 16150 16157 33703 33704 16142 16143 ...)

在这种情况下，插件不会自动分析 Table 段的内容。

在 UnityLoader 中可以找到 tableBase 的值为 0：

if (!env["tableBase"]) {
    env["tableBase"] = 0
}

根据 tableBase 的值将 Element #0 段映射到 Table #0 段的 0 号偏移处：

from wasm import WasmLoader
from wasm.analysis import WasmAnalysis
from ghidra.util.task import ConsoleTaskMonitor
monitor = ConsoleTaskMonitor()
WasmLoader.loadElementsToTable(currentProgram, WasmAnalysis.getState(currentProgram).module, 0, 0, 0, monitor)

Data 段的加载位置是立即数，插件可以自动分析，所以不需要手动指定偏移：

(data (;14128;) (i32.const 1567959) "\5c")

然后执行 analyze_dyncalls.py 分析程序中的 dynCall。

该脚本可以自动提取所有 dynCall 函数中的基址，并将 WebAssembly.Table 中的函数重命名为 func_[signature]_[offset] 的格式。

执行完成后搜索 func_iiii_1589 就可以定位到 N1CTFChecker::check 的位置，省去了手动计算的过程。

关于 Il2CppDumper

其实到这里可以看出来，使用脚本自动恢复符号需要做的工作很简单，把上面的几个步骤连起来就可以了，于是就有了这个 Pull request。

添加 ghidra_wasm.py 脚本，根据 script.json 的内容恢复 wasm 中的符号信息。

似乎有少量函数名称没有正确恢复出来，看了一下是 Il2CppDumper 生成 C 函数签名的逻辑有点问题，但是应该问题不大（

使用脚本恢复 wasm 符号后的结果：

和带调试符号的 wasm 进行对比：

和带调试符号的 x86-64 进行对比：

可以看出来除了像 IsInst、InterfaceFuncInvoker、VirtFuncInvoker 这样不需要导出的符号以外，其他符号的恢复效果都很可观。

StructGenerator.cs 的 这里 不知道为什么作者没有用标准的 C 语言格式输出 struct，导致 Ghidra 不能正常解析，还有一些类型声明问题 #287 似乎并没有很好的解决，在作者博客中也有提及到 这点，不过这个功能好像不是很重要，就先不修了（

参考

Il2CppDumper：https://github.com/Perfare/Il2CppDumper

ghidra-wasm-plugin：https://github.com/nneonneo/ghidra-wasm-plugin/

WebAssembly：https://developer.mozilla.org/en-US/docs/WebAssembly

WebAssembly.Table：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Table

WebAssembly 文本格式：https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

WebAssembly 工具集：https://github.com/WebAssembly/wabt

Emscripten：https://github.com/emscripten-core/emscripten

Binaryen：https://github.com/WebAssembly/binaryen

GenerateDynCalls：https://github.com/WebAssembly/binaryen/blob/main/src/passes/GenerateDynCalls.cpp

Unity WebGL 分析：https://qiita.com/hikipuro/items/d7cbc4294dd6b58d0ffb