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

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

我的思路
         通過閱讀L4Nce對于修復SE 2.2.6.0  IAT的腳本，我覺得部分內容依然適用于新版面的SE。就是執行到OEP，CODE段被完全解壓后，通過搜索call se_data代碼，找到可能的API調用位置，將EIP改到call的位置，然后執行call的代碼，定位所要找的API。
         但在舊版本中，讀取API地址的代碼段是唯一的，所以可以通過逆向分析找到關鍵位置，并下斷點，通過腳本對斷點攔截處edi的值的讀取來獲得API地址。而在新版本中，讀取API地址的代碼不是唯一的，可以說有多少API就有多少段代碼，使得L4Nce的腳本在新版本中已經完全不可行。
         我的思路是用類似于找OEP的方式，通過堆棧平衡的方法找到接近Fack_API_Entry出口的位置，然后通過腳本控制單步執行尋找真實被調用的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調用，特別是某些常用API的調用每分鐘能被調用成千上萬次，如果增加太多垃圾代碼，會非常影響速度。

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

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

 

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

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

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

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