聚星亭

在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了

问题解决了，嘿嘿。