问题标签 [position-independent-code]

Does ASLR affect the maps file? AFAIK the default virtual address for the text segment is 0x400000 for 64-bit binaries, but while parsing the /proc/pid/maps file I found that the OS was apparently using random addresses for the text and data segments, namely:

564992f16000-564992f17000 r-xp 00000000 00:2c 306966 /tmp/foo 564993116000-564993117000 r--p 00000000 00:2c 306966 /tmp/foo 564993117000-564993118000 rw-p 00001000 00:2c 306966 /tmp/foo

Can someone explain what is going on here?

PIE 二进制文件使用该函数__x86.get_pc_thunk获取在加载时动态定义的地址。

i) 有时它会调用__x86.get_pc_thunk.ax.

ii) 有时它会调用__x86.get_pc_thunk.bx.

iii）有时它调用__x86.get_pc_thunk.cx或有时__x86.get_pc_thunk.dx。

__x86.get_pc_thunk.bx我知道和之间的 区别__x86.get_pc_thunk.ax是寄存器，将返回地址存储在.bxtoEBX和.axto 中EAX。

然后，我的问题是：

编译器如何在__x86.get_pc_thunk.ax///中选择使用哪个函数 ？__x86.get_pc_thunk.bx__x86.get_pc_thunk.cx__x86.get_pc_thunk.dx

它是在编译时真正随机选择的吗？
或者有什么算法可以选择吗？

我正在尝试使用 GAS 语法创建一个汇编程序，该程序可以.data在 x86-64 架构上以与位置无关的方式从部分访问它的变量，并强制执行32 位架构和 IS（%eip而不是%rip）。

无论我尝试了什么寄存器，我得到的最好结果都是一个Segmentation fault: 11，甚至是访问我根本不应该做的 EIP，因此是 SF。最好的结果，因为这至少告诉了我“嗯，它不会做”以外的东西。

我gcc在 macOS 10.13.6 mid 2010 Intel Core 2 Duo 上编译文件（这clang可能就是为什么）：

并将一些选项传递给链接器：

ld：警告：PIE 已禁用。在代码签名的 PIE 中不允许使用绝对寻址（可能是 -mdynamic-no-pic），但在来自 /whatever.../test-a07cf9.o 的 _main 中使用。要修复此警告，请不要使用 -mdynamic-no-pic 进行编译或使用 -Wl,-no_pie 进行链接-v 查看调用）1

测试.s

我正在运行它./a.out; echo $?以检查最后的 EAX 值ret。

我查看了各种来源，但主要是英特尔语法或这些问题之一 - 1 , 2 , 3。我试图反汇编我能想到的最简单的 C 示例，即全局变量 +return来自main()- gcc -S test.c -fPIE -pie -fpie -m32：

这基本上导致：

这显然使用 MOV 作为 LEA 和几乎与我的指令相同的指令，除了-L0$pb应该是 +/- 地址的部分_var1- 地址L0$pb进入该.data部分。

然而，当我尝试使用var1和_main标签相同的方法时，什么也没有：

任何想法我做错了什么？

编辑：

我设法从反汇编的 C 示例中删除了任何不必要的东西，最后得到了这个：

这对我来说没有多大意义，因为根据本指南，调用者应该 1）将参数推送到堆栈（无）2）call标签和被调用者实际上应该使用 ESP、EBP 和其他寄存器。另外，为什么我什至需要一个中间标签或者更好地说，没有它有什么办法吗？

由于 PIE 二进制的性质，二进制中的所有数据都不能通过绝对地址访问。
所以，有两种相对访问数据的方式

两种方式

1. 在执行期间，加载程序GOT在入口处加载数据的位置。
   以及对该地址的二进制访问。

2. 使用位置计算数据的地址_GLOBAL_OFFSET_TABLE，并访问它。

但是，我看到了另一种相对访问数据的方法。
在下面的二进制中，二进制更改了<.text>部分的代码。
这很奇怪。

我将它编译成 pie 二进制文件。

正如你在上面的拆卸中看到的，push stderr组装成pushl 0x0.
而且..当我执行二进制文件时，

<.text> 部分更改为指向stderr!
我认为这很奇怪，因为<.text>部分-WX在一般应用程序中具有权限。
但在这种情况下，<.text>是RWX许可。

问题：

1. 为什么会发生这种情况？为什么编译器选择使用这种奇怪的方式，而不是上面的两种方式？
2. 这是馅饼二进制中的常见情况..？

我正在创建一个由多个二进制图像（通过 python 脚本组合在一起）构建的新图像。问题是最后一个二进制图像必须用 fPIC 编译，而以前的图像不是。最后一个图像（使用 fPIC 编译的图像）重用其他二进制图像中的函数，使用--just-symbols.

问题是，当我尝试从另一个二进制文件（由 接收的符号--just symbols）调用函数时，符号的地址是相对的而不是绝对的，这会导致硬故障。

如何将具有绝对地址的符号链接到 PIC 二进制文件？

代码示例：

文件 fun.c 编译成 fun.elf 剥离到 fun.bin：

-fPIC使用to 和编译的文件 fail.c --just-symbols=fun.elf：

在示例中，fail.bin 中 fun 的地址是相对的，而不是绝对的。

我一直在尝试更好地了解共享库的工作原理，但我无法解决两件事。

1-每个进程都有自己的虚拟内存空间和页表，所以如果一个共享库被加载到一个进程的虚拟内存空间中，那么第二个进程如何访问该共享库，因为它不在其内存空间中？

2-我知道只有文本部分被共享而全局数据不被共享，这怎么可能？我的理解是，对全局变量的每个引用都是通过全局偏移表（简称 GOT）完成的。所以，如果我有这行代码，x = glob那么这将大致等于mov eax,DWORD PTR [ecx-0x10]汇编中ecx的内容，其中用作 GOT 的基值。但如果是这种情况，那么很明显，无论哪个进程调用该行，它总是会访问同一个全局变量，其地址位于 GOT 中的偏移量 0x10。那么，如果两个进程使用引用相同 GOT 条目的相同文本部分，那么它们如何拥有不同的全局变量副本呢？

我正在尝试使用 GCC gnu 编译器为项目编译一些 GAS 代码。这是我的编译方式：

使用参数编译 kernel.c 文件后-fPIC，我尝试将其与以下命令链接：

它提出了：

这让我认为它没有使用-fPIC. 我怎样才能解决这个问题？

这是示例程序集文件，test.s

我尝试用-pie标志编译它，但失败了。

错误说，在 pie 二进制文件中，GOT只能使用基址寄存器访问条目。

问题。
我不知道为什么编译器会像上面那样抱怨。
更具体地说，为什么__progname@GOTpie 二进制文件不允许寻址？

我的意见。
Loader 知道__progname@GOTpie 二进制文件在加载时的地址。

__progname@GOT因此，加载程序可以简单地在加载时间的位置写入这个地址。
这就是装载机可以做的。

所以我不明白为什么编译器坚持像
mov __progname@GOT(%ebx), %eax.

我想获取和使用的地址_GLOBAL_OFFSET_TABLE_。我的期望是这个符号的地址在程序过程中不会改变。

但是，其地址的值似乎取决于哪个函数接受它：

程序输出：

编译-fPIC产生一致的结果：

与编译一样g++：

编译器细节：

行为是否符合clang预期？

我试图了解 PIC（与位置无关的代码）和无 PIC 代码之间的区别。

测试代码在这里。

我的操作系统是 Ubuntu。

编译后的汇编代码如下。我对汇编代码不是很熟悉。有人可以帮我理解PIC的区别吗？谢谢。

这是另一个测试代码f3.c。