跳转至

静态分析

接下来我们以DEF CON CTF 2019 Quals中的wasm为例,介绍一种wasm的逆向分析方法

拿到网址后f12把wasm下载下来,得到wasm.wasm

反汇编

就像x86汇编,wat的每一句机器码都能唯一的对应一句wasm汇编语句。

幸运的是,ida自带webassembly的处理器模块。wasm文件可以直接被反汇编。

或是使用wasm2wat,将生成一份文本格式的.wat文件。

1
$ ./wasm2wat wasm.wasm -o wasm.wat

然而没有人愿意对着"低级"的汇编代码分析,我们更情愿看"高级"一点的语言。

有关wat文本格式的文章:理解WebAssembly文本格式

反编译

ida当然没有反编译模块。(事实上,正常情况下ida只支持x86和arm架构的反编译)

好在,我们可以用wasm2c来生反编译

这里是wabt的项目仓库,可以基本实现wasm,wat,c之间的相互转换

编译好后,用如下指令得到c代码:

1
$ ./wasm2c wasm.wasm -o wasm.c

得到wasm.c和wasm.h

然而此工具得到的c代码并不尽如人意:

光是行数已经很吓人了,这道nodb反编译出来的c文件由12000+行!

代码几乎和wat内容没啥区别

随便截取其中的几行,似乎只是把局部变量与全局变量换了个名字。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
//...
  u32 i0, i1, i2;
  i0 = g12;
  l64 = i0;
  i0 = p1;
  l45 = i0;
  i0 = p0;
  l55 = i0;
  i0 = l45;
  i1 = l55;
  i0 ^= i1;
  l56 = i0;
  i0 = l56;
  i1 = 3u;
  i0 &= i1;
  l57 = i0;
  i0 = l57;
  i1 = 0u;

//...

优化

这种代码显然是无法分析的,我们需要优化

这里提供一种比较简单的优化方式:用gcc编译后在用ida反编译

将之前反编译出来的wasm.c,wasm.h,以及wabt项目内的wasm-rt.h,wasm-rt-impl.c,wasm-rt-impl.h三个文件放到同一个文件夹。

直接gcc wasm.c会报错,因为很多wasm的函数没有具体的实现。但是我们可以只编译不链接,我们关心的只是程序本身的逻辑,不需要真正编译出能运行的elf来。

1
$ gcc -c wasm.c -o wasm.o

得到的还未连接的elf文件wasm.o

现在可以丢进ida来分析了,比之前的wasm.c友好很多。

disassembly

尽管和原始的代码差别较大,但好歹可以开始分析了。

常量

搜索字符串是每个逆向手接触一个程序的第一步

对于wasm,所有的字符串会被存放在二进制文件的末尾,以此能获取一些关键的信息。

string0

同时也能在wasm.c中看到这些字符串的定义

string1

直接对字符串查找引用是找不到引用的,因为并不是直接对地址的引用,想找到这些字符串会困难一些。

然而开头的常量比较可疑,比赛的flag格式是OOO{},这里开头又有连续三个一样的字节,让人联想到异或或者只是一个偏移。抱着试试看的态度减了一下,直接出了flag。。。

除了这种偷鸡的做法,细心看看代码也能看出一点端倪。

