该工具是我自用的一个小工具（针对于做pwn题的辅助工具）（本工具的实现非常简单，而且这个工具的核心是依赖patchelf和glibc-all-in-one这两个工具），用于快速修改本地ELF文件的libc使其与远程服务器那边所运行的程序依赖的libc库一样
从而避免了因为 libc 问题，而导致本地打通了但是远程没打通的尴尬情况。因为每次都手动 patch libc 的过程太过于重复，而且有概率出错，同时受到了roderick 师傅写的 pwncli 的启发，于是就有自己写一个命令行工具的想法。
如果你想看施工现场，请见 github仓库
有时候我们要去追踪一些函数或是数据，需要用gdb动态调试并去结合着源码分析。下面介绍一下gdb源码调试的环境如何搭建
通过这段时间对于arm架构的题目学习，自认为收获还是不少的。下面是对于这段时间关于arm架构的pwn题学习所进行的总结。
有时候在做64位题目的时候会发现exp也能执行到 system(“/bin/sh”)，但就是获取不了shell。然后通过gdb调试发现是在最后的system函数执行到内部的时候卡住了，然后就满脸疑惑，这也能卡？？？
下面主要解释_dl_runtime_resolve这个函数运作时的情况，而延迟绑定的整体流程就不详细说明了，具体的流程可以参考下面这个流程图（这个我也忘记是哪个师傅做的了，很久之前收藏了这个图片）
而Linux中最终完成动态链接的函数进行重定位的是在_dl_runtime_resolve(link_map_obj, reloc_index)函数中完成的，如果再详细一点就是_dl_runtime_reslove函数调用了_dl_fixup函数，然后_dl_fixup函数调用了_dl_lookup_symbol_x函数，最终这个函数去动态库里面找到了我们此刻进行延迟绑定的函数，并且把它的地址填写到了got.plt表项中。这里主要详细讲一下_dl_runtime_resolve函数的运作流程
这个SROP是一种极其有趣的攻击方式，它是利用程序从内核层面切换到用户层面恢复上下文时的一个漏洞，该漏洞可以让我们自己自行设置所有寄存器里的值。
这个第一章，主要是介绍了计算机上的一些专业术语，以及一些最基础的概念（并没有深入讲解，不过会在后面的章节进行探究）。不过这些概念彼此之间联系不大，并不是循序渐进的，因此这一章，我单独介绍里面出现的术语。
在pwntools中，sendline和send都是发送数据，但是sendline是发送一行数据，换句话说就是sendline会在发送的数据末尾加一个回车。而这个回车所造成的影响，是跟对应的输入函数有关系，在做pwn题中，碰见的输入函数有scanf（”%s”)，gets()，read()，fgets(),这四个函数。我感觉最常见的应该是read函数。我们分别讨论一下这前三个函数在读取内容上的具体细节以及sendline所造成的影响。