前置知识：

这个fwrite函数中的_IO_write_ptr指针的挪动和fread函数中的_IO_read_ptr指针的挪动是不太一样的。先回顾一下上一篇文章中_IO_read_ptr指针什么时候挪动？当系统调用read的时候从文件中读取多少个字节的数据到输入缓冲区，就将_IO_read_end指针挪动多少个字节 初始值和_IO_read_base是一样的 ，而此时的_IO_read_ptr指针不动。当执行memcpy函数将数据从输入缓冲区拷贝多少个字节的数据到我们指定的内存地址，就将_IO_read_ptr指针挪动多少个字节。在_IO_read_base和_IO_read_ptr之间是已经拷贝过的数据，_IO_read_ptr和_IO_read_end之间是输入缓冲区中还未拷贝的数据。

而本次分析的fwrite函数则是直接将_IO_buf_end的值赋给了_IO_write_end（read的那个指针可不是这样），而_IO_write_ptr的初始值则和_IO_write_base的值一样。该函数先从指定的内存地址读取一定字节的数据到输出缓冲区，此时的_IO_write_ptr指针挪动(我这里以及上下文提到的挪动指的都是在原本的基础上加)相应的字节。此时的_IO_write_base指针和_IO_write_ptr指针之间的区域是将要从输出缓冲区写入文件的数据，而_IO_write_ptr指针和_IO_write_end指针之间的区域是输出缓冲区的可用区域(就是还能再往输出缓冲区拷贝多少个字节的内容)，当执行系统调用write往文件中写入一定的字节的内容后，_IO_write_ptr就会减去相应的字节。

上面的内容一定要清楚，不然分析的时候就会陷入误区

前面两篇文章的地址如下：

IO学习–源码调试fopen函数

IO学习–源码分析fread函数

上一篇分析的是fopen函数，这次来分析下fread函数。
IO学习–源码分析fread函数

什么是侧信道爆破？

侧信道攻击是一种非常有趣的攻击手法，在pwn中通常为侧信道爆破。我的理解是侧信道爆破是指在程序没有正常回显的情况下通过执行精心构造后的数据，获取一些程序的现象或反馈来确定最终正确的flag，这种反馈比如有程序回显的错误，或者死循环等等。

写在前面：

这篇文章是学习IO，进行源码分析四部曲中的第一篇，本篇主要就是源码调试fopen函数，并没有单独对fopen函数的源码专门阅读分析(之后的三篇基本上是源码分析)。如果要看fopen函数源码分析的话可以去看下文末的参考文章(师傅们写的都非常好诶)

这里我写了一篇关于初学者应该如何去读glibc源码的文章(希望可以帮助到刚刚入门的师傅们) here

house of force是针对top chunk的一种手法，通过这种攻击手法，可以将top chunk更新到任意内存，再次申请堆块并写入数据，这就相当于任意地址任意写了。

off by null的利用思路：

off by null漏洞，顾名思义就是溢出了一个空字节，核心是让其堆块的prev inuse位溢出为0，从而认为它的低地址堆块处于了free状态，然后加以利用。

关于unlink的学习总结，我打算分成4个部分来说明，分别是unlink的利用整体思路、如何伪造fake_chunk、探究下unlink漏洞是如何实现的、相关题目的WP。我这篇博客并没有画图片来说明unlink的操作，我认为不是特别适合完全不懂unlink的师傅来参考学习，建议去看一些其他师傅一些画图说明unlink的博客，对unlink有个模糊的认识后，再看这篇文章应该效果最好

我和我的同学 trunk 还有我学弟 Sta8r9 共同编写一些方便解PWN题的鸡肋函数封装到了这个库里，第一是平常用起来方便顺手，第二顺便练习下编程能力，第三如果以后有可能的话，希望逐渐做成像 roderick 师傅的pwncli那样。

源代码

一条命令下载 tools 函数库

wget https://raw.githubusercontent.com/ZIKH26/tools/master/tools.py

因为打CTF pwn题的时候，经常遇见本地程序的libc与远程服务器那边程序所依赖的libc不匹配的情况，尽管可以用patchelf和glibc-all-in-one来给程序patch一个libc。但是patchelf似乎有点小bug，为了防止比赛的时候在这个地方掉链子，因此可以采用在docker里跑不同版本的ubuntu。

同时随着时间的推移，自己也从一个拉跨的做题人偶尔客串了一下拉跨的出题人，因此需要打包一个题目环境，还得学习一下docker的几个基本配置文件。

本文是对我学习docker做了一个简单的小总结。

patchup

该工具是我自用的一个小工具（针对于做pwn题的辅助工具）（本工具的实现非常简单，而且这个工具的核心是依赖patchelf和glibc-all-in-one这两个工具），用于快速修改本地ELF文件的libc使其与远程服务器那边所运行的程序依赖的libc库一样
从而避免了因为 libc 问题，而导致本地打通了但是远程没打通的尴尬情况。因为每次都手动 patch libc 的过程太过于重复，而且有概率出错，同时受到了
roderick 师傅写的 pwncli 的启发，于是就有自己写一个命令行工具的想法。
如果你想看施工现场，请见 github仓库