从源码调试_int_free一次看懂how2heap之unlink
首先说一下个人感受，unlink是个在没有理解的情况下可能完全摸不着头脑的技术点。并且本来就没有搞清楚的东西还没有源码的话，就更头疼了。
unlink是个malloc.c文件里的宏，由于是个宏，所以经过编译以后已经inline了，虽然可以找到原始的宏定义，但是看起来毕竟没有那么直观，所以本文从源码调试入手，一次看清unlink的细节。
几个关键的技术点如下：
unlink是在哪个函数里被执行的？
unlink的几个参数分别是什么意思？
unlink的结果是什么？
为什么进行unlink攻击要伪造一个chunk？用原始的chunk只改变fd和bk就不可以吗？
如何进行源码调试
首先使用how2heap提供的脚本build出实验需要的2.25版本的ld和libc，如下：
$ ./glibc_build.sh -h
Usage: ./glibc_build.sh version #make-threads
$ ./glibc_build.sh 2.25 8
这里编译使用8线程，可以根据CPU情况调高线程数加快编译，整个过程花费时间可能较长。
如果卡在git clone那一步，建议指定http_proxy并将glibc_build.sh中git clone后的协议改为http。
编译出的ld和libc会放在glibc_versions目录下，clone下来的源码在glibc_src目录。
由于这里要进行的是2.25版本的调试，所以如果你依次build了2.25和2.26版本的，请到glibc_src目录下进行git checkout release/2.25/master将源文件恢复到2.25版本的状态以便后续调试。
接下来修改待调试文件的ld,有两种方法，可以自由选择：
# 首先要sudo apt install patchelf，以下两种方法实际上都是用了这个工具。
# 1. 使用现成的glibc_run.sh，脚本中含有patch待调试程序的功能。
$ ./glibc_run.sh 2.25 [exe]
# 2. 直接使用patchelf
$ patchelf –set-interpreter [path_to_ld] [exe]
文件patch好以后，只要在执行或者调试时设置LD_PRELOAD指向相应的libc就可以了。
如何在GDB中设置LD_PRELOAD可以看我前几天写的GDB指定被调试程序环境变量。
简单提一句就是在GDB中set exec-wrapper env ‘LD_PRELOAD=./glibc_versions/libc-2.25.so’
接下来就可以愉快的进行调试了。调试使用了pwndbg。
unlink是在哪个函数里被执行的？
源代码想必点开这篇文章的小伙伴们手里都有，为了突出重点，这里就不贴了。（如果没有快去这里看一下
单步跟踪可以发现chunk0_ptr的值第一次被改变是在第46行的free(chunk1_ptr)执行完之后。那么我们先b unsafe_unlink.c:46在执行这一行之前停下，然后si步进。
在main函数中call free@plt之前应该看起来是这个样子:
进入free函数时看起来应该是这个样子：
如果你看到和我一样的界面的话，说明上面的配置没有问题；如果看不到malloc.c的源码的话，建议检查上面哪一步出了问题。（当RIP在free@plt的时候不会看到malloc.c源码，详细信息请搜索“延时绑定、plt”相关内容）
ni了几步之后进入了_int_free函数，这也就是我们分析的重点。
打开malloc.c源文件（在glibc_src/malloc/malloc.c），可以看到_int_free函数中有2处调用了unlink，分别用于后向合并以及前向合并。
这里要解释一下unlink的各个参数，顺便讲清楚这两个合并分别是什么效果。
unlink的几个参数分别是什么意思？
#define unlink(AV, P, BK, FD) {
FD = P->fd;
BK = P->bk;
if (__builtin_expect (FD->bk != P || BK->fd != P, 0))
malloc_printerr (check_action, "corrupted double-linked list", P, AV);
else {