本文全文由winmt一人编写，初稿完成于2022.2.1，在编写过程中，参考了 《CTF竞赛权威指南（Pwn篇）》 一书，以及 raycp，风沐云烟，wjh，Ex，ha1vk 等众多大师傅的博客与 安全客，看雪论坛，先知社区，CTF-WiKi 上的部分优秀的文章，在此一并表示感谢。

本文主要着眼于glibc下的一些漏洞及利用技巧和IO调用链，由浅入深，分为 “基础堆利用漏洞及基本IO攻击” 与 “高版本glibc下的利用” 两部分来进行讲解，前者主要包括了一些glibc相关的基础知识，以及低版本glibc（2.27及以前）下常见的漏洞利用方式，后者主要涉及到一些较新的glibc下的IO调用链。

本篇文章加入了大量笔者自己的理解，力求用尽可能直白的语言解释清楚一些漏洞的原理和利用方式，给初学者们良好的阅读体验，以少走一些弯路，但笔者本身比较菜，水平也很有限，加上这篇文章成稿的时间较短，因此难免会有一些错误，也欢迎各位读者和笔者进行交流讨论，笔者的邮箱是：wjcmt2003@qq.com 。

由低地址向高地址增长，可读可写，首地址16字节对齐，未开启ASLR，start_brk紧接BSS段高地址处，开启了ASLR，则start_brk会在BSS段高地址之后随机位移处。通过调用brk()与sbrk()来移动program_break使得堆增长或缩减，其中brk(void* end_data_segment)的参数用于设置program_break的指向，sbrk(increment)的参数可正可负可零，用于与program_break相加来调整program_break的值，执行成功后，brk()返回0，sbrk()会返回上一次program_break的值。

当申请的size大于mmap的阈值mp_.mmap_threshold(128*1024=0x20000)且此进程通过mmap分配的内存数量mp_.n_mmaps小于最大值mp_.n_mmaps_max，会使用mmap来映射内存给用户（映射的大小是页对齐的），所映射的内存地址与之前申请的堆块内存地址并不连续（申请的堆块越大，分配的地址越接近libc）。若申请的size并不大于mmap的阈值，但top chunk当前的大小又不足以分配，则会扩展top chunk，然后从top chunk里分配内存。

泄露libc：在能够查看内存分配的环境下（本地vmmap，远程环境通过传非法地址泄露内存分配），通过申请大内存块，可通过利用mmap分配到的内存块地址与libc基址之间的固定偏移量泄露libc地址。

其中0x7ffff79e4000就是本次libc的基地址。

在这个结构体中，包含了许多成员（考虑在64位下）：

1.fast bin：

(1) 单链表，LIFO（后进先出），例如，A->B->C，加入D变为：D->A->B->C，拿出一个，先拿D，又变为A->B->C。
(2) fastbinsY[0]容纳0x20大小的堆块，随着序号增加，所容纳的范围递增0x10，直到默认最大大小（DEFAULT_MXFAST）0x80（但是其支持的fast bin的最大大小MAX_FAST_SIZE为0xa0），mallopt(1,0)即mallopt(M_MXFAST,0)将 MAX_FAST_SIZE设为0，禁用fast bin。
(3) 当一个堆块加进fast bin时，不会对下一个堆块的PREV_INUSE进行验证（但是会对下一个堆块size的合法性进行检查），同样地，将一个堆块从fast bin中释放的时候，也不会对其下一个堆块的PREV_INUSE进行更改（也不会改下一个堆块的PREV_SIZE），只有触发malloc_consolidate()后才会改下一个堆块的PREV_INUSE。

(4) 当申请一个大于large chunk最小大小（包括当申请的chunk需要调用brk()申请新的top chunk或调用mmap()函数时）的堆块之后，会先触发malloc_consolidate()，其本身会将fast bin内的chunk取出来，与相邻的free chunk合并后放入unsorted bin，或并入top chunk（如果无法与相邻的合并，就直接将其放入unsorted bin），然后由于申请的large chunk显然在fast bin,small bin内都找不到，于是遍历unsorted bin，将其中堆块放入small bin,large bin，因此最终的效果就是fast bin内的chunk与周围的chunk合并了（或是自身直接进入了unsorted bin），最终被放入了small bin,large bin，或者被并入了top chunk，导致fast bin均为空。
(5) 若free的chunk和相邻的free chunk合并后的size大于FASTBIN_CONSOLIDATION_THRESHOLD(64k)（包括与top chunk合并），那么也会触发malloc_consolidate()，最终fast bin也均为空。
(6) 伪造fast bin时，要绕过在__int_malloc()中取出fake fast bin时，对堆块大小的检验。

2.unsorted bin：

双链表，FIFO（先进先出），其实主要由bk连接，A<-B<-C进一个D变为D<-A<-B<-C，拿出一个C，变为D<-A<-B。bin中堆块大小可以不同，不排序。
一定大小的chunk被释放后在被放入small bin,large bin之前，会先进入unsorted bin。
泄露libc：unsorted_bin中最先进来的free chunk的fd指针和最后进来的free chunk的bk指针均指向了main_arena中的位置，在64位中，一般是<main_arena+88>或<main_arena+96>，具体受libc影响，且main_arena的位置与__malloc_hook相差0x10，而在32位的程序中，main_arena的位置与__malloc_hook相差0x18，加入到unsorted bin中的free chunk的fd和bk通常指向<main_arena+48>的位置。

此外，可修改正处在unsorted bin中的某堆块的size域，然后从unsorted bin中申请取出该堆块时，不会再检测是否合法，可进行漏洞利用。

3.small bin：

双链表，FIFO（先进先出），同一个small bin内存放的堆块大小相同。
大小范围：0x20 ~ 0x3F0 。

4.large bin：

双链表，FIFO（先进先出），每个bin中的chunk的大小不一致，而是处于一定区间范围内，里面的chunk从头结点的fd_nextsize指针开始，按从大到小的顺序排列，同理换成bk_nextsize指针，就是按从小到大的顺序排列。
需要注意，若现在large bin内是这样的：0x420<-(1)0x410(2)<-，再插一个0x410大小的堆块进去，会从(2)位置插进去。
large bin中size与index的对应如下：

5.tcache：

(1) 单链表，LIFO（后进先出），每个bin内存放的堆块大小相同，且最多存放7个，大小从24 ~ 1032个字节，用于存放non-large的chunk。
(2) tcache_perthread_struct本身也是一个堆块，大小为0x250，位于堆开头的位置，包含数组counts存放每个bin中的chunk当前数量，以及数组entries存放64个bin的首地址（可以通过劫持此堆块进行攻击）。
(3) 在释放堆块时，在放入fast bin之前，若tcache中对应的bin未满，则先放入tcache中。
(4) 从fast bin返回了一个chunk，则单链表中剩下的堆块会被放入对应的tcache bin中，直到上限。
从small bin返回了一个chunk，则双链表中剩下的堆块会被放入对应的tcache bin中，直到上限。
在将剩余堆块从small bin放入tcache bin的过程中，除了检测了第一个堆块的fd指针，都缺失了__glibc_unlikely (bck->fd != victim)的双向链表完整性检测。
(5) binning code，如在遍历unsorted bin时，每一个符合要求的chunk都会优先被放入tcache，然后继续遍历，除非tcache已经装满，则直接返回，不然就在遍历结束后，若找到了符合要求的大小，则把tcache中对应大小的返回一个。
(6) 在__libc_malloc()调用__int_malloc()之前，如果tcache bin中有符合要求的chunk就直接将其返回。
(7) CVE-2017-17426是libc-2.26存在的漏洞，libc-2.27已经修复。
(8) 可将tcache_count整型溢出为0xff以绕过tcache，直接放入unsorted bin等，但在libc-2.28中，检测了counts溢出变成负数（0x00-1=0xff）的情况，且增加了对double free的检查。
(9) calloc()越过tcache取chunk，通过calloc()分配的堆块会清零。补充：realloc()的特殊用法：size == 0时，等同于free；realloc_ptr == 0 && size > 0 时等同于malloc。如果当前连续内存块足够realloc的话，只是将p所指向的空间扩大，并返回p的指针地址；如果当前连续内存块不够，则再找一个足够大的地方，分配一块新的内存q，并将p指向的内容copy到q，返回 q。并将p所指向的内存空间free；若是通过realloc缩小堆块，则返回的指针p不变，但原先相比缩小后多余的那部分将会被free掉。

6.top chunk：

