how2heap 1-4
64位系统以下各字段均为8字节，32位系统为4字节。
glibc2.26及以上版本有tcache机制。咱目前也不太懂，快刀斩乱麻，glibc2.25的实验在Ubuntu16.04上做，glibc版本信息如下：
1. First_fit.c
运行结果：
分析：
新版的how2heap这里改为0x512、0x256（十六进制）.
malloc后的堆情况：
观察presize+size占0x10 个字节，那么两块的payload分别为0x510和0x250个字节。明显少于malloc的要求，难道这里也有四舍五入？希望以后会理解。
free(a)后，该块出现在unsorted_bin链表：
为指针c分配0x500字节，就会分配到a指向的块：
a指针前面已被释放，本质是该块内存变成空闲状态。如果仍然使用a指针，就会得到c修改的内容，即造成了use-after-free。本例就是为了理解linux堆的分配机制和堆的结构。
观察上面内存表示，每个单元是16个十六进制数，也就是16*4=64位。 说明64位系统，每个chunk都是8字节的整数倍。目前的疑问还是，0x512+0x10+1=0x523，为什么能少分配为0x520，而不是凑多到0x530？希望以后会理解。
2. Fastbin_dup.c
运行结果：
分析：
malloc后分配的三个块：
第二次free(a)后的堆布局，a指向的地址0x602000，再次出现在fast_bin(0x20)链表的尾部，该链表后进先出。如果中间没有0x602020(即没释放b),会被检测出异常。
注意观察三次malloc中fastbin链表的变化。这已经不再是，简单的第一次malloc和第三次malloc分配到相同的块。而是在分配后不修改块的fd的情况下，奇数次malloc分配到0x602000,偶数次malloc分配到0x602020。因为，这两个块的fd更像构成了循环链表。
3. Fastbin_dup_into_stack.c
运行结果：
分析：
前面的代码与fastbin_dup.c一致，都存在double free(a)。不同在于，双重释放后的第三次malloc前，会对第一次malloc分配块的payload进行如下修改：
补充一些知识点，malloc返回的地址是分配块的payload首地址(chunkptr)，而fastbin链表中的地址是整个块的首地址(chunkinfo)。&p是指针自己的地址，而p是指针指向的地址。%llu用来输出unsigned long long型，为64位。
d = (unsigned long long) (((char)&stack_var) - sizeof(d));
d是第一次malloc分配的块，指向0x603010，由于double free，它现在处于fastbin链表的尾部，被认为仍是空闲可分配的。Stack_var是局部变量，位于0x7fffffffde20。为了伪装出chunk的pre_size，d的fd指向该地址前8字节0x7fffffffde18(感觉sizeof(d)，是因为需要方便地表示8字节，而不是d得设计得多巧妙)，所以再次malloc分配0x603010后，该地址出现在fastbin链表的尾部。
可以看到，stack_var处伪装的堆块，其fd和bk就是前面在堆中分配的地址。这里我弄不懂，有大佬解释是，因为我们伪造的堆块的fd指针位置刚好是这个地址的值.当然这不是我们刻意设置的。也就是个巧合。
我到底在学习一种堆的攻击技巧，还是单纯的glibc缺陷呢？或者说这些技术怎么使用？可以看到，目的就是对栈空间stack_var分配出堆块，进行写覆盖来帮助其他攻击。 double free的意义在于，指针d指向的堆块，已被分配却仍然在fastbin链表上。已被分配意味着指针获得了该堆块的地址（有了地址才读写）。在fastbin链表上意味着对指针内容的写操作可以在再次分配时对fastbin链表产生影响。
此外，我注意到栈中地址用12个十六进制数表示，堆块中地址用6个十六进制数表示，我的Ubuntu是64位的，这有什么讲究么？希望以后理解。
4. fastbin_dup_consolidate.c
运行结果：
分析：
在第二次free(p1)后设下断点，观察到0x602000同时出现在fastbin和smallbin。
这个例子在说glibc的分配机制问题。分配大块时触发malloc_consolidate()，会将fastbin中的p1收到small bin，p1可再次释放到fastbin。连续两次malloc，两次都会得到p1指向的堆块，只不过一个从fastbin分配，另一个从smallbin分配。malloc_consolidate()机制一般要解决什么问题？希望以后理解。