微软的ASLR很奇怪 [英] Microsoft's ASLR is weird

问题描述

我看过一个ASLRed dll 图像的32位进程的地址。

这不是完全随机化的。它只是随机化的1/2概率。

I watched a ASLRed dll images's based address for 32bit Process.
It's not a fully randomization. It just randomizated 1/2 probability.

例如，一旦我加载了一个dll，那么图像被加载到 0x12345678 。 b $ b我再次加载图像，图像加载在 0x23456789 （基地址更改！）

但是我再次加载图像

0x12345678

0x23456789

0x12345678

0x23456789

...

For example, once I load a dll then the image is loaded on 0x12345678.
And I load the image again, the image is loaded on 0x23456789.(Base address is changed!)
But I load the image again
0x12345678
0x23456789
0x12345678
0x23456789
...

为什么他们这样实现？

是为了崩溃报告的频率（为了获得相同的崩溃地址重新部署的dll）

Why they did implement like this?
Is it for a crash report's frequency?(For getting same crash addresses of re-deployed dlls)

推荐答案

这是设计。通常，Windows首次加载DLL时，会为ASLR DLL选择首选基地址，然后在系统重新引导之前，它会继续使用该地址。这样，DLL将在加载它的每个进程中映射到相同的地址，从而允许共享代码页。

This is by design. Normally, Windows selects a preferred base address for an ASLR DLL when the DLL is first loaded, and then it keeps using that address until the system is rebooted. That way the DLL will be mapped at the same address in every process that loads it, allowing code pages to be shared.

但是，如果一个DLL已经从每个过程中，系统有时可能会在下次加载DLL时选择不同的基址。这样做是为了减少虚拟地址空间碎片，不是出于安全原因。这是你的情况似乎正在发生的。

However, if a DLL has been unloaded from every process, the system may sometimes select a different base address the next time the DLL is loaded. It does this to reduce virtual address space fragmentation, not for security reasons. This is what seems to be happening in your case.

这篇关于微软的ASLR很奇怪的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！