樣本三

如下所示在該樣本中，使用了Ole10Native的流，因此沒有equative head，默認讀取紅框中的4位長度。之後的metf head為01.

可以看到metf head的長度為01時，直接進入到if判斷中(該if中的函數實際是一個異常處理函數，但是當傳入的參數為45，145時不影響之後的漏洞利用)，之後讀取0A一位，因此當metf head的version為01時，實際的metf head的長度只有兩位。

往後讀取01，進入11882流程，導致直接返回，進入case流程。

進入case中的0798流程，讀取08，進入之後的fun_Matrixdispatch，此時進入fun_Matrixdispatch中的11882/0802流程。

樣本四

如下所示可以看到樣本使用的是常用的equationative流，長度為1c的字節，之後緊跟metf頭，但是咋看之下卻並不能確定其具體的漏洞cve，從metf之後的88字節來看，應該是對應的11882/0802漏洞

從vt上報的漏洞類型來看，大多數廠商的識別是0802系列，由於從上文所知，metf之後的構造擁有多種方式，因此我們就來看看這個漏洞是否真是0802.

可以看到fun_ParseMTEFData函數中，metf頭檢驗之後，向後讀取一字節，此時獲取的為0d，作為參數進入到正常的11882/0802流程，0d>09，因此函數直接跳過再次向下讀取。

一直跳過0D 0A，直到藍色框中的01字節。

01被正常11882/0802返回，直接dispatch到case1中。

進入case1流程中的0798，向下再讀取一字節01。

0798中由01 dispatch進入到case0流程。

如上文所示，在樣本二中提到進入該函數中實際上是有方法進入到對應的equation流程中，但是在當時的漏洞利用樣本中，該函數直接進入到if流程中，當時的分析中提到要進入else中需要相關的特殊構造，即a4等於1，else中實際是一個while循環，依次讀取並傳入到0798的dispatch中。

可以看到while循環中之後會讀取02的tag，在該tag中會以此處理之後的3個字節，樣本中一共構造了四對02的tag用於混淆，之後處理35tag，35tag->5，即tag 5，而tag5實際上就是0798的漏洞tag，因此基本可以證明該樣本使用的漏洞是0798.

如下所示，讀取對應的35位tag

導致dispatch到case4中，即對應的0798漏洞流程中。

0798函數中，以此向後讀取5字節的內容，其中第四，第五字節將導致溢出，即下圖中的20,80，之後分別以這兩字節內容為長度進行棧上數據的拷貝，一共調用兩次，最終兩段棧上數據連成一片，從而造成溢出。

第一次拷貝，參數為20，及0012f3fc，0012f3fc為目標棧上的地址。

第二次，拷貝，參數一為80，參數二為0012f404。可以看到第二次拷貝的地址在第一次拷貝的高地址出。

拷貝前的堆棧。

拷貝之後的堆棧，可以看到此時返回地址已經被覆蓋，但是這個覆蓋的數據是不是很奇怪，50505050這個地址並沒有意義，難道這只是測試樣本？但是從沙箱的結果來看樣本是執行成功的。

仔細再看一下漏洞函數可以發現，實際上在溢出之後，函數返回之前，還有相當一部分的操作，即之後的sub_4428F0函數，及之後的還有一次0798的操作，也就是還能向後讀取數據，結合對應的樣本數據，可以發現確實還能向後拷貝，sub_4428F0函數之後將其結果作為參數，返回給0798漏洞流程，同時也能看到第一次溢出的拷貝的數據v6，是作為第四個參數傳入到該函數中的，我們的看看這個函數具體做了啥。

首先可以看到a2，a3這兩個參數來自於sub_43b349函數，值分別為word_45B246和word_45B244

而word_45B246和word_45B244的相關引用函數如下所示，其中Headcheck引起了我們的註意

可以看到這兩個位置的數據是在metf頭檢驗中進行的設置，即函數sub_43B1D0。

可以看到sub_43B1D0中設置a2，a3的值是依賴於metf頭之後的一位的值，且在處理的過程中有ReadByte的操作，這就意味這實際上可以通過該函數來實現往metf頭之後插入混淆數據的操作。

但是實際上仔細看代碼就可以知道，上面a2，a3是取的棧上的地址，也就是說這個值實際上在溢出之後是可控的。

再次調試可以看到a2，a3的地址分別為0012f420，0012f41c。

溢出之後可以看到此時a2，a3的值被修改。

如下所示，該函數的調用棧，需要註意的是2,3,4參數，其中第四個參數為溢出數據的第一段內容，2,3參數的低四字節（溢出時被修改為5800,06eb）需要註意，下文中會有相關解釋。

