按关键词阅读：
文章插图
在本文中 ， 我们将为读者详细介绍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内部机制至关重要 ， 但是 ， 如果这些作者不公开发布其出色的研究成果 ， 那么 ， 我们将不得不花费更多的研究时间 。 本文参考的文献包括：
- (Wbenny): 关于ARM架构WOW64内部结构及其运行机理的详细阐述 。
- (ReWolf)：一个PoC天堂之门的实现代码 。
- (JustasMasiulis)：一个非常简洁的C++天堂之门实现代码 。
- (MalwareTech)：详细解释了WOW64的分段机制 。
文章插图图1 WOW64系统的Syscall Stub
图2显示了运行在WOW64上的32位进程的syscall stub：
文章插图图2 本地x64 syscall stub
注意 ， 在WOW64版本中 ， 调用的是Wow64SystemServiceCall函数 ， 而不是syscall指令 。 在WOW64系统中 ， 由于通常情况下是会进入内核空间的 ， 所以改为调用一个用户模式例程 。 我们可以在图3中看到 ， 在这个Wow64SystemServiceCall函数中 ， 会立即通过一个名为Wow64Transition的指针进行间接跳转：
文章插图图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的主体代码：
文章插图图4 KiFastSystemCall通过段选择器0x33切换到x64模式 。
KiFastSystemCall使用0x33段选择器跳转到指令后的内存位置处 。 这个0x33段通过GDT条目将CPU切换到64位模式 ， 具体如(MalwareTech)所述 。
让我们回顾一下对于调用的跟踪情况 。 我们首先从ntdll中的一个NtResumeThread调用开始出发 。 这个函数将调用Wow64SystemServiceCall函数 ， 而后者会执行Wow64Transition函数 。 最后 ， 由KiFastSystemCall函数完成从32位运行模式到64位运行模式的过渡 ， 具体流程如图5所示：
文章插图
稿源：(未知)
【傻大方】网址：http://www.shadafang.com/c/111J2RB2020.html
标题：深入考察WOW64子系统运行机制及其Hooking技术（上）