反-反汇编分析

字数统计: 3.2k字   |   阅读时长≈ 14分

Go研究卡住了，看代码看得头晕。休息一会看看其他的。

反-反汇编分析

反汇编器类型

线性扫描

Ollydbg，x64dbg这样的基本都是线性反汇编器。capstone更不用说了。

http://sf.net/projects/bastard/files/libdisasm/

实现例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
char buffer[BUF_SIZE];
int position = 0;

while (position < BUF_SIZE) {
    x86_insn_t insn;
    int size = x86_disasm(buf, BUF_SIZE, 0, position, &insn);
    
    if (size != 0) {
        char disassembly_line[1024];
        x86_format_insn(&insn, disassembly_line, 1024, intel_syntax);
        printf("%s\n", disassembly_line);
        position += size;
    } else {
        /* invalid/unrecognized instruction */
        position++;
    }
}
x86_cleanup();

这种反汇编器的实现简单，但是缺点也十分大。比如数据段和代码段难以区分。

递归下降扫描器

IDA这样比较智能的就是使用这种反汇编器。毕竟它都会分析近似的执行流来生成伪代码。

这种反汇编器会近似地跟踪执行流，从而绕开一些花指令和数据段。

显然它还是有局限性的，比如jz+jnz组合；以及在call指令后立刻跟随一串字符串；字符串开头字节要是能代表某个汇编指令的开头，也有可能会被误认为是汇编指令（比如0x68是push dword的开头，对应字符h）

破解反反汇编

IDA上处理这个还是很简单的，对着有问题的指令按D变成字节码数据，然后跳过垃圾数据（如果完全没用还可以patch掉），对着实际执行指令代码的开头按C返回变成正确指令。

Ollydbg，x64dbg上遇到这个还真不好处理。自动的analyze选项也经常不靠谱，容易搞错。不过这种纯线性汇编动态调试器，我不经常用，通常也就使用它的万能插件来处理一些特殊情形。

后面讲x64平台上的常见类型

jmp+call

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
.text:401568 EB 09                                   jmp     short near ptr loc_401572+1 
.text:40156A 90                                      nop
.text:40156B 90                                      nop
.text:40156C 90                                      nop
.text:40156D 90                                      nop
.text:40156E 90                                      nop
.text:40156F 90                                      nop
.text:401570 90                                      nop
.text:401571 90                                      nop
.text:401572                         loc_401572:                             ; CODE XREF: main+18↑j
.text:401572 E8 B8 00 00 00                          call    near ptr unk_40162F
.text:401572     ; ----------------------------------------------------------------------------------
.text:401577 00                                      db 0
.text:401578 48 83 C4 20                             add     rsp, 20h
.text:40157C 5D                                      pop     rbp
.text:40157D C3                                      retn

特征

jmp loc+1特意跳转过一个字节，到下面一个奇奇怪怪的call上。且指向了一个很诡异的地址。

构造方法

B8 00 00 00 就是个mov eax, 0。修改前面的一个字节为0xE8，这是call指令的特征码之一。

在前面编一个jmp，特意跳过0xE8，到原来正常应该执行的地方去。

虽然实际上0xE8并不会执行，但是这样会让线性扫描反汇编器误认为这里有个call指令。

效果

对于OD这种线性扫描的挺好的，对于IDA这种不是很好。不过在jmp和0xE8之间的空隙中搞点乱数据似乎也能影响IDA的分析。

jz+jnz

1
2
3
4
			    74 03 				jz short near ptr loc_4011C4+1
			    75 01 				jnz short near ptr loc_4011C4+1
		loc_4011C4:
0x4011C3 		 E8 58 C3 90 90 	  call near ptr 90D0D521h

jz+jnz就是jmp，但是IDA还是会把jnz后面理应从不会执行的假执行流给反汇编，从而上当，导致0xE8被反汇编进去，变成call指令。

0+jz

1
2
3
xor eax, eax
jz  LABEL_ALWAYS_TRUE
; some junk code

在前面设置一个恒真条件，然后再去“条件”跳转。这样会使得IDA也把假分支给反汇编了。

效果

一般情况下不靠谱，IDA现在的分支判断已经很成熟了，能够发现xor eax, eax干了啥的。

改进

添加指令混淆Pass，MBA Pass，能立刻提升效果。

