所以在嘗試修復(fù)SE的IAT時，直接在IAT下斷點并沒有任何作用。
依據(jù)我的研究，SE對API的調(diào)用機制是：先映射幾個常用的系統(tǒng)DLL到自己分配的內(nèi)存區(qū)域，然后逐個搜索查詢需要的shadow API，獲取他們的地址。
保存shadow API或者真實 API 的地址到殼段已經(jīng)被設(shè)定好的調(diào)用位置，殼程序會通過預(yù)先構(gòu)造好的代碼對其進行調(diào)用，這種構(gòu)造好的代碼我稱之為Fack_API_Entry。
處理所有原程序中對API的調(diào)用，使其以E8 call 的方式，通過調(diào)用構(gòu)造好的Fack_API_Entry來實現(xiàn)調(diào)用API。

（注：1、這里的 API 地址 和 Fack_API_Entry 是一一對應(yīng)的，有多少API 地址 就有多少Fack_API_Entry。         2、API 地址是被離散的存儲在殼段中的。）

我的思路
         通過閱讀L4Nce對于修復(fù)SE 2.2.6.0  IAT的腳本，我覺得部分內(nèi)容依然適用于新版面的SE。就是執(zhí)行到OEP，CODE段被完全解壓后，通過搜索call se_data代碼，找到可能的API調(diào)用位置，將EIP改到call的位置，然后執(zhí)行call的代碼，定位所要找的API。
         但在舊版本中，讀取API地址的代碼段是唯一的，所以可以通過逆向分析找到關(guān)鍵位置，并下斷點，通過腳本對斷點攔截處edi的值的讀取來獲得API地址。而在新版本中，讀取API地址的代碼不是唯一的，可以說有多少API就有多少段代碼，使得L4Nce的腳本在新版本中已經(jīng)完全不可行。
         我的思路是用類似于找OEP的方式，通過堆棧平衡的方法找到接近Fack_API_Entry出口的位置，然后通過腳本控制單步執(zhí)行尋找真實被調(diào)用的API。
         這種方法最大的缺陷是沒有辦法處理很大量的VM或者混淆代碼。萬幸的是，SE中的Fack_API_Entry出口處并不存在大量的VM或者混淆。至于原因，SE作者nooby大神是這么解釋的:

 
So what we need to do is:1. Dump the unpacked target2. Fix its import function calls / rebuild IATIn most cases the target will not contain any shell SDK calls or have many VMed code which do require a running shell, so that's all it takes to unpack the target.Talking about import protections, if you find it difficult to understand, I suggest that you pick ONE specific program like calc.exe or notepad.exe and try to protect it.Soon you will figure out that there is not many ways to do that, you can:1. Use random locations for each function address2. Replace call [iAT] instructions and retrieve API during runtimeAnd that pretty much covers every different methods you can see in many protectors.For #1, if you found it hard or inefficient to scan entire code section and locate all those locations, you should analyze the shell code and find the part that retrieves & fills API addresses. Make a log or something like what I did in my previous IAT fix scripts.For #2, you will need to scan the code section and identify these calls, then make a run trace to each of them, discover their corresponding API addresses. This is most likely what you will see in SE scripts.You may ask, is it really that simple like ... Yes! Keep in mind that any additional code adding to a simple call [iAT] will have significant performance impact on the program, so there cannot be many tricks, even the code must be simple. For case #1, the address filling process can loop many thousand times, for case #2, think of a typical message loop. So you won't see any heavy VM there, have a cup of tea and find proper ways to handle them.Why is unpacking all about IAT fixing? Because IAT is the only thing a protector can do with "blind" targets. Unless you are dealing with a protector designed for the sole purpose of protecting that one single program, or it can't just randomly pick some places and insert extra code there. Some protectors feature resource anti dump and stuff, but that either depends on API hooking or resource tree manipulation. Considering there is usually not many resources in UnpackMEs, you can always find & dump them manually.
基本的意思就是，由于API調(diào)用，特別是某些常用API的調(diào)用每分鐘能被調(diào)用成千上萬次，如果增加太多垃圾代碼，會非常影響速度。

           
         之后，重新載入程序，停在系統(tǒng)入口， 修復(fù)anti斷點后，在[esp-4]的堆棧位置下硬件寫入斷點，然后F9運行，觀察斷下來后[esp-4]中的值，斷下來三次之后，[esp-4]的值顯示為00ADCD41,這里就是程序的OEP了，至于為什么認為這里是OEP，因為[esp-4]被寫入的值總共4個，只有這個位置的代碼是可執(zhí)行的。
          

寫腳本來執(zhí)行CODE段中調(diào)用API位置的搜索
         在我們找到的OEP位置上下斷點，直接運行過去，如果在虛擬機環(huán)境下調(diào)試，最好在這里保存?zhèn)�快照，因為后面寫腳本調(diào)試腳本的時候，肯定要來回嘗試N次，每次都要把前面的過anti都做一遍，既麻煩又浪費時間。        
在腳本中設(shè)定se_data殼段的開始和大小，直接用暴力搜索法搜索所有的call代碼。
         當(dāng)然，最好還是要生成一個ingore 表，搜索的過程中可能會遇到處理不了的API或者并不是call的代碼，需要手動修復(fù)或者跳過的。

 

再通過ESP定律尋找真實被調(diào)用的API
       獲得API在IAT中的位置

       獲得API的入口地址并用其和IAT中的值匹配
      修復(fù)CODE段代碼
         CODE段的API調(diào)用主要有三種情況：call regcall ds:[imm]jmp ds:[imm]

題外話：似乎Nooby大神現(xiàn)在把精力轉(zhuǎn)到移動端的加密保護上了，PC端的殼到現(xiàn)在才更新到2.3.9.0，難道PC端的加密真的要沒落了？

上傳腳步，大家可以試一下