0x00：查看文件信息

該文件是32位的，canary和PIE保護機制沒開。

0x01：用IDA進行靜態(tài)分析

總覽：

該函數(shù)就是：v5初值為1，對v2輸入一串字符。然后執(zhí)行一個會根據(jù)輸入的字符串而修改v5的循環(huán)語句，最后調(diào)用相應(yīng)的函數(shù)。

同時，發(fā)現(xiàn)文件里面已經(jīng)含有cat flag的函數(shù)：

函數(shù)snprintf介紹：
printf("cat %s", "./flag")是將cat ./flag輸出到屏幕上。
snprintf(s, 0x32, "cat %s", "./flag")是最多將后面的字符串("cat ./flag")輸入0x32個到變量s上。

       所以，我們要想辦法去執(zhí)行這個cat_flag函數(shù)。現(xiàn)在我們已知的漏洞點是scanf對v2輸出存在溢出。再根據(jù)程序的第3行到第8行中變量的聲明可了解到v2可以溢出覆蓋數(shù)組v3、數(shù)組s、變量v5甚至是所在棧幀的返回地址。

       一個常規(guī)的解法是覆蓋v3[0]為cat_flag函數(shù)的地址值，然后進一步想辦法使執(zhí)行循環(huán)后，v5的值為1。這樣在最后就會調(diào)用v3[--1]指向的函數(shù)，即get_flag函數(shù)。

v5的初值為1，所以在switch中為case 1。其條件判斷為：

因為v5本來就是1，所以我們只要保持不變就好了，即return false。根據(jù)短路原理，只要字符串均為A(ascii=65 < 96)就行了。

0x02：編寫exp

from pwn import *
context(os='linux', arch='i386', log_level='debug')

io = process("./forgot")
#io = gdb.debug("./forgot",'b *0x08048A5D')
#io = remote("111.200.241.244",58065)

get_flag = 0x080486CC
payload = b'A'*0x20 + p32(get_flag)

io.sendline("tolele")
io.recv()
io.sendline(payload)
io.recv()
io.interactive()

可以成功cat到flag。

0x03：回顧再分析

因為v2定義的數(shù)組大小是32個元素，所以我們還需要考慮的問題是：

• 當對v2進行溢出式的賦值后，strlen(v2)會等于多少呢？
• 如果strlen(v2)的值大于或等于32，程序中對數(shù)組v2的訪問豈不是越界了么？

解決問題：

我們可以對strlen函數(shù)的源代碼進行分析：

strlen.c source code [glibc/string/strlen.c] - Woboq Code Browser

對該源代碼分析的博客：

c語言庫函數(shù)strlen源碼實現(xiàn)_風雨也從容的博客-CSDN博客_c語言strlen源代碼

簡而言之，strlen(const char* str)的返回值就是，從首字節(jié)開始從1往上計數(shù)，到'\x00'停止，且不算入'\x00'。

（注：以下內(nèi)容僅是個人想法，請保留質(zhì)疑！）

       既然這樣，那么payload = b'A'*0x20 + p32(get_flag)豈不是會遠遠大于32（數(shù)組v3中均沒有出現(xiàn)'\x00'字節(jié)），這樣對數(shù)組的訪問不會報錯嗎？

       其實，我們平時遇到的數(shù)組訪問越界是由于在集成開發(fā)環(huán)境（vs,vc…）中會進行檢測。但實際上源代碼中是沒有檢測機制的，linux中就是直接對動態(tài)庫進行鏈接，相當于是直接使用了源代碼。所以，在linux上并不會出現(xiàn)報錯。

        同樣，數(shù)組索引的本質(zhì)實現(xiàn)是基于匯編語言，相當于就是*(v2+i)。在linux中并不會進行越界檢測。

實驗一下：

我們對c2進行字符串輸入后，會自動在字符串末尾添加個'\x00'。即上面實驗中c3[14]被賦值了'\x00'。同時，由于get_flag = 0x080486CC，ascii碼值均小于96，所以v5不會被改變。

所以，問題也就差不多解決了。

0x04：其他思路的分析

其實在最開始時，我們?nèi)绻吹搅藯Ｒ绯龊?span id="w0obha2h00" class="ne-text">get_flag函數(shù)。最先想到的就是直接棧溢出覆蓋main函數(shù)棧幀的返回地址，結(jié)束時直接調(diào)用就好啦~

此時，payload = b'A'*0x78 + b'B'*0x4 + p32(get_flag)

(動態(tài)調(diào)試后發(fā)現(xiàn)是0x78，并不是ida中的0x74)

執(zhí)行后發(fā)現(xiàn)pwn不通，動態(tài)調(diào)試一下：

得知，程序開在了0x08048a61這一步。這不卡住才怪，用eax*4來進行偏移，而eax為0x44444443('CDDD')。

在ida中繼續(xù)對eax值的來源進行調(diào)查：

       對該處按F5查看反匯編代碼，發(fā)現(xiàn)((void (*)(void))v3[--v5])(); 這里的。上一步是將esp + 78h的值賦給了eax，esp + 78h對應(yīng)的變量則是v5。由于我們直接覆蓋到返回地址，所以圖中也把v5給覆蓋了，值還挺大的。早就超了最大空間，所以執(zhí)行不下去了。

0x05：個人嘮叨

        以前在做題過程中遇到問題總喜歡逃避，畢竟這是“解決”問題最輕松的一種方式。在做這道題時，我硬逼著自己去思考能夠解決問題的方法，以及動手去嘗試。一步一步的去解決問題，雖然很慢，但知識學得很實。希望自己能夠繼續(xù)以這種方式面對各種困難。

        最后再反省一下：在第一個思路pwn不通的時候，直接丟個代碼和exp問群里的師傅為啥pwn不通？現(xiàn)在想想這樣去提問還挺不好的，這將會浪費師傅們很多時間去確定問題所在。所以，以后問問題的話，盡量縮小出問題的范圍，或者將問題轉(zhuǎn)換為概念性的提問。

tolele

2022-06-05