Как протестировать, был ли двоичный файл Linux скомпилирован как положение независимый код?

Я использовал readelf --relocs для тестирования или статической или динамической библиотекой является PIC на x86-64 следующий путь:

$ readelf --relocs /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a |\
      awk '$3~/^R_/ && $5!~/^\.debug/{print $3}' |sort -u
R_X86_64_32
R_X86_64_32S
R_X86_64_64
R_X86_64_DTPOFF32
R_X86_64_GOTPCREL
R_X86_64_PC32
R_X86_64_PLT32
R_X86_64_TLSLD
R_X86_64_TPOFF32

Мы видим здесь R_X86_64_32 и R_X86_64_32S. Это означает, что код не является независимым положением. Когда я восстанавливаю библиотеку с,-fPIC я добираюсь:

$ readelf --relocs libstdc++.a |\
      awk '$3~/^R_/ && $5!~/^\.debug/{print $3}' |sort -u
R_X86_64_64
R_X86_64_DTPOFF32
R_X86_64_GOTPCREL
R_X86_64_PC32
R_X86_64_PLT32
R_X86_64_TLSGD
R_X86_64_TLSLD

Этот метод может, вероятно, работать на исполняемые файлы, но я не использовал его тот путь.

Просто используйте файл в двоичном формате:

$ file ./pie-off
./pie-off: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0dc3858e9f0334060bfebcbe3e854909191d8bdc, not stripped
$ file ./pie-on
./pie-on: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=962235df5bd188e1ec48c151ff61b6435d395f89, not stripped

Обратите внимание на другой тип, напечатанный после информации LSB.

file5.36 ясно говорит

file5.36 на самом деле ясно печатает, является ли исполняемый файл PIE или нет. Например, исполняемый файл PIE отображается как:

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

и не -PIE как:

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

Эта функция была представлена ​​в версии 5.33, но выполняла лишь простую chmod +xпроверку. До этого он просто печатал shared objectдля PIE.

В версии 5.34 предполагалось начать проверку более специализированных DF_1_PIEметаданных ELF, но из-за ошибки в реализации она на самом деле нарушила работу и показала исполняемые файлы GCC PIE как shared objects.

Я интерпретировал fileисходный код, включая ошибку,и какие именно байты формата ELF он проверяет в мучительных подробностях в:https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/55704865#55704865

Краткий обзор поведения файла 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
    • еще
      • печатьshared object
  • еще
    • если файл может быть запущен пользователем, группой или другими пользователями
      • печатьpie executable
    • еще
      • печать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 / динамический загрузчик изменит исполняемое местоположение или нет.

На Github есть bash-скрипт checksec.sh для проверки свойств защиты исполняемых файлов (, включая 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