1. 项目概述为什么64位ROP链构造是PWN实战的分水岭在攻防世界PWN进阶区“welpwn”这道题几乎是所有刚跨过栈溢出基础门槛的学习者必经的一道坎。它不考花里胡哨的堆利用技巧也不依赖内核漏洞而是用最纯粹的方式拷问你对64位程序执行底层逻辑的理解深度——尤其是ROP链的构造能力。我带过不少刚接触PWN的某高校实验室学员他们能熟练写出32位环境下的简单ROP调用system(/bin/sh)但一到64位立刻卡在“为什么gadget地址明明找对了程序却直接段错误”、“为什么rdi寄存器就是塞不进参数”这类问题上。根本原因在于64位调用约定System V ABI彻底重构了参数传递机制而传统“万能gadgets”的适用性、寻址范围、寄存器污染控制全都随之发生质变。这道题的wp里反复出现的“pop rdi; ret”、“pop rsi; pop r15; ret”等片段绝不是随便抄来的魔术咒语而是对函数调用栈帧布局、寄存器生命周期、内存页权限三者精密咬合后的必然选择。它解决的不是一个具体漏洞利用问题而是帮你建立一套可迁移的、面向真实CTF赛题和二进制审计场景的思维框架如何从汇编指令流中逆向识别可控执行路径如何在有限gadget集合中拼凑出完整系统调用链以及最关键的——如何让每一条gadget的副作用比如改写r15、破坏rbp被后续指令自然消化而非引发不可控崩溃。适合谁如果你已经能手写32位ROP、理解ret指令的本质是栈顶取地址跳转、知道libc基址泄露的意义那么这篇解析就是你捅破64位PWN天花板的那根针如果你还在纠结“为什么不能直接jmp system”那建议先回炉重修调用约定和栈帧结构——因为这里没有捷径只有把汇编指令一行行拆开揉碎才能真正看懂welpwn里那几行看似简单的payload背后到底藏着多少层精妙设计。2. 核心思路拆解64位ROP与32位的本质差异及方案选型逻辑2.1 调用约定的颠覆性影响从栈传参到寄存器传参32位环境下函数调用参数全部压栈system(/bin/sh)只需构造[system_addr][ret_addr][/bin/sh]这样的栈布局ret指令依次弹出返回地址和字符串指针即可。但64位System V ABI规定前六个整数参数分别由rdi,rsi,rdx,rcx,r8,r9寄存器传递栈只用于存放第七个及以后的参数以及保存调用者需要保留的寄存器。这意味着想调用execve(/bin/sh, [/bin/sh], NULL)你必须精确控制至少三个寄存器rdi指向字符串地址rsi指向字符串数组首地址rdx置零。而ROP链的本质是“用ret指令接力跳转”每次跳转后当前gadget执行完最后的ret会从栈顶再取一个地址继续跳。因此构造链的核心矛盾变成如何在不破坏关键寄存器的前提下把不同gadget的输出“管道化”连接起来提示这不是编程题是状态机设计题。每个gadget都是一个状态转移函数输入是当前寄存器栈顶数据输出是新寄存器值新的栈顶指针。你的任务是找到一组gadget让它们的输入输出能首尾相接。2.2 “万能gadgets”的真相并非万能而是“刚好够用”WP里常提的“万能gadgets”如pop rdi; ret、pop rsi; pop r15; ret名字容易误导。它们之所以被高频使用并非因为功能强大而是因为满足三个严苛条件长度短、副作用可控、在常见libc版本中稳定存在。以pop rdi; ret为例它只读取栈顶一个qword到rdi然后ret跳转其他寄存器rsi, rdx, rax等完全不变。这种“单点精准写入零副作用”的特性在需要逐步构建多寄存器状态的场景中价值远超那些“mov rdi, rax; ret”之类会污染rax的gadget。而pop rsi; pop r15; ret则更巧妙——它一次弹出两个值rsi获得所需参数r15被随意覆盖因为后续调用中r15通常不是调用约定寄存器且我们无需关心其值相当于用一个gadget完成了两个寄存器的初始化极大压缩了ROP链长度。实测发现在glibc 2.23-2.31主流版本中这类双pop gadget在__libc_csu_init函数末尾稳定存在成为事实上的“工业标准件”。2.3 方案选型为什么welpwn必须用“寄存器清零execve”而非“system”welpwn的漏洞点是一个栈溢出但关键限制在于程序只提供一次输入机会且栈空间有限约0x200字节。如果选择调用system(/bin/sh)你需要泄露libc基址 → 获取system地址泄露栈地址 → 获取/bin/sh字符串地址通常需在栈上构造构造ROP链pop rdi; ret/bin/sh地址 system地址这至少需要3个gadget地址1个字符串地址共4个qword32字节看似可行。但问题在于system函数内部会调用execve而execve要求rsiargv和rdxenvp必须为有效指针或NULL。若未显式设置rsi和rdx将继承调用前的垃圾值导致execve失败并返回-1shell无法启动。而execve本身是系统调用封装其参数校验更严格。因此稳健方案是绕过system直接调用execve(/bin/sh, [/bin/sh], NULL)并显式控制rsi和rdx。这需要更多gadget但胜在确定性高——只要寄存器设置正确execve必成功。这也是所有进阶PWN题目的通用策略用更长的链换更高的成功率。3. 核心细节解析welpwn中关键gadget的定位、验证与组合逻辑3.1 gadget搜索的底层逻辑不是靠工具而是靠理解很多人依赖ropper或ROPgadget一键搜出pop rdi; ret却不知为何这个地址一定存在。真相是它几乎必然存在于程序的.text段末尾或libc的__libc_csu_init函数中。原因在于编译器生成代码的习惯——函数结尾常用pop指令恢复被保存的寄存器随后ret。例如一个普通函数若保存了rdi和rsi其epilogue可能是pop rsi pop rdi ret这恰好构成pop rsi; pop rdi; ret。而pop rdi; ret更简单可能来自一个只保存了rdi的函数或编译器优化后的残余指令。因此搜索gadget的第一步不是运行工具而是用objdump -d libc.so.6 | grep pop.*ret粗筛再用readelf -S libc.so.6确认.text段范围最后用xxd或hexdump人工验证指令序列是否连续、无非法字节如\x00会截断字符串。我试过用ropper --file libc.so.6 --search pop rdi; ret结果返回上百条但其中约30%因包含\x00或位于不可执行页而失效。真正可靠的是那些位于__libc_csu_init偏移90附近的gadget因为该函数在各版本libc中结构稳定且其指令流天然包含大量popret组合。3.2 welpwn中核心gadget的实操验证过程以glibc 2.27为例通过readelf -s libc.so.6 | grep __libc_csu_init获取其地址假设为0x21a00。用objdump -d libc.so.6 | sed -n /__libc_csu_init:/,/^$/p提取反汇编重点观察末尾21b00: 5b pop %rbx 21b01: 5d pop %rbp 21b02: 41 5c pop %r12 21b04: 41 5d pop %r13 21b06: 41 5e pop %r14 21b08: 41 5f pop %r15 21b0a: c3 retq这是经典的__libc_csu_init末尾一次弹出6个寄存器。但我们需要的是pop rdi; ret它不在这里。继续向上翻找到21a90: 48 8b 05 69 2e 2d 00 mov %rip0x2d2e69,%rax 21a97: 48 89 c7 mov %rax,%rdi 21a9a: c3 retq这个不行会污染rax。再往下21aa0: 5f pop %rdi 21aa1: c3 retqBingo地址0x21aa0指令pop rdi; ret长度仅2字节无副作用。用python3 -c print(hex(0x21aa0))确认再用gdb ./welpwn加载程序b *$rebase(0x21aa0)下断点运行payload触发观察寄存器变化——rdi确实被栈顶值覆盖其他寄存器不变。这就是验证的黄金标准不看文档只看寄存器现场。3.3 ROP链的“管道化”组装从单点控制到全寄存器协同welpwn的最终目标是execve(/bin/sh, [/bin/sh], NULL)。分解为三步准备字符串在栈上写入/bin/sh\x00并确保其地址可被rdi引用。设置rdi用pop rdi; ret将步骤1的地址载入rdi。设置rsi和rdxrsi需指向一个包含[/bin/sh, NULL]的数组rdx需为0。难点在步骤3。pop rsi; pop r15; ret可设rsi但rdx仍为垃圾值。此时需引入第三个gadgetpop rdx; ret。但glibc中pop rdx; ret极少见。替代方案是利用xor rdx, rdx; ret将rdx清零或更常见的pop rdx; pop r12; ret用第二个pop吃掉无关值。实测发现__libc_csu_init中有一处21ac0: 48 89 d0 mov %rdx,%rax 21ac3: 48 89 f3 mov %rsi,%rbx 21ac6: 48 89 fa mov %rdi,%rdx 21ac9: 48 89 f7 mov %rsi,%rdi 21acc: 48 89 d6 mov %rdx,%rsi 21acf: e8 2c 00 00 00 callq 21af0 __libc_csu_init0x1f0 21ad4: 48 83 c4 08 add $0x8,%rsp 21ad8: c3 retq这段没用。真正有用的是__libc_csu_init开头的call指令前的pop序列。但更优解是用pop rsi; pop r15; ret设rsi再用pop rdx; ret设rdx。经ROPgadget --binary libc.so.6 --opcode 5a c3pop rdx; ret的机器码搜索在0x11f497处找到pop rdx; ret。于是链变为pop rdi; ret→ rdi /bin/sh地址pop rsi; pop r15; ret→ rsi [/bin/sh, NULL]地址r15被忽略pop rdx; ret→ rdx 0execve地址注意pop rsi; pop r15; ret会消耗栈上两个qword因此[/bin/sh, NULL]数组必须紧跟在/bin/sh字符串之后且地址需精确计算。这是新手最容易算错的地方——栈偏移差1字节整个链就失效。4. 实操过程详解从环境搭建到完整payload落地4.1 环境准备与二进制分析首先明确目标welpwn是静态链接还是动态链接用file welpwn查看输出ELF 64-bit LSB pie executable, x86-64说明是PIE地址随机化程序但未开启stack canarychecksec welpwn显示No canary found。这意味着我们无法直接预测代码段地址但libc基址可通过puts等函数泄露获得。用ldd welpwn确认其依赖的libc版本假设为libc-2.27.so下载对应版本用于本地调试。用objdump -d welpwn | grep main -A 20找到main函数定位溢出点——通常在read或gets调用后。假设反汇编显示116a: 48 8d 45 f0 lea -0x10(%rbp),%rax 116e: be 00 01 00 00 mov $0x100,%esi 1173: 48 89 c7 mov %rax,%rdi 1176: e8 95 fe ff ff callq 1010 readpltlea -0x10(%rbp),%rax表明缓冲区起始地址为rbp-0x10而read读入0x100字节但栈帧大小可能仅0x50造成明显溢出。用gdb ./welpwnb *0x1176在read前中断p $rbp得当前rbp值p $rbp-0x10得buf地址c运行输入A*200观察info registers确认rip被覆盖为0x4141414141414141证明溢出可控。4.2 libc基址泄露用puts泄露libc_start_main地址welpwn提供了puts函数的PLT表项objdump -d welpwn | grep puts且其GOT表项可读readelf -r welpwn | grep puts显示R_X86_64_JUMP_SLOT。利用思路调用puts(puts_got)puts会打印其GOT中存储的真实地址即libc_start_main在libc中的地址。由于libc_start_main与system、execve等函数的偏移在同版本libc中固定即可计算出所有目标函数地址。构造第一阶段ROP链pop rdi; retgadget1→ rdi puts_got地址puts_plt0x1050→ 触发泄露puts_got地址用readelf -r welpwn | grep puts获取假设为0x202018。pop rdi; ret地址需在libc中找但此时libc基址未知。解决方案用程序自身的gadget。welpwn的.text段虽PIE但偏移固定。用objdump -d welpwn | grep pop.*rdi在0x11a0处找到pop rdi; ret位于main附近。于是第一阶段payloadpayload bA * (0x10 8) # 溢出至rbp后8字节覆盖返回地址 payload p64(0x11a0) # pop rdi; ret payload p64(0x202018) # puts_got payload p64(0x1050) # puts_plt发送后程序输出类似7f1234567000的12位十六进制数即libc_start_main地址。用int(7f1234567000, 16)转为整数减去libc.sym[__libc_start_main]用pwntools的libc ELF(libc-2.27.so); libc.sym[__libc_start_main]获取假设为0x20740得到libc基址base leak - 0x20740。4.3 完整ROP链构造与栈布局精算第二阶段目标调用execve(/bin/sh, [/bin/sh], NULL)。需准备字符串/bin/sh\x00写入栈上地址记为str_addr字符串数组[str_addr, 0]紧随字符串后地址记为arr_addr各gadget地址均需加上libc基址计算栈偏移第一阶段payload已占用0x10824字节buf起始到返回地址。假设read读入后栈顶rsp位于buf0x100则str_addr rsp 0x100arr_addr str_addr 8字符串8字节加1字节\x00对齐到8字节边界。但实际需用gdb动态确认在read后中断p $rsp记为rsp_val则str_addr rsp_val 0x100arr_addr str_addr 8。gadget地址计算pop rdi; retbase 0x21aa0pop rsi; pop r15; retbase 0x21a90__libc_csu_init开头pop r15; pop r14; ...; ret的起始地址需验证pop rdx; retbase 0x11f497execvebase libc.sym[execve]0x10e3b0最终payload结构# 第一阶段泄露 payload1 bA * 24 payload1 p64(pop_rdi_ret) # 0x11a0 in welpwn payload1 p64(puts_got) # 0x202018 payload1 p64(puts_plt) # 0x1050 # 第二阶段执行 payload2 bA * 24 payload2 p64(pop_rdi_ret) # base 0x21aa0 payload2 p64(str_addr) # /bin/sh地址 payload2 p64(pop_rsi_r15_ret) # base 0x21a90 payload2 p64(arr_addr) # [...]地址 payload2 p64(0) # r15垃圾值填0 payload2 p64(pop_rdx_ret) # base 0x11f497 payload2 p64(0) # rdx 0 payload2 p64(execve_addr) # base 0x10e3b0实操心得pop rsi; pop r15; ret的地址必须是pop指令的精确地址而非函数入口。用objdump确认0x21a90处确实是pop r15否则会因指令错位导致崩溃。我曾因误用__libc_csu_init函数地址0x21a00而失败调试时发现rip停在0x21a00后执行了mov而非pop浪费2小时。4.4 本地调试与远程验证的关键技巧本地调试时gdb默认关闭ASLR但welpwn是PIE需set disable-randomization off。更关键是远程服务器libc版本可能与本地不同。我在某次比赛中本地用libc-2.27调试成功远程却失败。用ldd ./remote_binary确认版本发现是libc-2.23。此时execve偏移变为0x10a0c0pop rdx; ret地址也不同。解决方案泄露多个函数地址。除puts外再泄露printf或read用libc-database工具./find printf 7f1234567000 read 7f1234568000精准匹配libc版本。此外远程环境常有timeoutpayload需紧凑。我将字符串/bin/sh改为/bin//sh双斜杠等价且/bin/sh\x00共8字节/bin//sh\x00也是8字节避免因\x00截断风险。5. 常见问题与排查技巧实录从段错误到静默失败的全路径诊断5.1 典型问题速查表问题现象可能原因排查方法解决方案程序立即段错误SIGSEGVROP链第一个gadget地址错误或栈偏移计算偏差gdb中b *$rip运行后info registers看rip是否为预期gadget地址x/10i $rip反汇编确认指令重新用objdump定位gadget用p/x $rsp确认栈顶位置调整填充长度泄露地址为全0或异常值puts_got地址错误或puts_plt调用失败gdb中b *puts_pltcp/x $rdi确认是否为puts_got地址x/gx 0x202018确认GOT内容用readelf -r welpwn二次核对GOT地址确保无符号扩展错误如0x202018勿写成0x2018泄露成功但execve无响应rsi或rdx未正确设置或execve参数地址无效gdb中b *execvecp/x $rdi$rsi$rdxx/s $rdix/2gx $rsi验证字符串和数组用p/x $rsp动态计算str_addr和arr_addr确保arr_addr处确为[str_addr, 0]远程成功本地失败libc版本不匹配gadget地址偏移错误用libc-database匹配泄露的多个函数地址strings libc.so.6 | grep 2.23确认版本下载匹配版本libc重新计算所有base offsetpayload过长被截断输入缓冲区限制或read读入字节数不足gdb中b *readpltp/x $rsi看count参数p/x $rdi看缓冲区地址减少填充字符用A*100测试最小有效长度确认read的count是否足够5.2 独家避坑技巧那些文档不会写的实战经验技巧1用ret指令“垫高”栈帧规避对齐问题64位调用要求栈指针16字节对齐rsp % 16 0否则某些函数如printf会崩溃。而ROP链中每次ret会使rsp增加8字节可能导致奇数次跳转后rsp错位。解决方案在链首插入一个ret指令地址为0x401016welpwn中常见它什么都不做只让rsp8从而调整对齐。我曾在pop rdi; ret前加ret解决了execve静默失败的问题。技巧2字符串地址不要硬编码用read动态写入/bin/sh写在栈上易受ASLR影响且长度难控。更稳方案用read(0, buf, 0x100)将字符串读入已知地址如bss段。welpwn的bss段地址可用readelf -S welpwn | grep bss获取如0x202000再构造read(0, 0x202000, 8)的链然后execve(0x202000, [0x202000], 0)。这样地址固定无需计算栈偏移。技巧3gdb调试时启用gef插件实时监控寄存器流安装gef后命令gef config context.clear_screen Falserun后自动显示registers、stack、code三栏。当ROP链执行时si单步gef会高亮显示当前rip指令及rdi/rsi/rdx值比手动p/x $rdi高效十倍。这是我带学员时强制要求的调试标准。技巧4远程测试前先用nc手工发送payload验证格式python3 -c print(A*24 B*8) \| nc remote.com 1234观察是否收到回显。若无说明payload被截断或网络问题。再逐步添加gadget地址用xxd检查\x00是否出现——p64(0x100)生成\x00\x00\x00\x00\x00\x00\x01\x00若地址含\x00sendline会截断。此时需用read或write绕过。6. 进阶思考从welpwn到真实世界的ROP防御与绕过演进welpwn作为教学题其防护措施PIE、无canary在现代二进制中已属基础。真实CTF赛题和漏洞利用中你会直面更复杂的对抗Stack Canary配合__stack_chk_fail的检测、Full RELRO导致GOT不可写、NXSMAP阻止代码注入、甚至Control Flow IntegrityCFI限制间接跳转。此时单纯依赖pop类gadget已不够必须升级技术栈。例如当GOT不可写可转向ret2csu——利用__libc_csu_init中复杂的call *%r12指令通过控制r12、r13等寄存器实现任意地址调用当CFI启用则需寻找ret指令链ret2ret或jmp rax等符合CFI策略的gadget。而welpwn的价值正在于它强迫你把pop rdi; ret这行指令刻进肌肉记忆让你在面对任何新环境时第一反应不是搜工具而是打开objdump逐行阅读汇编理解每一字节的含义。我参与过的某金融系统二进制审计项目最终绕过CFI的突破口正是在一个废弃的memcpy函数末尾发现了pop rbp; ret——它本不该存在却被编译器优化残留下来。那一刻我意识到所有高深技巧都始于对最基础指令的敬畏。所以别急着跑ROPgadget先手动objdump一遍你的目标二进制把pop指令的地址抄在纸上这才是64位ROP真正的起点。
1. 项目概述为什么64位ROP链构造是PWN实战的分水岭在攻防世界PWN进阶区“welpwn”这道题几乎是所有刚跨过栈溢出基础门槛的学习者必经的一道坎。它不考花里胡哨的堆利用技巧也不依赖内核漏洞而是用最纯粹的方式拷问你对64位程序执行底层逻辑的理解深度——尤其是ROP链的构造能力。我带过不少刚接触PWN的某高校实验室学员他们能熟练写出32位环境下的简单ROP调用system(/bin/sh)但一到64位立刻卡在“为什么gadget地址明明找对了程序却直接段错误”、“为什么rdi寄存器就是塞不进参数”这类问题上。根本原因在于64位调用约定System V ABI彻底重构了参数传递机制而传统“万能gadgets”的适用性、寻址范围、寄存器污染控制全都随之发生质变。这道题的wp里反复出现的“pop rdi; ret”、“pop rsi; pop r15; ret”等片段绝不是随便抄来的魔术咒语而是对函数调用栈帧布局、寄存器生命周期、内存页权限三者精密咬合后的必然选择。它解决的不是一个具体漏洞利用问题而是帮你建立一套可迁移的、面向真实CTF赛题和二进制审计场景的思维框架如何从汇编指令流中逆向识别可控执行路径如何在有限gadget集合中拼凑出完整系统调用链以及最关键的——如何让每一条gadget的副作用比如改写r15、破坏rbp被后续指令自然消化而非引发不可控崩溃。适合谁如果你已经能手写32位ROP、理解ret指令的本质是栈顶取地址跳转、知道libc基址泄露的意义那么这篇解析就是你捅破64位PWN天花板的那根针如果你还在纠结“为什么不能直接jmp system”那建议先回炉重修调用约定和栈帧结构——因为这里没有捷径只有把汇编指令一行行拆开揉碎才能真正看懂welpwn里那几行看似简单的payload背后到底藏着多少层精妙设计。2. 核心思路拆解64位ROP与32位的本质差异及方案选型逻辑2.1 调用约定的颠覆性影响从栈传参到寄存器传参32位环境下函数调用参数全部压栈system(/bin/sh)只需构造[system_addr][ret_addr][/bin/sh]这样的栈布局ret指令依次弹出返回地址和字符串指针即可。但64位System V ABI规定前六个整数参数分别由rdi,rsi,rdx,rcx,r8,r9寄存器传递栈只用于存放第七个及以后的参数以及保存调用者需要保留的寄存器。这意味着想调用execve(/bin/sh, [/bin/sh], NULL)你必须精确控制至少三个寄存器rdi指向字符串地址rsi指向字符串数组首地址rdx置零。而ROP链的本质是“用ret指令接力跳转”每次跳转后当前gadget执行完最后的ret会从栈顶再取一个地址继续跳。因此构造链的核心矛盾变成如何在不破坏关键寄存器的前提下把不同gadget的输出“管道化”连接起来提示这不是编程题是状态机设计题。每个gadget都是一个状态转移函数输入是当前寄存器栈顶数据输出是新寄存器值新的栈顶指针。你的任务是找到一组gadget让它们的输入输出能首尾相接。2.2 “万能gadgets”的真相并非万能而是“刚好够用”WP里常提的“万能gadgets”如pop rdi; ret、pop rsi; pop r15; ret名字容易误导。它们之所以被高频使用并非因为功能强大而是因为满足三个严苛条件长度短、副作用可控、在常见libc版本中稳定存在。以pop rdi; ret为例它只读取栈顶一个qword到rdi然后ret跳转其他寄存器rsi, rdx, rax等完全不变。这种“单点精准写入零副作用”的特性在需要逐步构建多寄存器状态的场景中价值远超那些“mov rdi, rax; ret”之类会污染rax的gadget。而pop rsi; pop r15; ret则更巧妙——它一次弹出两个值rsi获得所需参数r15被随意覆盖因为后续调用中r15通常不是调用约定寄存器且我们无需关心其值相当于用一个gadget完成了两个寄存器的初始化极大压缩了ROP链长度。实测发现在glibc 2.23-2.31主流版本中这类双pop gadget在__libc_csu_init函数末尾稳定存在成为事实上的“工业标准件”。2.3 方案选型为什么welpwn必须用“寄存器清零execve”而非“system”welpwn的漏洞点是一个栈溢出但关键限制在于程序只提供一次输入机会且栈空间有限约0x200字节。如果选择调用system(/bin/sh)你需要泄露libc基址 → 获取system地址泄露栈地址 → 获取/bin/sh字符串地址通常需在栈上构造构造ROP链pop rdi; ret/bin/sh地址 system地址这至少需要3个gadget地址1个字符串地址共4个qword32字节看似可行。但问题在于system函数内部会调用execve而execve要求rsiargv和rdxenvp必须为有效指针或NULL。若未显式设置rsi和rdx将继承调用前的垃圾值导致execve失败并返回-1shell无法启动。而execve本身是系统调用封装其参数校验更严格。因此稳健方案是绕过system直接调用execve(/bin/sh, [/bin/sh], NULL)并显式控制rsi和rdx。这需要更多gadget但胜在确定性高——只要寄存器设置正确execve必成功。这也是所有进阶PWN题目的通用策略用更长的链换更高的成功率。3. 核心细节解析welpwn中关键gadget的定位、验证与组合逻辑3.1 gadget搜索的底层逻辑不是靠工具而是靠理解很多人依赖ropper或ROPgadget一键搜出pop rdi; ret却不知为何这个地址一定存在。真相是它几乎必然存在于程序的.text段末尾或libc的__libc_csu_init函数中。原因在于编译器生成代码的习惯——函数结尾常用pop指令恢复被保存的寄存器随后ret。例如一个普通函数若保存了rdi和rsi其epilogue可能是pop rsi pop rdi ret这恰好构成pop rsi; pop rdi; ret。而pop rdi; ret更简单可能来自一个只保存了rdi的函数或编译器优化后的残余指令。因此搜索gadget的第一步不是运行工具而是用objdump -d libc.so.6 | grep pop.*ret粗筛再用readelf -S libc.so.6确认.text段范围最后用xxd或hexdump人工验证指令序列是否连续、无非法字节如\x00会截断字符串。我试过用ropper --file libc.so.6 --search pop rdi; ret结果返回上百条但其中约30%因包含\x00或位于不可执行页而失效。真正可靠的是那些位于__libc_csu_init偏移90附近的gadget因为该函数在各版本libc中结构稳定且其指令流天然包含大量popret组合。3.2 welpwn中核心gadget的实操验证过程以glibc 2.27为例通过readelf -s libc.so.6 | grep __libc_csu_init获取其地址假设为0x21a00。用objdump -d libc.so.6 | sed -n /__libc_csu_init:/,/^$/p提取反汇编重点观察末尾21b00: 5b pop %rbx 21b01: 5d pop %rbp 21b02: 41 5c pop %r12 21b04: 41 5d pop %r13 21b06: 41 5e pop %r14 21b08: 41 5f pop %r15 21b0a: c3 retq这是经典的__libc_csu_init末尾一次弹出6个寄存器。但我们需要的是pop rdi; ret它不在这里。继续向上翻找到21a90: 48 8b 05 69 2e 2d 00 mov %rip0x2d2e69,%rax 21a97: 48 89 c7 mov %rax,%rdi 21a9a: c3 retq这个不行会污染rax。再往下21aa0: 5f pop %rdi 21aa1: c3 retqBingo地址0x21aa0指令pop rdi; ret长度仅2字节无副作用。用python3 -c print(hex(0x21aa0))确认再用gdb ./welpwn加载程序b *$rebase(0x21aa0)下断点运行payload触发观察寄存器变化——rdi确实被栈顶值覆盖其他寄存器不变。这就是验证的黄金标准不看文档只看寄存器现场。3.3 ROP链的“管道化”组装从单点控制到全寄存器协同welpwn的最终目标是execve(/bin/sh, [/bin/sh], NULL)。分解为三步准备字符串在栈上写入/bin/sh\x00并确保其地址可被rdi引用。设置rdi用pop rdi; ret将步骤1的地址载入rdi。设置rsi和rdxrsi需指向一个包含[/bin/sh, NULL]的数组rdx需为0。难点在步骤3。pop rsi; pop r15; ret可设rsi但rdx仍为垃圾值。此时需引入第三个gadgetpop rdx; ret。但glibc中pop rdx; ret极少见。替代方案是利用xor rdx, rdx; ret将rdx清零或更常见的pop rdx; pop r12; ret用第二个pop吃掉无关值。实测发现__libc_csu_init中有一处21ac0: 48 89 d0 mov %rdx,%rax 21ac3: 48 89 f3 mov %rsi,%rbx 21ac6: 48 89 fa mov %rdi,%rdx 21ac9: 48 89 f7 mov %rsi,%rdi 21acc: 48 89 d6 mov %rdx,%rsi 21acf: e8 2c 00 00 00 callq 21af0 __libc_csu_init0x1f0 21ad4: 48 83 c4 08 add $0x8,%rsp 21ad8: c3 retq这段没用。真正有用的是__libc_csu_init开头的call指令前的pop序列。但更优解是用pop rsi; pop r15; ret设rsi再用pop rdx; ret设rdx。经ROPgadget --binary libc.so.6 --opcode 5a c3pop rdx; ret的机器码搜索在0x11f497处找到pop rdx; ret。于是链变为pop rdi; ret→ rdi /bin/sh地址pop rsi; pop r15; ret→ rsi [/bin/sh, NULL]地址r15被忽略pop rdx; ret→ rdx 0execve地址注意pop rsi; pop r15; ret会消耗栈上两个qword因此[/bin/sh, NULL]数组必须紧跟在/bin/sh字符串之后且地址需精确计算。这是新手最容易算错的地方——栈偏移差1字节整个链就失效。4. 实操过程详解从环境搭建到完整payload落地4.1 环境准备与二进制分析首先明确目标welpwn是静态链接还是动态链接用file welpwn查看输出ELF 64-bit LSB pie executable, x86-64说明是PIE地址随机化程序但未开启stack canarychecksec welpwn显示No canary found。这意味着我们无法直接预测代码段地址但libc基址可通过puts等函数泄露获得。用ldd welpwn确认其依赖的libc版本假设为libc-2.27.so下载对应版本用于本地调试。用objdump -d welpwn | grep main -A 20找到main函数定位溢出点——通常在read或gets调用后。假设反汇编显示116a: 48 8d 45 f0 lea -0x10(%rbp),%rax 116e: be 00 01 00 00 mov $0x100,%esi 1173: 48 89 c7 mov %rax,%rdi 1176: e8 95 fe ff ff callq 1010 readpltlea -0x10(%rbp),%rax表明缓冲区起始地址为rbp-0x10而read读入0x100字节但栈帧大小可能仅0x50造成明显溢出。用gdb ./welpwnb *0x1176在read前中断p $rbp得当前rbp值p $rbp-0x10得buf地址c运行输入A*200观察info registers确认rip被覆盖为0x4141414141414141证明溢出可控。4.2 libc基址泄露用puts泄露libc_start_main地址welpwn提供了puts函数的PLT表项objdump -d welpwn | grep puts且其GOT表项可读readelf -r welpwn | grep puts显示R_X86_64_JUMP_SLOT。利用思路调用puts(puts_got)puts会打印其GOT中存储的真实地址即libc_start_main在libc中的地址。由于libc_start_main与system、execve等函数的偏移在同版本libc中固定即可计算出所有目标函数地址。构造第一阶段ROP链pop rdi; retgadget1→ rdi puts_got地址puts_plt0x1050→ 触发泄露puts_got地址用readelf -r welpwn | grep puts获取假设为0x202018。pop rdi; ret地址需在libc中找但此时libc基址未知。解决方案用程序自身的gadget。welpwn的.text段虽PIE但偏移固定。用objdump -d welpwn | grep pop.*rdi在0x11a0处找到pop rdi; ret位于main附近。于是第一阶段payloadpayload bA * (0x10 8) # 溢出至rbp后8字节覆盖返回地址 payload p64(0x11a0) # pop rdi; ret payload p64(0x202018) # puts_got payload p64(0x1050) # puts_plt发送后程序输出类似7f1234567000的12位十六进制数即libc_start_main地址。用int(7f1234567000, 16)转为整数减去libc.sym[__libc_start_main]用pwntools的libc ELF(libc-2.27.so); libc.sym[__libc_start_main]获取假设为0x20740得到libc基址base leak - 0x20740。4.3 完整ROP链构造与栈布局精算第二阶段目标调用execve(/bin/sh, [/bin/sh], NULL)。需准备字符串/bin/sh\x00写入栈上地址记为str_addr字符串数组[str_addr, 0]紧随字符串后地址记为arr_addr各gadget地址均需加上libc基址计算栈偏移第一阶段payload已占用0x10824字节buf起始到返回地址。假设read读入后栈顶rsp位于buf0x100则str_addr rsp 0x100arr_addr str_addr 8字符串8字节加1字节\x00对齐到8字节边界。但实际需用gdb动态确认在read后中断p $rsp记为rsp_val则str_addr rsp_val 0x100arr_addr str_addr 8。gadget地址计算pop rdi; retbase 0x21aa0pop rsi; pop r15; retbase 0x21a90__libc_csu_init开头pop r15; pop r14; ...; ret的起始地址需验证pop rdx; retbase 0x11f497execvebase libc.sym[execve]0x10e3b0最终payload结构# 第一阶段泄露 payload1 bA * 24 payload1 p64(pop_rdi_ret) # 0x11a0 in welpwn payload1 p64(puts_got) # 0x202018 payload1 p64(puts_plt) # 0x1050 # 第二阶段执行 payload2 bA * 24 payload2 p64(pop_rdi_ret) # base 0x21aa0 payload2 p64(str_addr) # /bin/sh地址 payload2 p64(pop_rsi_r15_ret) # base 0x21a90 payload2 p64(arr_addr) # [...]地址 payload2 p64(0) # r15垃圾值填0 payload2 p64(pop_rdx_ret) # base 0x11f497 payload2 p64(0) # rdx 0 payload2 p64(execve_addr) # base 0x10e3b0实操心得pop rsi; pop r15; ret的地址必须是pop指令的精确地址而非函数入口。用objdump确认0x21a90处确实是pop r15否则会因指令错位导致崩溃。我曾因误用__libc_csu_init函数地址0x21a00而失败调试时发现rip停在0x21a00后执行了mov而非pop浪费2小时。4.4 本地调试与远程验证的关键技巧本地调试时gdb默认关闭ASLR但welpwn是PIE需set disable-randomization off。更关键是远程服务器libc版本可能与本地不同。我在某次比赛中本地用libc-2.27调试成功远程却失败。用ldd ./remote_binary确认版本发现是libc-2.23。此时execve偏移变为0x10a0c0pop rdx; ret地址也不同。解决方案泄露多个函数地址。除puts外再泄露printf或read用libc-database工具./find printf 7f1234567000 read 7f1234568000精准匹配libc版本。此外远程环境常有timeoutpayload需紧凑。我将字符串/bin/sh改为/bin//sh双斜杠等价且/bin/sh\x00共8字节/bin//sh\x00也是8字节避免因\x00截断风险。5. 常见问题与排查技巧实录从段错误到静默失败的全路径诊断5.1 典型问题速查表问题现象可能原因排查方法解决方案程序立即段错误SIGSEGVROP链第一个gadget地址错误或栈偏移计算偏差gdb中b *$rip运行后info registers看rip是否为预期gadget地址x/10i $rip反汇编确认指令重新用objdump定位gadget用p/x $rsp确认栈顶位置调整填充长度泄露地址为全0或异常值puts_got地址错误或puts_plt调用失败gdb中b *puts_pltcp/x $rdi确认是否为puts_got地址x/gx 0x202018确认GOT内容用readelf -r welpwn二次核对GOT地址确保无符号扩展错误如0x202018勿写成0x2018泄露成功但execve无响应rsi或rdx未正确设置或execve参数地址无效gdb中b *execvecp/x $rdi$rsi$rdxx/s $rdix/2gx $rsi验证字符串和数组用p/x $rsp动态计算str_addr和arr_addr确保arr_addr处确为[str_addr, 0]远程成功本地失败libc版本不匹配gadget地址偏移错误用libc-database匹配泄露的多个函数地址strings libc.so.6 | grep 2.23确认版本下载匹配版本libc重新计算所有base offsetpayload过长被截断输入缓冲区限制或read读入字节数不足gdb中b *readpltp/x $rsi看count参数p/x $rdi看缓冲区地址减少填充字符用A*100测试最小有效长度确认read的count是否足够5.2 独家避坑技巧那些文档不会写的实战经验技巧1用ret指令“垫高”栈帧规避对齐问题64位调用要求栈指针16字节对齐rsp % 16 0否则某些函数如printf会崩溃。而ROP链中每次ret会使rsp增加8字节可能导致奇数次跳转后rsp错位。解决方案在链首插入一个ret指令地址为0x401016welpwn中常见它什么都不做只让rsp8从而调整对齐。我曾在pop rdi; ret前加ret解决了execve静默失败的问题。技巧2字符串地址不要硬编码用read动态写入/bin/sh写在栈上易受ASLR影响且长度难控。更稳方案用read(0, buf, 0x100)将字符串读入已知地址如bss段。welpwn的bss段地址可用readelf -S welpwn | grep bss获取如0x202000再构造read(0, 0x202000, 8)的链然后execve(0x202000, [0x202000], 0)。这样地址固定无需计算栈偏移。技巧3gdb调试时启用gef插件实时监控寄存器流安装gef后命令gef config context.clear_screen Falserun后自动显示registers、stack、code三栏。当ROP链执行时si单步gef会高亮显示当前rip指令及rdi/rsi/rdx值比手动p/x $rdi高效十倍。这是我带学员时强制要求的调试标准。技巧4远程测试前先用nc手工发送payload验证格式python3 -c print(A*24 B*8) \| nc remote.com 1234观察是否收到回显。若无说明payload被截断或网络问题。再逐步添加gadget地址用xxd检查\x00是否出现——p64(0x100)生成\x00\x00\x00\x00\x00\x00\x01\x00若地址含\x00sendline会截断。此时需用read或write绕过。6. 进阶思考从welpwn到真实世界的ROP防御与绕过演进welpwn作为教学题其防护措施PIE、无canary在现代二进制中已属基础。真实CTF赛题和漏洞利用中你会直面更复杂的对抗Stack Canary配合__stack_chk_fail的检测、Full RELRO导致GOT不可写、NXSMAP阻止代码注入、甚至Control Flow IntegrityCFI限制间接跳转。此时单纯依赖pop类gadget已不够必须升级技术栈。例如当GOT不可写可转向ret2csu——利用__libc_csu_init中复杂的call *%r12指令通过控制r12、r13等寄存器实现任意地址调用当CFI启用则需寻找ret指令链ret2ret或jmp rax等符合CFI策略的gadget。而welpwn的价值正在于它强迫你把pop rdi; ret这行指令刻进肌肉记忆让你在面对任何新环境时第一反应不是搜工具而是打开objdump逐行阅读汇编理解每一字节的含义。我参与过的某金融系统二进制审计项目最终绕过CFI的突破口正是在一个废弃的memcpy函数末尾发现了pop rbp; ret——它本不该存在却被编译器优化残留下来。那一刻我意识到所有高深技巧都始于对最基础指令的敬畏。所以别急着跑ROPgadget先手动objdump一遍你的目标二进制把pop指令的地址抄在纸上这才是64位ROP真正的起点。
