WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

  • A+
所属分类:逆向工程

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

 

在本文中,我们将为读者详细介绍WOW64子系统运行机制及其Hooking技术。

Microsoft公司一直以其向后兼容性而闻名。几年前,当他们推出Windows的64位版本时,他们需要提供与现有32位应用程序的兼容性。为了实现32位和64位应用程序的无缝衔接,WoW(Windows on Windows)系统便应运而生了;在本文中,我们将其称为“WOW64”,它负责将所有Windows API调用从32位用户空间转换为64位操作系统内核。本文主要分为两个部分。首先,我们将深入研究WOW64系统本身。为此,我们将考察一个来自32位用户空间的调用,并跟踪它最终过渡到内核的步骤。在本文的第二部分,我们将考察两种hooking技术及其有效性。我将介绍该系统的工作原理,恶意软件滥用它的方式,并详细介绍一种机制,通过这个机制可以从用户空间钩住所有WoW系统调用。请注意,文中的所有信息对于Windows 10, version 2004之后的版本来说起都是正确的;而在某些情况下,与较旧的Windows版本的实现方式可能存在差异。

 

声明

首先,这是一个已有多位作者研究过的课题。也就是说,虽然本文对高效探索WOW64内部机制至关重要,但是,如果这些作者不公开发布其出色的研究成果,那么,我们将不得不花费更多的研究时间。本文参考的文献包括:

  1. (Wbenny): 关于ARM架构WOW64内部结构及其运行机理的详细阐述。

  2. (ReWolf):一个PoC天堂之门的实现代码。

  3. (JustasMasiulis):一个非常简洁的C++天堂之门实现代码。

  4. (MalwareTech):详细解释了WOW64的分段机制。

 

WOW64系统的内部工作原理

为了了解WOW64系统的内部运行机制,我们需要考察来自32位用户模式的调用序列,是如何通过系统DLL映射到内核空间的对应代码的。在这些系统DLL中,操作系统将检查相关的参数,并最终将其传递给名为syscall stub的存根函数。这个syscall stub负责将用户空间的调用转换为内核中的API调用。在64位系统中,syscall stub的实现方法非常简单,因为它会直接执行syscall指令,具体如图1所示:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图1 WOW64系统的Syscall Stub

图2显示了运行在WOW64上的32位进程的syscall stub:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图2 本地x64 syscall stub

注意,在WOW64版本中,调用的是Wow64SystemServiceCall函数,而不是syscall指令。在WOW64系统中,由于通常情况下是会进入内核空间的,所以改为调用一个用户模式例程。我们可以在图3中看到,在这个Wow64SystemServiceCall函数中,会立即通过一个名为Wow64Transition的指针进行间接跳转:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图3:Wow64SystemService通过指针Wow64Transition进行跳转

需要注意的是,Wow64SystemServiceCall函数是在标为ntdll_77550000的ntdll模块中找到的;在这里,一个WOW64进程加载了两个ntdll模块,一个是32位的,一个是64位的。在WinDbg中,32位模块后面会带有其地址,以示区分。通常情况下,64位的ntdll模块位于%WINDIR%System32目录中,而32位的模块则位于%WINDIR%SysWOW64目录中。在PDB中,64位和32位的ntdll模块分别称为ntdll.pdb和wntdll.pdb,读者不妨尝试用反汇编器加载它们! 继续进行调用跟踪,如果我们查看Wow64Transition指针保存的内容,会发现其目标是wow64cpu!KiFastSystemCall。顺便说一下,请注意wow64cpu!KiFastSystemCall的地址是通过成员WOW32Reserved保存在32位TEB(线程环境块)中的,虽然它与这里的跟踪操作无关,但了解这一点还是很有用的。在图4中,我们看到的是KiFastSystemCall的主体代码:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图4 KiFastSystemCall通过段选择器0x33切换到x64模式。

KiFastSystemCall使用0x33段选择器跳转到指令后的内存位置处。这个0x33段通过GDT条目将CPU切换到64位模式,具体如(MalwareTech)所述。

让我们回顾一下对于调用的跟踪情况。我们首先从ntdll中的一个NtResumeThread调用开始出发。这个函数将调用Wow64SystemServiceCall函数,而后者会执行Wow64Transition函数。最后,由KiFastSystemCall函数完成从32位运行模式到64位运行模式的过渡,具体流程如图5所示:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图5 从32位到64位的过渡过程

用于实现CPU模式切换的跳转指令的目标是图6所示的64位代码:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图6 KiFastSystemCall的目标代码

图6显示了到目前为止,我们在这个调用跟踪中看到执行的第一条64位指令。为了理解它,我们需要看看WOW64系统是如何初始化自己的。关于这方面的详细解释,请参考(wbenny)。现在,我们可以看看wow64cpu!RunSimulatedCode中的重要部分:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图7 保存在RunSimulatedCode中的64位寄存器

图7描述了对64位TEB的检索,它用于访问槽位索引(slot index)1处的Thread Local Storage。然后,将一个函数指针表移入寄存器r15中。实际上,检索到的TLS数据是一个未公开的数据结构WOW64_CPURESERVED,它包含了WOW64层用来设置和恢复32位和64位边界的寄存器数据和CPU状态信息。在这个结构体中,还有一个WOW64_CONTEXT结构体,微软网站上提供了部分文档。我在本篇文章的最后给出了这两个结构体。我们将在后面介绍如何使用这个上下文结构,但是为了理解前面的jmp指令,我们只需要知道r15存放的是一个函数指针表的地址即可。

