青春时代是一个短暂的美梦,当你醒来时,它早已消失得无影无踪了。
 
昨日:篇  今日:篇   总帖:篇   会员:
admin
夜月琉璃Lv18   
汇编里看Wow64的原理     

原文转自:https://bbs.pediy.com/thread-221236.htm  作者:mrMORE 


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.secbox.cn/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偏移处的定义为:

PVOID WOW32Reserved;  // 0C0
其实在wow64之前还有wow32机制,用于兼容16位程序在32位windows上运行,与wow64异曲同工。所以 windows 系统在 wow64 中直接也拿这个保留位置用于进行32位64位环境切换的跳板。单步跟进,发现fs:[C0]处只有一行代码:

752B2320   jmp         0033:752B271E

这里是一个长跳转,目的地址是内存752B271E处,但是MDebug调试器显示752B271E处于未知模块。这时需要借助PCHunter,通过PcHunter发现该地址其实位于一个叫wow64cpu.dll的模块中,值得注意的一点是,该模块来自 system32 而非syswow64 目录,是64位的文件模块,也就是说,wow64下32位程序的进程空间内同时加载了32位与64位的可执行文件模块!在这个32位程序的进程空间里一共有4个来自SYSTEM32 目录64位的“客人”:

Image


终于,这里有了真正的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过程,在反汇编代码上有些小不同,但是逻辑原理是完全相同的,感兴趣的读者可以搞一把。


 3  已被阅读了263次  楼主 2017-10-01 21:34:00
回复列表

回复:汇编里看Wow64的原理

桂公网安备 45010302000666号 桂ICP备14001770-3号
您的IP:54.160.153.233,2018-02-26 09:27:44,Processed in 1.0625 second(s).
免责声明: 本网不承担任何由内容提供商提供的信息所引起的争议和法律责任。
Powered by HadSky 5.4.1