问如何测试Linux二进制文件是否编译为独立于位置的代码？

EN

file 5.36说得很清楚，

如果可执行文件是饼形的，那么file 5.36实际上会清晰地打印出来。例如，饼可执行文件显示为：

main.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, not stripped

而非派的是：

main.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

这个特性是在5.33中引入的，但是它只做了一个简单的chmod +x检查。在此之前，它只是打印了派的shared object。

在5.34中，它应该开始检查更专门的DF_1_PIE ELF元数据，但是由于实现中的一个错误，它实际上破坏了一些东西，并将GCC饼可执行文件显示为shared objects。

我已经解释了file源代码，包括bug，以及它在：https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/55704865#55704865上检查了哪些字节的ELF格式

文件5.36行为的快速总结如下：

• 如果Elf32_Ehdr.e_type == ET_EXEC
  • 打印executable

• 否则如果Elf32_Ehdr.e_type == ET_DYN
  • 如果存在DT_FLAGS_1动态节条目，则为
    • 如果DF_1_PIE设置为DT_FLAGS_1：
      • 打印pie executable

    - else  
        - print `shared object`

- else  
    - if file is executable by user, group or others  
        - print `pie executable`

    - else  
        - print `shared object`

GDB运行两次可执行文件，并查看ASLR

。

您可以做的一件非常直接的事情是通过GDB运行两次可执行文件，并查看地址是否由于ASLR而在运行期间发生了变化。

我已经在：https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld/51308031#51308031中详细解释了如何做到这一点。

虽然这不一定是最实用的解决方案，如果您不信任可执行文件，这也是不可能的，但这很有趣，而且它完成了我们真正关心的最终检查，即Linux内核/动态加载程序是否更改了可执行文件的位置。

有bash脚本checksec.sh在Github上的应用来检查可执行的缓解属性(包括RELRO、Stack Canary、NX位、PIE、RPATH、RUNPATH、Fortify Source)。

使用checksec (文件输入)参数运行-f：

$ checksec -f /usr/bin/bash

RELRO           STACK CANARY      NX            PIE             RPATH     RUNPATH      FORTIFY Fortified Fortifiable
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH    YES      13        33