在f24函数中,似乎从0x400开始的地方获取了个字节,然后返回了这个字节减66,刚好是跟flag的差距。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
  if ( g12 >= g13 )
    Z_envZ_abortStackOverflowZ_vi(80LL);
  v1 = i64_load(Z_envZ_memory, 0x400LL);
  i64_store(Z_envZ_memory, v13, v1);
  v2 = i64_load(Z_envZ_memory, 0x408LL);
  i64_store(Z_envZ_memory, v13 + 8, v2);
  v3 = i64_load(Z_envZ_memory, 0x410LL);
  i64_store(Z_envZ_memory, v13 + 16, v3);
  v4 = i64_load(Z_envZ_memory, 0x418LL);
  i64_store(Z_envZ_memory, v13 + 24, v4);
  v5 = i64_load(Z_envZ_memory, 0x420LL);
  i64_store(Z_envZ_memory, v13 + 32, v5);
  v6 = i64_load(Z_envZ_memory, 0x428LL);
  i64_store(Z_envZ_memory, v13 + 40, v6);
  v7 = i64_load(Z_envZ_memory, 0x430LL);
  i64_store(Z_envZ_memory, v13 + 48, v7);
  v8 = i64_load(Z_envZ_memory, 0x438LL);
  i64_store(Z_envZ_memory, v13 + 56, v8);
  v9 = i32_load(Z_envZ_memory, 0x440LL);
  i32_store(Z_envZ_memory, v13 + 64, v9);
  v10 = i32_load8_s(Z_envZ_memory, 0x444LL);
  i32_store8(Z_envZ_memory, v13 + 68, v10);
  v11 = i32_load8_s(Z_envZ_memory, a1 + v13);
  g12 = v13;
  --wasm_rt_call_stack_depth;
  return (unsigned __int8)(v11 - 66);

主逻辑在_authenticate,其中有两处比较可疑:

1
2
3
  v1 = i32_load(Z_envZ_memory, 0x4D0LL);
  i32_store(Z_envZ_memory, (unsigned int)(v18 + 28), v1);
  v2 = i32_load8_s(Z_envZ_memory, 0x4D4LL);

还有循环结尾的:

