(o・∇・o)
(o・∇・o)
X-NUCA 2020 - hellowasm 题解
X-NUCA 2020 - hellowasm 题解

前言

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

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

比赛期间没做出来不叫 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 的对应伪代码:

char* encode(char* str) {
    char* addr;
    int len;

    int i = 0, j = 0;
    while (1) {
        if (i >= addr + len - 2) {
            break;
        }

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

        i += 4;
        j += 3;
    }
    return addr;
}

对比 base64C 语言实现[1]:

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

	unsigned int i=0, j=0, k=0, s[3];
	
	for (i=0;i<in_len;i++) {
		s[j++]=*(in+i);
		if (j==3) {
			out[k+0] = b64_chr[ (s[0]&255)>>2 ];
			out[k+1] = b64_chr[ ((s[0]&0x03)<<4)+((s[1]&0xF0)>>4) ];
			out[k+2] = b64_chr[ ((s[1]&0x0F)<<2)+((s[2]&0xC0)>>6) ];
			out[k+3] = b64_chr[ s[2]&0x3F ];
			j=0; k+=4;
		}
	}
	
	if (j) {
		if (j==1)
			s[1] = 0;
		out[k+0] = b64_chr[ (s[0]&255)>>2 ];
		out[k+1] = b64_chr[ ((s[0]&0x03)<<4)+((s[1]&0xF0)>>4) ];
		if (j==2)
			out[k+2] = b64_chr[ ((s[1]&0x0F)<<2) ];
		else
			out[k+2] = '=';
		out[k+3] = '=';
		k+=4;
	}

	out[k] = '\0';
	
	return k;
}

可以看到,其和标准 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,我们可以得到如下结论:

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

假设输入正确,则可以得到:

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

即:

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

解密

最终的脚本如下:

data = `0xbe
6
0xac
'
0x99
O
0xde
D
0xee
_
0xda
0x0b
0xb5
0x17
0xb8
h
0xc2
N
0x9c
J
0xe1
C
0xf0
0x22
0x8a
;
0x88
[
0xe5
T
0xff
h
0xd5
g
0xd4
0x06
0xad
0x0b
0xd8
P
0xf9
X
0xe0
o
0xc5
J
0xfd
/
0x84
6
0x85
R
0xfb
s
0xd7
0x0d
0xe3`.split('\n').map(t=>t.length === 1 ? t.charCodeAt() : Number(t))

b64 = data.map((d, i) => i == 0 ? d : d ^ data[i-1]).map(t=>t^0xee).map((t,i)=>{switch(i%4){case 0:return t^0xa;case 1:return t^0xb;case 2:return t^0xc;case 3:return t^0xd;}}).map(t=>String.fromCharCode(t)).join('')

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

发表评论

textsms
account_circle
email

(o・∇・o)

X-NUCA 2020 - hellowasm 题解
前言 在比赛结束后一小时,得出了最终结果—— 怎么说呢,虽然有点遗憾,但也是做出来了。至少没白费这几小时的时间吧(笑) 比赛期间没做出来不叫 WriteUp(( 开始 开…
扫描二维码继续阅读
2020-11-01