X-NUCA 2020 - hellowasm 题解 | Yesterday17's Blog

前言

在比赛结束后一小时，得出了最终结果——

怎么说呢，虽然有点遗憾，但也是做出来了。至少没白费这几小时的时间吧（笑）

比赛期间没做出来不叫 WriteUp（（

开始

开始游戏。首先尝试用 JEB 读一下：

可以看到，逻辑还是非常清楚的（部分函数名为手动替换）。但美中不足的是对最关键的 f8 和 f9 不能查看伪代码，好像是 br_table 没做好，因此只能暂时放弃（

在等待了一段时间后，群里出现了 wasm2c 编译得到的 hello.o 文件。于是决定到 Windows 下用 F5 一战——

f9（base64）

f9 这个函数有超级明显的特征，就是这个字符串：

这东西过于 base64 了，甚至最后的 + 和 / 都完全一致。其得到结果的长度在动态调试下也和 base64 的一致，这就很有趣了。我们借助 IDA 的 F5 来看。首先是没进入循环的初始化部分：

注意到 72 行有一个 strlen 函数。这个函数并不是 IDA 读出来的，而是在动态调试中试出来的。这里也有一个经验谈吧，就是以字符串为输入的 WASM 程序中基本都会有一个用来计算字符串长度的函数。

接下来的 74-83 行是和 3 有关的数学运算。这里就是 base64 的长度计算了：当整除 3 时即为 /3*4，当不整除时要多补 4 位。

然后是分配内存，并且将内存空间的最后一位置 \0，最后则是将两个数据置了 0。这里又是一个经验谈，在这种地方初始化成 0 的一般都是循环里面用到的变量。所以在这里简单将其命名为 i 和 j。

看完了初始化的部分，我们来看下面的循环：

首先是跳出循环的条件，姑且看懂就好。由于我们猜测这个函数和 base64 有较大关联，因此主要要做的就是代码，并与 base64 的源码进行比对。最先完成的是 addr[i] 的部分。

然后如法炮制，可以得到 addr[i+1]、addr[i+2] 和 addr[i+3] 的部分。

循环最后是对循环变量的处理。到此，接下来的部分基本不需要看了。我们整理一下上面的逻辑，可以写出 C 的对应伪代码：

1
char* encode(char* str) {
2
    char* addr;
3
    int len;
4

5
    int i = 0, j = 0;
6
    while (1) {
7
        if (i >= addr + len - 2) {
8
            break;
9
        }
10

11
        addr[i] = table[str[j] >> 2] ^ 0xa;
12
        addr[i + 1] = table[((str[j] & 3) << 4) | (str[j+1] >> 4)] ^ 0xb;
13
        addr[i + 2] = table[((str[j+1] & 0xf) << 2) | (str[j+2] >> 6)] ^ 0xc;
14
        addr[i + 3] = table[str[j+2] & 0x3f] ^ 0xd;
15

16
        i += 4;
17
        j += 3;
18
    }
19
    return addr;
20
}

对比 base64 的 C 语言实现[1]：

1
unsigned int b64_encode(const unsigned char* in, unsigned int in_len, unsigned char* out) {
2

3
  unsigned int i=0, j=0, k=0, s[3];
4

5
  for (i=0;i<in_len;i++) {
6
    s[j++]=*(in+i);
7
    if (j==3) {
8
      out[k+0] = b64_chr[ (s[0]&255)>>2 ];
9
      out[k+1] = b64_chr[ ((s[0]&0x03)<<4)+((s[1]&0xF0)>>4) ];
10
      out[k+2] = b64_chr[ ((s[1]&0x0F)<<2)+((s[2]&0xC0)>>6) ];
11
      out[k+3] = b64_chr[ s[2]&0x3F ];
12
      j=0; k+=4;
13
    }
14
  }
15

16
  if (j) {
17
    if (j==1)
18
      s[1] = 0;
19
    out[k+0] = b64_chr[ (s[0]&255)>>2 ];
20
    out[k+1] = b64_chr[ ((s[0]&0x03)<<4)+((s[1]&0xF0)>>4) ];
21
    if (j==2)
22
      out[k+2] = b64_chr[ ((s[1]&0x0F)<<2) ];
23
    else
24
      out[k+2] = '=';
25
    out[k+3] = '=';
26
    k+=4;
27
  }
28

29
  out[k] = '\0';
30

31
  return k;
32
}

可以看到，其和标准 base64 实现的唯一区别就是对每一位都进行了一次异或。到此，f9 解析完成。

f8（主逻辑）

f8 的逻辑就复杂多了，不过也不是无迹可寻。看着复杂的代码分解到每个小部分却又各自非常简单，这就是 f8 的状况。

循环之前

我们首先来看进入循环之前的代码。

这里涉及到了大量对 u_addr 内存的操作。这里可以偷个懒，在初始化完成后的地方打上断点，然后把对应内存的内容复制出来：

简单整理一下对应 offset 的实际内容：

可以看到 2128 和 2160 分别被存储在了 offset = 4 和 offset = 24，而经过 base64 的数据则是存储在了 offset = 32 。

循环过程：初探

面对这样一个循环谁都头大。由于循环内是一个巨大的 switch，因此我简单跟踪了一下每次 switch 的取值：

中间发现了一个循环，于是猜测了一下：

循环过程：函数对应

观察每个 switch 分支，可以看到他们都是 call_indirect 调用函数：

这部分可能在 IDA 里观察不大明显，但动态调试跟进去就很直观了。这个技巧在当时逆向 SC 的时候也用到了。

经过简单对比，我们发现：

于是省下了 114514 秒的动态调试时间（

循环过程：逻辑分析

这个过程就是单纯的分析那一连串函数的时间了，总体耗时约 40 分钟。最终得到这样一张图：

其中 _ 开头的表示调用函数，括号内是这个函数执行的顺序。

整理出这样的逻辑后，仔细观察。可以发现，整个比对是基于异或的。在 offset = 20 赋值的比对中，第一次比对应该是实际的数值比对。这次比对比较的是 base64 的值和 offset = 12 处的值，而这处的值经过了两次异或。这也就是最基本的逻辑了。

再整理一下，这张图可以修订成这样：

可以看到，offset = 12 处的值在最初被赋为 0，然后经过两次异或。第一次异或是 base64 对应偏移的内容，而第二次则是 0xee。

循环过程：逻辑整理

令输入数组为 b64，加密后数组为 data，当前位下标为 i，我们可以得到如下结论：

1
\mathtt{b64}_0\oplus\mathtt{0xee}=\mathtt{data}_0 \\
2
\mathtt{b64}_0\oplus\mathtt{0xee}\oplus\mathtt{b64}_1\oplus\mathtt{0xee}=\mathtt{data}_1

假设输入正确，则可以得到：

1
\mathtt{data}_{i-1}\oplus\mathtt{b64}_i\oplus\mathtt{0xee}=\mathtt{data}_i

即：

1
\mathtt{b64}_0=\mathtt{data}_0\oplus\mathtt{0xee} \\
2
\mathtt{b64}_i=\mathtt{data}_i\oplus\mathtt{data}_{i-1}\oplus\mathtt{0xee}

解密

最终的脚本如下：

1
data = `0xbe
2
6
3
0xac
4
'
5
0x99
6
O
7
0xde
8
D
9
0xee
10
_
11
0xda
12
0x0b
13
0xb5
14
0x17
15
0xb8
16
h
17
0xc2
18
N
19
0x9c
20
J
21
0xe1
22
C
23
0xf0
24
0x22
25
0x8a
26
;
27
0x88
28
[
29
0xe5
30
T
31
0xff
32
h
33
0xd5
34
g
35
0xd4
36
0x06
37
0xad
38
0x0b
39
0xd8
40
P
41
0xf9
42
X
43
0xe0
44
o
45
0xc5
46
J
47
0xfd
48
/
49
0x84
50
6
51
0x85
52
R
53
0xfb
54
s
55
0xd7
56
0x0d
57
0xe3`
58
  .split("\n")
59
  .map(t => (t.length === 1 ? t.charCodeAt() : Number(t)));
60

61
b64 = data
62
  .map((d, i) => (i == 0 ? d : d ^ data[i - 1]))
63
  .map(t => t ^ 0xee)
64
  .map((t, i) => {
65
    switch (i % 4) {
66
      case 0:
67
        return t ^ 0xa;
68
      case 1:
69
        return t ^ 0xb;
70
      case 2:
71
        return t ^ 0xc;
72
      case 3:
73
        return t ^ 0xd;
74
    }
75
  })
76
  .map(t => String.fromCharCode(t))
77
  .join("");
78

79
atob(b64);

好耶，是十点半做出来的（

后记

到目前为止，我做过的 WASM 题都做出来了，这是不是算 AK 了我人生中所有的 WASM（逃

从这题开始我开始尝试用 IDA 分析 WASM。看过我之前博客（包括加密的两篇 SC）的读者应该知道，我之前都是直接分析 wat 的。但在 wat 行数不断增加的当下，我们也需要快速分析的手段。

JEB 分析很好用，但对于有些代码没办法成伪代码；IDA 配合 F5 也可一用，但混杂了大量无用的代码需要手动去除；Chrome 的动态调试是神，虽然还有不大好用的地方，但能大幅简化分析的难度；WAT 的阅读是基本功，只要会读 WAT，那么逆向 WASM 只是时间问题。

嘛，就是这样（逃

引用

https://github.com/joedf/base64.c/blob/master/base64.c