除了house of force外，其实对于top chunk还有一些利用点。
当申请的size不大于mmap的阈值，但top chunk当前的大小又不足以分配，则会扩展top chunk，然后从新top chunk里进行分配。
这里的扩展top chunk，其实不一定会直接扩展原先的top chunk，可能会先将原先的top chunk给free掉，再在之后开辟一段新区域作为新的top chunk。
具体是，如果brk等于该不够大小的top chunk（被记作old_top_chunk）的end位置（old_end，等于old_top + old_size），即top chunk的size并没有被修改，完全是自然地分配堆块，导致了top chunk不够用，则会从old_top处开辟更大的一块空间作为新的top chunk，也就是将原先的old_top_chunk进行扩展了，此时没有free，且top chunk的起始位置也没有改变，但是如果brk不等于old_end，则会先free掉old_top_chunk，再从brk处开辟一片空间作为new_top_chunk，此时的top chunk头部位置变为了原先的brk，而如今的brk也做了相应的扩展，并且unsorted bin或tcache中（一般修改的大小都至少会是small bin范围，但具体在哪得分情况看）会有被free的old_top_chunk。
因此，可以通过改小top chunk的size，再申请大堆块，做到对旧top chunk的free，不过修改的size需要绕过一些检测。
相关源码如下：

需要绕过以上的断言，主要就是要求被修改的top chunk的size的prev_inuse位要为1并且old_end要内存页对齐，所以就要求被修改的size的后三位和原先要保持一致。

free(p)后未将p清零，若是没有其他检查的话，可能造成UAF漏洞。
double free就是利用UAF漏洞的经典例子。

1.fast bin的double free：

(1) fast bin对double free有检查，会检查当前的chunk是否与fast bin顶部的chunk相同，如果相同则报错并退出。因此，我们不能连续释放两次相同的chunk。
可采用如下方式在中间添加一个chunk便绕过检查：
释放A，单链表为A，再释放B，单链表为B->A，再释放A，单链表为A->B->A，然后申请到A，同时将其中内容改成任意地址（改的是fd指针），单链表就成了B->A->X，其中X就是任意地址，这样再依次申请B，A后，再申请一次就拿到了地址X，可以在地址X中任意读写内容。
(2) 其实，若是有Edit功能的话，可以有如下方式：
若当前单链表是B->A，将B的fd指针通过Edit修改为任意地址X，单链表就变成了B->X，申请了B之后，再申请一次，就拿到了X地址，从而进行读写。
需要注意的是，以上的X准确说是fake chunk的chunk header地址，因为fast bin会检测chunk_header_addr + 8（即size）是否符合当前bin的大小。

2.tcache的double free：

libc-2.28之前并不会检测double free，因此可以连续两次释放同一个堆块进入tcache，并且tcache的next指针指向的是user data，因此不会做大小的检测。
释放A，单链表为A，再释放A，单链表为A->A，申请A并把其中内容（next指针）改成X，则单链表为A->X，再申请两次，拿到X地址的读写权。
在以上过程结束后，实际上是放进tcache了两次，而申请取出了三次，因此当前tcache的counts会变成0xff，整型溢出，这是一个可以利用的操作，当然若是想避免此情况，在第一次释放A之前，可以先释放一次B，将其放入此tcache bin即可。
此外，若是有Edit功能，仿照上述 fast bin对应操作的技术被称为tcache_poisoning。

3.glibc2.31下的double free：

在 glibc2.29之后加入了对tcache二次释放的检查，方法是在tcache_entry结构体中加入了一个标志key，用于表示chunk是否已经在所属的tcache bin中，对于每个chunk而言，key在其bk指针的位置上。
当chunk被放入tcache bin时会设置key指向其所属的tcache结构体：e->key = tcache;，并在free时，进入tcache bin之前，会进行检查：如果是double free，那么put时key字段被设置了tcache，就会进入循环被检查出来；如果不是，那么key字段就是用户数据区域，可以视为随机的，只有1/(2^size_t)的可能行进入循环，然后循环发现并不是double free。这是一个较为优秀的算法，进行了剪枝，具体源码如下：

可通过fast bin double free+tcache stash机制来进行绕过：
(1) 假设目前tcache被填满了：C6->C5->C4->C3->C2->C1->C0，fast bin中为：C7->C8->C7。
(2) 下一步，为了分配到fast bin，需要先申请7个，让tcache为空（或calloc），再次申请时就会返回fast bin中的C7，同时由于tcache stash机制，fast bin中剩下的C8,C7均被放入了tcache bin，此时，在C7的fd字段写入target_addr（相当于获得了Edit功能），于是target_addr也被放入了tcache bin，因此这里target_addr处甚至不需要伪造size（target_addr指向user data区）。
(3) 此时，tcache bin中单链表为：C8->C7->target_addr，再申请到target_addr，从而得到了一个真正的任意写。
补充：

上述代码，若是按注释中的写，则在没有触发tcache stash机制时，fast bin中为C9->C8->C7，取走C9，最终tcache bin中是C7->C8，符合设想（依次取C8，C7放入tcache bin）。
然而，若是double free chunk_7，则在没有触发tcache stash机制时，fast bin中为C7->C8->C7，取走C7，最终tcache bin中是C8->C7->C8，而若是按照tcache bin放入的规则，应该也是类似于C7->C8，不符合设想。
流程如下：
(1) 取C8放入tcache bin，同时REMOVE_FB (fb, pp, tc_victim);会清空C8的next(fd)指针，并且将链表头设置为指向C8原先fd指针指向的堆块C7（源码分析如下）。

(2) 目前fast bin中为C7->C8（最开始取走C7并不清空其fd字段），然后根据tcache bin的放入规则，最终依次放入后为C8->C7->C8。

4.当可以Edit时，往往就不需要double free了，而有些情况看似不能对空闲中的堆块进行Edit（比如存放长度的数组在free后会清零），但是可以利用UAF漏洞对处于空闲状态的堆块进行Edit，例如：

此时，我们编辑chunk 2，实则是在对已经free的chunk 1进行编辑。

缓冲区溢出了一个字节，由于glibc的空间复用技术（即pre_size给上一个allocated的堆块使用），所以可通过off by one修改下一个堆块的size域。
经常是由于循环次数设置有误造成了该漏洞的产生。比较隐蔽的是strcpy会在复制过去的字符串末尾加\x00，可能造成poison null byte，例如，strlen 和 strcpy 的行为不一致可能会导致off-by-one 的发生：strlen 在计算字符串长度时是不把结束符\x00计算在内的，但是strcpy在复制字符串时会拷贝结束符 \x00。
off by one经常可以与Chunk Extend and Overlapping配合使用。

unlink:由经典的链表操作FD=P->fd;BK=P->bk;FD->bk=BK;BK->fd=FD;实现，这样堆块P就从该双向链表中取出了。
unlink中有一个保护检查机制：(P->fd->bk!=P || P->bk->fd!=P) == False，需要绕过。

对于fast bin，可以在栈上伪造两个fake chunk，但需要绕过检查，应满足第一个fake chunk的标志位IS_MMAPPED与NON_MAIN_ARENA均为零（PREV_INUSE并不影响释放），且要求其大小满足fast bin的大小，对于其next chunk，即第二个fake chunk，需要满足其大小大于0x10，小于av->system_mem（0x21000）才能绕过检查。之后，伪造指针P = & fake_chunk1_mem，然后free(P)，fake_chunk1就进入了fast bin，之后再申请同样大小的内存，即可取出fake_chunk1，获得了栈上的任意读写权（当然并不局限于在栈上伪造）。
该技术在libc-2.26中仍然适用，可以对tcache做类似的操作，甚至没有对上述next chunk的检查。

主要思路为：将top chunk的size改为一个很大的数，就可以始终让top chunk满足切割条件，而恰好又没有对其的检查，故可利用此漏洞，top chunk的地址加上所请求的空间大小造成了整型溢出，使得top chunk被转移到内存中的低地址区域（如bss段，data段，got表等等），接下来再次请求空间，就可以获得转移地址后面的内存区域的控制权。

house of rabbit是利用malloc_consolidate()合并机制的一种方法。
malloc_consolidate()函数会将fastbin中的堆块之间或其中堆块与相邻的freed状态的堆块合并在一起，最后达到的效果就是将合并完成的堆块（或fastbin中的单个堆块）放进了smallbin/largebin中，在此过程中，并不会对fastbin中堆块的size或fd指针进行检查，这是一个可利用点。

fastbin中的堆块size可控（比如off by one等）
比如现在fastbin有两个0x20的堆块A -> B，其中chunk B在chunk A的上方，我们将chunk B的size改为0x40，这样就正好包含了chunk A，且fake chunk B下面的堆块也就是chunk A下方的堆块，也是合法的，假设这个堆块不是freed的状态，那么触发malloc_consolidate()之后，smallbin里就会有两个堆块，一个是chunk A，另外一个是fake chunk B，其中包含了chunk A，这样就实现了堆块重叠。

fastbin中的堆块fd可控（比如UAF漏洞等）
其实就是将fastbin中的堆块的fd改为指向一个fake chunk，然后通过触发malloc_consolidate()之后，使这个fake chunk完全“合法化”。不过，需要注意伪造的是fake chunk's next chunk的size与其next chunk's next chunk的size（prev_inuse位要为1）。

unsorted bin into stack的原理比较简单，就是在栈上伪造一个堆块，然后修改unsorted bin中某堆块的bk指针指向此fake chunk，通过申请到此fake chunk达到对栈上地址的读写权。需要注意的是高版本有tcache的情况，此时在unsorted bin中找到一个合适大小的堆块后并不会直接返回，而是会放入tcache bin中，直到上限，若是某时刻tcache_count达到上限，则直接返回该fake chunk，不然会继续遍历，并在最后从tcache bin中取出返回给用户，此时就要求fake chunk的bk指针指向自身，这样就可以通过循环绕过。
再来看真正的unsorted bin attack，其实在上述利用中，fake chunk的fd指针被修改成了unsorted bin的地址，位于main_arena，甚至可以通过泄露其得到libc的基地址，当然也可以通过这个利用，将任意地址中的值改成很大的数（如global_max_fast），这就是unsorted bin attack的核心，其原理是：当某堆块victim从unsorted bin list中取出时，会进行bck = victim->bk; unsorted_chunks(av)->bk = bck; bck->fd = unsorted_chunks(av);的操作。
例如，假设chunk_A在unsorted bin中，此时将chunk_A的bk改成&global_max_fast - 0x10，然后取出chunk_A，那么chunk_A->bk->fd，也就是global_max_fast中就会写入unsorted bin地址，即一个很大的数。若是在高版本有tcache的情况下，可通过放入tcache的次数小于从中取出的次数，从而整型溢出，使得tcache_count为一个很大的数，如0xff，就可以解决unsorted bin into stack中提到的tcache特性带来的问题。

假设当前chunk_A在large bin中，修改其bk为addr1 - 0x10，同时修改其bk_nextsize为addr2 - 0x20，此时chunk_B加入了此large bin，其大小略大于chunk_A，将会进行如下操作：

其中，victim就是chunk_B，而fwd就是修改过后的chunk_A，注意到3处bck->fd = victim，同时，把1带入2可得到：fwd->bk_nextsize->fd_nextsize=victim，因此，最终addr1与addr2地址中的值均被赋成了victim即chunk_B的chunk header地址，也是一个很大的数。

一种large bin attack配合类似于unsorted bin into stack的攻击手段，适用于libc-2.30版本以下，由于基本可以被IO_FILE attack取代，目前应用情景并不是很广泛，但是其思路还是挺巧妙的，所以这里也介绍一下。
我们想用类似于unsorted bin into stack的手段，将某个unsorted bin的bk指向我们需要获得读写权限的地址，然后申请到该地址，但是我们又没办法在该地址周围伪造fake chunk，这时候可以配合large bin attack进行攻击。
假设需要获取权限的目标地址为addr，我们首先将某个unsorted bin（large bin大小，大小为X，地址为Z）的bk指向addr-0x20，然后将此时large bin中某堆块（大小为Y，X略大于Y）的bk设为addr-0x18，bk_nextsize设为addr-0x20-0x20+3。
这时通过申请0x50大小的堆块（后面解释），然后unsorted bin的那个堆块会被放入large bin中，先是addr-0x10被写入main_arena+88（在此攻击手段中用处不大），然后由于large bin attack，在地址Z对应的堆块从unsorted bin被转入large bin后，addr-0x8会被写入地址Z，从addr-0x20+3开始也会写入地址Z，造成的结果就是addr-0x18处会被写入了0x55或0x56（即地址Z的最高位），相当于伪造了size。
此时的情形如下：

这时，由于之前申请了0x50大小的堆块（解释了设置large bin的bk_nextsize的目的，即为伪造size），那么就会申请到chunk header位于addr-0x20的fake chunk返回给用户，此时需要访问到fake chunk的bk指针指向的地址（bck->fd = victim），因此需要其为一个有效的地址，这就解释了设置large bin的bk的目的。
最后需要说明的是，当开了地址随机化之后，堆块的地址最高位只可能是0x55或0x56，而只有当最高位为0x56的时候，上述攻击方式才能生效，这里其实和伪造0x7f而用0x7_后面加上其他某个数可能就不行的原因一样，是由于__libc_malloc中有这么一句断言：

过上述检测需要满足以下一条即可：

值得一提的是，由于addr-0x8（即fake chunk的bk域）被写入了地址Z，因此最终在fake chunk被返还给用户后，unsorted bin中仍有地址Z所对应的堆块（已经被放入了large bin中），且其fd域被写入了main_arena+88（bck->fd = unsorted_chunks(av)）。

先来看house of lore，如果能够修改small bin的某个free chunk的bk为fake chunk，并且通过修改fake chunk的fd为该free chunk，绕过__glibc_unlikely( bck->fd != victim )检查，就可以通过申请堆块得到这个fake chunk，进而进行任意地址的读写操作。
当在高版本libc下有tcache后，将会更加容易达成上述目的，因为当从small bin返回了一个所需大小的chunk后，在将剩余堆块放入tcache bin的过程中，除了检测了第一个堆块的fd指针外，都缺失了__glibc_unlikely (bck->fd != victim)的双向链表完整性检测，又calloc()会越过tcache取堆块，因此有了如下tcache_stashing_unlink_attack的攻击手段，并同时实现了libc的泄露或将任意地址中的值改为很大的数（与unsorted bin attack很类似）。

假设目前tcache bin中已经有五个堆块，并且相应大小的small bin中已经有两个堆块，由bk指针连接为：chunk_A<-chunk_B。

利用漏洞修改chunk_A的bk为fake chunk，并且修改fake chunk的bk为target_addr - 0x10。

通过calloc()越过tcache bin，直接从small bin中取出chunk_B返回给用户，并且会将chunk_A以及其所指向的fake chunk放入tcache bin（这里只会检测chunk_A的fd指针是否指向了chunk_B）。

在fake chunk放入tcache bin之前，执行了bck->fd = bin;的操作（这里的bck就是fake chunk的bk，也就是target_addr - 0x10），故target_addr - 0x10的fd，也就target_addr地址会被写入一个与libc相关大数值（可利用）。

再申请一次，就可以从tcache中获得fake chunk的控制权。

综上，此利用可以完成获得任意地址的控制权和在任意地址写入大数值两个任务，这两个任务当然也可以拆解分别完成。

此外，让tcache bin中不满七个，就又在smallbin中有同样大小的堆块，并且只有calloc，可以利用堆块分割后，残余部分进入unsorted bin实现。

_IO_FILE_plus结构体的定义为：

vtable对应的结构体_IO_jump_t的定义为：

这个函数表中有19个函数，分别完成IO相关的功能，由IO函数调用，如fwrite最终会调用__write函数，fread会调用__doallocate来分配IO缓冲区等。

进程中FILE结构通过_chain域构成一个链表，链表头部为_IO_list_all全局变量，默认情况下依次链接了stderr,stdout,stdin三个文件流，并将新建的流插入到头部，vtable虚表为_IO_file_jumps。
此外，还有_IO_wide_data结构体：

还有一些宏的定义：

此外，许多Pwn题初始化的时候都会有下面三行：

这是初始化程序的io结构体，只有初始化之后，io函数才能在程序过程中打印数据，如果不初始化，就只能在exit结束的时候，才能一起把数据打印出来。

主要原理为劫持vtable与_chain，伪造IO_FILE，主要利用方式为调用IO_flush_all_lockp()函数触发。
IO_flush_all_lockp()函数将在以下三种情况下被调用：

源码：

可以看到，当满足：

就会调用_IO_OVERFLOW()函数，而这里的_IO_OVERFLOW就是文件流对象虚表的第四项指向的内容_IO_new_file_overflow，因此在libc-2.23版本下可如下构造，进行FSOP：

因此这样构造，通过_IO_OVERFLOW (fp)，我们就实现了system("/bin/sh\x00")。

而libc-2.24加入了对虚表的检查IO_validate_vtable()与IO_vtable_check()，若无法通过检查，则会报错：Fatal error: glibc detected an invalid stdio handle。

可见在最终调用vtable的函数之前，内联进了IO_validate_vtable函数，其源码如下：

glibc中有一段完整的内存存放着各个vtable，其中__start___libc_IO_vtables指向第一个vtable地址_IO_helper_jumps，而__stop___libc_IO_vtables指向最后一个vtable_IO_str_chk_jumps结束的地址。
若指针不在glibc的vtable段，会调用_IO_vtable_check()做进一步检查，以判断程序是否使用了外部合法的vtable（重构或是动态链接库中的vtable），如果不是则报错。
具体源码如下：

因此，最好的办法是：我们伪造的vtable在glibc的vtable段中，从而得以绕过该检查。
目前来说，有四种思路：利用_IO_str_jumps中_IO_str_overflow()函数，利用_IO_str_jumps中_IO_str_finish()函数与利用_IO_wstr_jumps中对应的这两种函数，先来介绍最为方便的：利用_IO_str_jumps中_IO_str_finish()函数的手段。
_IO_str_jumps的结构体如下：

其中，_IO_str_finish源代码如下：

其中相关的_IO_str_fields结构体与_IO_strfile_结构体的定义：

可以看到，它使用了IO结构体中的值当作函数地址来直接调用，如果满足条件，将直接将fp->_s._free_buffer当作函数指针来调用。
首先，仍然需要绕过之前的_IO_flush_all_lokcp函数中的输出缓冲区的检查_mode<=0以及_IO_write_ptr>_IO_write_base进入到_IO_OVERFLOW中。
我们可以将vtable的地址覆盖成_IO_str_jumps-8，这样会使得_IO_str_finish函数成为了伪造的vtable地址的_IO_OVERFLOW函数（因为_IO_str_finish偏移为_IO_str_jumps中0x10，而_IO_OVERFLOW为0x18）。这个vtable（地址为_IO_str_jumps-8）可以绕过检查，因为它在vtable的地址段中。
构造好vtable之后，需要做的就是构造IO FILE结构体其他字段，以进入将fp->_s._free_buffer当作函数指针的调用：先构造fp->_IO_buf_base为/bin/sh的地址，然后构造fp->_flags不包含_IO_USER_BUF，它的定义为#define _IO_USER_BUF 1，即fp->_flags最低位为0。
最后构造fp->_s._free_buffer为system_addr或one gadget即可getshell。
由于libc中没有_IO_str_jump的符号，因此可以通过_IO_str_jumps是vtable中的倒数第二个表，用vtable的最后地址减去0x168定位。
也可以用如下函数进行定位：

可以进行如下构造：

利用house of orange（见下文）构造的payload：

再来介绍一下：利用_IO_str_jumps中_IO_str_overflow()函数的手段。
_IO_str_overflow()函数的源码如下：

和之前利用_IO_str_finish的思路差不多，可以看到其中调用了fp->_s._allocate_buffer函数指针，其参数rdi为new_size，因此，我们将_s._allocate_buffer改为system的地址，new_size改为/bin/sh的地址，又new_size = 2 * old_blen + 100，也就是new_size = 2 * _IO_blen (fp) + 100，可以找到宏定义：#define _IO_blen(fp) ((fp)->_IO_buf_end - (fp)->_IO_buf_base)，因此new_size = 2 * ((fp)->_IO_buf_end - (fp)->_IO_buf_base) + 100，故我们可以使_IO_buf_base = 0，_IO_buf_end = (bin_sh_addr - 100) // 2，当然还不能忘了需要绕过_IO_flush_all_lokcp函数中的输出缓冲区的检查_mode<=0以及_IO_write_ptr>_IO_write_base才能进入到_IO_OVERFLOW中，故令_IO_write_ptr = 0xffffffffffffffff且_IO_write_base = 0x0即可。
最终可按如下布局fake IO_FILE：

参考payload（劫持的stdout）：

而在libc-2.28及以后，由于不再使用偏移找_s._allocate_buffer和_s._free_buffer，而是直接用malloc和free代替，所以FSOP也失效了。

利用unsorted bin attack 配合 IO_FILE attack (FSOP)进行攻击。
通过unsorted bin attack将_IO_list_all内容从_IO_2_1_stderr_改为main_arena+88/96（实则指向top chunk）。
而在_IO_FILE_plus结构体中，_chain的偏移为0x68，而top chunk之后为0x8单位的last_remainder，接下来为unsorted bin的fd与bk指针，共0x10大小，再之后为small bin中的指针（每个small bin有fd与bk指针，共0x10个单位），剩下0x50的单位，从smallbin[0]正好分配到smallbin[4]（准确说为其fd字段），大小就是从0x20到0x60，而smallbin[4]的fd字段中的内容为该链表中最靠近表头的small bin的地址 (chunk header)，因此0x60的small bin的地址即为fake struct的_chain中的内容，只需要控制该0x60的small bin（以及其下面某些堆块）中的部分内容，即可进行FSOP。

_fileno的值就是文件描述符，位于stdin文件结构开头0x70偏移处，如：stdin的fileno为0，stdout的fileno为1，stderr的fileno为2。
在漏洞利用中，可以通过修改stdin的_fileno值来重定位需要读取的文件，本来为0的话，表示从标准输入中读取，修改为3则表示为从文件描述符为3的文件（已经open的文件）中读取，该利用在某些情况下可直接读取flag。

1.利用stdin进行任意写

scanf，fread，gets等读入走IO指针（read不走）。
大体流程为：若_IO_buf_base为空，则调用_IO_doallocbuf去初始化输入缓冲区，然后判断输入缓冲区是否存在剩余数据，如果输入缓冲区有剩余数据（_IO_read_end > _IO_read_ptr）则将其直接拷贝至目标地址（不会对此时输入的数据进行读入），如果没有或不够，则调用__underflow函数执行系统调用读取数据（SYS_read）到输入缓冲区（从_IO_buf_base到_IO_buf_end，默认0x400，即将数据读到_IO_buf_base，读取0x400个字节），此时若实际读入了n个字节的数据，则_IO_read_end = _IO_buf_base + n（即_IO_read_end指向实际读入的最后一个字节的数据），之后再将输入缓冲区中的数据拷贝到目标地址。
这里需要注意的是，若输入缓冲区中没有剩余的数据，则每次读入数据进输入缓冲区，仅和_IO_buf_base与_IO_buf_end有关。
在将数据从输入缓冲区拷贝到目标地址的过程中，需要满足所调用的读入函数的自身的限制条件，例如：使用scanf("%d",&a)读入整数，则当在输入缓冲区中遇到了字符（或scanf的一些截断符）等不符合的情况，就会停止这个拷贝的过程。最终，_IO_read_ptr指向成功拷贝到目的地址中的最后一个字节数据在输入缓冲区中的地址。因此，若是遇到了不符合限制条件的情况而终止拷贝，则最终会使得_IO_read_end > _IO_read_ptr，即再下一次读入之前会被认定为输入缓冲区中仍有剩余数据，在此情况下，很有可能不会进行此次读入，或将输入缓冲区中剩余的数据拷贝到此次读入的目标地址，从而导致读入的错误。
getchar()和IO_getc()的作用是刷新_IO_read_ptr，每次调用，会从输入缓冲区读一个字节数据，即将_IO_read_ptr++。
相关源码：

综上，为了做到任意写，满足如下条件，即可进行利用：
(1) 设置_IO_read_end等于_IO_read_ptr（使得输入缓冲区内没有剩余数据，从而可以从用户读入数据）。
(2) 设置_flag &~ _IO_NO_READS即_flag &~ 0x4（一般不用特意设置）。
(3) 设置_fileno为0（一般不用特意设置）。
(4) 设置_IO_buf_base为write_start，_IO_buf_end为write_end（我们目标写的起始地址是write_start，写结束地址为write_end），且使得_IO_buf_end-_IO_buf_base大于要写入的数据长度。

2.利用stdout进行任意读/写

printf，fwrite，puts等输出走IO指针（write不走）。
在_IO_2_1_stdout_中，_IO_buf_base和_IO_buf_end为输出缓冲区起始位置（默认大小为0x400），在输出的过程中，会先将需要输出的数据从目标地址拷贝到输出缓冲区，再从输出缓冲区输出给用户。
缓冲区建立函数_IO_doallocbuf会建立输出缓冲区，并把基地址保存在_IO_buf_base中，结束地址保存在_IO_buf_end中。在建立里输出缓冲区后，会将基址址给_IO_write_base，若是设置的是全缓冲模式_IO_FULL_BUF，则会将结束地址给_IO_write_end，若是设置的是行缓冲模式_IO_LINE_BUF，则_IO_write_end中存的是_IO_buf_base，此外，_IO_write_ptr表示输出缓冲区中已经使用到的地址。即_IO_write_base到_IO_write_ptr之间的空间是已经使用的缓冲区，_IO_write_ptr到_IO_write_end之间为剩余的输出缓冲区。
最终实际调用了_IO_2_1_stdout_的vtable中的_xsputn，也就是_IO_new_file_xsputn函数，源码如下：

（1）任意写
可以看到，在行缓冲模式下，判断输出缓冲区还有多少空间，用的是count = f->_IO_buf_end - f->_IO_write_ptr，而在全缓冲模式下，用的是count = f->_IO_write_end - f->_IO_write_ptr，若是还有空间剩余，则会将要输出的数据复制到输出缓冲区中（此时由_IO_write_ptr控制，向_IO_write_ptr拷贝count长度的数据），因此可通过这一点来实现任意地址写的功能。
利用方式：以全缓冲模式为例，只需将_IO_write_ptr指向write_start，_IO_write_end指向write_end即可。
这里需要注意的是，有宏定义#define _IO_LINE_BUF 0x0200，此处flag & _IO_LINE_BUF为真，则表示flag中包含了_IO_LINE_BUF标识，即开启了行缓冲模式（可用setvbuf(stdout,0,_IOLBF,1024)开启），若要构造flag包含_IO_LINE_BUF标识，则flag |= 0x200即可。
（2）任意读
先讨论_IO_new_file_xsputn源代码中if (to_do + must_flush > 0)有哪些情况会执行该分支中的内容：
(a) 首先要明确的是to_do一定是非负数，因此若must_flush为1的时候就会执行该分支中的内容，而再往上看，当需要输出的内容中有\n换行符的时候就会需要刷新输出缓冲区，即将must_flush设为1，故当输出内容中有\n的时候就会执行该分支的内容，如用puts函数输出就一定会执行。
(b) 若to_do大于0，也会执行该分支中的内容，因此，当 输出缓冲区未建立 或者 输出缓冲区没有剩余空间 或者 输出缓冲区剩余的空间不够一次性将目标地址中的数据完全拷贝过来 的时候，也会执行该if分支中的内容。
而该if分支中主要调用了_IO_OVERFLOW()来刷新输出缓冲区，而在此过程中会调用_IO_do_write()输出我们想要的数据。
相关源码：

