Windows虚拟地址空间

当我读取32位Windows应用程序的虚拟地址空间时，它有来自0x00000000-0x7FFFFFFF的2GB存储空间。其他2GB预留给系统地址空间

然而，我在一个使用作弊引擎的32位程序中发现了一个指针，它指向一个不在虚拟地址空间范围内的地址。我上次探索的地址是0x301DDC3C->0x87F56190，如图所示：

第一行中的展开表示指针0x301DDC3C的解引用，在下一行中，您可以看到RAM中解引用位置0x87F56190中的内容

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

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

这是否意味着位置0x301DDC3C中的指针指向系统地址空间中的某个位置？所以我正在检查的进程是使用内核模式的东西？

您看到的所有地址都是虚拟地址，进程中的地址不是物理地址。用户空间进程可以使用恰好来自系统空间的指针，但这并不意味着进程可以自由访问内核资源，也不意味着这些指针必须映射到物理地址

下面是另一个Microsoft链接，可能有助于澄清：

当处理器读取或写入内存位置时，它使用 虚拟地址。作为读或写操作的一部分，处理器 将虚拟地址转换为物理地址

范围 进程可用的虚拟地址称为虚拟地址 进程的地址空间。每个用户模式进程都有自己的 专用虚拟地址空间。对于32位进程，虚拟 地址空间通常为2 GB的范围0x00000000到 0x7fffff

Notepad.exe和MyApp.exe等进程在用户界面中运行 模式核心操作系统组件和许多驱动程序在 更特权的内核模式。有关处理器的详细信息，请参阅 模式，请参见用户模式和内核模式。每个用户模式进程都有自己的 拥有私有虚拟地址空间，但所有在内核中运行的代码 模式共享一个称为系统空间的虚拟地址空间。这个 用户模式进程的虚拟地址空间称为用户空间

在32位Windows中，总可用虚拟地址空间为 2^32字节4千兆字节。通常较低的2G字节用于 用户空间，最高2G字节用于系统空间

在用户模式下运行的代码可以访问用户空间，但没有访问权限 访问系统空间。此限制可防止用户模式代码丢失 读取或更改受保护的操作系统数据结构。密码 在内核模式下运行可以访问用户空间和系统空间。 也就是说，在内核模式下运行的代码可以访问系统空间和 当前用户模式进程的虚拟地址空间

还值得注意内核模式和用户模式之间的区别：

启动用户模式应用程序时，Windows会为 应用程序。该进程为应用程序提供了一个私有 虚拟地址空间和专用句柄表。因为 应用程序的虚拟地址空间是专用的，一个应用程序不能 更改属于其他应用程序的数据。每个应用程序都会运行 在隔离状态下，如果应用程序崩溃，崩溃仅限于 那是一份申请。其他应用程序和操作系统包括 没有受到车祸的影响

。。。 除了私有之外，用户模式应用程序的虚拟地址空间也是有限的。在用户模式下运行的处理器 无法访问为操作系统保留的虚拟地址 系统限制用户模式应用程序的虚拟地址空间 防止应用程序更改，甚至可能损坏， 关键操作系统数据

从

内存和地址空间的限制因平台、操作系统以及中是否存在映像\u文件\u大\u地址\u感知标志而有所不同。IMAGE\u FILE\u LARGE\u ADDRESS\u知道应用程序可以处理大于2 GB的地址，这是通过使用链接器选项设置或清除的

默认情况下，32位PE清除图像\文件\大\地址\感知，并设置为64位PE，但我们可以覆盖默认值：

因此，具有set IMAGE_FILE_LARGE_ADDRESS_感知标志的32位进程—最多4Gb内存可用

的确，在x64 windows中，用户模式下可以使用[0，0x8000000000 win8.1+或[0，0x8000000000 win8.1+之前的[0，0x8000000000]内存空间。但系统人为地限制了这一点，保留了大范围的内存。此分配受保护，无法释放

对于32位进程，此保留从7FFF0000或FFFE0000开始 和高达64位的ntdll.dll。非常有趣的是，在64位的进程中，图像\文件\大\地址\感知被清除-也就是这样的保留内存空间从0x8000000开始。同样有趣的是，在本例中，kernel32.dll是在另一个地址加载的，与通常的64位进程相比。因此，kernel32.dll的基通常在所有64位进程中都不相同。但所有进程中的ntdll.dll都加载在同一地址

x64 windows上的常规内存分配：

32位进程，图像\文件\大\地址\清除默认值 32位进程，图像\u文件\u大\u地址\u感知集 64位进程，图像\u文件\u大\u地址\u清除 64位进程，图像\u文件\u大\u地址\u感知设置默认值

---

如果标记为在64位windows下运行的32位可执行文件，则应用程序可使用完整的4gb空间检查图像\u文件\u头中的图像\u大\u地址\u感知。Characteristics@RbMm很好的提示。非常感谢。它的定义。因此，它必须是应用程序的专用地址空间中的正常地址…是的，如果您运行32位应用程序，并且具有图像\u文件\u大\u地址\u感知-对于32位代码，最多FFFE0000可用。真正的用户空间高达7FFFFF0000为我的应用程序设置/LargeAddressWare标志修复了我的问题。当你写一个带有更多解释的答案时，在这种情况下会出现一个指针>0x7FFFFFFF，我可以将它标记为正确答案。帮助我在64位Windows中实现了很大的限制—4 GB的图像、文件、大地址、支持setWindows Server 2008是微软发布的第一款仅支持64位的操作系统/LARGEADDRESSAWARE是一个-在当前版本的Windows中未使用/不需要它。/LARGEADDRESSAWARE这是链接器选项。它在IMAGE\u FILE\u HEADER.Characteristics中设置了IMAGE\u FILE\u LARGE\u ADDRESS\u AWARE标志，当然这不是错时现象32位和DOS 16位应用程序都是错时现象。OPs最初的问题似乎是关于运行时，而不是编译/链接。至于源代码级别的问题：A应用程序不应该知道或关心指针值是否小于或大于2^31，B应用程序可能需要>>2GB的连续空间，无论如何，为64位构建应用程序是明智的。我试图传达的要点是：用户空间与系统空间，物理地址与虚拟地址在两个空间中的区别，以及C用户模式与内核模式。直到32位应用程序事实上都没有过时。应用程序的链接方式会影响运行时。我只是注意到，如果我们在32位PE-64位的窗口中设置IMAGE\u FILE\u LARGE\u ADDRESS\u AWARE标志，那么他就可以在4GB空间内操作。没有此标志-仅2GB。具体而言，这是通过保留来完成的，因此，如果4gb或7FFF0000通常高达64位ntdll.dll，请防止从FFFE0000分配一些内存空间。