|
Windows操作系统作为PC上最普及的操作系统，面向的用户各种各样，因此在版本升级时，对比其它操作系统，兼容性都要做得好，不需要用户费神DIY处理一些BUG。 64位windows上市后大多以前32位的程序依旧正常地运行，当然这里主要指用户态程序。那64位windows是如何支持32位程序运行的呢？之前在看《windows核心编程》一书时只知道这个机制的名字叫wow64，但是具体如何实现的一无所知。为此我上网查阅资料，结果相关文章都讲得很笼统，包括Microsoft官方文档也是从很上层架构上进行了介绍，对于搞逆向的人来说，只了解架构不看代码怎么能忍，windows就在手边，何不亲自研究窥探一把庐山面目呢？说搞就搞，从代码的角度看一下这个wow64的大概。 这里插一句，其实在着手了解wow64机制前，是另外一个问题先引起了我的好奇：64位CPU比32位CPU除了每个寄存器宽度多了32bit，还多了几个通用寄存器：R8, R9, R10, R11, R12, R13, R14, R15，那32位程序在win64上运行时这些新加的寄存器就没用了吗？这个问题最后也会得到解决。 首先，先从宏观分析一下，32位程序的运行需要软硬件两个大方面的支持： 1）硬件上，CPU的解码模式需要是32位模式。64位CPU（我只熟悉INTEL的）是通过GDT表中CS段所对应的表项中L标志位来确定当前解码模式的。这里不展开描述GDT表与CPU运行模式的关系，感兴趣的可以参看http://www./hacker/program/9875.html 2）软件上，操作系统需要提供32位的用户态运行时环境（C库，WINDOWS API）对32位程序支持，其次因为win64内核是64位模式的，所以32位运行时环境在与64位内核交互时需要有状态转换。 当然另外肯定还有大量其它的兼容32位软件所需要实现的功能，比如资源管理，句柄管理，结构化错误管理等等，这些属于细节就不进行研究了，我这里先看一个大体。 好了，接下来针对上面的分析进行探索。关于32位运行时环境这点，可以在c:/windows/syswow64中发现许多和c:/windows/system32下同名的动态链接库，如kernel32.dll, ntdll.dll, msvcrt.dll, ws2_32.dll等，其实这些都是32位的版本。像wow64名字所传达的含义一样，syswow64文件夹下的这些库相当于在64位windows中构建了一个32位windows子系统环境，我们32位的程序能正常在win64上运行正是靠这个子环境负责与64位环境进行了交互和兼容，所以需要重点探究下这个32位子环境是如何与win64环境交互的。 我这里用到的工具是 PCHunter 与调试器 MDebug，静态分析工具 IDA。 了解 windows 的读者都知道 ntdll.dll 是用户态与内核态交互的桥梁，所以我选择从 ntdll.dll 入手，选择了逻辑简单的 NtAllocateVirtualMemory 函数。首先看一下原生32位操作系统里这个函数是什么样的。我手头有个 win8 32bit 版本，利用 MDebug 直接转到 NtAllocateVirtualMemory 函数查看反汇编，可以看到，在设置好调用号 0x19B 之后直接就使用 sysenter 进行了系统调用，中间没有其它操作，下面是相应的反汇编代码： NtAllocateVirtualMemory: 7778F048 mov eax, 0x19B 7778F04D call sub_7778F055(7778F055) 7778F052 ret 0x18 sub_7778F055: 7778F055 mov edx, esp 7778F057 sysenter 7778F059 ret 看完原生32位操作系统里的样子，win64 中运行一个 32 位程序时它的进程空间里的 NtAllocateVirtualMemory 是一番什么情景呢？我手头有 win7 64bit 版，运行的一个32bit程序进行调试，可以看到 NtAllocateVirtualMemory 的形式如下： NtAllocateVirtualMemory: 77C8FAD0 mov eax,0x15 77C8FAD5 xor ecx,ecx 77C8FAD7 lea edx,[esp+0x4] 77C8FADB call dword ptr fs:[000000C0] 77C8FAE2 add esp,4 77C8FAE5 ret 0x18 OK，区别很明显，wow64中的 ntdll.dll 与原生32位 windows 中的 ntdll.dll 有了变动，它不再是与内核交互的最后一个用户态模块，而是call 进了fs:[C0]处的函数，隐约感觉这里就是打开wow64秘密的入口。fs:[C0] 是什么呢？Windows操作系统中，fs寄存器用于记录线程环境块TEB，根据TEB结构体定义可以看出0xC0偏移处的定义为：
其实在wow64之前还有wow32机制，用于兼容16位程序在32位windows上运行，与wow64异曲同工。所以 windows 系统在 wow64 中直接也拿这个保留位置用于进行32位64位环境切换的跳板。单步跟进，发现fs:[C0]处只有一行代码：
这里是一个长跳转，目的地址是内存752B271E处，但是MDebug调试器显示752B271E处于未知模块。这时需要借助PCHunter，通过PcHunter发现该地址其实位于一个叫wow64cpu.dll的模块中，值得注意的一点是，该模块来自 system32 而非 syswow64 目录，是64位的文件模块，也就是说，wow64下32位程序的进程空间内同时加载了32位与64位的可执行文件模块！在这个32位程序的进程空间里一共有4个来自 SYSTEM32 目录64位的“客人”： 终于，这里有了真正的64位 ntdll.dll 的出现。所以很容易可以推断，wow64.dll, wow64win.dll, wow64cpu.dll 组成了环境转换模块，而最终依然是ntdll.dll 负责与内核交互，wow64中这4个模块在默默地在后台支持着32位程序的运行。 上面说到这里经历了一个长跳转，段寄存器由0x23变换为0x33，在win64中，0x23和0x33所对应的GDT表项中CPU的模式分别为32位与64位。自此，CPU解码模式由32位切换为64位。当然，故事还没结束。不过由于调试器是32位，无法准确捕获接下来发生的事情，单步跟进也没用了，我们转为使用IDA静态分析。 找到 752B271E 所对应的 wow64cpu.dll 中的位置： 00000000752B271E mov r8d,[esp] //取出返回地址 00000000752B2723 mov [r13+0xBC],r8d //保存返回地址 00000000752B272A mov [r13+0xC8],esp //保存32位环境堆栈指针 00000000752B2731 mov rsp,[r12+0x1480] //切换至64位环境堆栈 00000000752B2739 and qword ptr [r12+0x1480],0x0 00000000752B2742 mov r11d,edx 00000000752B2745 jmp qword ptr [r15+rcx*8] 第一句读取[esp]的值其实是把返回地址取出，接着保存到了r13所指向的地方，同时还保存了esp，然后重新赋值了rsp。看了这一小段，我们基本可以猜测到，在wow64中那个幕后的64位环境里其实是有自己的堆栈和执行上下文的，在CPU由32位切换到64位后，堆栈也相应切换。好了，下面要搞最后一句跳向了哪里，也就是[r15+rcx*8]的值，我们上面考察的 NtAllocateVirtualMemory 有 xor ecx, ecx 的操作，所以到这里时rcx = 0，所以就我们考察的例子而言，最后就是跳转到了[r15]。 那，r15的值是多少？ 这是有点棘手的问题。Wow64中32位程序只能由32位调试器调试，但是32位调试器下又无法获得64位模式下才可见的r15的值，怎么办？我这里使用shellcode的方式，利用32位MDebug调试shellcode的功能调试精心准备的一段shellcode，这段shellcode的作用独特而简单：让CPU切换到64位模式下“潇洒走一回”，将R8 ~R15的值记录到堆栈中，接着切换回32位模式。 shellcode的二进制为： \x6A\x33\xE8\x00\x00\x00\x00\x83\x04\x24\x05\xCB\x48\xB8\x88\x77\x66\x55\x44\x33\x22\x11\x50\x41\x50\x41\x51\x41\x52\x41\x53\x41\x54\x41\x55\x41\x56\x41\x57\x50\xE8\x00\x00\x00\x00\xC7\x44\x24\x04\x23\x00\x00\x00\x83\x04\x24\x0D\xCB 它的反汇编如下： /*开始时CPU处于32位模式*/ Push 0x33 // cs = 0x33 Call L1 L1: add [esp], 5 retf // far ret，切换CPU状态 /*此时CPU处于64位模式*/ mov rax, 1122334455667788h //将r8~r15用特殊值与周边数据隔开，方便查看 push rax push r8 push r9 push r10 push r11 push r12 push r13 push r14 push r15 push rax Call L2: L2: mov [esp + 4], 0x23 // cs = 0x23 add [esp], 0xd retf 虽然32位调试器无法对64位代码运行时下断，但是可以在切换回32位模式后的地方下断点。所以在这段代码后下一个断，运行代码。执行完毕后，查看一下堆栈上的收获： 地址 内容 0018FEA0 1122334455667788 0018FEA8 00000000752B2450 r15 0018FEB0 000000000008EC80 r14 0018FEB8 000000000008FD20 r13 0018FEC0 000000007EFDB000 r12 0018FEC8 0000000000000246 r11 0018FED0 0000000000000000 r10 0018FED8 0000000077C8FAFA r9 0018FEE0 000000000000002B r8 0018FEE8 1122334455667788 Bingo！我们成功获得到了32位程序运行环境下R8~R15的值，根据R15的值定位出它同样位于wow64cpu.dll文件模块内，根据R15的值 找到wow64cpu.dll中相应的位置，发现是指向了一堆函数指针： .text:0000000078B62450 dq offset TurboDispatchJumpAddressEnd .text:0000000078B62458 dq offset sub_78B62DBA .text:0000000078B62460 dq offset sub_78B62BCE .text:0000000078B62468 dq offset sub_78B62D6A //后面还有很多函数指针，此处省略 其实在第一次打开wow64cpu.dll寻找752B271E位置时，就可以看到它附近有一个名为CpuSimulate的函数，里面有这样的操作： .text:0000000078B625F9 mov r12, gs:30h .text:0000000078B62602 lea r15, off_78B62450 可以看到r15是指向了偏移78B62450处，对应动态加载后就是752B2450。所以这也印证了我们的实验结果。另外还可以看到的一点是r12指向了64位下的TEB(64位下gs段寄存器用于记录TEB结构)。 所以很显然，[r15]是指向了TurboDispatchJumpAddressEnd处，就是上文jmp qword ptr [r15+rcx*8]所要跳转到的地方（因为ecx = 0），看一下它的代码： TurboDispatchJumpAddressEnd: .text:0000000078B62749 mov [r13+0A4h], esi .text:0000000078B62750 mov [r13+0A0h], edi .text:0000000078B62757 mov [r13+0A8h], ebx .text:0000000078B6275E mov [r13+0B8h], ebp //保存32位环境下的寄存器 .text:0000000078B62765 pushfq .text:0000000078B62766 pop rbx .text:0000000078B62767 mov [r13+0C4h], ebx //保存32位环境的eflags .text:0000000078B6276E mov ecx, eax //调用号 .text:0000000078B62770 call cs:Wow64SystemServiceEx //继续完成未尽竟的事业 .text:0000000078B62776 mov [r13+0B4h], eax .text:0000000078B6277D jmp loc_78B62611 上面的代码最后跳转到78B62611，loc_78B62611的代码如下： text:0000000078B62611 loc_78B62611: .text:0000000078B62611 and dword ptr [r13+2D0h], 1 .text:0000000078B62619 jz loc_78B626CE .text:0000000078B6261F movaps xmm0, xmmword ptr [r13+170h] .text:0000000078B62627 movaps xmm1, xmmword ptr [r13+180h] .text:0000000078B6262F movaps xmm2, xmmword ptr [r13+190h] .text:0000000078B62637 movaps xmm3, xmmword ptr [r13+1A0h] .text:0000000078B6263F movaps xmm4, xmmword ptr [r13+1B0h] .text:0000000078B62647 movaps xmm5, xmmword ptr [r13+1C0h] .text:0000000078B6264F mov ecx, [r13+0B0h] .text:0000000078B62656 mov edx, [r13+0ACh] .text:0000000078B6265D and dword ptr [r13+2D0h], 0FFFFFFFEh .text:0000000078B62665 mov edi, [r13+0A0h] .text:0000000078B6266C mov esi, [r13+0A4h] .text:0000000078B62673 mov ebx, [r13+0A8h] .text:0000000078B6267A mov ebp, [r13+0B8h] .text:0000000078B62681 mov eax, [r13+0B4h] //恢复32位环境寄存器 .text:0000000078B62688 mov [r12+1480h], rsp //保存64位环境堆栈指针 .text:0000000078B62690 mov [rsp+0B8h+var_B0], 23h .text:0000000078B62697 mov [rsp+0B8h+var_98], 2Bh .text:0000000078B6269E mov r8d, [r13+0C4h] //之前保存的32位环境eflags .text:0000000078B626A5 and dword ptr [r13+0C4h], 0FFFFFEFFh .text:0000000078B626B0 mov [rsp+0B8h+var_A8], r8d .text:0000000078B626B5 mov r8d, [r13+0C8h] .text:0000000078B626BC mov [rsp+0B8h+var_A0], r8 .text:0000000078B626C1 mov r8d, [r13+0BCh] .text:0000000078B626C8 mov [rsp+0B8h+var_B8], r8 .text:0000000078B626CC iretq //排好堆栈，返回至32位模式返回地址处 可以看到，在 TurboDispatchJumpAddressEnd 代码片段中，调用了一个外部函 Wow64SystemServiceEx，由这个函数再继续把下面的事情做完，最终调用64位的 ntdll.dll 的 NtAllocateVirtualMemory 来完成整个操作。TurboDispatchJumpAddressEnd 最后跳转至78B62611，将CPU主要寄存器值恢复至之前保存好的32位环境中的值，同时在堆栈中排布好返回地址，cs段寄存器值，eflag值，执行iretq，返回至32位环境中，在我们的例子中，即返回到 NtAllocateVirtualMemory 中 call dword ptr fs:[C0] 的下一句，看起来像真的执行了一个普通函数一样。上面讲到跳转的函数指针表是根据r15+rcx*8来得到的，在32位进程空间的那个ntdll.dll里面 call dword ptr fs:[C0] 前都有对ecx的赋值，我们可以推测在wow64中，系统调用被分成多类，类别号存在于rcx中，根据rcx的值来进行不同类别的模拟转换。 Wow64SystemServiceEx 做的事情就暂时不详细研究了，感兴趣的可以细细钻研。 对这次简单的wow64之旅做个小总结： 1) windows/syswow64目录下的大量DLL库与SYSTEM32目录下的wow64.dll, wow64cpu.dll, wow64win.dll, ntdll.dll 支撑着wow64机制。 2) Wow64下32位进程中实际有32位和64位两个逻辑子空间，每个子空间都 有各自的数据结构、堆栈，64位子空间负责与操作系统内核交互： 32位用户态模式 <---------> 64位用户态模式 <------------------> 64位内核 3)Wow64模式下，那些不可见的寄存器并不都是闲置不用的，在切换到64位环境后全部启用，和正常64位程序无差别。且经过分析可以知道有确切作用的寄存器有： R12: 指向64位环境的TEB结构体 R13：指向保存32位环境CPU的状态的位置 R15: 指向跳转函数指针列表的起始 上面是针对win7下做的一个wow64机制小探索，我也简单看了下在win8和win10下的wow64过程，在反汇编代码上有些小不同，但是逻辑原理是完全相同的，感兴趣的读者可以搞一把。 PS：写完后发现windbg可以通过wow64的扩展组件更好地调试wow64程序。吐血。。。。。。
本文由看雪论坛 mrMORE 原创 转载请注明来自看雪社区 热门阅读 |
|
|