综上，为了做到任意读，满足如下条件，即可进行利用：
(1) 设置_flag &~ _IO_NO_WRITES，即_flag &~ 0x8；
(2) 设置_flag & _IO_CURRENTLY_PUTTING，即_flag | 0x800；
(3) 设置_fileno为1；
(4) 设置_IO_write_base指向想要泄露的地方，_IO_write_ptr指向泄露结束的地址；
(5) 设置_IO_read_end等于_IO_write_base 或 设置_flag & _IO_IS_APPENDING即，_flag | 0x1000。
此外，有一个大前提：需要调用_IO_OVERFLOW()才行，因此需使得需要输出的内容中含有\n换行符 或 设置_IO_write_end等于_IO_write_ptr（输出缓冲区无剩余空间）等。
一般来说，经常利用puts函数加上述stdout任意读的方式泄露libc。
_flag的构造需满足的条件:

因此，例如在libc-2.27下，构造payload = p64(0xfbad1800) + p64(0)*3 + b'\x58'，泄露出的第一个地址即为_IO_file_jumps的地址。
此外，_flags也可再加一些其他无关紧要的部分，如设置为0xfbad1887，0xfbad1880，0xfbad3887等等。

fastbin_ptr在libc-2.23指向main_arena+8的地址，在libc-2.27及以上指向main_arena+0x10的地址，从此地址开始，存放了各大小的fast bin的fd指针，指向各单链表中首个堆块的地址，因此可将global_max_fast改为很大的数，再释放大堆块进入fast bin，那么就可以将main_arena后的某处覆盖成该堆块地址。
因此，我们需要通过目标地址与fast bin数组的偏移计算出所需free的堆块的size，计算方式如下：

容易想到，可以通过此方式进行IO_FILE attack：覆写_IO_list_all，使其指向伪造的结构体，或者伪造._chain指向的结构体来实现任意读写，或者伪造vtable（libc-2.23）。
也可以利用此方式，修改__free_hook函数（__malloc_hook与__realloc_hook在main_arena的上方），从而getshell，此时需要有UAF漏洞修改__free_hook中的fake fast bin的fd为system_addr或one_gadget（这里不涉及该fd指针指向的堆块的取出，因此不需要伪造size），然后申请出这个fake fast bin，于是__free_hook这里的“伪链表头”将会指向被移出该单链表的fake fast bin的fd字段中的地址，即使得__free_hook中的内容被修改成了system_addr或one_gadget。
需要注意的是，若是用此方法改stdout来泄露相关信息，也可以不改_flags，如假设有漏洞可以修改一个堆块的size，那么可以构造_IO_read_end等于_IO_write_base来进行绕过，具体方式是：改了global_max_fast后，先释放一个需要泄露其中内容的fake fast bin到_IO_read_end（此时，正常走IO指针的输出均会失效，因为过不了_IO_read_end = _IO_write_base的判断，就不会执行_IO_SYSWRITE），然后修改该fake fast bin的size，再将其释放到_IO_write_base处即可。
利用此方法，也可以对libc进行泄露，毕竟在算index的时候，libc_base是被抵消掉的，或者说，是可以泄露在fastbinsY之后的数据。泄露的思想就是：当free时，会把此堆块置入fastbin链表的头部，所以在free后，此堆块的fd位置的内容，就是free前此SIZE的链表头部指针，通过越界就可以读取LIBC上某个位置的内容。

1.free_hook

劫持free_hook，一般都是申请到free_hook_addr的写入权，改写为one_gadget或system等，有时候one_gadget无法使用，就需要free(X)，其中这里X地址中的值为/bin/sh，故我们可以申请到free_hook_adddr - 8处的写入权，写入b'/bin/sh\x00' + p64(system_addr)，然后free(free_hook_adddr - 8)即可，而一般都由chunk[t] = malloc(...)申请到堆块的读写权，故直接free(chunk[t])即可。

2.malloc_hook配合realloc_hook调整栈帧打one_gadget

malloc_hook与realloc_hook地址相邻，realloc_hook在malloc_hook_addr - 8处，而__libc_realloc中有如下汇编代码：

故我们可以申请到malloc_hook_addr - 8的写入权，写入p64(one_gadget) + p64(realloc_addr+offest)，即在realloc_hook写入one_gadget，在malloc_hook写入realloc_addr + offest，此处通过控制offest来减少push个数，进而达到调整栈帧的目的，offest可取[0x0, 0x2, 0x4, 0x6, 0x8, 0xb, 0xc]，relloc_addr = libc_base + libc.sym['__libc_realloc']，然后通过malloc–>malloc_hook–>realloc–>realloc_hook–>one_gadget的流程getshell。
此外，fast bin attack的时候，需构造0x70的fast bin的fd指针指向malloc_hook-0x23处，此时fake size域为0x7f，会被当作0x70。

3.setcontext + 53

setcontext中的汇编代码如下：

可以看到从setcontext+53处的mov rsp, [rdi+0A0h]这行代码往后，修改了很多寄存器的值，其中，修改rsp的值将会改变栈指针，因此我们就获得了控制栈的能力，修改rcx的值后接着有个push操作将rcx压栈，然后汇编指令按照顺序会执行到最后的retn操作，而retn的地址就是压入栈的rcx值，因此修改rcx就获得了控制程序流程的能力。
利用pwntools带的SigreturnFrame()，可以方便的构造出setcontext执行时对应的调用区域，实现对寄存器的控制，从而实现函数调用或orw调用，具体如下：

我们将bytes(frame)布置到某个堆块K中，然后将free_hook改为setcontext+53，再通过free(K)即可触发（此时rdi就是K，指向堆块的user data），在我们构造的Frame中，frame.rip就是rcx的值，即执行完setcontext后执行的地址，而 frame.rsp就是最终retn后rsp的值（最后再跳转到此处rsp），因此可类似于SROP做到连续控制。

4.劫持exit hook

在exit中调用了__run_exit_handlers，而在__run_exit_handlers中又调用了_dl_fini，_dl_fini源码如下：

发现了其中调用的两个关键函数：

再看__rtld_lock_lock_recursive()的定义：

查看宏GL的定义：

由此可知，_rtld_global是一个结构体，_dl_rtld_lock_recursive和_dl_rtld_unlock_recursive实际上是该结构体中的函数指针，故我们将其中之一修改为one_gadget即可getshell。
需要注意的是，_rtld_global结构位于ld.so中 ( ld.sym['_rtld_global'] )，而libc_base与ld_base又有固定的差值，如在2.27中有libc_base+0x3f1000=ld_base，此时dl_rtld_lock_recursive于_rtld_global的偏移是0xf00，dl_rtld_unlock_recursive于_rtld_global的偏移是0xf08，最终修改dl_rtld_lock_recursive还是dl_rtld_unlock_recursive为one_gadget视情况而定，需要满足one_gadget的条件才行。
此外，由源码可知，若是有两次修改机会，可以将dl_rtld_lock_recursive或dl_rtld_unlock_recursive函数指针改成system的地址，然后在_rtld_global.dl_load_lock.mutex（相对于_rtld_global偏移0x908）的地址中写入/bin/sh\x00，即可getshell。
在libc中，还有一个更为方便的exit hook，就是__libc_atexit这个函数指针，从exit.c的源码中可以看到：

而在我们调用__run_exit_handlers这个函数时，参数run_list_atexit传进去的值就为真：

因此，可以直接改__libc_atexit的值为one_gadget，在执行exit函数（从main函数退出时也调用了exit()）时，就能直接getshell了。
这个__libc_atexit有一个极大的优点，就是它在libc而非ld中，随远程环境的改变，不会有变化。缺点就是，它是无参调用的hook，传不了/bin/sh的参数，one_gadget不一定都能打通。

5.scanf读入大量数据申请large bin，触发malloc_consolidate

当通过scanf，gets等走IO指针的读入函数读入大量数据时，若默认缓冲区（0x400）不够存放这些数据，则会申请一个large bin存放这些数据，例如读入0x666个字节的数据，则会申请0x810大小的large bin，并且在读入结束后，将申请的large bin进行free，其过程中由于申请了large bin，因此会触发malloc_consolidate。

