译者：myswsun
预估稿费：100RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
0x00 前言
最近， Alex lonescu表明Windows的发布版本中将包含将增强缓解措施工具包（EMET）编译到内核中。
因为更多的缓解措施出现于MSVC和Windows操作系统中，定位API来利用内存崩溃漏洞变得越来越困难。
我就在想，如果导入地址表和导出地址表都不能访问了，是否有其他的方式来获得GetProcAddress？
下面你看到的就是我几个小时研究的成果，但没有铺开来研究IAT和EAT无法访问时如何获得GetProcAddress。
0x01 特征检测
用于检测恶意软件的每种算法可以重新利用来检测包括GetProcAddress在内的任何代码。
恶意代码的检测范围可以从简单的搜索字符串、常量（包括加密）或者代码字节序列到类似仿真和统计分析的高级方式。
通过特征定位GetProcAddress是一种尝试，因为它是唯一的返回错误码STATUS_ORDINAL_NOT_FOUND的函数。
从WindowsNT到Windows10，使用这个常量搜索kernel32.dll或者kernelbase.dll来定位GetProcAddress是很有可能的。
0x02 搜索算法
搜索算法的伪代码如下：
理论上很简单，并且对于32位是有效的。
然而，如果对于一些DLL（尤其是64位的版本）中GetProcAddress使用函数块，那么就无效了。
在Windows7中，在kernelbase中定位我们的常量，是在代码块中。
减去0x3FFFFEC8得到0xC0000138。
在Windows10中，常量在相同的GetProcAddress代码中，因此入口通过简单的搜索就能找到。
为了能适应Windows7，我建议使用一个长度反汇编引擎（LDE）来模拟相关的跳转知道你定位到GetProcAddress，但是没有64位版本的LDE能独立的操作内存。也可能不需要？
因为我们搜索kernel32或者kernelbase的节，我们检查下PE节头结构，有个有趣的成员。
Misc.VirtualSize
加载到内存的节的大小（字节），如果这个值大于SizeOfRawData，节将被填充0。这个字段只针对可执行映像有效，并且对于obj文件应该置为0.
VirtualAddress
加载到内存的节的第一个字节的地址（RVA）。对于obj文件，这是在重定位之前的第一个字节的地址。
Characteristics
映像的特征。因为我们搜索可执行代码，我们能测试这个值是否有IMAGE_SCN_CNT_CODE 或 IMAGE_SCN_MEM_EXECUTE。
一旦我们找到一个可执行区域，我们简单的搜索我们的特征，是一个4字节的序列：0x38, 0x01, 0x00, 0xC0。
如果找到了，我们假设我们在GetProcAddress的代码中，因此我们往回扫描内存来找到函数序言0x55, 0x8B, 0xEC（32位）和0x48, 0x89, 0x5C, 0x24, 0x08（64位）。
尽管从XP SP2开始大部分的32位的API在序言前有mov edi,edi以便热补丁，但是我们可以跳过它。
64位上找到入口点的另一种方式是搜索编译器添加的填充（不同的编译器填充不同）。
函数是16字节对齐，会在GetProcAddress前后填充。
在Windows7上，使用0x90，在x86上是NOP指令。
在Windows10中，使用0xCC，是软件中断（INT 3）。
我提到它是因为在不同的搜索算法中这会很有用。
0x03 C代码
对于PEB中的每个DLL；
找到kernel32或者kernelbase；
针对这个dll的每个节；
找到特征，并反向扫描函数序言。
0x04 总结
对于大部分32位的操作系统，他都能很好的工作，因为STATUS_ORDINAL_NOT_FOUND是在GetProcAddress函数的序言和结语之间的。但是在Windows7 x64上不能起作用，因为常量在外面。
Windows7 32位（可以）
第一个地址偏了2字节，但是那是mov edi,edi指令，可以安全跳过
Windows7 64位（不可以）
Windows10 64位（可以）
