现在我们的指针指向InMemoryOrderModuleList是一个LIST_ENTRY结构，Windows定义这个为包含进程模块的双向列表。这个列表中的每项是指向LDR_DATA_TABLE_ENTRY结构的指针，这个结构是我们主要的目标，包含加载模块的所有地址和名字，因为模块加载的顺序可能改变，我们应该校验全名，以便选择包含我们要查找的函数的动态库，这能简单的通过在LDR_DATA_TABLE_ENTRY向前移40字节做到，如果名字匹配了，则正是我们寻找的那个，我们在结构中向前移16字节，能得到加载模块的地址。

得到函数地址的第一步完成了，现在我们有了包含要寻找的函数地址的DLL的基地址，我们不得不解析模块的导出地址表，以便能找到需要的函数地址，导出地址表能在PE可选头中定位到，从基址向前移60字节，我们有了DLL的PE头的内存地址，

最后我们需要通过公式（模块基地址 PE头地址 120字节）计算导出地址表的地址，我们能得到导出地址表（EAT）的地址，在得到EAT地址后我们能访问DLL导出的所有函数，微软描述IMAGE_EXPORT_DIRECTORY结构如下，

这个结构包含地址，名字和导出函数的数量，使用想通大小计算遍历技术能得到函数的地址，当然导出函数的顺序在每个版本中可能有变化，因此获取函数地址和名字前应该校验。你可以把这个方法理解为计算几个Windows数据结构的大小，并在内存中遍历，这里真正的挑战是建立一种稳定的名字比较机制来选择正确的DLL和函数，如果PEB解析技术太难实现，不用担心，有更简单的方法做到这个。

0x05 Hash API

metasploit项目中所有的shellcode几乎都使用了称为Hash API的汇编块，它是由Stephen Fewer编写的一个代码片段，且从2009年以来在metasploit中主要用于Windows shellcode，这个汇编代码块使得解析PEB结构变得容易，它使用基本的PEB解析逻辑和一些额外的哈希方法，使用函数和模块名的ROR13哈希计算法来快速查找需要的函数，使用这个块非常简单，它使用stdcall调用约定，唯一的不同是压栈的参数，需要使用ROR13计算函数名和DLL名的哈希。在压入必须的参数和函数哈希后，像之前解释的解析PEB块并找到模块名。在找到模块名后，计算ROR13哈希且将它保存到栈上，然后移到DLL的导出地址表中，计算每个函数的哈希和模块名哈希，如果匹配到我们要找的哈希，意味着想要的函数被找到了，最后Hash API使用栈上的参数跳转到找到的函数地址执行。它是一段非常优雅的代码，但是它的日子到头了，因为它的流行和广泛使用，一些AV产品和反利用缓解措施有专门针对这个代码块的检测，甚至一些AV产品使用Hash API使用的ROR13哈希作为识别恶意文件的特征，因为最近操作系统中的反利用缓解措施的改进，Hash API只剩下很短的生命周期，但是有其他方法来找到API函数地址，同时针对这种方法使用一些编码机制也能绕过主要的AV产品。

0x06 编码器/解码器设计

在开始设计前，读者应该知道的事实是只使用这个编码器不能生成完全躲避检测的shellcode，在执行shellcode后，解码器将直接运行并解码整段shellcode为它的原始格式，这个不能绕过AV产品的动态分析机制。

解码器的逻辑非常简单，它使用一个随机生成的多字节XOR密钥来解码shellcode，在解码操作完成后将执行它，在将shellcode放置在解码器头之前应该使用多字节的XOR密钥加密，且shellcode和XOR密钥应该在“<Shellcode>”,”<Key>”标签内，