進入函數，可以看到首先通過sub_435B4A返回了一段內存v5，之後通過傳入的參數對該段內存進行初始化，其中紅框中的三處賦值初始化是關鍵，第一二次賦值分別將二三參數的低四位分別去處並v5偏移40和42處（06rb5800），之後通過函數memory將a4的0x14長度的數據拷貝到v5偏移50處，a4就是之前0798溢出時的第一次拷貝shellcode

此時反編譯一下00281c3c這段內存，可以看到之前第一次拷貝的06eb5800的對應反編譯源碼為pop eax，jmp 00281c6e

而00281c6e正好就是之前v5+50處拷貝的溢出shellcode的第一段，而最終00281c3c這段內存會作為參數返回。

00281c3c的作為返回值返回，並作為參數1傳入到之後的0798 dispatch函數中。

進入dispatch後，之前溢出shellcode之後的35將再次觸發0798的漏洞，函數首先分別獲取參數1偏移0x28，和0x2a處的數據，並保存到局部變量中，需要註意是獲取的是兩字節，賦值後內存中變成了00445800.

0044實際上只之前sub_4428F0函數的返回地址。

有意思的是在漏洞函數中sub_438349中，該函數會設置對應傳入的a2，a3地址的值，此時正好將00445800設置為00440000（該值在之後的利用中被使用）.

如下所示之後35之後依次讀取的5個字節為35, 33,36,20,44（其中用於控制溢出長度的字節為20，44）。

第一次拷貝，拷貝地址為0012f35c，長度的控制參數為20.

第二次拷貝，拷貝地址為0012f376，長度的控制參數為44.

拷貝前的堆棧數據。

拷貝後的棧數據，此時返回地址已經被修改為00430bfb，需要註意的此時覆蓋的只是返回地址的第四位，即高四位並沒有被修改，返回地址後四位即為傳入的第一個參數00281c3c，同樣需要註意的還有00281c3c之後的00440000，現在來整理以下第二次漏洞利用的流程

00281c3c作為參數一傳入0798漏洞函數，之後分別獲取00281c3c偏移40,42處的內容），並賦值給v5，v6，其中v5就是0044000（其來源上文中已經說明），之後將00281c3c，v5，v6分別作為2,3,4參數傳入到dispatch函數中。

之後進入漏洞函數2,3,4參數又分別作為1,2,3參數來調用case 4處的漏洞函數。

此時函數返回，由於之前的漏洞將函數的返回地址已經修改為00430bfb，而該地址對應的反匯編代碼為ret，執行ret，將導致程序的執行流程直接進入到00430bfb之後的00281c3c中。

00281c3c向下執行，最終導致執行之後00281c3c中已經構造好的shellcode

這裏可以看到在jmp前，有一條pop eax的操作，此時pop，即將之前棧上00281c3c之後的00440000賦值給eax，該值作為之後shellcode中尋址的高位地址，最終從此處進入到攻擊者控制的流程中。

由此可以看到該樣本中0798和正常0798的區別之處

1. 首先正常進行一次0798的漏洞利用，在上布置好後續的shellcode
2. 之後精心在函數sub_4428f0中構造出一段包含跳板shellcode的內存，並將該段內存作為參數再次調用0798函數。
3. 再次觸發漏洞，通過ret的方式將程序的執行流程定向到之前的跳板shellcode中。

總結

如下所示即可看到11882/0802/0798這三個漏洞的混淆點了，對於這三個漏洞，除了綠色1c，*8（11882，0802），*1/*4-*5（0798）不能變，其他位置都是可變的，其中紫色指有要求的變（第一處不能大於0x20000，第二處只能為01(當為01時，metf頭由五位變成1位，即之前的後四位去掉)，02，03，102，103），當metf為五位時，之後的一位，即第六位實際上是可以導致之後有附加數據的，及下圖中的藍色部分，因此metf頭之後和tag頭之間也是可以插入混淆數據的。除此之外eqnolefilehdr，mtef head其余位置應該都是可以隨便搞的。

之後mtef byte stread中可以插入任意多的tag，只要保證最終進入08，05tag即可，因此在紫色01和綠色08之間也是可以加入混淆數據的（通過0798中的處理或標準流程中11882處理（>9,01，04會進入0798），0798中還依賴dispatch來處理，case0/case1/case5流程中是可以再次進入到0798，如上文的第2,4個樣本。

轉載請註明出處

Equation漏洞混淆利用分析總結(下)