Windows内核开发-9-32位和64位的区别

Windows内核开发-9-32位和64位的区别

32位的应用程序可以完美再64位的电脑上运行,而32位的内核驱动无法再64位的电脑上运行,或者64位的驱动无法在32位的应用程序上运行。这是为什么呢。

原因是在x64的Windows操作系统上,模拟了x86操作系统的操作,并且引入了一个WOW64子系统,将x86和x64完美进行兼容。

WOW64子系统

x86能在x64上运行全靠这个东西。全名叫做Windows On Windows,英文名感觉是在套娃,其实它的意思就是在Windows64上运行Windows32。

这个系统由Wow64.dll,Wow64Win.dll,Wow64Cpu.dll三个dll实现,具体怎么实现的不用考虑。

Wow64子系统可以完美实现x86和x64之间的转换。

转换流程: 当一个32位Application发起系统调用时,WOW64会拦截下来,将其转换为64位的类型(包括指针范围,数据类型范围等等),然后再把系统调用请求提交给内核。这整个拦截-转换的流程被称为"thunking"。

WOW64有两个重要的模块,一个是系统文件重定向(File System Redirector),一个是注册表重定向(Registry Redirector)。

系统文件重定向(File System Redirector)

Windows64位OS包含了两个System32文件,一个是System32另一个是SysWow64。默认情况下的安装路径%Windows%\System32和%Windows%\SysWow64。

System32这个文件里面保存了系统需要的一些二进制文件,System32里面存放的是x64的系统二进制文件,SysWow64里面存放的是x86里的文件。不要被这个什么system32迷惑成了它就是32位的系统文件了。

 

一般情况下32位的只能加载32位的系统dll,64只能加载64的。因为是64位的操作系统,所以肯定默认是加载64的dll,但是32位怎么办,为了解决这个问题WOW64就构成了文件系统重定向模块,把32的系统dll放到了SysWow64里面,然后把System32这个文件夹给他重定向指到了SysWow64文件夹里了。

这里我们写一个代码来验证一下:

void TestFileRedirector()
{
    HANDLE hFile = CreateFileA("C:\\Windows\\System32\\test.txt", GENERIC_READ | GENERIC_WRITE, 0x00000000, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE)
    {
        cout << "创建文件失败" << endl;
    }
    else
    {
        cout << "创建文件成功,文件名为test.txt" << endl;
    }
    CloseHandle(hFile);
}

 

假如说这个test文件是在SysWow64文件夹下面创建的,那么说明我们前面的讲述没问题,确实是重定向到了SysWow64里面。这里我们要用管理员启动Visual Studio才行,因为这个文件夹是系统文件夹,需要管理员权限。

下面是我的验证结果:

Windows内核开发-9-32位和64位的区别

 

 

在x86和x64运行后分别是在System32和SysWow64新建了文件,足以说明结论了。

关闭系统文件重定向

文件重定向固然不错,但是肯定有时候我们会不得不关闭它。

这里就会用到两个API:

BOOL Wow64DisableWow64FsRedirection(
  [out] PVOID *OldValue
);//关闭重定向,将原来的值保存到输入参数oldvalue里面
BOOL Wow64RevertWow64FsRedirection(
  PVOID OlValue
);//通过参数olvalue来恢复重定向

 

这里我们在修改一下我们的代码,让他x86的程序不要重定向到x64文件里面:

void TestFileRedirector()
{
    PVOID OldValue;
    auto ret = Wow64DisableWow64FsRedirection(&OldValue);
    if (ret == 0)
    {
        cout << "调用关闭重定向的函数失败,请检查" << endl;
        return;
    }
    else
    {
        cout << "调用重定向的函数成功,已经取消文件系统重定向" << endl;
    }
​
    HANDLE hFile = CreateFileA("C:\\Windows\\System32\\test.txt", GENERIC_READ | GENERIC_WRITE, 0x00000000, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE)
    {
        cout << "创建文件失败" << endl;
        return;
    }
    else
    {
        cout << "创建文件成功,文件名为test.txt" << endl;
    }
    CloseHandle(hFile);
    Wow64RevertWow64FsRedirection(OldValue);
}

 

这样再创建就是到System32系统文件夹里面了。

Windows内核开发-9-32位和64位的区别

 

 

有一部分文件是不会被重定向的:

%Windows%System32\catrrot
%Windows%System32\catrrot2
%Windows%System32\drivers\etc
%Windows%System32\logfiles
%Windows%System32\spool

 

注册表重定向(Registry Redirector)

