Question

上一章节，我们介绍了如何定位 stolen bytes,本章我们的任务是修复 IAT,再次用 OD 加载 UnPackMe_ACProtect1.09,我们可以通过并执行 HBP.TXT 脚本到达假的 OEP 处。

现在我们在壳的入口处，现在我们来利用上一章节编写的脚本定位到 OEP 处，首先，需要需要给 KiUserExceptionDispatcher 入口处以及其下方的 ZwContinue 调用处分别设置断点。

现在我们到了假的 OEP 处，大家可以修改一下这个脚本让其自动给 KiUserExceptionDispatcher 入口以及 ZwContinue 调用处设置断点，并且让其支持输入需要设置硬件断点的地址，但这里我们暂时没有必须修改，这个脚本目前来说已经够用了。

下面我们来随便定位一个 API 函数的调用处，单击鼠标右键选择 Search for - All intermodular calls 选项搜索。

我们可以看到很多 API 函数的调用，其中有些 IAT 项是正常的，显示出了函数名称，但是大部分的 IAT 项都是经过重定位的，并没有显示函数名称，我们随便选中一个重定向的 IAT 项，双击鼠标左键。

这里我们可以看到 CALL 的是 460E80 内存单元中对应的 IAT 项，我们在数据窗口中定位到该项。

这里我们可以看到很多经过重定向的项，这些项直接就位于壳的区段中，我们来看看区段列表窗口。

大家应该还记得该壳的入口点也是位于这个区段的，壳的入口点为 46B000,也就是说该壳并没有重新创建一个区段用来处理重定向的 API 函数。

接下来任务就需要定位修复 IAT 项的关键跳转(magical jump) 了。

下面我们就来通过 460ADC 这一项来定位关键跳。

首先我们将定位 OEP 的脚本备份一下。

我们将备份过的脚本重命名为 OEP.txt,接下来我们通过修改 HBP.txt 脚本来定位修复 IAT 的关键跳转。

这里我们将脚本修改为对 460ADC 这个重定向的 IAT 项设置硬件写入断点，也就是说断点类型修改为 W。

现在我们清除之前设置的硬件断点，重新启动 OD。

执行上面的脚本，不一会儿弹出了是否继续执行脚本的消息框。

我们可以看到这里对 460ADC 写入的时候触发了硬件写入断点，我们知道硬件断点是断在下一条指令处，我们来看看前一条指令是什么。

这里我们可以看到是这条指令将对 460ADC 地址进行写入，我们来看看 EAX 的值是多少。

这里 EAX 的值为 46B492。

这里我们在反汇编窗口中定位到 46B492 这个地址，看看该壳做什么处理。

这里我们看到这个重定向的处理非常简单，首先将常量 5BF11A9 压入堆栈，接着将该值与 793E0502 进行异或，接着就 RET 返回。

异或得到的结果就是 API 函数的入口地址，我们一起来计算一下。

5BF11A9 XOR 793E0502 = 7C8114AB

计算出来的这个地址就是 API 函数的入口地址，我们返回到 OD 中看看。

我们将堆栈窗口往上拉一点就能看到正确的 API 函数地址了，下面我们就来看看是不是所有的重定向的 IAT 项都是这样处理的，先停止脚本。

我们对部分重定向的 IAT 项设置内存写入断点，看看会发生什么。

我们运行起来，当下一个重定向的 IAT 项被写入的时候断了下来。

我们定位到重定向的部分，执行异或操作以后可以看到得到的 API 函数是 MulDiv,这么看来修复是有可能的，我们可以看到正常的 API 地址被保存在了堆栈中，确切点来说是[ESP - 0C]中。

这里我们可以看到往下都是需要重定向的，到了 460BA8,就是正常的 IAT 项了。

所以我们对 460BA8 这一项设置内存写入断点。

运行起来，到了这里。

我们可以看到对于正常的 IAT 项,[EBP - 0C]处并不会保存正确的 API 函数入口地址，所以说有点遗憾，不然我们可以使用一个简单的脚本轻松的修复 IAT。

我们该怎么做呢?我们需要对写入 IAT 项的指令设置硬件执行断点，当脚本执行到这里的时候，我们判断 EAX 的值是正常的还是重定向的，如果是重定向的，那么我们就将[ESP + 0C]的值填充到 IAT 对应的条目中，如果是正常的 IAT 项的话，我们就不予处理，我们来看看该脚本如何编写。

以上就是完整的脚本，这里我是在下一行的 4743d5 处设置的硬件执行断点，因为硬件执行断点当将要执行该条指令的时候就断下来，不同于硬件写入或者访问断点。

这个脚本是基于 HBP.txt 改写的，首先对 IAT 项重定向的下一条指令 4743d5 处设置硬件执行断点。

这里是 ToProcess 这个分支，当脚本检测到中断异常，将 EIP 与 4743d5 进行比较，如果相等就跳转到 ToRepair 分支中。

ToRepair 分支，我们首先判断 EAX 是否为正常，如果被重定向到壳所在区段的话，那么地址是小于 500000 的，反之，如果 EAX 的值大于 500000,就表示该 IAT 项是正常的，我们就无须进行修复，回到开始处继续捕获下一次中断。如果 EAX 是重定向的值的话，我们就使用变量 aux2 来保存正确的 API 函数地址，正确的 API 函数地址保存在[ESP - 0C]中。我们将其写入到 EDI 指向的 IAT 项中即可。

下面我们就来执行一下该脚本，试试效果。

重启程序，将之前设置的硬件断点全部清空，接着对 KiUserExceptionDispatcher 的入口处以及 ZwContinue 的调用处分别设置断点，然后运行脚本。

程序运行起来了，我们来看下 IAT。

嘿嘿，我们可以看到 IAT 项都被修复了。

我们将脚本重命名为 IAT.txt。

下面我们需要定位 IAT 的起始地址以及 IAT 的大小。

这里我们可以看到 IAT 的起始地址为 460818,结束于 460F28。

OEP(RVA) = 271b5

IAT 的起始地址(RVA) = 60818

IAT 的大小 = 710

这里我们可以用的假的 OEP,后面我们可以手工修改。

下一章节，我们来解决 AntiDump，敬请关注。