有时候我们要去追踪一些函数或是数据，需要用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的，因此只要是动态链接的程序就都会有这个函数（至少我还没有遇见过特殊情况）），从而达到控制参数的目的。

​ 这个第一章，主要是介绍了计算机上的一些专业术语，以及一些最基础的概念（并没有深入讲解，不过会在后面的章节进行探究）。不过这些概念彼此之间联系不大，并不是循序渐进的，因此这一章，我单独介绍里面出现的术语。

在pwntools中，sendline和send都是发送数据，但是sendline是发送一行数据，换句话说就是sendline会在发送的数据末尾加一个回车。而这个回车所造成的影响，是跟对应的输入函数有关系，在做pwn题中，碰见的输入函数有scanf（”%s”)，gets()，read()，fgets(),这四个函数。我感觉最常见的应该是read函数。我们分别讨论一下这前三个函数在读取内容上的具体细节以及sendline所造成的影响。

​ ret2syscall需要寻找的指令的思路和构造shellcode的思路是一样的，只不过ret2syscall获取的指令算是就地取材，而ret2shellcode创造指令算是无中生有。