Как рандомизировать адреса функций в ELF-файле?

Question

[luaPower]

Здравствуйте.

Я компилирую некоторый исполняемый файл в среде Linux, с помощью GCC с флагом -O2.
На выходе получаю ELF-файл, в котором функции из одного и того же исходного файла имеют подряд идущие адреса:

# nm binfile | sort
...
000000000040ca40 T queue_create                                                                                                     
000000000040cab0 T queue_free
000000000040cad0 T queue_append
000000000040cb00 T queue_remove
...

Как можно с помощью флагов компилятора/линкера или любых стандартных UNIX-средств расположить адреса функций в исполняемом файле в случайном порядке? То есть, чтобы не было группировки функций по принадлежности к одному и тому же исходному файлу.

UPD Иначе говоря, нужно поменять последовательность, в которой компоновщик присвоил адреса функциям.

Comments

[Antony]

Если не секрет, какой в этом смысл?

[luaPower]

Есть программа, имеющая защиту от несанкционированного использования. Реализация защитных механизмов сосредоточена в одном модуле.

[Inviz Custos]

luaPower, рандомизация адресов никак Вам не поможет в защите, так как любой декомпилятор моментально покажет все связи. Для подобных целей используйте специальные инструменты, которые для этого предназначены. К примеру - https://oreans.com/CodeVirtualizer.php

[luaPower]

Inviz Custos, покажет, наверное, если эти связи имеются. В моем случае защитные методы связаны между собой лишь по принципу их назначения. Иначе говоря, можно было бы разместить их где угодно, но удобнее хранить в одном месте. За ссылку большое спасибо!

[shurshur]

luaPower, как Очень Дурацкое Решение можно с помощью #define назначить этим символам другие имена. В исходном коде будут такие, какие есть, в скомпилированный код попадут другие. Можно даже нарочно сделать имена, которые будут вводить потенциального взломщика в заблуждение :)

[Inviz Custos]

shurshur, или же просто вырезать отладочную информацию и не париться :)

[luaPower]

Inviz Custos, Я как раз это и хочу сделать. Удалить всё лишнее: отладочные символы, необязательные секции. А безымянные адреса функций хотелось бы перемешать.

[shurshur]

luaPower, советую посмотреть на команду strip.

[Everything_is_not_so_bad]

https://android-review.googlesource.com/c/platform...

[Василий Дёмин]

shurshur, Лучше sstrip

[shurshur]

Василий Дёмин, не знаю чем лучше, из описания непонятны его возможные преимущется, зато strip идёт в составе штатных binutils.

[Василий Дёмин]

shurshur, Тем, что он больше стандартного стрипа вырезает. strip, например, не может вырезать все секции и не обязательные сегменты.

[shurshur]

Василий Дёмин, буду иметь в виду.

[Everything_is_not_so_bad]

Василий Дёмин,
мне любопытно, а strip разве имеет какое-либо отношение к рандомизации адресов ELF?
Я думал, что рандомизацией должно заниматься ядро. Наверное есть путаница между рандомизацией адресов в формате ELF и той, которая мешает эксплуатацией уязвимостей.

[Василий Дёмин]

Román Mirilaczvili, Нет, не имеет. Однако автор вопроса хочет ещё и отладочную информацию удалить

Я как раз это и хочу сделать. Удалить всё лишнее: отладочные символы, необязательные секции.

Рандомизацией адресов действительно должно заниматься ядро. Зачем перемешивать функции в исполняемом файле я так и не понял, т.к. никакой дополнительной защиты от этого не будет

[Василий Дёмин]

luaPower, я так понимаю, вы хотите сделать защиту для своего исполняемого файла. В этом случае можно, например, его зашифровать и перед исполнением расшифровывать (почитайте про userland exec), или зашифровать каждую функцию отдельным ключом и перед вызовом расшифровывать, а после - обратно зашифровывать. Это может помочь при защите, в отличие от перемешивания функций

[luaPower]

Василий Дёмин, каким бы не было шифрование, ничто не мешает сдампить и проанализировать память исполняемого процесса, разве не так? В вопросе я хотел на примере показать, что функциям из одного и того же модуля компоновщиком присваиваются адреса в той последовательности, в которой эти функции располагаются в модуле. Таким образом, если разместить все защитные методы в одном исходном файле, то потенциальный взломщик, обнаружив один из этих методов, может захотеть посмотреть на функции, адреса которых расположены рядом в ELF-файле.

[luaPower]

В принципе, описанную проблему я решил путем объявления всех защитных функций как static с последующим подключением модуля целиком (#include "module.c"). В процессе оптимизаций неиспользуемый код вычищается компилятором, что в итоге дает желаемый результат - функции распределены в бинарном файле, грубо говоря, рандомно, и не имеют дубликатов. Но я думал, что есть какие-то способы проделать все это более эстетично.

[Василий Дёмин]

luaPower, Всё так. Но если шифровать каждую функцию отдельно и расшифровывать только на время исполнения, всё будет крайне печально с анализом

[Василий Дёмин]

luaPower, Я всё ещё не понимаю, как изменение адреса функции поможет усложнить анализ? Вот я открываю elf файл в каком-нибудь radare2, какая мне разница, по каким адресам функции расположены? Если они вызываются, я точно так же беру и анализирую их

[luaPower]

Василий Дёмин,

> Если они вызываются, я точно так же беру и анализирую их
Если в программе несколько тысяч функций, а вызовы защитных методов организованы нелинейно, например, не на старте, а спустя сотни тысяч вызовов других функций, при определенных условиях, то я думаю, что найти все защитные функции будет уже не так просто. Особенно когда эти функции не приводят к завершению программы, а ломают ее логику.

> какая мне разница, по каким адресам функции расположены?
Можно сделать предположение о том, что функции, адреса которых расположены подряд, принадлежат одному модулю. Таким образом, найдя один защитный метод, можно найти и все остальные.

[Александр Булитеров]

luaPower, Но вы осложняете, но не скрываете вызов. Да, время на отладку и поиск будет потрачено, но скрывается. Искать чисто по адресам тоже не вариант.
Возможно вам может помочь ld скрипт с секциями и каждую функцию кидать в свою секцию, но это муторно.

Answer 1

[mayton2019]

Так они не подряд идут. У них дистанция для первых двух - 112 байт. Далее 32. Упаковка. А ты что хотел? Чтоб бинарник был дырявый как сыр и имел 1 Гигабайт размером?

Comments

[luaPower]

Я хочу поменять последовательность, в которой компоновщик присвоил адреса функциям.

[mayton2019]

luaPower, я думаю что ты можешь сгенерить ассемблерный листинг используя опции GCC а потом поменять местами два куска кода.

Но меня терзает любопытство. Зачем это?

Когда человек хочет странного - то это такой себе тревожный звоночек что на проекте все плохо и на самом деле решается совсем другая проблема. Вот какая?

Answer 2

[Мирон]

смещение адреса функций можно отрегулировать после сборки, есть всякие редакторы для выполнимых
случайные адреса функций внутри блока, это ответственность так называемых обфускаторов, как правило это отдельные утилиты встроенные в пакеты сборки, возможно GCC имеет встроенный тогда да, может быть флаг, по которому функции будут иметь случайные адреса
поскольку конкретный флаг легко ищется в яндексе не сложным запросом, будьте так добры, поделитесь в комментарии, когда найдете :)