这应该是一个非常简单、非常快速的问题。这些是我用 C 编写的程序的前 3 行:
Dump of assembler code for function main:
0x0804844d <+0>: push ebp
0x0804844e <+1>: mov ebp,esp
0x08048450 <+3>: and esp,0xfffffff0
... ... ... ... ... ... ...
什么是 0x0804844d
和 0x0804844e
和 0x08048450
?它不受 ASLR 的影响。还是内存地址,还是文件的相对点?
最佳答案
如果您查看 Intel Developer Manual instruction-set reference你可以看到 0x0804846d <+32>: eb 15 jmp 0x8048484
编码一个相对地址。即它是 jmp rel8
短编码。这甚至适用于与位置无关的代码,即在任何地址映射/加载时可以运行的代码。
ASLR 意味着每次将文件加载到内存时,可执行文件中的堆栈地址(以及可选的代码+数据)都会发生变化。 很明显,一旦程序被加载,地址就不会再改变,直到它被再次加载。因此,如果您在运行时知道该地址,则可以将其作为目标,但您不能编写假定固定地址的漏洞。
GDB 在任何 ASLR 之后向您显示进程的虚拟内存空间中的代码地址。 (顺便说一句,GDB 默认禁用 ASLR:set disable-randomization on|off
进行切换。)
对于可执行文件,通常只有堆栈指针是ASLRed。 ,虽然代码是位置相关的并加载到固定地址,所以代码和静态数据地址是链接时常量,所以代码像 push OFFSET .LC0
/call puts
可以工作,将字符串常量的地址硬编码为 push imm32
.
无论如何,库通常需要与位置无关,因此 ASLR 可以将它们加载到随机地址。
但可执行文件的 ASLR 是可能的,并且变得越来越普遍,要么通过 making position-independent executables (Linux),或者通过让操作系统在将可执行文件加载到与为 (Windows) 编译的地址不同的地址时修复每个硬编码地址。
地址与文件中的位置只有 1:1 的关系,只是在同一段内的相对意义上。即下一个字节的代码是文件的下一个字节。可执行文件的 header 描述文件的哪些区域是什么(以及它们应该被操作系统的程序加载器映射到哪里)。
关于memory - GDB 'Addresses' 。这些是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21133429/