4. dump
根據(jù)脫US UnpackMe的經(jīng)驗,不能在false OEP處dump,此時BSS section中許多數(shù)據(jù)已經(jīng)初始化了。最好在第一句(push ebp)就dump?？墒悄莻€push ebp離false OEP很遠L。

Packer EP的初始化環(huán)境:






先看看發(fā)出第1個call的殼代碼:


可以看到(跟一下可以證實),在call入原程序空間前,最后的異常是div 0。用現(xiàn)在的OllyDbg腳本(跟到737B63),停下后修改異常攔截選項:


試試能否攔截異常找到合適的dump位置。當前OllyScript腳本停下時的環(huán)境:



棧中為pushad的結果。
第7次div 0異常時:




注意ebp的值已經(jīng)入棧了。Pushad的結果,對應寄存器值為:
esp = 12FFC0 (原來為12FFC4)
ebp = 12FFC0 = esp (原來為12FFF0)
看看BSS section:




全為0,就在這里dump。如果需要仔細跟stolen code,也可以從這里入手(可以從腳本停下的第6次div 0異常處理后開始)。

先用4D9DE4為OEP。



用LoadPE查看節(jié)表:


先把CODE的Vsize和Rsize加大,以避免修復stolen codes時空間不夠。



重新跟到false OEP(4D9E37)。重建輸入表。



用了Add new section,會不會有問題(好象有篇脫文里提到過這個)? 先這樣處理。
用IDA編譯dumped_.exe,結果不錯。
現(xiàn)在剩下stolen code和replaced code。
5. 修復stolen code

既然不打算仔細跟,就只有猜了。對執(zhí)行第1個call以前的stolen code進行猜測,應該是安全的。后面的4次call需要仔細看看。

1) call 406EDC

在IDA中看dumped_.exe的結果:


先執(zhí)行腳本,停下后只勾選div 0異常。直到73A9AF。經(jīng)過一番遮遮掩掩的代碼:


在call前的寄存器:


堆棧:


call完后,下面的pushad為分界線,標識stolen code的結束。所以到這里的stolen code為(對于不確定的,可以在Packer EP修改寄存器值,到這里核對):
Call完后,pushad前的環(huán)境:





2) call 46261C





到這里的stolen code:
從這里開始,不能圖省事了。要追出全部的stolen code,必須跟(必須確保上一次pushad和下一次popad時的環(huán)境一致,才不會丟代碼)。先試直接攔截div 0異常,注意后面是否有popad。如果兩次的環(huán)境不一致,則必須單步跟L。

另外,追stolen code不是一次完成的,所以有些圖中寄存器和堆棧中的數(shù)據(jù)對不上,不必管它。

3) 0073BC47


4) 0073C558


5) 第1次call 462634


這個函數(shù)有2個參數(shù)L。



這是最后一次后面存在popad的div 0異常。看看是如何回到原程序的。
在73D872忽略所有異常,對code section下內存訪問斷點。中間在kernel32中有一次內存訪問異常。



最后一次div ebx在73DBE1。單步跟到這里:


73DE38破壞前面代碼。



至此修復所有stolen codes,將前面的6部分和fasle OEP的2個call合在一起。

最新評論