jarvisoj_level中都是一些基础题目，较为简单
仔细做了做，解决了一些以前遗留的问题与误区，做这个 level5 的时候，发现有个师傅的思路很有意思（这种思路应该可以来对付ORW，也可以成为绕NX的手段）
level5
64位，dynamically，开了NX
经典泄露数据：可以用DynELF或LibcSearcher
1 | from pwn import* |
// 一般“system”打不通
程序要求不使用“system”和“execve”（只能使用shellcode）
这时就需要考虑绕过NX：栈迁移 + mprotect
但这里不用栈迁移，用另一种方式：ret2csu + got表劫持
完整exp：
1 | from pwn import* |
报错总结
需要输入地址的地方必须用“send”，因为“sendline”最后加上的“\n”会扰乱地址
House Of Spirit 是 Fastbin Attack 中的一种，也是 the Malloc Maleficarum 中的一种技术
通过free技术来达到任意地址读写的目的（WAA）：技术中利用free函数来释放一个原本属于栈中的一块地址（伪造为 fake chunk ），将地址free到堆的bin链中，然后实现对栈地址的读写
// 当然也可以不在栈中，任意可写的段都可以
2 * SIZE_SZ，同时也不能大于av->system_mem主要是检查当前chunk的size，和下一个chunk的size
1 |
|
1 | fake_chunks: 0x7fffffffdcc0 |
可以发现：函数“free”把栈上的“fake_chunks”送入了“tcachebins”
1 | pwndbg> bins |
// 这里的“fake_chunks”被送入了“tcachebins”，如果是低libc版本就送入“fastbins”
house of spirit 简单的来说就是 free 一个假的 fastbin 堆块，然后再下次 malloc 的时候就会返回该假堆块
利用条件：
不同 libc 的版本“释放检查”不同，像 libc-2.23 就只有上文的两个检查，后续会尽量把不同版本的 House Of Spirit 都复现一遍，直到完全没法打为止
libc-2.23
上文提到的，基本的 free 检查
1 | //检查p的大小是否小于global_max_fast |
libc-2.27
多了一个检查
1 | if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0) |
检查下一个 chunk 的 pre_size 是否为 NULL，一般在伪造 size 的时候多写一步就可以了
后续版本都没有添加新的检查（最新测试到 libc-2.31）
注意
在64位的程序中：可以轻易实现 House Of Spirit（至少在 libc-2.31及其之前的版本是这样）
但是在32位的程序中：只有在 libc-2.23 版本成功实现 House Of Spirit，其他版本均报错
1 | free():invalid pointer |
看了源码，定位了报错的位置，但是还是不知道原因……
Double Free是 Fastbin Attack 中的一种
本质上就是对一个chunk进行两次free，从而实现 多个指针指向同一个堆块 的操作
通常来说，同一个chunk是不能被free两次的
例如：
1 | int main(void) |
1 | free(): double free detected in tcache 2 |
这是因为有以下代码：
1 | /* Another simple check: make sure the top of the bin is not the |
检查 fastbin 头部指向的 chunk 和被 “free” 的 chunk 是否相等，其后就没有检查了
如果这样构造payload，就会形成异常的fastbin：
1 | typedef struct _chunk |
当所有的free执行完成后：
1 | pwndbg> bins |
fastbin出现异常，接下来继续单步，看看程序会怎么分配chunk：
1 | chunk_a = 0x55555555b010 |
“chunk_a”和“chunk_c”被分配到了同一个地方，这就是Double Free的核心
Double Free 和 UAF 很像，都是程序没有置空指针而产生的漏洞
利用的关键都是看程序的“free模块”，看下哪些指针没有被置空
利用条件：
利用效果：
利用姿势：
一，申请两个chunk，并依次释放chunk1，chunk2：（chunk2 -> chunk1）
二，再次释放chunk1：（chunk1 -> chunk2 -> chunk1）
三，申请chunk：（New chunk1）
四，修改New chunk1，把FD指针的位置改为“ Malloc_hook - 0x10 ”：
五，申请chunk：（New chunk2）
六，申请chunk：（New chunk3 和 New chunk1重合）
七，再次申请chunk，并进行修改（程序把“Malloc_hook”误以为是chunk）
原理总述：
利用Double Free的特性（可以申请到相同的chunk），先在某个chunk的FD指针中写入 “目标地址 - 0x10” ，程序会误以为它是某个chunk，于是会把这片区域当成chunk给申请出来，最后就可以直接修改了
// 虽然New chunk1是“allocate chunk”，但是通过Double Free把它存储在了fastbin中，所以它也会被当做是“free chunk”
PS：
因为在 fastbin 中，malloc 会检查 fast chunk 的 size 位是否合适才分配 chunk
这导致了 Double free 的利用需要一些特殊手段（利用现成地址分割“size”）
而在 cachebin 中没有对应的检查（至少2.27没有），所以 Double free 满天飞
hfctf_2020_marksman
两次输入
64位，dynamically，全开
有两次输入，第一次输入“16字节”，第二次输入“3字节”（第二次可以分段多次输入）
程序还泄露了“puts”的libc地址，就相当于知晓了“libc_base”
如果符合if条件，第二次输入的值会进行覆盖
入侵思路
程序的思路十分简单：
也有明显的问题：
泄露了“puts”的libc地址，可以用LibcSearcher获取libc版本
1 | 0: ubuntu-glibc (id libc6_2.27-3ubuntu1_amd64) |
用“glibc-all-in-one”下载对应版本的libc，获取“one_gadget”
// 加 “—level 2” 参数输出所有“one_gadget”
1 | ➜ [/home/ywhkkx/tool/glibc-all-in-one/libs/2.27-3ubuntu1_amd64] git:(master) one_gadget libc-2.27.so --level 2 |
发现 0xe569f execve(“/bin/sh”, r14, r12) 刚好符合条件，解决了“one_gadget”的问题
程序原本的got表不可以写，但一个突破口：dlopen
1 | void * dlopen (const char *file, int mode) |
功能：打开一个动态链接库
参数：file就是libc文件路径，mode只有以下两种常用的值，并且必须指定其一
先看一下“dlopen”的源码：
1 | void * dlopen (const char *file, int mode) |
1 | void * __dlopen (const char *file, int mode DL_CALLER_DECL) |
这就是“dlopen”的调用流程 ，重点注意一下“_dl_open”
1 | void * _dl_open (const char *file, int mode, const void *caller_dlopen, Lmid_t nsid, int argc, char *argv[], char *env[]) |
// 其中的“_dl_catch_error”就是劫持的对象
“dlopen”里面有调用libc函数的地方，于是劫持它的got表，便可以getshell
可以把“_dl_catch_error”的内容，覆写为“one gadget”，这样调用“dlopen”的时候就会调用“one gadget”，解决了got表不可写的问题
参考：
动态调试
“_dl_catch_error”的具体地址可以在GDB中查看：
1 | pwndbg> telescope 0x555555400D63 |
1 | pwndbg> telescope 0x555555400860 |
完整exp：
1 | from pwn import* |
这个方法的条件苛刻（主要是“one_gadget”），而且找偏移不好找
网上有另一种劫持技术：exit_hook
攻击技术：exit_hook
exit的调用过程：
1 | exit() -> __run_exit_handlers -> _dl_fini -> __rtld_lock_unlock_recursive |
其中的 “__rtld_lock_unlock_recursive” 是可以被劫持的，它的偏移也可以在GDB中计算
// 注意：利用“exit_hook”进行攻击，“one_gadget”有所改变
1 | from pwn import* |
大体的步骤都是差不多的，就是劫持的地址不一样
PS
1 | str(__rtld_lock_unlock_recursive) |
exp选择用 “str&chr” 而不是 “p64”
经过实验发现，只有使用 “str&chr” 才不会报错，“str，p64，chr”三者的其他任意组合都不能打通，并且会进行报错：
1 | timeout: the monitored command dumped core |
目前不知道原因，只有先记住：被修改的对象用“str”，修改的内容用“chr”
我们在利用 unlink 所造成的漏洞时，其实就是对 chunk 进行内存布局，然后借助 unlink 操作来达成修改指针（某个chunk的fd指针）的效果
这个指针可以修改为任何地址（fake pointer），那些下一次对该chunk进行操作时，就会向“fake pointer”中写入数据，以实现WAA
unlink是一个宏操作，用于将某一个空闲chunk从其所处的双向链表中脱链
阉割版代码：
1 | void unlink(malloc_chunk *P, malloc_chunk *BK, malloc_chunk *FD) |
流程图：
在程序进行unlink操作时，还有一个检查：
1 | // 由于'P'已经在双向链表中，所以有两个地方记录其大小，所以检查一下其大小是否一致(size检查) |
简单来说就是：
chunkP的下一个chunk的上一个chunk是不是chunkP
chunkP的上一个chunk的下一个chunk是不是chunkP
unlink 操作虽然有检查，但并不是那么“智能”，程序只会 根据地址的相对位置 来推测此位置大概是什么数据，比如，程序会认为 chunk_head+0x8 的位置为 presize， 而不会去检查 chunk 本身的“完整性” ，我们就可以利用这一点来欺骗检查程序
buf[0] 中装有 chunk 的首地址，修改 fake chunk->FD 为 buf[0] - 0x18（buf[-3]），修改 fake chunk->BK 为 buf[0] - 0x10（buf[-2]）
假设程序要对 fake chunk 进行 unlink 操作，而 FD，BK 中指向的地址显然不合法，看看程序是怎么检查的：
这只是一种伪造方法，核心点：程序只会根据地址的相对位置获取数据
一，针对 chunk_list ，劫持修改模块（两个chunk合并后unlink）
这种攻击的套路比较固定：
此后Unlink攻击完成，在 unsortedbin 中存储的地址变为“chunk_list - 0x18”，并且在 chunk_list 中残留的chunk1数据区地址也变为“chunk_list - 0x18”
接下来可以用修改模块进行 hook，GOT劫持，也可以把chunk申请到“chunk_list - 0x18”上
二，针对 heap ，实现 overlapping（三个chunk合并后unlink）
这种攻击可以直接在 heap 中打：
注意：“fake->size”的大小为“chunk1->size + chunk2->size - 0x10 ”
glibc-2.23：
绕过：用上述操作就可以绕过
glibc-2.27：
1 | if (__builtin_expect (chunksize(P) != prev_size (next_chunk(P)), 0)) |
标准的是申请三个堆 chunk0 chunk1 chunk2（控制 chunk1 为“buf[-3]”）
释放 chunk0，chunk1 的 prev_size 位置会留下 chunk0 的大小
释放 chunk2 glibc 会通过 prev_size 向上索引到 chunk0
chunk0 会被检测，这里 “chunk0的size” 会和 “chunk1的prev_size” 比较
注意：chunk2 需要申请一个 chunk3，防止 chunk2 释放后与“top chunk”合并
绕过：需要多伪造一个“fake_chunk0”，并通过“fake_chunk1”索引到“fake_chunk0”
glibc-2.29：
1 | if (!prev_inuse(p)){ |
// 这里还没有搞清楚，以后遇到题目了再补充
stkof
循环输入
64位，dynamically，开了Canary，开了NX
代码分析
程序有4种选择：
一，申请可以输出大小的chunk，把它的“fd”指针装入“list”
二，输入“index”，输入“size”，输入写入的内容
// 这种写入方式还是比较稀奇的
三，输入“index”，然后free掉对应的chunk，并把指针置空
四，输入“index”，打印一个字符串
入侵思路
先搭好框架：
1 | def alloc(size): |
本程序没有栈溢出，但是有堆溢出（“ fill的size ”可以大于“ alloc的size ”）
那么思路就明确了：
利用“Unlink攻击”实现WAA，把got表中的某个函数改为“ system(“/bin/sh”) ”
注意：
本程序没有设置“无缓存”，所以在初次调用“fgets”和“puts”时，malloc都会分配缓冲区
没有执行任何操作时：
1 | pwndbg> heap |
这里的“0xe05290”和“0xe056a0”就是“输入”和“输出”申请的缓存区，为了排除缓存区干扰，应该先生成一个“无关chunk”
1 | alloc(0x100) |
1 | pwndbg> x/100xg 0x00000000019cd7c0 |
“ free(3) ”执行以后：
1 | pwndbg> x/10xg 0x602140 |
现在Unlink攻击已经完成，chunk2的“fd”被伪造成了“ list-0x8”（chunk2[-3]）
1 | payload='a'*0x8 #填充list[-1] |
1 | pwndbg> telescope 0x602140 |
现在WAA已经完成了，用“fill”填入数据就可以了，首先修改“free”为“puts”，泄露“puts_got”获取“libc_base”：
1 | payload = p64(elf.plt['puts']) |
最后获取“system”，把“atoi”改为“system”，输入“/bin/sh”作为“system”(atoi)的参数
完整exp：
1 | from pwn import* |
PS：
本程序libc版本为“2.23”，使用“2.31”版本打不通，用GDB调试后发现chunk根本没有合并，可能是高版本的libc增加了更多的检查，掐掉了unlink攻击，至于是什么检查以后学习
fheap
循环输入
64位，dynamically，全开
逻辑简单的程序
函数“create”：
程序出现了栈指针异常的错误：（可能掺入了花指）
解决方法如下：
在“0x12AA”处：用“P”创建函数，用“F5”进行反汇编
就是一段执行读操作的代码
先申请“0x20”字节大小的chunk：ptr
然后read读入输出长度：nbytes
输入“input”，获取“input”的实际长度，如果长度大于 “0xf” 就重新“malloc”一个chunk来存储“input”，否则就直接装入“ptr” （最多可以create16次）
函数“delete”：
没有用“free”，这个“unk_4040”无法识别
动态调试
IDA静态分析不能很好地体现程序的流程，先用GDB分析一下
输入值小于“0xf”：
1 | pwndbg> heap |
输入值大于“0xf”：
1 | pwndbg> heap |
小于“0xf”时：直接把“input”写到自己的数据区
0x000055555555549c：“free_one”
1 | void __fastcall free_one(void *a1) |
大于“0xf”时：先malloc一个chunk，然后把malloc出来的地址，写到自己的数据区
0x00005555555554bb：“free_double”
1 | int __fastcall free_double(int **a1) |
入侵思路
没有栈溢出，有UAF漏洞（“free_one”和“free_double”都不置空指针）
先搭好框架：
1 | def add(size,content): |
问题的关键就是“free_one”这个函数：
1 | 0x5555555592c0: 0x0000000000000000 0x0000000000000031 |
“free_one”位于“chunk2 + 5”这个位置，它不属于“chunk2”，所以在“chunk2”被“free”的时候，它是不受影响的，因此“free_one”遗留在了“chunk2”中
如果利用UAF就可以把“chunk2”作为“chunk1”的“chunk1_data”：
1 | add(8,'a'*8) |
1 | pwndbg> x/20xg 0x55ee908bc290 |
因为“chunk2”的指针并没有被置空，所以可以使用“delete(1)”操作“chunk2”，而遗留在“chunk2”中的“free_one”会被覆盖低字节为“puts”，泄露了内存数据
// 这里只能覆盖最后两位（溢出1字节），因为开了PIE只有最后3位固定
“free_one”原本的参数就是“chunk1_data”，现在改成了“pust”
1 | p.recvuntil('a'*24) |
可以顺势获“pro_base”，获取“printf_plt”，再利用“printf”格式化字符串来泄露“libc_base”
1 | delete(0) |
1 | pwndbg> telescope 0x55fa4c41a2c0 |
发现泄露出来的地址和“libc_base”的差值固定，从而获取“libc_base”：
1 | In [9]: 0x7f02d59a86a0-0x7f02d57bc000 |
完整exp：
1 | from pwn import* |
堆利用中较为常见的漏洞，利用了“free”函数本身的缺陷，对已经置空的指针进行操作
UAF一般有以下几种情况：
UAF漏洞主要是后两种，被置空的指针被称为“dangling pointer”
简单来说bin就是free chunk的容器
ptmalloc 把大小相似的 chunk，用双向链表连接起来，这样就形成了一个 bin，ptmalloc 一共维护了 128 个这样的 bin，并使用数组来存储这些 bin 如下：（32位）
从第2个到第64个bin是small bin，small bin中的chunk大小相同，small bin是一个双向链表
在某一条bin中(chunk大小相同)按照「先入先出」（FIFO 的规则）进行排序，也就是说，刚被释放的放在前面
bins分类：fast bin，small bin，unsorted bin，large bin
bin链都是由当前线程的arena管理的
Fast bin
Fast bin可以看着是 small bins 的一小部分 cache ，设计初衷就是进行快速的小内存分配和释放
概念：chunk 的大小在32字节~128字节（0x20~0x80）的 chunk 称为“fast chunk”（大小不是 malloc 时的大小，而是在内存中 struct malloc_chunk 的大小，包含前2个成员）
特征：
使用次序：后入先出（可以类比一下栈）
通常情况下：
1 |
|
1 | ➜ [/home/ywhkkx/桌面] ./test |
Small bin
small bins 中一共有 62 个循环双向链表，每个链表中存储的 chunk 大小都一致
使用次序：先入先出（可以类比一下食堂排队）
1 |
|
1 | ➜ [/home/ywhkkx/桌面] ./test |
Large bin
large bins 中一共包括 63 个 bin，每个 bin 中的 chunk 的大小不一致，而是处于一定区间范围内
1 | #define largebin_index_32(sz) \ |
Unsorted bin
没有来得及被其他bin收入的chunk，就会被认为在unsorted bin中
在使用malloc申请内存时，如果在“fastbin”和“smallbin”中都没有找到合适的free chunk，程序就会在unsorted bin中进行遍历，寻找合适的free chunk，不合适的chunk会被 排序 并 重新分配 到对应的“bins”中
用户释放掉的 chunk 不会马上归还给系统，ptmalloc 会统一管理 heap 和 mmap 映射区域中的空闲的 chunk，当用户再一次请求分配内存时，ptmalloc 分配器会试图在空闲的 chunk 中挑选一块合适的给用户，这样可以避免频繁的系统调用，降低内存分配的开销
详细过程：
malloc的时候，不论malloc的大小，ptmalloc首先会去检查每个bins链（除去fastbins链）是否有与malloc相等大小的freechunk，如果没有就去检查bins链中是否有 大的freechunk 可以切割
如果存在，那么就切割大的freechunk，那么切割之后 剩余 的chunk成为 last remainder chunk ，并且last remainder chunk会被放入到 unsorted bin 中
如果没有 大的free chunk 可以切割，程序就会查询 top chunk ，如果top chunk的大小比用户请求的大小要大的话，就将该top chunk分作两部分：1.用户请求的chunk，2.新的top chunk，否则，就需要扩展heap或分配新的heap了——在 main arena 中通过 sbrk 扩展heap，而在 thread arena 中通过 mmap 分配新的heap
流程图：
UAF的利用比较简单，重点看下程序的“free模块”，看下哪些指针没有被置空
1 | int main() |
1 | a addr:6792d2a0,ywhkkx |
可以发现，“a”和“b”指向了同一片内存：对“a”进行控制，就相当于控制了“b”
利用条件：
利用效果：
利用姿势：
一，申请一个chunk，然后释放：
二，修改该chunk的FD指针为“ Malloc_hook - 0x10 ”：
三，再次申请chunk，并进行修改
原理总述：
利用UAF的特性（可以申请到相同的chunk），先在某个chunk的FD指针中写入 “目标地址 - 0x10” ，程序会误以为它是某个chunk，于是会把这片区域当成chunk给申请出来，最后就可以直接修改了
// 如果程序没有提供“修改模块”，则使用Double Free
PS：
基于UAF，可以实现一种被称为Alloc to Stack的技术，和上述操作一致，只不过把“目标地址”换做了栈地址
Wiki上把它归为Fastbin Attack，但它的利用核心还是UAF
这是我在学习堆利用时的例题，因为libc版本的原因，例题的exp完全不适用于我的系统，并且我看不太懂Wiki上的解析，导致我受挫了很多次
通过不断的试错，我最终搞明白了其中的原理，泄露出了“libc_base”，但是被“libc-2.29.so以及后续版本”中的保护机制给卡了一下，get不了shell
在不断的调试中，我的GDB用得越来越熟练了，算是受益匪浅吧
Asis_2016_b00ks
循环输入
64位，dynamically，开了NX，开了PIE，开了Full RELRO
代码分析
先输入“name”，最多“read”32字节到“off_202018”中，接着就是进入选项了
1.Create a book：
输入“书名长度”，“书名”，“描述长度”，“描述”，最后malloc一个list来存储信息
2.Delete a book：
把“书名长度”，“书名”，“描述长度”，“描述”都free了，但只置空了list的指针
3.Edit a book：
可以修改“描述”
4.Print book detail：
打印信息
5.Change current author name：
修改“name”
入侵思路
程序可以修改“description”，那么就要围绕“description”来打，首先搭好框架：
1 | def create(len_book,bookname,len_description,description): |
程序对于堆溢出有所防范：“description”和“bookname”都是没有堆溢出的
但是“name”的输入却溢出了一字节，这里先看看list中的信息：
1 | if ( list ) |
1 | struct list |
先用GDB看看“name”的位置，和“name”附近有什么
在“name”中输入“flag”，然后“search flag”：
1 | pwndbg> search -s flag |
再打印这个地址：
1 | pwndbg> x/20xg 0x555555602040 |
只有一个“0x00005555556036f0”，就是“list_addr”（用于存放malloc的list地址）
程序故意把“输入字符串”的末尾设置为“\x00”，但“name”的“\x00”溢出到“list_addr”中了，如果这时申请一个“list”，这时它的写入地址就会存入“list_addr”中，从而覆盖掉“\x00”，就可以利用“printf”打印了
1 | p.recvuntil('Enter author name: ') |
那么接着干什么呢？还是要围绕“description”来打
1 | pwndbg> x/20gx 0x555555602040 |
“0x00005555556036f0”为第一个list，它的低字节是可以被“name”给覆盖的
1 | pwndbg> x/20gx 0x555555602040 |
“0x00005555556036f0”变为了“0x0000555555603600”
这样，程序就会以为“0x0000555555603600”是第一个list
再分析下heap空间：
1 | pwndbg> x/20xg 0x555555602040 |
1 | 0x5555556036a0: 0x0000000000000000 0x0000000000000021 |
如果这样“create list1”，“create list2”，编辑“list_1_description”输入以下数据：
1 | create(0xe0, 'aaaa', 0xe0, 'bbbb') |
那么会生成以下的heap空间：
1 | pwndbg> x/60xg 0x55c18a470390 |
// 因为“list2”的“bookname”和“description”很大，所以用mmap函数进行调用
可以发现，如果用“name”把“list_1”尾字节覆盖为“\x00”，程序就会把“fake_list”识别为“list_1”，接着如果用“show”打印，就可以泄露写入的数据
其中“bookname2”会被泄露出来，而“bookname2”是用mmap函数申请的
这里有一个知识：
1 | pwndbg> vmmap |
bookname2（0x7ff6d3df1010）：第一次用mmap函数获取的地址
/usr/lib/x86_64-linux-gnu/libc-2.31.so（0x7ff6d3e13000）：libc基址
1 | In [4]: 0x7ff6d3e13000-0x7ff6d3df1010 |
两者的差值是一个常数（不同的libc文件偏移不同，甚至可能是负数，需要用GDB看）
那么“libc_base”就可以被计算出来，就可以用“free_hook”来get shell了
1 | libc_base = bookname2 + 0x21ff0 |
编辑“list_1_description”，实际上写入了“list_2”
1 | 0x55c18a470400: 0x0000000000000001 0x000055c18a4704c8 #fake_list |
1 | 0x55c18a4704c0: 0x0000000000000002 addr("/bin/sh") #list_2 |
编辑“list_2_description”，在“free_hook”中写入“system”
执行“free(2)”时，就会执行“free_hook”挂钩的函数“system”
而“list_2”的“list_addr + 8”中被写入了”/bin/sh”，这里就相当于执行了“ system(“/bin/sh”) ”
当然用“one_gadget”也可以：
1 | libc_base = bookname2 + 0x21ff0 |
完整exp：
1 | from pwn import* |
1 | [+] list1_addr >> 0x563929e21490 |
PS：
本程序服务器的libc版本为“libc-2.23.so”可以利用这种方式来打
但“libc-2.29.so”以后假如了两行代码：
1 | if (__glibc_unlikely (chunksize(p) != prevsize)) |
如果“list_2”的“presize”不等于“list_1”的“size”，程序就会报错
导致以下代码没法执行：
1 | change(1, p64(bin_sh) + p64(free_hook)) #这个'list_1'是伪造的 |
利用hook机制，把某个函数的hook劫持为shellcode
这种技术在堆利用中很常见，想要了解它，必须先了解hook机制
hook直意为钩子又叫做回调函数，是一种特殊的消息处理机制，它可以监视系统或者进程中的各种事件消息，截获发往目标窗口的消息并进行处理
在程序中设置钩子，用来在 malloc ， realloc ， free 的时候，对其进行检查，可以看到对应的函数调用后的地址是什么
原理：
hook本质上就是一个函数指针，可以指向不同的函数，从而完成不同的功能
设计理念：
我们在写main函数的时候，可能还不知道它会完成什么功能，这时候留下函数指针作为接口，可以挂上不同的函数完成不同的功能，究竟执行什么功能由钩子函数的编写者完成，钩子的出现体系了程序模块化的思想
案例：
1 |
|
1 | ➜ [/home/ywhkkx/桌面] ./test |
这里的函数“fun1”和函数“fun2”就是hook把函数指针fun指向fun1和fun2的过程称为“挂钩子”
libc中最常见，也是堆利用中最常见的两种hook：malloc_hook，free_hook
接下来以“malloc_hook”为例，分析一下hook的具体实现：
ptmalloc 定义了一个全局钩子 malloc_hook，这个钩子会被赋值为 malloc_hook_ini 函数
1 | void *weak_variable (*__malloc_hook) |
而函数malloc会调用 malloc_hook ，那么在 第一次调用malloc函数 时会执行 malloc_hook，也就是执行了 malloc_hook_ini
1 | static void * |
可见在 malloc_hook_ini 会把 malloc_hook 置空，然后调用 ptmalloc_init 函数，完成对 ptmalloc 的初始化，最后再次调用 malloc_hook，但是这次的 malloc_hook 已经置空，从而继续执行剩下的代码
第一次调用：
1 | malloc(__libc_malloc) -> __malloc_hook(malloc_hook_ini) -> ptmalloc_init -> __libc_malloc -> _int_malloc |
再次调用：
1 | malloc(__libc_malloc) -> _int_malloc |
最后，malloc_hook会指向一个“检查函数”
1 | void * function(size_t size, void * caller) |
caller：表示用malloc申请空间的“可写入地址”（ fd&bk 所在处）
使用malloc的时候就可以返回其“可写入地址”了
hook劫持的基本操作就是：在hook的地址中写入shellcode的地址，可以把hook地址写在某个固定地址上，然后在这个地址中写入shellcode，这样就挂钩完毕了
那么问题的关键就是找hook的地址：
一，如果知道libc版本，可以直接引入libc库，用ELF工具进行查找
1 | free_hook = libc_base + libc.sym['__free_hook'] |
这种方法需要泄露libc基地址
二，还可以用“main_arena”来定位“malloc_hook”
malloc_hook位于main_arena上方16字节
当small chunk被释放时，它的fd、bk指向一个指针，这个指针指向top chunk地址，这个指针保存在“main_arena+0x58”
找到合适的small chunk再free掉，然后通过“main_arena”获取“malloc_hook”
// 等到分析 Unsortedbin attack 的时候，再分析这种hook劫持技术