2021 ctfshow 月饼杯 pwn Moon_note

保护全开，没给libc。
没给libc真可恶。

菜单

create
设计的很有意思，申请的chunk实现了类似unsorted bin 的一个hash表。
chunk的结构是前16个字节是title，中间16个字节是链表，后八个字节是一会write的时候写内容的chunk地址。

write
就是申请一个chunk，写东西，地址放到上面create里面说的那个玩意里面。
但是只能写一次。

show
正常show

delete
free掉chunk，但是漏洞就在free掉那个wirte的chunk之后没有清理指针，造成uaf。那个指针可以重复使用，多次释放，可以double free。

思路是啥
首先我们需要知道libc的版本。
先尝试一次double free，看报不报错，或者报错类型，来看看libc版本是2.23 2.27还是2.29及以上。

因为2.23的话就会直接报double free。
2.29及以上会报tcache dup 2.

最后double free啥都不报，确定了2.27的版本，具体2。27那个版本一会试一试就清楚了。

再说解题，我们现在有double free，首要任务是泄露libc，但是我们的chunk只能申请到0x60大小，所以首先想到的是攻击tcache struct。所以首先就通过double free泄露heap地址，然后污染tcache struct，释放掉它，得到libc地址。

得到之后再怎么利用，常规来讲我们只需要利用double free去攻击free_hook就好啦。
但是因为tcache被污染了，我们只能提前申请好大小合适的chunk，然后free进入tcache，或者我这里利用的方法是tcache中有一个残留的指针，只需要提前留几个0x30的chunk，方便申请，就可以直接利用残留的指针攻击free_hook。

exp

from pwn import*

context.log_level = "debug"
context.terminal = ['tmux', 'splitw', '-h']


#r = process("./moon")
r = remote("pwn.challenge.ctf.show", 28098)

elf = ELF("./moon")
#libc = ELF("/home/wuangwuang/glibc-all-in-one-master/glibc-all-in-one-master/libs/2.27-3ubuntu1.2_amd64/libc.so.6")
libc = ELF