Windows虚拟地址空间 [英] Windows Virtual Address Space

问题描述

我在此处阅读32位Windows应用程序的虚拟地址空间具有2GB的存储空间(从0x00000000-0x7FFFFFFF开始).其余2GB保留用于系统地址空间.

as I read here the virtual address space of a 32 bit Windows application has 2GB of storage (from 0x00000000-0x7FFFFFFF). The other 2GB are reserved for the system address space.

但是现在我在32位程序(使用作弊引擎)中找到了一个指针，该指针指向不在虚拟地址空间范围内的地址.我上次浏览的地址为0x301DDC3C-> 0x87F56190，如图所示:

But now I found a pointer in a 32bit program (using Cheat Engine) which is pointing to an address which isn't in range of the virutal address space. The addresses in my last exploration were 0x301DDC3C -> 0x87F56190 like you can see in the picture:

(第一行的扩展表示对指针0x301DDC3C的取消引用，在下一行中，您可以看到RAM的取消引用位置0x87F56190中的内容)

(The expansion in the first line means a dereference of the pointer 0x301DDC3C, in the next line you can see what's in the dereference location 0x87F56190 in RAM)

在取消对指针的引用之后，会有指针返回到进程虚拟地址空间.

After dereferencing the pointer there are pointers back into the process virtual address space.

用户模式应用程序如何可能具有指向系统地址空间的有效指针?

这是否意味着位置0x301DDC3C中的指针指向系统地址空间中的位置?因此，我正在研究的过程正在使用内核模式的东西?

Does this mean the pointer in location 0x301DDC3C is pointing to an location in the system address space? And so the process I'm examining is using kernel mode stuff?

推荐答案

来自对内存和地址空间的限制因平台，操作系统以及 /LARGEADDRESSAWARE 链接器选项.

Limits on memory and address space vary by platform, operating system, and by whether the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the IMAGE_FILE_HEADER.Characteristics. IMAGE_FILE_LARGE_ADDRESS_AWARE (The application can handle addresses larger than 2 GB) is set or cleared by using the /LARGEADDRESSAWARE linker option.

默认情况下，IMAGE_FILE_LARGE_ADDRESS_AWARE对于32位PE清除并设置为64位PE，但是我们可以覆盖默认值:

by default IMAGE_FILE_LARGE_ADDRESS_AWARE cleared for 32-bit PE and set for 64-bit PE, but we can overwrite default:

因此设置了IMAGE_FILE_LARGE_ADDRESS_AWARE标志的32位进程-最多可以使用4Gb内存.

so 32-bit process with set IMAGE_FILE_LARGE_ADDRESS_AWARE flag - up to 4Gb memory is avaible.

当然，在x64窗口中，用户模式可以使用[0, 0x800000000000)(win8.1 +)或[0, 0x80000000000)(win 8.1之前)的内存空间.但是系统通过保留大范围的内存来人为地限制了此操作(此分配受保护并且不能释放)

really of course [0, 0x800000000000) (win8.1 +) or [0, 0x80000000000) (before win 8.1) memory space is avaible for user mode in x64 windows. but system artificially restrict this by reserve big range of memory (this allocation is protected and can not be free)

对于32位进程，此保留从7FFF0000或FFFE0000开始，直到64位 ntdll.dll .非常有趣的是，在64位进程中，清除了IMAGE_FILE_LARGE_ADDRESS_AWARE-保留的内存空间也从0x80000000开始.同样有趣的是，在这种情况下，将 kernel32.dll 加载到另一个地址，与通常的64位进程进行比较.因此， kernel32.dll 的基础通常在所有64位进程中都不相同.但是 ntdll.dll 无论如何都在所有进程中加载​​到相同的地址.

for 32-bit process this reservation begin from 7FFF0000 or FFFE0000 and up to 64-bit ntdll.dll. very interesting that in 64-bit process, where IMAGE_FILE_LARGE_ADDRESS_AWARE cleared - also was such reserved memory space begin from 0x80000000. also interesting that in this case kernel32.dll is loaded at another address compare usual 64-bit process. so base of kernel32.dll not the same in general in all 64-bit processes. but ntdll.dll loaded at the same address in all processes anyway.

x64窗口上的常规内存分配:

usual memory allocations on x64 windows:

1. 32位进程，IMAGE_FILE_LARGE_ADDRESS_AWARE已清除(默认)
2. 32位进程，IMAGE_FILE_LARGE_ADDRESS_AWARE置位
3. 64位进程，IMAGE_FILE_LARGE_ADDRESS_AWARE已清除
4. 64位进程，已设置IMAGE_FILE_LARGE_ADDRESS_AWARE(默认值)

1. 32 bit process, IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default)
2. 32 bit process, IMAGE_FILE_LARGE_ADDRESS_AWARE set
3. 64 bit process, IMAGE_FILE_LARGE_ADDRESS_AWARE cleared
4. 64 bit process, IMAGE_FILE_LARGE_ADDRESS_AWARE set (default)

这篇关于Windows虚拟地址空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！