運行程序,crashedL。直接用修復(fù)完stolen code的dumped_.exe看看。從EP的第1個call進去就有問題。







在OllyDbg中可以看到:


有部分IAT在殼中。這部分代碼前面是跟到了的(在第6次int 3以后),原來認為這只是loader自己需要的API。實際上正常的程序代碼也使用了這個IAT。

如果用ImportRec把這部分也取出來,屬于不同dll的api混排了,ImportRec不能處理。
這些地址是在736643處理的。


而且有一個不能識別(這個實際上是Hooked MessageBoxA)。



估計這是加殼時做的手腳。當(dāng)發(fā)現(xiàn)主程序使用了與殼代碼同樣的API時,修改了對應(yīng)的調(diào)用代碼,使其調(diào)用到殼中的IAT。這樣可以加強與殼的聯(lián)系。反過來看,這里大部分API(除了只有殼使用的),在前面避開IAT加密處理后,都已經(jīng)import了。

在ACProtect_Fixed中已經(jīng)有解好的api名。


緊臨的函數(shù)指針:



注意函數(shù)名及指針與7339A9附近的代碼并不完全對應(yīng)。有的函數(shù)名或指針在別處。

可以在程序入口自己調(diào)用LoadLibrary,GetProcAddress進行處理,填入相應(yīng)的地址?；蛘甙袻oader的代碼搬過來。也可以修改主程序的代碼,使其調(diào)用前面得到的干凈的IAT而不是殼中的IAT(這樣要處理的地方太多,很麻煩)。

注意ACProtected_Fixed中,import了幾個基本的API:

在加載API時殼代碼會使用這些函數(shù)。這幾個地址直接填入007300D8開始的IAT中了。修改dumped_.exe的EP,從殼代碼開始(可以看到dump出來的代碼,這部分已經(jīng)解開了),





注意Loader代碼中用的幾個API(GetModuleHandleA,GetProcAddress)改為使用避開IAT加密后得到的主程序的IAT。


原來在殼代碼import的4個API,從主程序的IAT直接取。結(jié)束處理后跳回前面的OEP 409DE4。用pushad,pushad保存寄存器值。



注意最后一項7301CC實際是MessageBoxA,被ACProtect用做SDK的接口。 不要填入MessageBox的真正地址。

下面的73013C在跟原程序的過程中始終為0,可能是注冊版才有?


處理完后,位于殼空間的IAT已經(jīng)賦上了正確值。


7. 修復(fù)Replaced code (1)

用前面的OllyScript腳本,停下后對Code section設(shè)內(nèi)存訪問斷點。忽略所有異常。斷下后,在抽取代碼的共同入口722416設(shè)斷,運行。第1次調(diào)用在004047E5。


里面還有SMC,解出后貼到ACProtect_Fixed中對照跟蹤。這部分的處理與低版本基本相同。

1) 查返回地址表



7225CC后ebx指向返回地址表,里面是RVA:



找到匹配地址后,ecx等于表項的offset,第1項為0x2A。

2) 查opcode表
用1中的到的offset查opcode數(shù)據(jù)表(007262ED):

密文opcode表:


counter表(記錄每個地址的調(diào)用次數(shù),超出0x20次將使用新的地址解碼):


第1次解出的變形碼:



3) 調(diào)整stack以便正確調(diào)用變形碼及返回




4) 破壞解出的代碼,ret到變形碼




5) 執(zhí)行變形碼,返回到原程序




6) Patch

先把解出的代碼binary copy到dumped_.exe(直接copy 722416 - 7226B0的代碼即可)。

關(guān)閉722579的解碼(解出7225C1 - 7226B0):


關(guān)閉7226A8處對前面代碼的破壞:


patch 72260C: jnz->jmp,無論執(zhí)行多少次都使用同一解碼地址



copy正確的ImageBase值,這里為0,改72FC1F為400000





copy 正確的10 bytes key(第1 byte為0)




執(zhí)行,仍然crashedL。

8. 修復(fù)Replaced code (2)

還有replaced code,在這里出異常:


->


將解出的代碼貼到ACProtect_Fixed.exe?？梢钥吹?這些實際上是變形的call代碼。第1次執(zhí)行到這里,在buffer中解出的變形碼為:




