以[GKCTF 2020]domo为例来看off-by-null

今天开始学习off-by-one系列，这是今天遇到的第一个样题，以此记录一下其中的知识点。

这是题目：

会把指针清零，没有uaf漏洞，并且保护全开，不能edit。

一眼off-by-null

首先肯定要泄露libc基址，在wp中有两种方法：
 

add(0xf0) #index 0
add(0xf0) #index 1
free(0)
add(0xf0, b'a'*8) #index 0
show(0)
libc_base = get_addr() - 0x68 - libc.sym['__malloc_hook']

这是第一种，分配一个0xf0，然后free到unsortedbin中，由于unsortedbin中只有这一个chunk，所以它的fd和bk都是usortedbin地址，可以再分配回来打印内容。

下面分段补充知识：

add(0x80)  #0
add(0x60)  #1
add(0x20)  #2
add(0xf0)  #3
add(0x10, b'/bin/sh\x00')  #4

delete(2)  
add(0x28, b'\x00'*0x20 + p64(0x130)) #2
delete(0)
delete(3)
add(0xf0)  #0
show(2)

首先，由于是off-by-null，所以你被off的chunk的大小必须是0x100,0x200这样，因为一字节会直接覆盖十六进制的低2位，你如果是0x80，会直接变成0x00，会出现错误。

这是未off-by-null之前，可以看到with flag bits是0x101

这是off-by-null之后，变成了0x100，当这个chunk被free的时候就会认为前面有个0x130的空闲chunk，会进行合并。

这是还要注意一点，合并之前一定要先释放掉要合并的最底下的chunk，让它的fd和bk域有相应的地址，因为合并的时候会进行unlink，如果bk和fd区域是乱七八糟的东西肯定会报错。

这是合并之后的：

成功合并了。

继续补充知识：当我们要分配一个chunk时，它会先去unsortedbin里找。直到找到一个比所要内存大的，但不会把这个unsortedbin全都给你，它会切你要的大小给你，剩余部分继续挂unsortedbin上。

由gdb调试可知，是从低地址开始切。

现在我们就知道了off-by-null的大致作用，就是将一大片区域分配给我们，我们可以在这片区域写fd，来实现fastbin attack。,我认为这是他的主要作用。

顺便又用gdb做了一些调试：

这说明top chunk不会与fastbin合并，并且fastbin和fastbin的下一个chunk的pre_inuse位肯定为1。