在上面一个板块中，对部分新版本glibc的改进稍有提及，在此板块中将深入展开对新版本glibc下利用的讲解。

在2.28以后，tcache的bk位置写入了key，在2.34之前，这个key值为tcache struct的首地址加上0x10，在2.34以后，就是一个随机值了，当一个chunk被free的时候，会检测它的key是否为这个值，也就是检测其是否已经在tcache bin中，这就避免了tcache的double free。
然而，当有UAF漏洞的时候，可以用house of botcake来绕过key的检测，达到任意写的目的。需要注意的是，在2.30版本后，从tcache取出堆块的时候，会先判断对应的count是否为0，如果已经减为0，即使该tcache bin中仍有被伪造的地址，也无法被取出。
流程如下：

在2.27的版本，对在unlink的时候，增加了一个检测：

也就是说，会检查“即将脱链”的chunk的size域是否与他下一个chunk的prev_size域相等。
这个检测很好绕过，只需要将“即将脱链”的堆块在之前就真的free一次，让它进入list，也就会在其next chunk的prev_size域留下它的size了。
在2.29版本以后，在unlink时，增加了判断触发unlink的chunk的prev_size域和即将脱链的chunk的size域是否一致的检测：

有了这个检测就会比较麻烦了，不过仍然是有以下两种新方法绕过该检测：

1.思路一：利用 largebin 的残留指针 nextsize

首先，当一个堆块进入某个原本是空的largebin list，他的fd_nextsize和bk_nextsize内都是他自身的堆地址。
我们现在从这个largebin + 0x10的位置开始伪造一个fake chunk，也就是将原本的fd_nextsize和bk_nextsize当成fake chunk的fd和bk，而我们最终也是要将触发unlink的堆块和这个fake chunk合并，造成堆叠。
如此，我们很好控制fake chunk的size等于触发堆块的prev_size了，不过在此情况下又要绕过unlink的一个经典检测了，即检测每个即将脱链的堆块的fd的bk和bk的fd是否都指向其本身：

这个检测在之前都是不需要绕过的，因为对于之前的方法来说，双向链表显然都是合法完整的，但对于我们想重新伪造fd和bk，却成了一个大麻烦。

对于大部分off by null的题目，是不太好直接泄露libc_base和heap_base的，因此我们想重新伪造fd和bk并绕过双向链表完整性检查，对于原先残留的fd_nextsize地址，可以对其进行部分写入最后两位，更改为我们想要伪造成的堆地址（并进一步通过伪造成的堆地址满足双向链表检查）。不过，这里需要注意的是，我们需要让我们想要伪造成的堆地址与fd_nextsize中的残留地址只有后两位不同，且进行部分写入后，由于off by null，会将部分写入的地址后一字节覆盖成\x00，因此我们需要让我们想要伪造成的堆地址本身就是0x......X0XX这种形式，然后再爆破倒数第四位，让它为0即可，有1/16的爆破成功概率；而对于bk_nextsize来说，由于其之前的fd_nextsize不可再被更改了，就无法覆盖到bk_nextsize了，那么bk_nextsize就只能是原先的largebin地址了，而fake chunk的bk->fd在此时也就是fake chunk的prev_size位，只要在其中填上fake chunk的地址（largebin + 0x10）即可绕过检查。
下面来看一下具体的实现操作：
（1）首先进行一些堆块的申请，使得所需的largebin的地址为0x....000

（2）伪造出fake chunk并伪造fd，绕过fake chunk->fd->bk = fake chunk的检测
同样，我们将fake chunk的fd改成了某个临近堆块A，但仍然需要将chunk A的bk改成fake chunk的地址，所以仍需要部分写入的方式更改，这就要求我们需要使chunk A的bk本身就是一个堆地址，且与fake chunk的地址只有最后两位不同（临近）。
我们可以通过将chunk A和chunk B（fake chunk的临近堆块）放入small bin或unsorted bin等中，使得其链表为chunk B <-> chunk A，这样即可满足要求。
由于要是fake chunk的临近堆块，只能申请小堆块，所以这里使其放入small bin比较好实现，因为小堆块进入fastbin中后，只要触发malloc_consolidate()，若它们之间无法合并，即可让它们直接进入small bin。

（3）伪造bk，绕过fake chunk->bk->fd = fake chunk的检测
按照之前的分析，需要在fake chunk的prev_size位填入fake chunk的地址，仍然需要部分写入的方法，也就要求fake chunk的prev_size位原先就是一个fake chunk的临近堆地址。
我们只需要将原先largebin的头部被分割出来的一个小堆块和另外一个fake chunk的临近堆块均放入fastbin中，这样largebin头部小堆块的fd，也就是fake chunk的prev_size位就会被填入一个fake chunk的临近堆地址，再申请出来进行部分写入，使其为fake chunk的地址即可。
需要注意的是，不能将堆块放入tcache，这样虽然prev_size域仍然是这个临近堆地址，但是我们之前伪造好的fake chunk的size域就会被tcache的key所覆盖。

（4）伪造触发堆块的prev_size，利用off by null修改size的prev_inuse标志位为0，free触发堆块，进行unlink合并，造成堆叠。

2. 思路二：利用 unsorted bin 和 large bin 链机制

该方法与上面一个方法的主体思路类似（都是通过部分写入来篡改地址），实现方式有所不同，稍微简单一些。
堆块布局如下：

（1）我们可以通过unsorted bin链，直接让某堆块的fd和bk都分别指向一个堆地址（free堆块1/2和利用堆块），就不需要通过部分写入来伪造fd和bk了，不过这样就不好直接伪造利用堆块的size域了，可以通过辅助堆块和利用堆块合并后再分配，来使得原先利用堆块的size在重分配堆块1的mem区，就可以修改到原先利用堆块的size了，但这样的话，由于堆块的重分配，原先的利用堆块就不合法了，也就意味着需要绕过双向链表检测。以下就将利用堆块叫作fake chunk了。

（2）绕过fake chunk->fd->bk = fake chunk的检测
我们在之前的状态下，先删除fake chunk->fd堆块，再删除重分配堆块2（辅助堆块），我们就可以在fake chunk->fd堆块的bk位置写入一个重分配堆块 2（辅助堆块）的地址。
再将这个fake chunk->fd堆块申请回来，由于重分配堆块2（辅助堆块）就是fake chunk的临近堆块，所以利用部分写入的方式，就可以修改其bk为fake chunk的地址了（这里仍会涉及到off by null导致后一个字节被覆写为\x00，依然需要爆破，下面代码的示例题目是将输入的最后一字节改成\x00，因此不需要爆破），最后再申请回重分配堆块2（辅助堆块）。

（3）绕过fake chunk->bk->fd = fake chunk的检测
若是我们仍采用上述的思路，先删除重分配堆块2（辅助堆块），再删除fake chunk->bk堆块，的确会在fake chunk->bk的fd写入重分配堆块2（辅助堆块）的地址，但是在申请回fake chunk->bk堆块时，会先遍历到重分配堆块2（辅助堆块），然后将其放入largebin，与unsorted bin链断开了，这样等申请到fake chunk->bk的时候，其fd就不再是重分配堆块2（辅助堆块）的地址了。
不难想到，如果先删除重分配堆块2（辅助堆块），再删除fake chunk->bk堆块，然后就将它们全放入largebin，从largebin中申请出堆块，就不会涉及上面的问题了。
我们申请出fake chunk->bk，直接部分写入其fd，指向fake chunk即可。

（4）伪造触发堆块的prev_size，利用off by null修改size的prev_inuse标志位为0，free触发堆块，进行unlink合并，造成堆叠。

从glibc 2.28开始，_int_malloc中增加了对unsorted bin的bk的校验，使得unsorted bin attack变得不可行：

因此，对于高版本的glibc来说，通常用largebin attack或tcache stashing unlink attack来达到任意写大数值，而其中largebin attack更好，因为它写入的是堆地址，堆的内容常常是可控的。
然而，从glibc 2.30开始，常规large bin attack方法也被封堵，加入了判断bk_nextsize->fd_nextsize是否指向本身：

还加入了检查：

但这都是在我们原先利用的分支中加入的判断，也就是当加入该largebin list的chunk的size大于该largebin list中原先chunk的size时。
而在加入堆块的size小于largebin list中原有堆块的size时的分支中，仍然是可以利用的，不过相对于旧版可以任意写两个地址，到这里只能任意写一个地址了：

利用流程如下：

在largebin list中放入一个堆块A，并利用UAF等漏洞修改其内容为p64(0)*3 + p64(target_addr - 0x20)，也就是在bk_nextsize写入target_addr - 0x20

释放一个大小略小于堆块A的堆块B进入到同一个largebin list，此时就会在target_addr中写入堆块B的地址
原理解释：源码中的bck就是largebin list的头部，而bck->fd就指向了其中size最小的堆块，将源码中1带入2中得：fwd->fd->bk_nextsize->fd_nextsize = victim，又在之前有fwd = bck，fwd->fd就是largebin list头部的fd，而此largebin list在加入堆块B之前只有堆块A，因此fwd->fd->bk_nextsize->fd_nextsize = victim就是堆块A的bk_nextsize->fd_nextsize也就是target_addr处写入了victim也就是堆块B的地址。

