【HITCON-Training】Lab 13 - HeapCreator

学习于2024年9月29日

心得感想：现在是2024/9/30的凌晨2：19分，今天又熬夜了。但是这道题是真正意义上自己思考做出来的（虽然还是有看答案）。成就感很足，这就是pwn的魅力！

Lab 13 - HeapCreator

首先查看ida，理清程序思路（感觉这道题的漏洞off-by-one太刻意了）：

在edit_heap中发现居然允许我们多溢出一个字节，很明显，当chunk在使用中占用下一个的prev_size的时候，多溢出的一个字节不多不少就是控制size且能控制最关键的AMP标志位。
思路就有了：

1. 通过chunk[0]使用off-by-one使chunk[1]认为自己的大小包括content
2. 释放chunk1（此处free的很完整，没有UAF漏洞），然后再申请chunk2，通过重叠的两个chunk获得写入chunk1的权限（有一点像use after free,程序以为你没有权限，其实你有）。此时chunk2的content包括chunk2的heap_struct。
3. 通过chunk2将chunk2的heap_struct的地址修改为libc@got表地址
4. 使用show()获得地址算出偏移
5. 再次用edit将system填入某个got表中
6. 大功告成，下次使用这个地址就会自动调用got表地址

过程

通过off-by-one覆盖size

结果是成功将chunk1的size修改成40：

想要运用prev_size是有讲究的！你要故意不申请对齐长度（2机器字长，那么64位就是16字节），那么“勤俭节约”的堆管理器才会帮你把别人不用的prev_size八字节给你“缝上”，真是节约啊！

再次申请达到overlapping chunk

我们可以发现勤俭节约的堆管理器把“垃圾桶”bins里面的chunk给你用了，谁叫你刚好申请的就是那么大呢？

但他似乎没意识到，为什么chunk_struct的string指针居然指在离它不远处并且还在低地址，难道不怕写上来覆盖吗？

覆盖并将字符串指针指向atoi@got,然后将它读出来

目的达到了，看看地址：

接下来老生常谈了，将atoi@got劫持成system

成功啦~