重叠花指令

垃圾代码也会影响到具体执行的特殊形式。非常特别的构造形式。以下字节码：

1
66 B8 EB 05 31 C0 74 FA E8

直接得到：

1
2
3
4
5
6
loc_40155D:
.text:000000000040155D 66 B8 EB 05        mov     ax, 5EBh
.text:0000000000401561 31 C0              xor     eax, eax
.text:0000000000401563 74 FA              jz      short near ptr loc_40155D+2
.text:0000000000401563  ; ----------------------------------------------------
.text:0000000000401565 E8                 db 0E8h

xor+jz绝对执行，那么会跳到EB那里。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.text:000000000040155D 66                        db  66h ; f
.text:000000000040155E B8                        db 0B8h
.text:000000000040155F           ; -------------------------------------------
.text:000000000040155F EB 05                     jmp     short loc_401566
.text:000000000040155F           ; -------------------------------------------
.text:0000000000401561 31                        db  31h ; 1
.text:0000000000401562 C0                        db 0C0h
.text:0000000000401563 74                        db  74h ; t
.text:0000000000401564 FA                        db 0FAh
.text:0000000000401565 E8                        db 0E8h
.text:0000000000401566           ; -------------------------------------------
.text:0000000000401566
.text:0000000000401566           loc_401566:   
							  ; 真正执行的指令

x86和x64似乎都能用

总结

核心代码就是原来mov ax, 5EBh中的EB 05。这玩意就是jmp $+7。

重叠花指令2

1
EB FF C0 48

得到

1
2
3
.text:004132D4 loc_4132D4:
.text:004132D4                 jmp     short near ptr loc_4132D4+1
.text:004132D6                 ror     byte ptr [eax-34h], 0CCh

而jmp会跳转到自身的第二个字节上，从而实际上得到

1
2
3
4
.text:004132D4                 db 0EBh
.text:004132D5 ; ---------------------------------------------------------------------------
.text:004132D5                 inc     eax
.text:004132D7                 dec     eax

不要最后的0x48大抵也是可以的，那么这一块代码的意思就是将eax递增1。若不删除，那就是一个复杂4字节的nop指令。

利用异常处理

老生常谈了。单独分一个博客来研究。

anti-disas.pdf (ustc.edu.cn)

里面有关于x86 SEH的。

栈分析混淆

大抵是用于针对IDA这种智能分析工具，否则的话也用不着这么高雅的技术。作用挺大的，那就是IDA会无法正常分析变量，以及没法生成函数伪代码。

举个例子：

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
00401543    sub_401543 proc near ; CODE XREF: sub_4012D0+3Cp
00401543    ; sub_401328+9Bp
00401543    
00401543    arg_F4 = dword ptr 0F8h
00401543    arg_F8 = dword ptr 0FCh
00401543    
00401543  000   sub esp, 8
00401546  008   sub esp, 4
00401549  00C   cmp esp, 1000h
0040154F  00C   jl short loc_401556
00401551  00C   add esp, 4
00401554  008   jmp short loc_40155C
00401556    ; --------------------------------------------------------------
00401556    
00401556    loc_401556: ; CODE XREF: sub_401543+Cj
00401556  00C   add esp, 104h
0040155C    
0040155C    loc_40155C: ; CODE XREF: sub_401543+11j
0040155C  -F8   mov [esp-0F8h+arg_F8], 1E61h
00401564  -F8   lea eax, [esp-0F8h+arg_F8]
00401568  -F8   mov [esp-0F8h+arg_F4], eax
0040156B  -F8   mov edx, [esp-0F8h+arg_F4]
0040156E  -F8   mov eax, [esp-0F8h+arg_F8]
00401572  -F8   inc eax
00401573  -F8   mov [edx], eax
00401575  -F8   mov eax, [esp-0F8h+arg_F4]
00401578  -F8   mov eax, [eax]
0040157A  -F8   add esp, 8
0040157D  -100  retn
0040157D    sub_401543 endp ; sp-analysis failed

会发现后面的栈分析出了错误，这是由于IDA将永远不会执行的分支add esp, 104h给判断进了栈分析中。至于为什么不会执行，是因为esp的值至少在Windows中必然是不可能小于0x1000的。

