6，原版zlib溢出

這個測試需要用到原版winmugen，winmugen最初是官方給捐獻者私有的2人限制版，經過2004年無限制破解，以及2007年的多輪高分辨率破解，得到現(xiàn)在常用的Win Mugen Plus。但還有一種國內流行的星光主程序，其zlib和原版winmugen不一樣，導致zlib溢出沒有那么通殺。我前的文章全部使用星光主程序測試，現(xiàn)在替換成原版winmugen。

https://www.infinitymugenteam.com/infinity.wiki/mediawiki/index.php?title=M.U.G.E.N

zlib溢出常見的是兩個人物模板，一個是五月雨的，一個是遙遠的。

遙遠的血神模板打開比較直接。

但五月雨的就沒那么直接，上調試(換x32dbg了)，根據前人研究，斷點422438

可以看得出來，此時已經完成溢出，422438是棧溢出中覆蓋了ret的地址，和之前Reboot用過的403246一樣是個add esp;ret?？礂？梢钥吹贸鰜?，接下來會跳到ALLEG40.DLL上的10078CEF上。跟進之后發(fā)現(xiàn)就是jmp esp。

跟我們之前用mona找到的1005FB9D(call esp)效果一樣都是棧內執(zhí)行。

血神的則是直接ret到10078D87(也是jmp esp)，血神壓縮文件符合010Editor的zip模板，比較方便我們定位溢出點在哪里，是deFileTime+deFileDate。

同理五月雨模板可以推算出來，他用的溢出點在deCompressedSize上。

接下來主要研究血神，斷點10078D87，在棧上找到一個最近的返回地址418BE1，這個就是離棧溢出比較近的代碼。

其位于sub_418B90()，似乎是個文件讀取函數(shù)，非常像溢出點，斷點下在418BDC(call sub_418A70)上。

418BDC，F(xiàn)8之后完成棧溢出，直接跳到10078D87，那么證實棧溢出確實發(fā)生在sub_418A70()。

那么斷點418A70，一點一點動態(tài)調試，最終搞清楚整個棧溢出流程。從最外層函數(shù)到最內層函數(shù)如下。

兩張圖概括如下。

485D0E rep movsd(qmemcpy)為什么會導致棧溢出呢？rep movsd的意思很簡單，就是從ESI復制內容到EDI上去(復制ECX個字節(jié))。在發(fā)生棧溢出前，也有兩次正常的rep movsd，我們可以看內存變化。

可以清楚的看到92C8120上被改寫了，也就是說它將棧上的值復制到內存中，這也正是qmemcpy()的主要功能。然而在發(fā)生問題的rep movsd上，EDI居然也是棧上的地址，那么就是從棧復制到棧上。

再往前看edi的賦值匯編就會發(fā)現(xiàn)EDI本質上是a2，也就sub_485520()的第二個參數(shù)造成的。

那為什么之前兩次rep movsd沒問題呢？因為它們的調用鏈是這樣的sub_418A70()——sub_485F00()——sub_485520()，結構圖如下。

只有sub_4854E0()，將棧上的v6當成第二個參數(shù)傳入，導致了最后棧溢出的發(fā)生。

?

如何從零制作zlib溢出包呢？根據遙遠的提示，他是將正常人物包進行僅存儲的壓縮模式，然后發(fā)現(xiàn)mugen崩潰發(fā)現(xiàn)的。看血神模板也可以看得出來，整個人物本質上就是一個寫了shellcode/0/空格的def，然后僅存儲壓縮，

那么我們將正常的kfm.def改為test.def，加上大概40KB左右的空格，然后單獨將def僅存儲壓縮，斷點004866E4。

這樣非常輕松就獲取了棧溢出的偏移量，將ZIPDIRENTRY dirEntry的deFileTime/deFileDate修改為我們自己找到的1005FB9D (call esp)。成功跳轉，棧上執(zhí)行。

那么如何執(zhí)行shellcode呢？因為zip模板限制，接下來CRC等空間顯然不夠填充所有的shellcode。我們可以學習Reboot的思路，跳轉到一個存儲test.def自己文本的地方。而這個地方就在棧上。

那么CRC應該填充的東西就呼之欲出了。sub esp,0x20;ret(83EC20C3)

這也正是血神的利用方式，但是如果我們這樣做的話，會發(fā)現(xiàn)溢出不成功了，會直接在40DAF1(repne scasb)拋出錯誤。

這個錯誤很有可能是因為CRC校驗的問題，參考血神和五月雨模板的做法，是同時修改了ZIPFILERECORD record和ZIPDIRENTRY dirEntry兩處的FileTime/FileDate/Crc為9DFB051083EC20C3，即可成功實現(xiàn)完美棧布局。

那么接下來要做的就是將test.def前面的那些注釋替換成shellcode。注意原版kfm.def的那些注釋不夠填充220長度的shellcode，直接填充會覆蓋到name導致報錯，所以需要先加上220+的A，重新壓縮，在010editor中手動替換成shellcode。

msfvenom -p windows/exec cmd="calc.exe" exitfunc=thread -b "\x00" -o calc.bin

但這樣最終還是無法執(zhí)行shellcode，動態(tài)調試一下，很容易發(fā)現(xiàn)我們sub esp,0x20;ret這一步錯了，跳到其他地方去了。

929D550才是我們需要跳的地方，多跳了4位。但從929D550存儲的0x20可以看得出來那是我們寫入的非常多的空格，也可以往里面放shellcode。

當然，最好還是改成sub esp,0x1C;ret(83EC1CC3)

最終效果如下。