1
2
3
4
5
6
7
8
9
    if ( v11 == 69 )
    {
      g12 = v18;
      v13 = 0x4D5;
    }
    else
    {
      g12 = v18;
      v13 = 0x4DD;

如果0x400指向常量的开头,0x4d5刚好对应success,0x4DD刚好对应failure。这肯定不是巧合。事实上,0x400的偏移都对应常量开头,在之前做的另外一些题中也能看到类似的结构。

如此一来,我们便能轻易的从密文中猜出flag

另外两个例子

simple wasm

这是去年上交大运维赛的一道web题,直接弄出一个wasm来。

直接在文件为查找字符串:

yunweisaistring

看到了base64表和密文,解码出来是

1
iodj~44h393d5fh4;e:9h6i598f798;gd<4hf

看看check函数,有个地方可疑:

1
2
3
4
5
6
  while ( v14 != 38 )
  {
    v4 = v14++;
    v5 = i32_load8_s(Z_envZ_memory, v4 + a1);
    f797(v21, (unsigned __int8)(v5 + 3));
  }

38就是长度,下面有个+3,也就是凯撒密码。

减一下就能得到flag

1
flag{11e060a2ce18b76e3f265c4658da91ec}

另外,这道题函数数量出奇的多,我只拿到了wasm文件,没有访问最终实现的网页,所以具体是怎么样的也不清楚。而且我尝试寻找base64解密的代码区,并没有发现具体的实现位置,也没有像其他两题一样找到具体字符串偏移的部分。。。

where_u_are

这是前阵子国赛初赛中的一道wasm题。

whereyou_string

先找字符串,确定main函数位置

注意f23中几个函数调用的参数:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  for ( i = 0; i < 1; ++i )
  {
    i32_store(Z_envZ_memory, (unsigned int)v11, v9);
    f99(0x1170u, (char *)(unsigned int)v11, (unsigned int)v11);
    v4 = f23(v9, (char *)(unsigned int)v11, v3);
    v7 = f24((int *)v4, (unsigned int)v11, v5);
    f64_load(Z_envZ_memory, v7 + 8);
    f64_load(Z_envZ_memory, v7);
    f64_store(Z_envZ_memory, v10);
    f64_store(Z_envZ_memory, (unsigned int)((_DWORD)v11 + 16));
    f98(0x1173u, v10, v10);
  }
  f64_load(Z_envZ_memory, v7);
  if ( 0.0 - (double)25 >= 1.0 || (f64_load(Z_envZ_memory, v7 + 8), 1.0 - (double)175 >= 1.0) )
  {
    f98(0x1186u, (unsigned int)((_DWORD)v11 + 32), (unsigned int)((_DWORD)v11 + 32));
    g10 = (signed int)v11;
  }
  else
  {
    f98(0x117Cu, (unsigned int)((_DWORD)v11 + 24), (unsigned int)((_DWORD)v11 + 24));
    g10 = (signed int)v11;
  }

注意f99, f98的参数:0x1170, 0x1173, 0x1168, 0x117C

刚好对应之前的字符串常量之间的偏移,可以断定这是scanf和printf

f23中对输入进行了一些操作:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
  for ( i = 0; i < (unsigned int)strlen(a1, (__int64)a2, v3); ++i )
  {
    for ( j = 4; ; --j )
    {
      v3 = (unsigned int)j;
      if ( j >= 0 == 0 )
        break;
      ++v11;
      v4 = i + a1;
      v5 = i32_load8_s(Z_envZ_memory, v4);
      v7 = f22(v5, v4, v6);
      a2 = (char *)(unsigned int)(4 * (v11 - 1) + 0x11E0);
      i32_store(Z_envZ_memory, (__int64)a2, (v7 >> (j % 5 & 0x1F)) & 1);
    }
  }

再看看f22

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
  for ( i = 0; ; ++i )
  {
    if ( i >= 32 )
    {
      v6 = 6;
      goto LABEL_11;
    }
    v4 = i;
    if ( a1 == (char)i32_load8_s(Z_envZ_memory, (unsigned int)(i + 0x400)) )
      break;
  }

似乎是从0x400的偏移找某个值,而且范围是32?

找找0x400的偏移(跟之前一样,0x400也是字符串常量的开头?)

在数据开头,看到了一个长度为32的表

1
2
3
.rodata:000000000006BF00 data_segment_data_0 db '0123456789bcdefghjkmnpqrstuvwxyz'
.rodata:000000000006BF00                                         ; DATA XREF: init_memory+14↑o
.rodata:000000000006BF20                 db    2

联想一下之前的查表,这应该是我们的输入范围。

回到f23,看到循环内有右移j%5再&1得操作,可能是分离每一位

加密逻辑在f24内:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 v11 = -180.0;
  v12 = 180.0;
  v13 = -90.0;
  v14 = 90.0;
  for ( i = 0; i < 50; ++i )
  {
    v6 = i32_load(Z_envZ_memory, (unsigned int)(4 * i + (_DWORD)a1));
    if ( (i + 1) % 2 == 1 )
      i32_store(Z_envZ_memory, (unsigned int)(4 * ((i + 1) / 2) + v7), v6);
    else
      i32_store(Z_envZ_memory, (unsigned int)(4 * (i / 2) + v8), v6);
  }
  for ( j = 0; j < 20; ++j )
  {
    if ( (unsigned int)i32_load(Z_envZ_memory, (unsigned int)(4 * j + v7)) == 1 )
    {
      v11 = v10;
      v10 = (v10 + v12) / 2.0;
    }
    else if ( (unsigned int)i32_load(Z_envZ_memory, (unsigned int)(4 * j + v7)) == 0 )
    {
      v12 = v10;
      v10 = (v11 + v10) / 2.0;
    }
    if ( (unsigned int)i32_load(Z_envZ_memory, (unsigned int)(4 * j + v8)) == 1 )
    {
      v13 = v9;
      v9 = (v9 + v14) / 2.0;
    }
    else if ( (unsigned int)i32_load(Z_envZ_memory, (unsigned int)(4 * j + v8)) == 0 )
    {
      v14 = v9;
      v9 = (v13 + v9) / 2.0;
    }
  }

是不是很像二分查找?

猜测下逻辑,把输入按32个字符的table映射到一个0-31的数字,转二进制后,根据奇数位和偶数位分成两组,根据每一位为1或0决定二分查找的方向,两组分别在[-180,180]和[-90,90]区间内二分查找,找到结果为175和25时结果正确,注意精度要足够。

小结

初步分析了wasm静态分析的方法。动态调试过程在网上可以查到教程,这里就不多做分析了,用chrome,Firefox 等浏览器可以轻松实现wasm的动态调试。在动态调试的过程也能验证静态分析的猜想。

评论