若是仅在任意地址写入大数值，那上述过程就已经实现了，但很多时候需要修复largbin list，以免在之后申请堆块时出现错误，或者有时候需要再将largebin list中的堆块申请出来，对其内容进行控制。在上述过程结束后，堆块B的bk_nextsize有源码中的1处，也改成了target_addr - 0x20，我们将堆块B取出后，堆块B的bk_nextsize->fd_nextsize也就是target_addr就写入了堆块A的地址，此时再用同样的UAF等漏洞对堆块A的bk/fd和bk/fd_nextsize进行修复，即可成功取出堆块A，并可以对堆块A的内容进行控制，也就是对target_addr所指向的地址进行控制，就可以劫持IO FILE或是TLS结构，link_map等等。

关于Tcache Struct的劫持与溢出包含了很多方法，且基本不存在高低版本有区别的问题，但是在高版本libc的题目中运用更广泛，因此就放到这里来讲了。
首先简单介绍一下Tcache Struct：
在2.30版本以下：

在2.30版本及以上：

可以看到，Tcache Struct的有一个counts数组和entries链表，它本身就是一个堆，在所有堆块的最上面，而在不同版本，它的counts数组大小不同，2.30以下的类型只占一个字节，而2.30及以上的类型就占两个字节了，又TCACHE_MAX_BINS = 64，因此2.30以下Tcache Struct的大小为0x250，而2.30及以上为0x290。
Tcache Struct的counts数组中每个元素代表其对应大小的tcache bin目前在tcache中的个数，而entries数组中的地址指向其对应大小的tcache bin所在的单链表中头部的tcache bin。
在2.30以下，在从tcache struct取出内容的时候不会检查counts的大小，从而我们只需要修改我们想要申请的size对应的链表头部位置，即可申请到。而在2.30及以上版本的libc，则需要考虑对应counts的大小要大于0，才能取出。
对于劫持Tcache Struct，有两种方式，一种就是直接劫持Tcache Struct的堆块，对其中的数据进行伪造，另外一种就是劫持TLS结构中的tcache pointer，其指向Tcache Struct，将其改写，即可改为指向一个伪造的fake Tcache Struct。
对于Tcache Struct的溢出，先往mp_.tcache_bins写入一个大数值，这样就类似于改global_max_fast一样，我们之后free的堆块，都会被放入tcache中，而Tcache Struct中的某些counts和entries数组都会溢出到我们可控的堆区域中，但是利用此方法，需要对堆块的布局格外留心，防止出现一些不合法的情况从而报错。

在2.32版本，对tcache和fastbin都新增了指针保护：

比如在tcache_put()中加入tcache bin时，就有e->next = PROTECT_PTR (&e->next, tcache->entries[tc_idx])，对其next指针进行加密，而在tcache_get()中取出tcache bin时，就有tcache->entries[tc_idx] = REVEAL_PTR (e->next)将解密后的结果放入entries数组更新。在fastbin中也有类似的p->fd = PROTECT_PTR(&p->fd, old)操作。
PROTECT_PTR操作就是先对pos（fd/next域的堆块地址）右移了12位（去除了末三位信息），再将与原先的指针（在此版本之前fd/next储存的内容）异或得到的结果存入fd/next。由异或的自反性，解密只需PROTECT_PTR (&ptr, ptr)即可。
值得一提的是，当fastbin/tcache中只有一个chunk的时候，它的fd/next为零，而零异或pos>>12就是pos>>12，因此可以通过这样的堆块泄露pos>>12（密钥）的值，当然还可以通过泄露heap_base来得到pos>>12（密钥）的值，每在0x1000范围内，堆块的密钥都一样。

main_arena其实也可以通过劫持TLS结构直接劫持，但是通过劫持TLS结构来劫持main_arena的话，需要伪造一个近乎完整的main_arena，这并不是很容易，堆块大小也要足够大才行，而若是我们能劫持到原先已有的main_arena，对其中部分数据进行修改，这样就简单很多了，我们可利用fastbin attack进行劫持实现。
我们知道，在fastbin attack中常常需要伪造堆块的size，因为当堆块从fastbin中取出时，会检查其size是否匹配。在libc 2.27以上的main_arena中，有一项have_fastchunks，当其中fastbin中有堆块时，这一项将会置为1，而这一项又在main_arena中所有重要信息的上方，又have_fastchunks在main_arena + 8的位置，若是have_fastchunks = 1，则可以通过fastbin attack，将其中一个chunk的fd改为main_arena - 1的地址，即可伪造出一个size为0x100的堆块，但是0x100这个大小已经超过了默认的global_max_fast的大小0x80，因此需要先将global_max_fast改为一个大数值，才能够劫持到main_arena。

先看到_IO_str_overflow函数：

在源码中，old_blen = _IO_blen (fp) = (fp)->_IO_buf_end - (fp)->_IO_buf_base，malloc的大小为2 * old_blen + 100。
可以看到注释的1,2,3处连续调用了malloc，memcpy，free，在2.34以前，有__free_hook的存在，所以不难想到：先在某个bin list里伪造一个与__free_hook有关的堆块地址，然后用这里的malloc申请出来，再通过memcpy往__free_hook里面任意写system，最后在调用free之前先调用了__free_hook，此时rdi是old_buf = fp->_IO_buf_base，也是我们伪造IO_FILE时可控的，直接将其改为/bin/sh即可getshell。
比如说，先利用tcache stashing unlink attack或者劫持TLS中的tcache pointer等方式，在0xa0的tcache bin中伪造一个__free_hook - 0x10在链首，然后伪造IO_FILE如下：

最后通过exit触发，即可getshell，当然也可以配合house of KiWi等方式通过调用某个IO的fake vtable，来调用_IO_str_overflow，伪造的IO_FILE需要按情况微调。
在2.34以后，__free_hook，__malloc_hook，__realloc_hook这些函数指针都被删除了，house of pig的利用看似也就无法再使用了，但是我们注意到上面源码的注释4处，调用了memset，在libc中也是有got表的，并且可写，而这里的memset在IDA中可以看到是j_memset_ifunc()，这种都是通过got表调用的，因此我们可以把原先house of pig的改写__free_hook转为改写memset在libc中的got表。
先在0xa0的tcache链表头伪造一个memset_got_addr的地址，并伪造IO_FILE如下：

这里是通过house of KiWi调用的，并且开了沙盒。需要注意的是，在memset之前仍然有free(IO->buf_base)，因此需要伪造一下memset_got_addr的fake chunk的堆块头，以及其next chunk的堆块头。此外，在__vfxprintf中有_IO_flockfile(fp)，因此_lock也需要修复（任意可写地址即可）。至于各寄存器在_IO_str_overflow中最后的情况，最后调试一下就能得到，magic gadget也不难找。

主要是提供了一种在程序中触发IO的思路，恰好又能同时控制rdx，很方便地orw。

可以看到，在malloc.c中，assert断言失败，最终都会调用__malloc_assert，而其中有一个fflush (stderr)的函数调用，会走stderr的IO_FILE，最终会调用到其vtable中_IO_file_jumps中的__IO_file_sync，此时rdx为IO_helper_jumps。
开了沙盒需要orw的题目，经常使用setcontext控制rsp，进而跳转过去调用ROP链，而在2.29版本以上setcontext中的参数也由rdi变为rdx了，起始位置也从setcontext+53变为了setcontext+61（2.29版本有些特殊，仍然是setcontext+53起始，但是控制的寄存器已经变成了rdx），rdx显然没有rdi好控制，然而house of KiWi恰好能帮助我们控制rdx。
下面的问题就在于如何触发assert的断言出错，通常有以下几种方式：

1.在_int_malloc中判断到top chunk的大小太小，无法再进行分配时，会走到sysmalloc中的断言：

因此，我们可以将top chunk的size改小，并置prev_inuse为0，当top chunk不足分配时，就会触发这个assert了。

2.在_int_malloc中，当堆块从unsorted bin转入largebin list的时候，也会有一些断言：assert (chunk_main_arena (bck->bk))，assert (chunk_main_arena (fwd))等。

再看相关的宏定义：
#define NON_MAIN_ARENA 0x4
#define chunk_main_arena(p) (((p)->mchunk_size & NON_MAIN_ARENA) == 0)
对mchunk_size的解释：mchunk_size成员显示的大小并不等价于该chunk在内存中的大小，而是当前chunk的大小加上NON_MAIN_ARENA、IS_MAPPED、PREV_INUSE位的值。
因此，assert (chunk_main_arena(...))就是检测堆块是否来自于main_arena，也可以通过伪造即将放入largebin list的largebin's size来触发assert。
对于house of KiWi利用，需要存在一个任意写，通过修改_IO_file_jumps + 0x60的_IO_file_sync指针为setcontext+61，并修改IO_helper_jumps + 0xA0 and 0xA8分别为ROP链的位置和ret指令的gadget地址即可。

