手脱ASPack

ESP定律到达OEP，重新分析代码块

在菜单栏中找到OllyDump插件，该插件的窗口的弹了出来,有一些选项可供我们修改,我们可以对Base of Code进行修改,这里Base of Code = 4000(RVA),该选项相当于对代码段进行了指定,不需要像上一章那样在数据窗口中的PE头中去修改。我们应该还记得ASPack加壳程序的原程序代码段并不是第一个区段,而是第三个区段,4000(RVA),即404000(VA),OEP也是404000,刚好在代码段中,所以Base of Code这一项我们不需要修改。我们可以看到下面还有一个选项Rebuild Import(重建IAT),跟IMP REC的功能类似,提供了两种方式来重建IAT,这个选项对于一些简单的壳还是有效的,大家可以试一试。

我们这里就不使用这个功能了,去掉Rebuild Import的对勾,为了保险起见,我们还是使用IMP REC来修复IAT。

单击dump按钮。

这里我们将dump出来的文件命名为dumpaspack.exe。这里我们没有修复IAT直接运行起来,看看会不会报错。

提示无效的win32程序,我们需要修复IAT,打开IMP REC,定位到UnPackMe_ASPack2.12所在的进程,当前该进程停在了OEP处。

我们回到OD中,我们需要定位IAT的起始地址以及大小,还有OEP的值。

现在OEP的值我们知道了,等于404000,IMP REC要求的是RVA(相对虚拟地址),404000(VA:虚拟地址) - 400000(映像基址) = 4000(RVA)。

接下来我们需要定位IAT的起始地址以及大小,我们随便找一个API函数的调用处,好,OEP的下面正好有一处CALL GetModuleHandleA

选中CALL GetModuleHandleA这一行,单击鼠标右键选择-Follow。

这里我们可以看到直接来到了GetModuleHandleA的入口点处,并没有间接跳转(并不是所有的程序调用API函数都是通过间接跳转来实现的,该程序就没有使用间接跳转)。

这里是通过一个间接CALL来调用API函数的。

显然,4011F4是IAT其中的一项,该内存单元中保存了GetModuleHandleA的入口地址。

我们直接搜索二进制串FF 25,看看能不能定位到跳转表。（但我搜索ff25却什么也没搜到不知道为什么这里是看教程直接跳到了该地址ORZ）

我们可以看到定位到了跳转表,接着我们在数据窗口中定位到IAT中的GetModuleHandleA地址

我们将最后一个DLL中的IAT项用绿色标注出来了,地址是768XXXXX的形式,单击工具栏中的M按钮,在区段列表窗口中看看这类地址是属于哪个DLL。

这里我们可以看到这些地址是属于kernel32.dll的代码段。

这里IAT中的最后一个元素起始地址为401214,即401218是IAT的结束位置,现在我们再来看看IAT的起始地址是多少。

每个DLL的IAT项都是以零隔开的。

这里我们可以看到这部分绿色标注出来的数值为10XX 或者 11XX的形式,明显不属于任何一个DLL,而且这些数值比当前进程空间中分配内存单元中的最小地址还要小。

所以这些数值不属于任何一个DLL,也不属于任何一个区段,有可能是壳存放的一些垃圾数据,我们继续往下拉。

这部分地址是75EXXXXX的形式,我们在区段列表窗口中看看这些地址属于哪个DLL。

属于user32.dll。

区段列表窗口中还有些其他的DLL,如:GDI32.dll,NTDLL.dll,原程序并没有用到,这几个DLL有可能是壳加载的,我们在反汇编窗口中单击鼠标右键选择-Search for-All intermodular calls看看该程序调用了哪些DLL中的API函数。

这里我们可以看到原程序总共调用了3个DLL的API函数,我们只找到了两个DLL的IAT项,NTDLL的IAT项呢?我们随便找一个NTDLL的API函数调用处。

这一项的地址为401200,它填充的77a0XXXX混在了一堆7686XXXX中间，经过检查也就是说和Kernel32.dll的IAT项混在了一起。

401210这一项也被混在了Kernel32.dll的IAT项中。（我没发现啊不太明白这里）

好,现在我们来看看IAT的起始位置在哪里,IAT的所有元素这里我们用绿色标注出来了。

IAT的起始地址为40119C,跟跳转表中的最小地址一致。

好了,现在我们有了以下三条数据:

OEP = 4000 (RVA)

IAT的起始地址 = 119C (RVA)

IAT的大小 = 401218 - 40119C = 7C。

我们将这三个值填到IMP REC中去,单击Get Imports,获取IAT项。

哇全是NO怎么办？没事这时我们需要剔除掉垃圾数据,即valid显示为NO的项(无效数据),我们单击左边的+号将其展开。

我们单击kernel32.dll（第三个加号）这条记录左边的+号,可以看到401200和401210 这两项和kernel32.dll中的IAT项混在了一起。

可以看到这里ntdll.dll中分配内存空间的两个函数用kernel32.dll中两个类似的函数HeapAlloc,HeapFree替换掉了。

这里日志信息中也提示说这两个函数跟ntdll.dll中的RtlAllocateHeap,RtlFreeHeap完成的功能类似,壳也可以对这些IAT项进行修改和混淆。

下面我们来将这些垃圾数据删除掉。

单击Show Invalid,显示无效的数据,然后单击鼠标右键选择-Cut thunk(s)(剪切掉)。结果如下图

这里这些无效数据就被剪切掉了,程序运行的时候就不会提示尝试加载不存在的API函数了。

现在,我们单击Fix Dump,选择我们之前dump出来的文件。

好了,修复完毕,我们双击运行修复完毕的程序dumpaspack_.exe。

但是到了这一步我发现打不开该程序

可能问题在于自己电脑吧

仅允许非商业转载,转载请注明出处