EternalBlue Shellcode详细分析

说来很惭愧，EnternalBlue 已经出来很久了，最近才开始分析，漏洞原理和环境搭建网上已经烂大街了，因此这篇文章只分析Shellcode，调试平台如下：
windows 7 sp1  en    32 位
Windbg
Eternalblue
Doublepulsar
Wireshark
断点方法是将Shellcode中的31c0修改为CCCC（int 3）后发送，成功断下来后再通过ew(fdff1f1) c031即可。该Shellcode 大致分为三段： 0x1，hook nt! kiFastCallEntry篇； 0x2， 主要功能篇；0x 3， 后门通信篇，下面来逐一进行介绍。
0x1 Hook ntdll! kiFastCallEntry篇
这部分代码功能比较简单， 但还是值得学习：首先是判断系统环境，作者用法比较巧妙，利用了x86和x64系统通过对二进制指令的解析不同来判断系统环境（64位环境没有调试，直接用IDA查看， 如下图。

1.1   x86环境 

1.2  x64位环境
可以发现同样一段二进制代码, 在x86环境下eax=1 ， x64环境下 eax = 0。 紧接着通过读取MSR的176号寄存器（放着nt! kiFastCallEntry函数地址）（这里还有简单的混淆），将其保存在Shellcode的末尾位置（Shellcode末尾空置了0x1d byte），然后再将第二段Shellcode的地址存放在MSR 176号寄存器中实现对nt! kiFastCallEntry函数的hook。

1.3  简单混淆

1.4  hook nt!kiFastCallEntry

1.5 hook前的情况

1.6 hook后的情况
为什么要hook kiFastCallEntry?
在Ring3应用程序需要调用ring0函数的时候， 会通过ntdll!kiFastSystemCall 函数，该函数的内容如下：
     mov edx, esp
      sysenter
      ret
Ring3层最终通过 sysenter 调用内核函数 nt!KiFastCallEntry实现空间转换。因此只要存在用户空间需要调用内核函数，都会调用这个函数。
0x2 主要功能篇
首先是获取到上一段Shellcode功能中保存末尾的kiFastCallEntry实际地址，然后写入MSR的176号寄存器中，恢复kiFastCallEntry。
 

2.1  unhook KiFastCallEntry
接下来获取ntoskrnl.exe 的基地址，fs:[0x38] 指向_KIDTENTRY表结构的开始地址，也指向0号中断，将0号中断的ExtendedOffset 和Offset组合成地址，就是0号中断处理函数地址。而这个函数位于ntoskrnl.exe中，因此该空间在ntoskrnl.exe进程空间中，在这个地址对齐（&0x00F000）处理后只需要每次减0x1000，然后比较前两位的PE(MZ)文件标识，最后一定能找到ntoskrnl.exe的基地址地址。

2.2.  寻找ntoskrnl.exe基地址

2.3  0号中断结构信息
    找到ntoskrnl.exe的基地址后，利用应用层常用的查找函数地址方式查找ntoskrnl.exe导出表中的函数地址（此代码中的所有函数名和文件名都采用了hash处理），分别是
1，  ExAllocatePool
2，  ExFreePool
3，  ZwQuerySystemInformationEx

2.4  根据hash 获取函数地址
函数寻找完成后，便是将后门程序hook到SrvTransaction2DispatchTable表中的函数SrvTransactionNotImplemented地址上，至于为什么要挑选这个函数我认为主要有以下三个原因：
1， 不增加无关网络协议连接，直接利用SMB协议进行数据传输（可以达到隐藏流量的目的，估计这也是为什么到公布了利用工具后才发现漏洞的原因）。
2， 通过查看SrvTransaction2DispatchTable表结构，我们有两个函数在这个表中出现了两次以上SrvSmbFsct1（3次）和SrvTransactionNotImplemented （2次），因此这两个函数更有利于hook。
3， 如果hook到SMB协议的常用处理函数， 那么这个函数的调用会比较频繁，那么处理过程就相对要复杂很多。而SrvTransactionNotImplemented的调用时在发送非正常Trans2 Request请求时才会调用，在正常情况下执行到这个函数的概率很小。