做CTF的pwn题很多人一看到ROP就条件反射地找system、找“/bin/sh”、找pop rdi满脑子都是怎么一次性getshell。但有一类题目真正卡住你的往往不是最后的shell而是那些不起眼的“边角料”函数。0CTF 2016的warmup就是个典型例子——拿到手第一眼看过去就是个普通栈溢出可真正把exp写到一半才发现能不能把程序里那个不起眼的alarm用明白直接决定了你是十分钟搞定还是卡一整晚。这篇文章就围绕这道题把我对alarm在ROP里几种用法的理解完整拆一遍。alarm这个函数平时没人正眼看它但在特定场景下它比system还好使。适合已经学过栈溢出基础、想提升ROP构造灵活度的朋友也适合那些遇到“本地能通、远程就断”问题但一直找不到原因的人。1. 先从warmup说起一道“看起来人畜无害”的栈溢出题1.1 题目的大致面貌0CTF 2016的warmup从名字就能看出来官方定位是热身级别的送分题。二进制程序本身不大保护开得也比较松至少溢出点非常明显输入缓冲区大小远小于覆盖返回地址所需偏移攻击者能直接控制返回地址把它改成某个函数地址或者构造一段ROP链。这种题平时大家做得太多了流程基本上是固定的先checksec看保护再用IDA看伪代码接着找溢出偏移、找gadget、写exp、一把梭。如果你只是在本地随手打一下可能一次就通了甚至会觉得这题出得毫无诚意。那它凭什么能被大家反复拿出来讨论关键就在“远程”两个字上。本地调试环境里你可以随便下断点、慢慢看栈帧、甚至直接修改寄存器但一接到远程环境你就会发现对方程序在启动阶段给进程挂了一个定时器这种机制在CTF题目里非常常见。定时器一到点SIGALRM信号直接把进程杀掉你的连接就断了。如果不做处理不管你ROP链布置得多完美只要执行总时间超过了这个阈值看到的永远是remote connection closed。这不是warmup独有的问题很多带交互的CTF题目都会用“几秒后自动断开”的方式来限制盲注类攻击。warmup有意思的地方在于它没有绕开这个机制而是让你在构造ROP链时主动去处理它。想明白这一点你才算真正入门了这道题。1.2 新手第一次打这道题会卡在哪我见过不少同学做这道题时的状态本地通了一次然后跑到远程一打发现payload发过去之后对面要么没回显要么直接断连。于是开始怀疑是不是offset算错了、是不是栈没对齐、是不是system地址在远程和本地不一样。排查了半天把能怀疑的地方全怀疑了一遍其实问题根本不在这。远程环境里最常见的情况是程序初始化阶段调用了alarm并设置了一个倒计时意味着从进程启动那一刻起到你ROP链完成所有操作总时间不能超过这个数。如果你的利用流程需要先栈迁移、再调read、再回到第二段ROP链一次交互要打好几个来回那必然超时被杀。这类问题有个典型特征本地怎么调都是好的一上远程就“超时”而且没有core文件可以分析。因为它不是crash是被信号杀掉的。很多pwn新手对这个现象完全没有概念因为本地调试根本不会触发这个分支。这就像是你考试时题目都会做但交卷铃一响就被拖走你连答题卡都来不及涂。所以要习惯一个视角exp不只是在“构造一次栈溢出”而是在“和程序的运行机制进行一场带时限的谈判”。alarm这种平时被忽略的函数恰恰是谈判桌上最好用的筹码。2. alarm在ROP里的第一重妙用单参数函数的“低配置”优势2.1 x64调用约定下一个参数意味着什么x64 Linux下函数调用的前六个整型参数分别放在rdi、rsi、rdx、rcx、r8、r9。ROP的核心难点之一就是你在控制返回地址的前提下还得把这几个寄存器设置成你想传的值。假设目标函数是system想执行system(“/bin/sh”)只需要rdi一个参数但“/bin/sh”这个字符串的地址你得先找到如果是execve(“/bin/sh”, 0, 0)那就需要rdi、rsi、rdx三个参数链子至少要找三组pop gadget再加上函数调用点。每多一个参数就多一组约束。在gadget数量有限的小程序里这往往就是把人逼疯的地方。而alarm的签名是unsigned int alarm(unsigned int seconds)只有一个参数。这意味着构造一次alarm调用只需要一个pop rdi; ret甚至在某些特殊布局下可以直接复用已有的rdi内容。相比execve、system这些“高配”目标alarm是真正的“低配”函数对寄存器的要求极低。这种低配置特性在ROP里非常有价值。很多时候你并不需要一个能直接getshell的函数你只是需要“某个函数被调用一次并且最好别产生坏影响”。alarm恰好满足调用它传一个数字然后正常返回不会产生什么结构性副作用。2.2 几个常见目标的寄存器开销对比我整理一下几个在ROP里经常出现的目标函数的寄存器开销方便直观感受alarm到底有多“省”目标函数参数数量需要预先控制的寄存器典型用途alarm1rdi设置/取消定时器sleep1rdi挂起当前进程usleep1rdi微秒级挂起system1rdi执行命令open3rdi、rsi、rdx打开文件read3rdi、rsi、rdx读数据write3rdi、rsi、rdx写数据execve3rdi、rsi、rdx执行新程序从这个表可以看得很清楚单参数函数在ROP里属于“最低门槛”的一档。如果要构造多次连续调用每多一个多参数函数payload长度和gadget匹配难度都会大幅上升。所以当你的目标只是“调一个函数、增加一个步骤”时优先选单参数函数是更省力的方案。2.3 何时拿alarm当“过渡拼图”在实际构造ROP链时有一种情况经常遇到中间某个环节需要消耗两三个gadget才能把寄存器调整到下一个调用需要的状态但你又不想让整条链子长度失控。这时alarm可以当“无害过渡函数”用。具体来说最常用的过渡场景就是栈对齐。x64的ret2libc里如果你直接调用system有时会遇到movaps指令导致的段错误原因是栈指针没有16字节对齐。解决办法通常是在调用system前加一次ret。如果程序里找不到单独的ret gadget那么alarm的调用本质上也能充当一次return。因为alarm正常返回后会走下一条链它的PLT地址在这个场景里能起到“额外ret”的等价效果。当然前提是alarm调用不会破坏你已经设置好的关键参数。另一个很实用的场景是调试定位。当你拿不准ROP链到底执行到了哪一步可以在某个关键节点放一个alarm(1)然后观察远程是否在1秒后出现断连。如果断了说明执行流确实走到了这一节点如果完全没反应那问题出在更早的地方。这种“探针式调试法”在处理复杂链条时极其好用比gdb在远程环境里可靠得多。3. alarm在ROP里的第二重妙用时间侧信道与超时免死金牌3.1 ROP链太长alarm(0)取消定时器alarm(0)是一个特殊调用取消当前进程的定时器让先前设定的SIGALRM不再触发。这个用法在ROP里堪称“免死金牌”。如果题目在程序初始化时设了一个几十秒的定时器你的完整利用链又特别长包含多次read、多次栈迁移甚至还有盲注循环那第一时间在ROP链开头调一次alarm(0)把定时器彻底关掉后面所有操作就都不再受时间约束。这里有个容易忽略的细节alarm(0)本身也是alarm也需要rdi 0。如果你已有的gadget能让rdi变成0那这条链的构造难度很低。而且alarm(0)的行为是“取消定时器”不是“重置定时器”所以之后不会再收到那个信号。如果你的目标是“重新开始计时”那得先alarm(0)再alarm(N)分两次调用才能实现。在CTF题目里最常见的还是“alarm到点杀进程”这种设计。遇到这种情况alarm(0)就是最直接有效的解法。很多远程环境不稳定的题加一个alarm(0)之后立刻稳定原因就在这里。3.2 无回显盲注时alarm当节拍器另一种妙用是“时间侧信道”。什么叫盲注就是在完全没有回显的情况下通过某种手段逐位推断内存中的内容。经典做法是拿地址是否满足某个比较条件来控制程序走不同分支再用“是否收到回显”来区分结果。但如果连回显都没有那就只能用“程序是否超时被杀”来传递信息。思路是这样的如果目标地址的某个字节等于猜测值就调用alarm(0)或alarm(1)如果不等就什么都不做让程序进入死循环或者自然超时。攻击者通过观察连接是“继续保持”还是“被断开”就能确认这一位的值。alarm在这里充当的是一台节拍器它把“猜测正确”这个布尔信息编码成了“进程能活多久”这个时间信息。这种技巧在沙箱题、无输出题的本地盲打里非常实用。我自己在做没有输出函数的题目时经常先用alarm搭一个时间侧信道验证思路确认程序执行流能到某个关键点再去考虑更精细的泄露手段。当然时间侧信道对网络稳定性有要求远程延迟抖动大的话需要多次测量取均值这是实战里必须接受的成本。3.3 返回值里的信息通道很多人没注意到alarm的返回值是“上一次定时器的剩余秒数”。如果上一次设的是alarm(30)过了5秒后调alarm(0)返回值就是25。这个返回值本身可能携带一点时间信息。在极少数场景下ROP链可以利用这个返回值判断自己在调用链中的位置是否正确。比如有一段逻辑依赖alarm的返回值做分支选择那alarm的返回值就成了一个可利用的条件开关。这不算特别通用的技巧但它提醒我们一个思维模式在ROP里任何一个函数的返回值都可能是可利用的信息通道。不要只盯着系统调用和输入输出函数看真正在赛场上拉开差距的往往就是把这种“边角料”用出花的能力。4. 第三重妙用在沙箱与连环调用中当“垫场函数”4.1 沙箱题目里ROP链的连锁调用结构开了沙箱的CTF题是现在的主流不能用execve直接弹shell只能open/read/write一路把flag读出来。这种利用结构在ROP里就变成了一个“连环调用链”先open再read再write。每一步三个参数每次都要重新设置rdi、rsi、rdx。链条越长中间可用的寄存器状态就越紧张。连环调用链里最怕的就是“某一小段gadget断了”。比如你已经凑齐了pop rdi、pop rsi、pop rdx但它们的排列顺序导致中间需要多余的一次ret来调整栈指针。这时候你会特别希望有一个无害的函数能垫一下让布局更从容。alarm正好满足行为无害、单参数、地址基本肯定存在于程序中因为程序初始化大概率会调它而且不依赖具体libc版本。4.2 alarm在关键节点起到的“垫场”作用在ROP链中gadget的拼接本质上是“寄存器状态机”。每一步都在变换寄存器内容最终在目标函数处让所有需要的寄存器恰好到达期望值。alarm作为一个函数调用本身不额外读内存参数行为可预期所以可以在你“已经设置好关键参数但还需要一个调用点让程序往前走”的时候充当垫场。举个例子当你利用栈迁移把一个新栈写到堆上需要立刻验证当前栈布局是否正确时先放一个alarm(1)试试水如果1秒后程序被杀说明你的栈迁移成功了如果一点动静都没有说明链子根本没执行到这个地方。这种用法在复杂的沙箱题里特别有用因为这类题目往往链长、节点多一步错步步错没有快速定位手段会非常痛苦。alarm作为“垫场函数”的另一个优势是不产生额外的内存副作用。相比之下如果你拿read来垫场会真的读入数据并修改缓冲区内容拿system来垫场会真的执行命令。只有alarm这种“设个定时器就走”的函数才真正配得上“无害过渡”四个字。4.3 从单次利用到多次交互的攻击链设计当题目需要多次输入交互时比如第一次输入触发一段ROP第二次输入触发另一段ROP中间的时序就很重要。alarm可以用来给两次交互之间留出稳定时间窗口或者干脆在第一轮就把超时机制取消掉让后面几轮利用不受干扰。这算是我自己在做复杂题目时的习惯凡是远程有超时限制的题目只要我计划做两次以上的交互第一轮payload里就一定带一个alarm(0)。先把这个变数消灭后面的流程再慢慢调。因为一旦定时器还挂着你调试时每次都要跟时间赛跑浪费大量精力在“快一点、再快一点”上根本没心思分析漏洞。另外如果你在构造攻击链时发现步骤太多一次交互放不下所有ROP片段可以考虑把攻击拆成多段第一段先alarm(0)解除超时再调用read把第二段ROP链读入某个可执行或者已知地址第二段才慢慢做真正的数据泄露。这种“两次交互”的模型在CTF里非常常见alarm(0)就是第一段提稳定性的核心保证。5. 完整攻击链复盘0CTF_2016_warmup的思路还原5.1 从溢出点到可控寄存器的路径0CTF_2016_warmup这道题第一步自然是找溢出偏移。一般用cyclic pattern就能确定覆盖返回地址需要多少字节。找到偏移后控制rip是很容易的事情难点在于如何规划rip之后的执行流。如果你把checksec结果打出来发现程序没有开太多保护顶多是栈不可执行或者NX开启那么直接用ROP是主流选择。题目里肯定有alarm的PLT这就给了我们前面说的各种玩法。要注意的是我不打算贴具体地址值因为不同版本题目加载基址和环境可能不同。实际做的时候用objdump或IDA找到alarm的PLT地址用ROPgadget找到pop rdi; ret和其他需要的小片段按照当时的题目环境动态计算即可。这也是做CTF的基本素养不要死记硬背writeup里的地址要理解每一步在做什么。5.2 如何把alarm塞进ROP链而不打乱布局对于这道题最有效的做法是在ROP链开头插入一段pop rdi; retrdi设为0然后跳alarm的PLT。这样做就是取消程序初始化时设置的那个定时器。后面再接上你的system或open/read/write链整个payload就稳了。关键点是这个过程不需要额外找新的gadget你本来构造system链就需要pop rdi; ret现在只是多用一个pop指令和alarm的PLT地址payload长度增加8字节左右。成本极低收益却很大。有些writeup还会稍微改动不调用alarm(0)而是把rdi设成一个比较大的秒数比如alarm(60)。区别在于alarm(60)是“重置定时器为60秒”alarm(0)是“取消定时器”。在大多数题目里两者都能用但我个人更推荐alarm(0)因为它更干净不给后续执行留任何定时器隐患。如果你的题目环境后续还有别的逻辑依赖定时器那就得看具体场景再选择。5.3 本地调试与远程环境之间的差异坑这道题最典型的一个坑就是本地和远程行为不一致。本地你爱怎么调都行远程却经常在payload执行到一半时断连。以前我遇到这种情况会反复检查payload长度和gadget选择浪费了很多时间。后来养成了习惯遇到远程断连第一时间排查定时器问题。验证方法很简单在本地用strace或gdb确认程序启动时有没有调用alarm或者用objdump/IDA检查初始化代码里有没有对alarm的引用。如果有那远程断开大概率就是它搞的鬼直接在ROP链里加一个alarm(0)即可。如果没有定时器再去排查别的因素。另一个坑是alarm在PLT里存在但如果程序只调用过一次alarm而且开启了某些编译优化PLT表项可能存在但间接跳转目标需要额外解析。这种情况下直接跳PLT可能出问题稳妥做法是先利用puts或write泄露libc基址再用libc里的alarm真实地址。在warmup这种简单题目里一般不用走这一步但一旦遇到你要知道有这个可能性。6. 实战之后选gadget时的几条判断标准6.1 优先“一个函数解决”其次“少参数函数过渡”自己在赛场上总结下来的判断顺序第一看能不能用一个函数直接搞定目标比如有后门就优先后门第二如果没有现成后门再看单参数函数能不能至少帮你完成一个中间步骤第三实在不行才去选execve这类需要三四个参数的“全家桶”。alarm就属于“单参数中间步骤”那一档里最常出现的选手。它不像sleep在CTF环境里有时会让人担心卡住执行流也不像usleep的参数单位容易搞错。虽然sleep也是单参数但sleep会真的挂起进程alarm则只是设置一个信号不会阻塞执行流。在ROP里这一点区别很大——alarm调用完可以立刻继续执行后面的链子而sleep会卡住进程导致后续ROP没法继续。所以选“过渡函数”时alarm的优先级通常远高于sleep。6.2 alarm vs sleep vs usleep的选型对比这三兄弟都是一参数“延时”函数但用途天差地别函数行为ROP场景下的适用性alarm设置SIGALRM定时器到点发信号不阻塞执行高可用于取消定时器、时间侧信道、过渡垫场sleep挂起当前进程直到时间结束低会阻塞执行流不适合放在ROP链中间usleep微秒级挂起低参数单位容易混淆同样会阻塞执行流我见过一个特别容易犯的错把alarm当成sleep用。alarm(5)之后程序并不会睡5秒它只是5秒后发一个信号。如果你以为程序会先等5秒再继续那对整个执行流的理解就偏了。在ROP场景里alarm设置完立刻返回后续链子继续跑。这个差异必须记牢否则会把payload的时序完全搞乱。6.3 我踩过的几个坑和习惯性做法踩坑1以为alarm(0)会重置现有定时器而不是取消。实际上POSIX标准里alarm(0)就是取消。如果你希望“重新计时”需要先alarm(0)再alarm(N)不能在一次调用里完成“从剩余时间重新开始算”。踩坑2忘记alarm的PLT解析问题。在部分题目里PLT表项不是马上就可用如果libc地址没加载直接跳PLT的alarm可能触发错误。稳妥做法是先利用puts或write泄露libc基址再跳真实地址。踩坑3时间侧信道盲注里alarm的信号会被某些环境的安全机制吃掉。如果远程环境有seccomp或者信号过滤alarm不一定能可靠触发SIGALRM。要提前用小流量测试一下alarm到底灵不灵别等盲注打到一半才发现判断条件全部失灵。习惯性做法我拿到一个新题目会先扫一遍程序里有没有alarm/read/write这类“教学友好型”函数。只要程序初始化里带alarm我就默认这个题目在远程大概率有超时限制于是ROP链里默认加上alarm(0)。这个习惯帮我省了很多调试时间也让我遇到“本地通远程断”的问题时能第一时间定位。最后再分享一个小技巧如果你在构造ROP链时发现某个节点怎么调试都过不去别急着重写全部payload先在这个节点之前加一个alarm(1)。观察程序是否在1秒后被杀就能判断你的执行流到底走到哪一步了。这个小“探针”比什么都好用。alarm在ROP里的价值往往就是在这些最不起眼的地方体现出来的。