现在,我们还需要留意WOW64层的架构。从64位内核的角度来看,32位(Wow64)用户模式应用程序的运行过程本质上就是一个大的while循环。这个循环在处理器的32位执行模式下执行x86指令,并偶尔退出循环来运行系统调用。因为内核是64位的,所以这时处理器模式会暂时切换到64位,以提供系统调用服务,然后,处理器将切换回原来的模式,从暂停的地方继续循环。也就是说,WOW64层的作用就像一个模拟器,但是其中的指令都是在物理CPU上执行的。

回到图6中我们看到的jmp指令,现在我们知道发生了什么。指令jmp [r15 + 0xF8] 相当于C代码jmp TurboThunkDispatch[0xF8/sizeof(uint64_t)]。观察这个索引处的函数指针,我们可以找到函数wow64cpu!CpupReturnFromSimulatedCode(图8)。

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)
图8 TurboThunk表的最后一个函数指针条目是一个exit例程

这个例程负责将32位寄存器的状态保存到我们之前提到的WOW64_CONTEXT结构体中,并获取syscall的参数。这里有一些棘手的问题,所以让我们来详细研究一下。首先,通过xchg将堆栈指针移到r14中,这个位置的值将是调用Wow64SystemServiceCall的syscall stub的返回地址。然后,堆栈指针r14递增4,以获得一个指针,该指针指向在恢复所有这些上下文值时堆栈应该重置的位置。然后,这两个值分别保存到上下文的EIP和ESP变量中。然后,让r14堆栈指针再递增一次,以得到__stdcall参数的位置(记住stdcall是通过堆栈传递所有参数的)。这个参数数组对以后很重要,所以要记住它。之后,将参数指针移到r11中,所以在C语言中,这意味着r11相当于一个堆栈槽的数组,每个槽是一个参数uint32_t r11[argCount]。最后,保存其余的寄存器和EFlags。

一旦保存了32位上下文,WOW64层就会通过获取syscall编号的高16位来计算要调用的TurboThunk,并派发到该thunk。需要注意的是,在这个数组的开头是图9所示的函数TurboDispatchJumpAddressEnd,它是为不支持TurboThunks的函数而调用的。

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图9 TurboThunk表的第一个函数指针条目是一个entry例程

关于TurboThunks,建议读者仔细阅读wbenny撰写的相关文章。为了照顾没有读过这篇文章的读者,我们总结一下这篇文章的大意:对于那些参数宽度<= sizeof(uint32_t)的简单函数,WOW64层会直接通过零扩展或带符号的扩展将这些参数拓宽到64位,然后直接通过系统调用进入内核模式。这一切都发生在wow64cpu中,而不是执行如下所述的更复杂的路径。这就起到了优化的作用。对于不支持TurboThunks的复杂函数,可以使用TurboDispatchJumpAddressEnd存根函数,以派遣到wow64!SystemServiceEx执行系统调用,具体如图10所示。

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图10 复杂的系统调用要经过Wow64SystemServiceEx例程

稍后,我们将介绍这个例程,因为它是本文的重点内容,但现在让我们跟踪调用流程。当Wow64SystemServiceEx运行系统调用并返回后,eax寄存器中的返回值就会被移动到WOW64_CONTEXT结构体中,并恢复32位寄存器的状态。为此,有两种路径,一种是常见的情况,一种是似乎只存在于NtContinue和其他WOW64内部的情况。至于选择哪种恢复路径,要视从TLS槽中检索到的WOW64_CPURESERVED结构体开头的一个标志而定,具体如图11所示:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图11 系统调用完成后恢复CPU状态,这时,有一个简单的路径和一个复杂的路径来处理XMM寄存器

更简单的情况是创建一个jmp,在恢复WOW64_CONTEXT中所有已保存的寄存器后,将使用段选择器0x23转换为32位模式。在较为复杂的情况下,还会额外恢复一些段、xmm值以及WOW64_CONTEXT结构中保存的寄存器,然后通过iret转换为32位模式。在正常情况下,构建的jmp如图12所示:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图12 通过动态构建的jmp切换到32位模式

至此,我们的调用跟踪已完成。WOW64层已切换回32位模式,并将在我们开始使用的syscall stub中的Wow64SystemServiceCall之后的ret处继续执行。在了解了WOW64层本身的执行流程后,接下来,让我们开始考察之前提到的Wow64SystemServiceEx调用。

图13展示了Wow64SystemServiceEx例程中的一些逻辑,我们稍后将用到它们:

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

图13 分派系统调用之前和之后调用的日志记录例程

该例程首先会查询服务表,该服务表保存有指向例程的指针,这些例程将传递的参数数组转换为常规64位系统模块期望的64位类型。这个参数数组正是存放在r14中的栈槽(stack slot)。

这里有两个对LogService函数的调用,但是只有在动态库%WINDIR%system32wow64log.dll已被加载且导出了Wow64LogInitialize、Wow64LogSystemService、Wow64LogMessageArgList和Wow64LogTerminate函数的情况下,这些调用才能正常生效。不过,在默认情况下,Windows系统中并没有包含这个动态库;要将这个动态库放入上述目录,需要具有管理员权限。

下一节将详细介绍如何使用该日志记录DLL来hook通过这个wow64layer进行模式切换的系统调用。因为在服务系统调用前后都会调用日志记录例程LogService,所以,我们可以实现一种标准的内联hook风格的回调函数,来检查其参数和返回值。


小结

在本文中,我们为读者详细介绍了WOW64子系统的内部运行机制,在下一篇文中,我们将继续为读者介绍WOW64子系统的Hooking技术。

译文声明

译文仅供参考,具体内容表达以及含义原文为准。

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)


戳“阅读原文”查看更多内容

本文始发于微信公众号(安全客):WOW64!Hooks:深入考察WOW64子系统运行机制及其Hooking技术(上)

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: