Skip to content

X-NUCA 2020 - hellowasm 题解

Published: at 00:58

前言

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

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

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

开始

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

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

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

f9(base64)

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

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

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

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

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

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

首先是跳出循环的条件,姑且看懂就好。由于我们猜测这个函数和 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
}

对比 base64C 语言实现[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 的实际内容:

可以看到 21282160 分别被存储在了 offset = 4offset = 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 只是时间问题。

嘛,就是这样(逃

引用

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