从一道题来体会用UAF打unlink
关于house of banana的学习总结
house of cat -2022强网杯pwn复现
前几天进行了 house of apple 的学习,而 house of appl2 和 house of cat 利用的大致思想是一样的(都是通过 wide_data->wide_vtable 中的函数指针进行的跳转),因此来复现一下去年强网杯的这道 house of cat
本题我感觉也比较有代表性,因为在 house of apple 的那篇文章中的例题最后触发攻击是在 exit 函数,但是如果题目中无法从 main 函数返回也没有 exit 函数,那就需要通过 malloc_assert 来触发最后的攻击,而本题就是通过这样的方式触发的攻击。
Safe-Linking 机制的绕过
前言
自从引入了 tcache 机制后,从 2.26 开始 tcache poisoning 就是一种简便的攻击方式,因为它不需要像 fastbin attack 利用那样对 size 检查较为严格(只能申请到 malloc 和 _IO_2_1_stdout_ 上方的区域),篡改了 tcache bin 中堆块的 next 指针就相当于可以任意地址申请了
safe-Linking
在 2.32 之前 tcache poisoning 可以说是无往不利,但到了 glibc 2.32 及以后,增加了 safe-Linking 机制,至此篡改 next 指针直接任意地址申请的操作便绝迹在了高版本的 libc 中
check_gadget--检测one_gadget能否使用的gdb命令
作为一个 pwner ,对 one_gadget 肯定不会陌生,如果在能劫持执行流的前提下, one_gadget 在劫持执行流的位置也恰巧能用,那就可以在一定程度上简化获取 shell 的操作,因为执行 system("/bin/sh\x00") 是需要控制参数的,有些情况下劫持执行流容易但可能控制参数还得再废些力气,此时成功打一发 one_gadget 可以说是方便又迅速。
但因为 one_gadget 条件的限制, one_gadget 成功的概率并不高,通常是一个一个试,或者调试到劫持执行流的位置观察一下寄存器和内存的情况进行判断。很早之前我就有这样一个想法,如果能用 gdb 调试到劫持的地址处,输入一个命令直接判断所有的 one_gadget 能否生效该有多方便。终于在几天前进行了动手实践,并将其写出来。
关于vm pwn的学习总结
目前就做了两道vm pwn的题目先简单总结一下,这类题目逆向量较大,如果有分析不懂的函数或者某段指令可以尝试配合gdb动态调试观察某些寄存器或内存值的变化来猜测其功能。漏洞点大多为数组越界可以写或者任意读来劫持hook或者got表等等。不一定每个指令都要具体分析明白,个人认为去关注漏洞指令,其他指令用到哪个去简单分析哪个
C++ 常见术语&&基础概念的学习总结
简单入门了一下 C++ ,学习了几天,大概清楚了这些常用的术语和基础概念,虽然这对 PWN 中的 C++ 题目逆向帮助实在不大,但好奇心总是驱使着我尝试弄懂它们。感谢 winmt 师傅在我这部分的学习中,解惑我的一些奇奇怪怪的问题