Safengine Shielden 2.3.8.0（以下称SE）对IAT的破坏还算彻底，虽然对原程序的IAT做了完整的保存，但是保护后的程序是不会调用那里的API地址的，所以原IAT其实是废掉的。

         所以在尝试修复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 target

2. Fix its import function calls / rebuild IAT

In 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 address

2. Replace call [iAT] instructions and retrieve API during runtime

And 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.

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课