禁用copy on write实现全局EAT HOOK
以前写过一个，但是一不小心删除了，哎，就当再次复习复习吧。
首先抛出一个有意思的问题：
已知所有Windows可执行文件exe都会链接子系统ntdll.dll，那么真实内存中有几份ntdll.dll？
答案很显然只有一份！所有的exe都是映射的同一份物理内存！
那么又有一个新问题：
我如果对一个进程下的ntdll.dll导出表进行hook,作用域范围是当前进程还是所有进程呢？
有很多人在没有实践下或许会认为是所有进程，可是真正结果是作用域只是在本进程内！
为什么会出现这种情况呢？不是内存中只有一份ntdll.dll吗？
其实原因就在于Windows的copy on write机制！
copy on write 大致原理：
应用程序启动多个实例，这多个进程的地址空间中，应用程序部分地址空间对应到physical storage上，都是一份（memory map的）。所以，如果一个实例尝试修改一个全局或静态变量时，如果没有copy-on-write，这个变量就会被污染。所以windows在使用 memory map装载应用程序时，对全局和静态变量识别，然后给存放这些变量的page设上copy-on-write属性，这样当一个实例尝试修改一个全局或静态 变量时，一个exceptin产生，windows捕获然后重新分配page出来给该实例使用，从而避免了污染。DLL的处理方式和这个是一模一样的。
也就是说当有程序改变公用的dll内存页时，操作系统会copy出来一份一模一样的来让程序write！所以要想实现理想中的全局EAT，必须得禁用copy-on-write！
那么如何禁用copy-on-write呢？
首先我们必须得了解Windows的内存管理以及虚拟内存与物理内存的转换过程，因为开启/关闭copy-on-write是页表PTE的一个标志位。
虚拟内存与物理内存的转换：
下面以32位Windows操作系统，未开启PAE物理地址扩展为例，分析下Windows虚拟地址与物理地址的转换问题：
首先我们看看intel手册的经典图例：
一个内存地址如图4字节32位，高10位代表页面录得索引，中间10位代表页表的索引，最后低12位代表页内偏移。
Windows的页表与页目录是连续的，可以看成一维数组，数组每一项的大小是4个字节。
0xC0300000 页目录即被映射到这个地址上，页目录本身为一页，具有1024个页目录项，每一项为4字节，整个页目录的大小为4k。每一个页目录项都描述一张页表。
0xC0000000 所有的页表都将从该地址开始映射，每4kb为一个页表，每个页表1024个项，每项描述4k的内存页，因此每个页表应当描述： 1024个页表项*4kb = 4M ，4M大小的内存，共1024张页表，因此这些页表描述了整个4G内存地址空间。而每个页表项与页目录项一样，仅占用4个字节的地址空间，因此每一张页表的占内存的大小为: 1024个页表项*4字节 = 4KB。
那么我们就可以得到一个换算公式：
1.PDE = PDBR[Directory];
2.PTE = PDE + Table * 4;
3.PA = PTE + Offset;
在Windbg上完全可以很简单的得到验证。
下面我们来看一看具体获得PDE与PTE的代码
Pde = ( ((VirtualAddress)>>20) & 0xFFC ) + 0xC0300000; Pte = ( ((VirtualAddress)>>10) & 0x003FFFFC ) + 0xC0000000;
似乎与我们所推论的不太一样，为什么Pte的计算不需要用到pde？
这是因为物理地址是不能直接访问的。也就是这个所在页表的起始物理地址(PDE)，是不能访问的，因此我们没有办法通过得到的PDE地址去访问一个页表。既然页表都访问不了，那么久不可能获得一个PTE。所以这时候就需要进行变通了。所以用到了一个很有意思的数学问题：
我们可以看到：
当虚拟地址寻址页目录为第0项的时候，其页表地址其实是从第0张页表开始的，
当虚拟地址寻址页目录为第1项的时候，其页表地址其实是从第1张页表开始的。
当虚拟地址寻址页目录为第2项的时候，其页表地址其实是从第2张页表开始的。
接下来我们可以得知：
当虚拟地址寻址页目录为第0项的时候，其页表地址实际跨越了0个页表项，
当虚拟地址寻址页目录为第1项的时候，其页表地址实际跨越了1024个页表项。(跨过了第0张页表的1024个页表项)
当虚拟地址寻址页目录为第2项的时候，其页表地址实际跨越了2048个页表项。(跨过了第0张页表的1024个页表项和第1张页表的1024个页表项)
现在我们来试着计算一个地址：
假设地址： 0x00401000
该地址二进制形式为：10000000001000000000000
取其高10bit 0000000001 (页目录牵引第一项)
取其中10bit 0000000001 (页表牵引 第一项)
其低12bit为0，即页对齐，这里为了简单点说明，因此没有页内偏移。
我们按照上面得出的结论，以页表项为最小单位进行计算，0000000001为第一个页目录项，即其指向了第一张页表，针对所有页表的总基址而言，这张页表的所处位置已经跨越了1024个页表项(属于第0张页表的1024个页表项)，所以我们可以写出：
0000000001 * 1024个页表项 * 4(每个页表项4字节) = 4096个字节。
即相对于所有页表的总基址0xC0000000的偏移。
现在我们得到了页表的地址，接下来再看中10bit 的0000000001，其含义为我们需要的是这张页表中的第1项，因为不是使用第0项，所以我们略过第个0页表项所占用的4个字节。取第一项即得到该虚拟地址真实所在的内存页物理地址。
总结为：
页表项相对页表总基址的偏移为 = 4096个字节 + 4个字节 = 4100个字节。
好，接下来我们用作者的方式来计算这个偏移：
0x00401000 右移 12位后 等于 0x401
0x401 * 4 = 0x1004 = 4100个字节。
结果是很明显的，是正确的。
页目录与页表
的结构：
得到的页表后只需要把第1位置为1就可以停止此页面的copy on write机制了
NTSTATUS DispatchIoctl(PDEVICE_OBJECT pDevObj, PIRP pIrp) { NTSTATUS status = STATUS_INVALID_DEVICE_REQUEST; PCOPY_ON_WRITE_MEMORY pMM ; ULONG ulMemSize=0; PVOID pMem=0; ULONG ulPDEB=0; ULONG ulPTEB=0; BOOLEAN bPDEB=FALSE; BOOLEAN bPTEB=FALSE; ULONG ulPDE=0; ULONG ulPTE=0; BOOLEAN bPDE=FALSE; BOOLEAN bPTE=FALSE; BOOLEAN PAE = FALSE; // 取得IRP的I/O堆栈指针 PIO_STACK_LOCATION pIrpStack = IoGetCurrentIrpStackLocation(pIrp); // 取得I/O控制码 ULONG uIoControlCode = pIrpStack->Parameters.DeviceIoControl.IoControlCode; // 取得I/O缓冲区指针和它的长度 PVOID pIoBuffer = pIrp->AssociatedIrp.SystemBuffer; ULONG uInSize = pIrpStack->Parameters.DeviceIoControl.InputBufferLength; ULONG uOutSize = pIrpStack->Parameters.DeviceIoControl.OutputBufferLength; // 获取缓冲区 pMM = (PCOPY_ON_WRITE_MEMORY)pIoBuffer; // 获取待修改数据区地址和大小 pMem = pMM->Base; ulMemSize = pMM->Size; DbgPrint("memory : 0X%08X \n", pMem); PAE=ExIsProcessorFeaturePresent(PF_PAE_ENABLED); if(PAE==TRUE) { DbgPrint("PAE page mode.\n"); // 按照PAE page mode尝试计算PDE和PTE,并查看虚拟地址是否在同一页面 //要修改的地址起始处 ulPDEB = ( (((ULONG)pMem)>>18) & 0x3FF8 ) + 0xC0600000; ulPTEB = ( (((ULONG)pMem)>>9) & 0x7FFFF8 ) + 0xC0000000; bPDEB = MmIsAddressValid((PVOID)ulPDEB); bPTEB = MmIsAddressValid((PVOID)ulPTEB); //要修改的地址后边界 ulPDE = ( ((((ULONG)pMem+ulMemSize))>>18) & 0x3FF8 ) + 0xC0600000; ulPTE = ( ((((ULONG)pMem+ulMemSize))>>9) & 0x7FFFF8 ) + 0xC0000000; bPDE = MmIsAddressValid((PVOID)ulPDE); bPTE = MmIsAddressValid((PVOID)ulPTE); if ((bPDEB && bPTEB && bPTE)) { DbgPrint("PDE(%d) : 0X%08X -> 0X%08X\n", bPDEB, ulPDEB, *(PULONG)ulPDEB); DbgPrint("PTE(%d) : 0X%08X -> 0X%08X\n", bPTEB, ulPTEB,ulPTE ); } else return STATUS_UNSUCCESSFUL; } else { DbgPrint("Non PAE page mode.\n"); // 按照Non PAE page mode尝试计算PDE和PTE ulPDEB = ( (((ULONG)pMem)>>20) & 0xFFC ) + 0xC0300000; //cr3寄存器起始地址 ulPTEB = ( (((ULONG)pMem)>>10) & 0x3FFFFC ) + 0xC0000000; bPDEB = MmIsAddressValid((PVOID)ulPDEB); bPTEB = MmIsAddressValid((PVOID)ulPTEB); ulPDE = ( (((ULONG)pMem+ulMemSize)>>20) & 0xFFC ) + 0xC0300000; ulPTE = ( (((ULONG)pMem+ulMemSize)>>10) & 0x3FFFFC ) + 0xC0000000; bPDE = MmIsAddressValid((PVOID)ulPDE); bPTE = MmIsAddressValid((PVOID)ulPTE); if ((bPDEB && bPTEB && bPTE)) { DbgPrint("PDE(%d) : 0X%08X -> 0X%08X\n", bPDEB, ulPDEB, *(PULONG)ulPDEB); DbgPrint("PTE(%d) : 0X%08X -> 0X%08X\n", bPTEB, ulPTEB, *(PULONG)ulPTEB); } else return STATUS_UNSUCCESSFUL; } switch(uIoControlCode) { case IOCTL_MODIFY_MEMORY: { // 禁用指定内存的Copy on write机制 if (bPTE==bPTEB)//物理页面是否存在有效 { *(PULONG)ulPTEB |=0x00000002; //修改PTE使指定页Copy on write机制失效 DbgPrint("The copy-on-write attrib in address 0X%08X has been forbidden!\n", pMem); status = STATUS_SUCCESS; } else { *(PULONG)ulPTEB |=0x00000002; *(PULONG)ulPTE |=0x00000002; DbgPrint("The copy-on-write attrib has been forbidden!\n"); status = STATUS_SUCCESS; } break; } case IOCTL_RECOVER_MEMORY: { // 恢复指定内存的Copy on write机制 if (bPTE==bPTEB) { *(PULONG)ulPTEB &= ~0x00000002; //修改PTE恢复指定页的Copy on write机制 status = STATUS_SUCCESS; } else { *(PULONG)ulPTEB &= ~0x00000002; *(PULONG)ulPTE &= ~0x00000002; status = STATUS_SUCCESS; } break; } } if(status == STATUS_SUCCESS) pIrp->IoStatus.Information = uOutSize; else pIrp->IoStatus.Information = 0; // 完成请求 pIrp->IoStatus.Status = status; IoCompleteRequest(pIrp, IO_NO_INCREMENT); return status; }
一般情况下，每个进程都加载了Kernel32.dll这个模块，并且绝大多数情况下Kernel32在每个进程中所加载的基址都一样，在物理内存中，也只有一份Kernel32的映象，所以可以让用户程序LoadLibrary后，把Kernel32的基地址发到Ring 0的驱动程序中，让驱动程序来修改相应PTE，禁了Copy-On-Write后再修改相应的API指令就行了，但是，为了防止某种可能，比如：之前有一个进程也对它进行了写操作，让系统中有了两份或多份Kernel32的映象，而在用户级LoadLibrary，最多只可能修改到某一个映象，所以，我从内核中枚举了所有的EPROCESS结构，再根据PEB_LDR_DATA结构中找到它的所加载的模信息，对其修改。 直接操作各个进程地址空间的数据，很不方便，可以用Windows 未公开API，KeAttachProcess， 函数来切换到指定进程的内存上下文环境。把CreateProcessW的入口处改成了JMP XXX，但是，跳到哪去呢？程序工作在Ring 0下，CreateProcessW不可能直接那里边的一个函数中的，但是，PE文件中每个节都会存在一些“空洞”，kernel32也不例外，就把代码Copy到Kernel32的某个节区的“空洞”中去吧。如果“空洞”太小，怎么办呢？可以把我们的代码写成一个DLL，在那个“空洞”中放上一小段代码来Load这个DLL。
