我和我的同学 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仓库

有时候我们要去追踪一些函数或是数据，需要用gdb动态调试并去结合着源码分析。下面介绍一下gdb源码调试的环境如何搭建

通过这段时间对于arm架构的题目学习，自认为收获还是不少的。下面是对于这段时间关于arm架构的pwn题学习所进行的总结。

有时候在做64位题目的时候会发现exp也能执行到 system(“/bin/sh”)，但就是获取不了shell。然后通过gdb调试发现是在最后的system函数执行到内部的时候卡住了，然后就满脸疑惑，这也能卡？？？

疑惑

从第一次接触pwn的到现在将近四个月了，每次做出来pwn题之后，把写好的脚本打到服务器上，就可以在服务器那边开启一个shell，然后用cat就可以读出我们需要的flag了。可是事实上我们真的可以用pwn的解题手法去进行一次攻击么？我们最后在对方主机去执行system(‘/bin/sh’)真的可以拿到shell么？

延迟绑定整体流程图

下面主要解释_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是一种极其有趣的攻击方式，它是利用程序从内核层面切换到用户层面恢复上下文时的一个漏洞，该漏洞可以让我们自己自行设置所有寄存器里的值。

什么是ret2csu？

这个其实就是在程序中一般都会有一段万能的控制参数的gadgets，里面可以控制rbx,rbp,r12,r13,r14,r15以及rdx,rsi,edi的值，并且还可以call我们指定的地址。然后劫持程序执行流的时候，劫持到这个__libc_csu_init函数去执行（这个函数是用来初始化libc的，因此只要是动态链接的程序就都会有这个函数（至少我还没有遇见过特殊情况）），从而达到控制参数的目的。