在begin09論壇上nick放出了一個UnpackMe，我閑來無聊就搗鼓了下。感覺這個殼還可以啦。

花指令比較少。
IAT處理上，很像是PE-Armor。
需要修復TLS表。

下面是我分析的詳細過程：

在00401000下內存寫入斷點:

很明顯，這些是解密IAT的。

        0045E6CC  770F4880  oleaut32.SysFreeString
        0045E6D0  770FA3EC  oleaut32.SysReAllocStringLen
        0045E6D4  770F4B39  oleaut32.SysAllocStringLen
        0045E6D8  00000000
        0045E6DC  77DA7ABB  advapi32.RegQueryValueExA
        0045E6E0  77DA7852  advapi32.RegOpenKeyExA
        0045E6E4  77DA6C27  advapi32.RegCloseKey
        0045E6E8  00000000
        0045E6EC  77D311DB  user32.GetKeyboardType
        0045E6F0  77D2B19C  user32.DestroyWindow
        0045E6F4  77D2C908  user32.LoadStringA
        0045E6F8  77D507EA  user32.MessageBoxA
        0045E6FC  77D2C8B0  user32.CharNextA
        0045E700  00000000
        0045E704  7C8099B5  kernel32.GetACP
        0045E708  7C802446  kernel32.Sleep
        .

繼續向下，發現一個anti dump的代碼：

然后在內存映射視圖，的代碼段下內存訪問斷點，很容易，我們就來到了如下的地方：

這樣就來到OEP了，如下，根據這個入口點我們可以知道，這是一個Delphi6.0到7.0的程序。

接下來我們修復IAT。
我們知道，Delphi程序，一般第一個函數的第一個API是GetModuleHandle。我們從這里入手，來看一下。

理論上講，按照上面的分析，改寫類似于如下的代碼：

這樣的代碼，寫個腳本修復所有的代碼這個殼應該就算是脫OK了。
可是，情況卻不是這樣的，我們在運行到：

這里的代碼的時候，程序莫名奇妙的異常了，查了一下異常信息是：0x80000004 (SINGLE STEP)異常。
具體原因，我水平有限，沒有辦法，我們就在到達OEP以前來修復這個IAT。

具體過程如下：

根據這個代碼，我們重新加載程序，在地址00406508上下內存寫入斷點。運行程序，來到如下代碼：

這時我們去看一下我們要關注的地址已經被改成了什么樣子：

看到了吧，我們的00406508地址處的代碼已經被改寫了，只不過還沒有完全寫完。
我們繼續看代碼：

003D026F    03BD 48040000   add    edi, dword ptr [ebp+0x448]
003D0275    83C2 05         add    edx, 0x5
003D0278    8BF2            mov    esi, edx
003D027A    56              push    esi
003D027B    FF95 3C040000   call    dword ptr [ebp+0x43C]                          ; kernel32.GetModuleHandleA
003D0281    0BC0            or      eax, eax
003D0283    75 07           jnz    short 003D028C
003D0285    56              push    esi
003D0286    FF95 40040000   call    dword ptr [ebp+0x440]
003D028C    0FB64E FF       movzx  ecx, byte ptr [esi-0x1]
003D0290    03F1            add    esi, ecx

003D02B8    42              inc    edx
003D02B9    52              push    edx
003D02BA    52              push    edx
003D02BB    56              push    esi
003D02BC    FF95 38040000   call    dword ptr [ebp+0x438]                          ; kernel32.GetProcAddress
003D02C2    8907            mov    dword ptr [edi], eax                          ; 保存API地址
003D02C4    5A              pop    edx
003D02C5    0FB642 FF       movzx  eax, byte ptr [edx-0x1]
003D02C9    03D0            add    edx, eax
003D02CB    42              inc    edx
003D02CC    83C7 04         add    edi, 0x4
003D02CF    59              pop    ecx
003D02D0  ^ E2 CA           loopd  short 003D029C                                ; 循環獲取所有用到的API地址
003D02D2  ^ EB 93           jmp    short 003D0267                                ; 繼續其它DLL

我們可以猜測出來，接下來程序要做什么。
對的，它是要把所有API調用的地址代碼從類似于：

改寫成：

就是說，程序會自動定位所有要改寫的地方，我們就可以借用這個時機，來修復我們的IAT調用。
好，我們繼續。

為了相信跟蹤我們熟悉的API，以保證代碼的準確性，我們可以在這里下條件斷點： EAX == 0x0040650E，然后自己跟蹤這個過程。
經過調試，我們知道，此時的[EDI]跟0x0x7FFFFFFF&運算以后，再減去4就是我們要填充的地址了。
而[EDI+4]中存放的就是我們需要的API地址。

當然，如果相信分析過我們逆向班15課的課后作業的話，我們很明白，這個殼加密的IAT不一定全是FF25類型的，還有FF15類型的。
詳細分析003D03C0這個CALL的話，我們就可以明白，它有一個分流器來處理這些IAT加密。

好了，現在讓我們整理一下我們現在所掌握的信息：

現在萬事俱備，就差我們去修補它了，好我們開始動手修改這個殼的代碼來修復IAT了。
先找一個足夠大的空間，來寫我們的代碼，我找到下面的地址:

好，我們先改個跳轉，來轉移到我們的這個地址上：

33 D2 B9 02 00 00 00 F7 E1 D1 E8 08 D2 0F 85 87 02 00 00 E9 9D 02 00 00

到我們新找到空間將代碼改寫成如下樣子：

66 C7 40 FA FF 25 8B 5F 04 89 58 FC 8B 0B 33 4F FC 89 0F 83 C7 08 E9 43 FD FF FF 66 C7 40 FA FF
15 8B 5F 04 89 58 FC 8B 0B 33 4F FC 89 0F 83 C7 08 E9 43 FD FF FF

 執行完這些代碼，讓我們看下API調用的代碼，如下：

不過這個殼好像沒有FF15類型的，好，到現在已經全部修復完成了。

接下來就是讓代碼修復OEP出的代碼，然后我們跳到OEP處就可以了。
但是如果我們現在繼續在00401000段下個斷點程序會拋異常而不會像我們一開始那樣，到OEP附近。
我們單步跟蹤：

當我們單步跟蹤到003D04B5的時候，發現，EDI不是一個正常的地址，往這里寫內容，程序會異常的。
通過我們剛才到OEP的調試，我們知道，edi本身應該是我們OEP的地址，這個代碼就是填充OEP用的。我們先不管它。

在003D04C0這里，將EAX修改為我們的OEP，然后跳到OEP以后，手工改好了OEP的代碼，dump出一個文件，修復了下轉存文件。可是問題提示C0000005初始化錯誤，本來以為全盤皆輸了，經Nick提示，說是要修復TLS表。
所以，我按照沒脫殼的程序把TLS填好，重新計算了下索引變量的虛擬地址（就是TLS表的RVA+SIZE）。然后保存，運行，OK了

問題解決了，嘿嘿。