注意：栈分析混淆十分依赖于高级语言编译器实现，如果是使用高级语言编程恶俗程序的话。直接汇编写的话灵活性就会高很多，恶俗操作也会更多。

消除

alt+k手动更改栈指针，或者直接patch掉让IDA产生混淆的指令。

控制流混淆

间接跳转

IDA的交叉引用都是通过直接调用来获知的，比如jmp 0x400000。

若强行改成jmp rax，call rax这种基于函数指针的形式，那么交叉引用就会失效。

实现

这一块纯脑洞实验内容，强度应该很弱

如何去写这个我倒是没啥想法。可以试试宏替换。

实验环境：Visual Studio 2019，不喜欢gcc内联汇编风格。

1.无混淆
1
2
3
4
5
6
7
8
9
10
11
12
#include <stdio.h>


void CallMe(void) {
	puts("Callme");
}

int main(void) {
	_asm nop;
	_asm call CallMe;
	return 0;
}

可执行。

2.lea+call eax

先lea获得函数地址于eax寄存器中，然后再call。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <stdio.h>


void CallMe(void) {
	puts("Callme");
}



int main(void) {
	_asm nop;
	_asm call CallMe;

	_asm pushf
	_asm pushad
	_asm lea eax, CallMe
	_asm call eax
	_asm popad
	_asm popf
	return 0;
}

可执行，但是混淆力度不大，轻松被IDA的常量传递操作识别出来。

3.间接调用+加解密
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
36
37
38
39
40
41
42
43
44
#include <stdio.h>

void __declspec(naked) EncAddr(void) {
	_asm ror eax, 5
	_asm ret
}

//void EncAddr(int addr) {
//
//}

void __declspec(naked) DecAddr(void) {
	_asm rol eax, 5
	_asm ret
}

void CallMe(void) {
	puts("Callme");
}

int main(void) {
	int decaddr;
	int encaddr;

	printf("%#p\n", &CallMe);

	// 作为一个整体，写成宏
	_asm lea eax, CallMe
	_asm call EncAddr
	_asm mov encaddr, eax

	printf("%#x\n", encaddr);

	_asm mov eax, encaddr
	_asm call DecAddr
	_asm mov decaddr, eax

	printf("%#x\n", decaddr);

	_asm mov eax, decaddr
	_asm call eax

	return 0;
}

大概的方法很迫真，但是确实起了一定的作用。也就是消除了直接的调用。

1
2
3
4
5
6
7
8
9
10
11
12
13
int __cdecl main_0(int argc, const char **argv, const char **envp)
{
  int v4; // [esp+D0h] [ebp-18h]
  void (*v5)(void); // [esp+DCh] [ebp-Ch]

  printf("%#p\n", sub_41116D);
  v4 = EncAddr();
  printf("%#x\n", v4);
  v5 = (void (*)(void))DecAddr();
  printf("%#x\n", v5);
  v5();
  return 0;
}

当然看汇编的话还是有lea eax, sub_41116D这样直接引用函数地址的操作，所以交叉引用还是有效的。

可见在IDA自动生成的情况下，反编译中，EncAddr()函数是并不会显示出传入的地址的。

4.before main

https://stackoverflow.com/questions/10897552/call-a-function-before-main

给了很多方法。其中有几个是基于C++特性实现的。msvc中不提供对main前面start等初始化函数进行修改的宏；gcc有修改main前面函数的，但是我现在不想换汇编格式。

换个博客仔细讲这个骚操作。总而言之，目的就是要解密函数离main函数远一点。

1
2
3
4
5
6
7
8
9
10
11
12
bool foo() {
	puts("Foo");
	return true;
}

bool foo2() {
	puts("Foo2");
	return true;
}

auto b = foo();
auto c = foo2();

foo()，foo2()会依次提前运行，因为这2个类对象的生成必然得提前于main。

那么配合控制流混淆：

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#include <stdio.h>

bool foo() {
	puts("Foo");
	return true;
}

bool foo2() {
	puts("Foo2");
	return true;
}


void CallMe(void) {
	puts("Callme");
}

void __declspec(naked) EncAddr(void) {
	_asm ror eax, 5
	_asm ret
}

int __declspec(naked) DecAddr(void) {
	_asm rol eax, 5
	_asm ret
}