和系统文件重定向(File System Redirecotr)比较类似,但是功能更为复杂。除了重定向还有注册表反射功能(Registry Reflection 该功能暂时用不到)。

和File System Redirector比较类似的是,win32访问HKEY_LOCAL_MACHINE\SOFTWARE会被重定向到HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node下面。同样写一下代码测试一下:

void TestRegRedirector()
{
    HKEY hKey = NULL;
    RegCreateKeyEx(HKEY_LOCAL_MACHINE, TEXT("Software\\Test"),
        0, NULL, 0, KEY_READ, NULL, &hKey,NULL);
    if (hKey != NULL)
    {
        cout << "创建注册表成功" <<endl;
        RegCloseKey(hKey);
    }
    else
    {
        cout << "创建注册表失败" << endl;
        return;
    }
}

 

用32位来运行,看他添加到哪里:

Windows内核开发-9-32位和64位的区别

 

 

当然也肯定有关闭的办法。

DIY注册表重定向

在创建注册表的API上加一个宏定义就可完美解决这个问题了:

    RegCreateKeyEx(HKEY_LOCAL_MACHINE, TEXT("Software\\Test"),0, NULL, 0, KEY_READ | KEY_WOW64_32KEY, NULL, &hKey,NULL);

 


这里的KEY_WOW64_32KEY就是32位,KEY_WOW64_64KEY就可以锁定为64位了。
void TestRegRedirector()
{
    HKEY hKey = NULL;
    RegCreateKeyEx(HKEY_LOCAL_MACHINE, TEXT("Software\\Test"),
        0, NULL, 0, KEY_READ | KEY_WOW64_32KEY, NULL, &hKey,NULL);
    if (hKey != NULL)
    {
        cout << "创建注册表成功" <<endl;
        RegCloseKey(hKey);
    }
    else
    {
        cout << "创建注册表失败" << endl;
        return;
    }
}

 

64位系统的升级技术

64对比32提供了很多新技术,比如之前的32位被很多程序很多公司,进行挂钩啊各种功能导致很不安全很麻烦。

PatchGuard

所以升级了一个PatchGuard技术,这个机制就是系统会定期检查内部的关键位置是否被篡改,一旦被篡改就会蓝屏。

比如一些论坛常见的SSDT(系统描述表),GDT(全局描述表),IDT(中断描述表)等等。但是其实也是可以绕过的。正所谓道高一尺魔高一丈就是这个意思,没有绝对的安全。

x64的编译、安装、运行

编译很简单,vs换成x64就行了。

安装的话著需要考虑32位exe安装驱动的时候不会把他放到64位驱动system32这个文件夹下就行了,这个用关闭File System redirecotr就行。

运行:x64的驱动必须得有签名才行,变相提高了安全吧,不过我们自己测试就把测试机变成测试模式就好了。

编程差异

x86和x64编程还是有少许区别的。

加入汇编

32位和64比较麻烦的就是不能直接内联汇编了,就比如说下面这段代码:

#include<ntddk.h>
​
​
extern "C"
NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject,PUNICODE_STRING RegistryPath)
{
    UNREFERENCED_PARAMETER(DriverObject);
    UNREFERENCED_PARAMETER(RegistryPath);
    __asm
    {
        int 3
    }
​
    return STATUS_SUCCESS;
}

 

一个很简单的内核驱动代码,用x64编译就不行,而x86没问题:

Windows内核开发-9-32位和64位的区别

 

 

也就是说不运行直接内联汇编了,只能用汇编asm写好了,然后作为函数的形式放进去了。

条件编译

WDK设置了宏来帮助条件编译,比如针对操作系统平台有: _M_AMD64, _M_IX64等等,对于位数也有 _WIN64和 _WIN32 ,比如说:

#ifdef _WIN32   //32位情况
​
#else //不是32位情况
​
#endif

 

调整数据结构

当一个32位的exe通过DeviceIoControl的方式和64位驱动进行交互的时候,如果结构体里有指针是不会进行thunking技术调整的,所以这里就会涉及到一些问题了,比如指针位数的不兼容,以及比如int这种位数也是不兼容的,还有对齐的一些很多问题。所以最好是采用限制好了的数据结构体。

比如说结构体定义成这样

struct DRIVER_DATA
{
    void* POINTER_32    test;
    UNICODE_STRING32    testUnicode_string;
};

 

直接把长度一次到位限制了。

小结:

x64和x86的区别还是蛮多的,如果要从头到尾设计一个驱动的话是必须得思考这个问题的。

上一篇:x64版本的OpenGL库配置


下一篇:Centos 7安装npm和node