XOR的結(jié)果:



目前的dumped_.exe,地址72ED83的值為0(這些值是loader寫入的)。

406DF8的變形碼原來是call GetKeyboardType。原程序的call API 全部被抽掉了。殼代碼的動作與前面相似,用返回地址查表,獲取相應(yīng)的指針,生成jmp dword ptr ds:[xxxxxxxx]指令,該地址則指向類似72124C的變形碼,調(diào)用正確的API。

變形call API的返回RVA地址表:

開始:


結(jié)束:


尋址變形碼數(shù)組下標表(每項1字節(jié)),用于查變形碼指針數(shù)組:


變形碼地址表(指向變形碼的指針):



開始打算寫個inline-patch:

用同樣的查表動作,把對應(yīng)的變形碼copy出來,得到對應(yīng)的API地址,與跳過加密而得到的干凈IAT對比。查到匹配值后,修改對應(yīng)的opcode,使其直接call到IAT中的地址。

用OllyScript腳本跳過IAT加密,得不到變形碼（此時從變形碼地址表中得到的就是API的真正地址,有46項指針無效,為0xCCCCCCCC）。

另一個問題卻是難以解決的,replaced code只有5字節(jié):

這里的call是0xE8,調(diào)用殼中的絕對地址。InlinePatch寫到一定程度才發(fā)現(xiàn),如果要修復(fù)代碼,使其調(diào)用到IAT,需要相對地址調(diào)用6 bytesL。真是個低級錯誤。

現(xiàn)在patch的結(jié)果:


真正需要的是:



這樣只有保留變形碼。把殼中對應(yīng)的代碼copy過來,OEP前生成正確的變形碼。而且脫殼后的程序不能直接看到API名字,很不舒服。

只好把殼的相應(yīng)代碼搬過來。再次修改dumped_.exe入口處代碼,在把loader空間中的IAT填好后,跳到處理變形碼的位置:



loader在處理IAT時需要調(diào)用幾個API,及判斷dll的映射地址、API地址等,先保存需要的數(shù)據(jù)(我們有干凈的IATJ):



由于在前面避開了IAT加密,生成變形碼需要的數(shù)據(jù)已經(jīng)被正確的API地址覆蓋了。用LoadPE把ACProtect的idata section存到文件,然后加到dumped_.exe。



把這個section的密文數(shù)據(jù)copy到dumped_.exe的idata section,覆蓋掉干凈的IAT,我們已經(jīng)不需要它了?，F(xiàn)在只要偽造好現(xiàn)場J。



往下執(zhí)行l(wèi)oader的IAT處理代碼,做幾處小小的修改,使其使用剛才保存的API地址等數(shù)據(jù)。


IAT及變形碼處理結(jié)束后回到OEP。



執(zhí)行。又掛了L。這次是內(nèi)存訪問異常。跟一跟可以知道,是在Hooked MessageBoxA中。這里面的代碼還沒有仔細看,有幾個switch-case分枝。第1次eax為5。



進去后有幾個查表動作:



用調(diào)用Hooked MessageBoxA的返回地址查表。這張表在721F25處,dumped_.exe中有,共21項。
注意查表時不是找相等值,而是找大于返回地址值且最接近的值。



繼續(xù)->



這里出現(xiàn)了另外2張表。7220B5的表中數(shù)據(jù)為size。Dumped_.exe中有:



問題出在第3張表:



dump出的數(shù)據(jù)為0。這段代碼要把主程序中的一段數(shù)據(jù)copy到這張表中數(shù)據(jù)所指的地址。在loader中執(zhí)行時,這里填入了指向動態(tài)分配內(nèi)存的指針。



顯然不能直接復(fù)制這些值。有個簡單的辦法可以騙過loader。從那張size表中可以看到,最大的數(shù)據(jù)FD5D。用LoadPE再次增加1個section,size為FFFF即可。



修改dumped_.exe,設(shè)置21項數(shù)據(jù),使其全部指向該地址。



在W2K下運行,顯示窗口,但不能響應(yīng)輸入。在WinXP下運行什么也不顯示。
下面該與主程序交手了,這需要把板凳坐穿的耐心L。

最新評論