int EncAddrWrapper(int addr) {
	int tmp;
	_asm mov eax, addr
	_asm call EncAddr
	_asm mov tmp, eax
	return tmp;
}

int DecAddrWrapper(int addr) {
	int tmp;
	_asm mov eax, addr
	_asm call DecAddr 
	_asm mov tmp, eax
	return tmp;
}

auto c = EncAddrWrapper((int)&CallMe);

int main(void) {
	printf("%#x\n", (int)&CallMe);
	printf("%#x\n", c);

	_asm mov eax, c
	_asm call DecAddr
	_asm call eax
	return 0;
}
1
2
3
0xe8118b
0x5807408c
Callme
5.完全去除具体地址

上面的玩意无论怎么说都还是有具体函数地址的。消除也是完全可行的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void CallMe(void) {
	puts("Callme");
}

int main(void) {

	_asm mov eax, CallMe+1919810
	_asm sub eax, 1919810
	_asm push L
	_asm push eax
	_asm ret
	L:
	return 0;
}

这样能保证绝绝对对得到的不是具体地址了。虽然看上去还是很简单，因为相隔距离太近了；不过要是配合其他几个手法的话，再加上指令替换Pass，就会比较厉害了。

还有一种想法

1
2
3
call $+5
add  [esp], 0x????
ret

用这种代替jmp指令的操作。即将CallMe函数地址直接拆成add指令所在地址+0x????（相对偏移），更加具有迷惑性。不过直接源码上似乎无法实现，我也暂时不打算在汇编层面上魔改甚至直接patch二进制程序了。以后有机会的话看看别人的开源混淆器实现后，再来找思路。

6.其他脑洞（未实现）

比如在main函数里面lea eax, A，那么可能会被认为这是在调用A，但是实际上进行了一次解密转换后，变成了实际调用函数B。

消除

  1. 若是很明显的宏替换，那么可以选择直接Python脚本替换字节码。
  2. 若没什么规则，则得考虑使用模拟执行。比如使用Unicorn或者angr，模拟执行相关跳转块，然后保存具体跳转地址，然后再patch。

利用ret

一般而言ret == pop + jmp，所以可以利用这一点来进行骚操作。

上面实现的第五点已经用过了

1
2
3
call $+5
add  [esp], 0x????
ret

反Patch（没写完）

反混淆难免得需要魔改程序，修改几个字节码。那么通过CRC自校验算法，则可以检测自身是否被patch过。

我一开始的想法是，开个线程，然后读取内存或者硬盘上本可执行程序的字节码，然后哈希或者CRC梭哈一番，然后比对未patch时的哈希码，看看有没有篡改。但是这个手段似乎太容易被日了

https://www.codeproject.com/Articles/18961/Tamper-Aware-and-Self-Healing-Code#pre0

提供了一个不错的思路，学完后再补充。

缺陷

这玩意相关文章都是05-09年左右的了，技术古老。本地自校验确实太容易被patch了。

进阶

2011年的时候就有一个人写过Windows上可以说最详细的反调试手段。

https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf

内容过多不Copy了，不过可能会自己尽量尝试实现一番。

IDAPython脚本

nop指令

1
2
3
4
5
6
7
8
9
10
11
12
13
import idaapi

idaapi.CompileLine('static n_key() { RunPythonStatement("nopIt()"); }')

AddHotkey("Alt-N", "n_key")

def nopIt():
     start = ScreenEA()
     end = NextHead(start)
     for ea in range(start, end):
     	PatchByte(ea, 0x90)
     Jump(end)
     Refresh()

（IDAPython的API似乎已经有变化了，留在这做个参考罢了）

添加xref交叉引用

1
AddCodeXref(0x004011DE, 0x004011C0, fl_CF);

fl_CF是call

fl_JF是jmp

参考

anti-disas.pdf (ustc.edu.cn)

代码混淆／程序保护（对抗反汇编）原理与实践_pianogirl123的博客-CSDN博客_防止反汇编

在 VS2008 下用 CRC32 算法实现程序自校验_蜡笔小辛的专栏-CSDN博客

https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

A junior undergraduate
studying in the college of cyber science and engineering
in Sichuan University
in Sichuan , China.
Pronouns:He/him.
A core member of 0x401 CTF team
majorly focus on Reverse Engineering chanllenges.