值得一提的是，在house of KiWi调用链中，在调用到__IO_file_sync之前，在__vfprintf_internal中也会调用IO_FILE虚表中的函数，会调用[vtable] + 0x38的函数，即_IO_new_file_xsputn，因此我们可以通过改IO_FILE中vtable的值，根据偏移来调用其他虚表中的任意函数。

对于第一种，svcudp_reply+26处有个gadget可以实现：

对于第二种，先来看通过gadget进行rdi与rdx间的转换（最常用）：

再看通过改__malloc_hook并劫持_IO_FILE的方法：
为什么说一般劫持的都是stdin的IO_FILE呢？因为__malloc_hook与stdin距离是比较近的，可以在劫持IO_FILE的同时，就把__malloc_hook改掉。
可按如下方式构造payload：

至于第三种，house of KiWi的方式，在上面已经单独介绍过了，就不再多说了。
关于第四点提到的其他IO劫持，在之后都会提及，比如house of banana，house of emma等等。

在用printf进行输出时，会根据其格式化字符串，调用不同的输出函数来以不同格式输出结果。但是如果调用呢？自然是需要格式化字符与其输出函数一一对应的索引表的。glibc中的__register_printf_function函数是__register_printf_specifier函数的封装：

__register_printf_specifier函数就是为格式化字符spec的格式化输出注册函数：

可以看到，如果格式化字符spec超过0xff或小于0，即ascii码不存在，则返回-1，如果__printf_arginfo_table为空就通过calloc分配两张索引表，并将地址存到__printf_arginfo_table以及__printf_function_table中。两个表空间均为0x100，可以为0-0xff的每个字符注册一个函数指针，且第一个表后面紧接着第二个表。由此，我们有很明显的思路，可以劫持__printf_arginfo_table和__printf_function_table为我们伪造的堆块（多用largebin attack），进而伪造里面格式化字符所对应的函数指针（要么为0，要么有效）。
在vfprintf函数中，如果检测到__printf_function_table不为空，则对于格式化字符不走默认的输出函数，而是调用printf_positional函数，进而可以调用到表中的函数指针：

__printf_function_table中类型为printf_function的函数指针，在printf->vfprintf->printf_positional被调用：

另一个在__printf_arginfo_table中的类型为printf_arginfo_size_function的函数指针，在printf->vfprintf->printf_positional->__parse_one_specmb中被调用，其功能是根据格式化字符做解析，返回值为格式化字符消耗的参数个数：

可以看到，是先调用了__printf_arginfo_table中的函数指针，再调用了__printf_function_table中的函数指针。
假设现在__printf_function_table和__printf_arginfo_table分别被填上了chunk 4与chunk 8的堆块地址（chunk header）。
方式一：

由于有堆块头，所以格式化字符的索引要减2，这样写就满足了__printf_function_table不为空，进入了printf_positional函数，并调用了__printf_arginfo_table中的函数指针。
方式二：

这样写同样也是可以的，首先仍然满足__printf_function_table不为空，进入了printf_positional函数，会先进入__parse_one_specmb，此时__printf_arginfo_table[spec->info.spec] == NULL成立，那么根据逻辑短路，就不会再执行下面的语句了，最后又回到printf_positional函数，调用了__printf_function_table中的函数指针。

其实就是劫持了link_map，需要exit函数触发，调用链：exit()->_dl_fini->(fini_t)array[i]，可以很方便地getshell或者在高版本下orw。
先看Elf64_Dyn结构体定义（注意里面有一个共用体）：

再看_dl_fini.c中的这一段：

这里面涉及的结构体比较多，成员参数也比较复杂。可以看到源码中l指针的类型为link_map结构体。link_map结构体的定义很长，节选如下：

可以看到，link_map和堆块链表一样，是通过l_next与l_prev指针连接起来的，那么肯定就有一个类似于main_arena或者说是tcache struct的地方，存放着这个链表头部指针的信息，这个地方就是_rtld_global结构体：

这里的_ns_loaded就是link_map链表头部指针的地址，_ns_nloaded = 4说明这个link_map链表有四个link_map结构体，它们通过l_next与l_prev指针连接在一起。
我们再用gdb打出link_map的头部结构体的内容：

很自然，在house of banana的利用中，我们需要劫持_rtld_global的首地址，也就是_ns_loaded，将它通过largebin attack等方式改写为我们可控的堆地址，然后再对link_map进行伪造（当然，对于有些题目，有办法直接劫持到原先的link_map并修改，那更好）。
伪造link_map的时候，首先就需要注意几个地方：将l_next需要还原，这样之后的link_map就不需要我们再重新伪造了；将l_real设置为自己伪造的link_map堆块地址，这样才能绕过检查。
之后，我们再回到_dl_fini.c中的源码，看看如何利用house of banana进行攻击。
首先，再最外层判断中，需要使l->l_init_called为真，因此需要对l_init_called进行一个伪造。
然后，需要使l->l_info[DT_FINI_ARRAY] != NULL，才能调用函数指针，这里有#define DT_FINI_ARRAY 26，也就是使得l->l_info[26]不为空。
再之后就是array = (l->l_addr + l->l_info[DT_FINI_ARRAY]->d_un.d_ptr);，这里需要伪造link_map中的l_addr（这里在已经伪造的link_map的堆块头，需要通过其上一个堆块溢出或是合并后重分配进行修改），以及l->l_info[26]->d_un.d_ptr，也就是l->l_info[27]，使其相加的结果为函数指针的基地址。
调用函数指针的次数i由i = (l->l_info[DT_FINI_ARRAYSZ]->d_un.d_val / sizeof (ElfW(Addr)))控制，其中#define DT_FINI_ARRAYSZ 28，sizeof (ElfW(Addr)) = 8，因此i = l->l_info[29] / 8。
这里每次调用的函数指针都为上一个的地址减8，直到最后调用函数指针的基地址array，而每一次调用函数指针，其rdx均为上一次调用的函数指针的地址，由此我们可以轻松地通过setcontext + 61布置SROP，跳转执行ROP链。
构造代码如下：

这个利用也是通过exit触发的，和house of banana实现的效果差不多，利用流程比house of banana简单，但是主要是用于getshell，在开了沙盒后，orw并没有house of banana方便。
首先来看dtor_list结构体的定义：

可以看到，tls_dtor_list就是dtor_list的结构体指针，里面存放着一个dtor_list结构体的地址。
再看到__call_tls_dtors函数（对tls_dtor_list进行遍历）：

由此可知，dtor_list结构体中的func成员，其实是一个函数指针，而其中的obj成员就是其调用时的参数。
很显然，若我们可以劫持tls_dtor_list，在其中写入我们伪造的堆地址，使其不为空（绕过while (tls_dtor_list)），就能执行到func (cur->obj)，而我们又可以控制伪造的堆块中prev_size域为system的相关数据（由于有指针保护，之后会讲），size域为/bin/sh的地址（通过上一个堆块的溢出或合并后重分配），这样就能getshell了，若是想orw，那么可以让func成员为magic_gadget的相关数据，将rdi与rdx转换后，再调用setcontext + 61走SROP即可。
需要注意的是，在调用func函数指针之前，对func执行了PTR_DEMANGLE (func)，这是一个指针保护，我们可以通过gdb直接看到其汇编：

这操作主要是先进行循环右移0x11位，再与fs:0x30（tcbhead_t->pointer_guard）进行异或，最终得到的数据就是我们的函数指针，并调用。
因此，我们在之前所说的将func成员改成的与system相关的数据，就是对指针保护进行一个逆操作：先将system_addr与pointer_guard进行异或，再将结果循环左移0x11位后，填入prev_size域。
然而，pointer_guard的值在TLS结构中（在canary保护stack_guard的下一个），我们很难直接得到它的值，但是我们可以通过一些攻击手段，往其中写入我们可控数据，这样就可以控制pointer_guard，进而绕过指针保护了。

主要是针对于glibc 2.34中删除了__free_hook与__malloc_hook等之前经常利用的函数指针而提出的一条新的调用链。
house of emma利用了_IO_cookie_jumps这个vtable：

可以考虑其中的这几个函数：

其中涉及到的结构体定义：

在这几个函数里，都有函数指针的调用，且这几个函数指针都在劫持的IO_FILE偏移的不远处，用同一个堆块控制起来就很方便，不过在任意调用之前也都需要绕过指针保护PTR_DEMANGLE。此外，在调用函数指针的时候，其rdi都是cfile->__cookie，控制起来也是非常方便的。
利用house of KiWi配合house of emma的调用链为__malloc_assert -> __fxprintf -> __vfxprintf -> locked_vfxprintf -> __vfprintf_internal -> _IO_new_file_xsputn ( => _IO_cookie_write)，这里用的是_IO_cookie_write函数，用其他的当然也同理。
伪造的IO_FILE如下：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！