обфускация кода как метод защиты от вирусов и атак #720083

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

+ Под обфусификацией подразумевается изменение потока выполнения, ложные функции и т.д

... обфускация - это ж фишка для человека... Вирусу пофик. Он свой код исполняет.

Ну вирус же "рассчитывает" на определенный адрес внедренного  кода,  а тут у каждого пользователя свой вариант программы

+ Типа за счет фековых функций адреса функций в памяти будут разными для каждой скомпилированной проги

если аката направлена на конкретную версию и релиз конкретного ПО - то да, это может иметь смысл. Однако это почти не реально. Скорее всего вирус найдет нужные ему блоки даже в модифицированном коде по сигнатурам кода (например вызовы системных библиотек - их изменить не получится).

Если у вас самописное решение, то для взлома злоумышленнику придётся каким-то образом получить это решение и проанализировать его. Если решение тиражное, то у всех оно будет одинаковое.

Повторяю: вирус исполняет свой код. Как написан вирус, так и будет работать. Не исключено, что он будет работать не так, как ты предполагаешь.

фигню какую-то придумал

Ок, если так же обфусифицировано ядро и библиотеки(я про линукс), изменит ли это адреса вызова системных функций? Если приложение в исходных кодах, можно ж? Ну вопрос не про работу, а про внедрение ж

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

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

То есть внедряясь вирусы не исполняют свой код, а они его исполняют только "работая"?

2 программы если общаются друг с другом. то они должны находить общий язык. А ты предлагаешь изменить язык каждого экземпляра программы. Угу, "вирусы" не пройдут, но и система работать перестанет.

А если имеется ввиду обычная программа - *.exe то вирусу вообще пофик - он в начале свой загрузчик прилепляет и все. Да и вообще сейчас актуальнее даже не вирусы как таковые а вредные программы-шифровальщики.

Вопрос о конкретном виде атаки на срыв стека, понятно что за всеми скриптами не уследишь Немного не силен в теории, эти адреса не линковщиком задаются на этапе компиляции ? Ну конечно исполняют, но они же его должны как то внедрить, вот вопрос о защите от срыва стека и идет Если вся система перекомпилирована у тебя с нуля (gentoo)? почему нет?

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

Да но для анализа этой вещи, нужна будет именно эта вещь, так? А не бинарник который можно получить с сайта разработчика

Роешь в этом направлении?

Предположу, что вирусу не нужно знать расположение функций взламываемой программы, ему нужно будет знать расположение адреса собственного тела, которое возможно и сейчас находится в разных местах на разных компах (что не мешает вирусу внедряться).

Ну типа проблема в этом. Вопрос  в защите :)

Я думаю, обфускация тут мало поможет. У нее другая цель.

Скрипт ? На php или на perl срывает стек? если ты смог загрузить php на сервак и исполнить его - значит ты уже взломал сервак. ЗЫ Вы че нанюхались что ли :) валяюсь ....

Ну ему надо для начала на комп как то попасть и записаться, если это только не жалостливый китайский вирус который просит его запустить а потом разослать 10 своим друзьям.

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

Тело может попасть хоть с письмом, хоть со страницей html, прямо внутри страницы. Для этого делать ничего не нужно, стоит только открыть сайт...

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

в старых системах защиты от дебагера использовался прием передачи управления вне сегмента исполняемого кода а в сегмент даты или даже в стек. И в случае использования дебагера стек был совершенно другим, что приводило отладку к фейку. Но в современных системах с их виртуальными машинами и защищеными режимами таке наверно не возможно. так-что все эти офбуксатры и прочее - это шаг назад, сейчас технологии идут в двух направлениях 1. изоляция кода (виртуальные машины и т.д.) 2. анализ кода до его выполнения (в очереди процессора)

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

есть такие. пользуются дырявыми виндовыми службами для получения прав уровня системы. очень популярен в этом плане svchost.exe