Жив ли самомодифицирующийся код?

Question

[Ternick]

Доброго времени суток, недавно наткнулся на эту тему. Это по идее называется, как полиморфный код, но найти это под этим названием крайне сложно из-за приёма в ООП с таким же названием...
Ну так вот, все статьи об этом приёме датированы 2005 годом или даже позже, ничего более свежего найти не удалось, но всё же интересно узнать что случилось с таким интересным направлением.

Мне интересно живо ли ещё это направление, мертво ли или эволюционировало во что-то более интересное ? (По идее в статьях пишут, что этот приём как-бы умер из-за появления windows, в которой слегка прикрыли возможность исполнять код на стеке и плохо документировали информацию о функциях которые помогают выполнить код на стеке)

Меня заинтересовала эта тема т.к. я интересуюсь темой реверсинга и анти реверсинга и по идее, это одно из направлений анти реверсинга.

Так как я знаю питон, то могу сказать, что если закрыть глаза на то, что питон интерпретируемый и много других, штук, то можно сказать, что дохлый потомок полиморфизма есть и в нём, который реализуется функцией exec, которая исполняет код.

Ну вот в принципе и всё, интересно послушать, информацию на эту тему.

Ссылка на две статьи о том, что я имею в виду:
https://habr.com/ru/post/272619/
https://www.securitylab.ru/blog/personal/vxlab/291...

Comments

[Евгений Шатунов]

Ternick , а приведи в своем вопросе ссылки на те самые статьи. Чтобы лучше понимать о чем именно ты хочешь спросить.

[Ternick]

Евгений Шатунов, Ну например статья на хабре, *КУСЬ*

Answer 1

[pfg21]

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

на заре компов помнится читал описание игры в которой какие-то игровые функции формировались прямо во время работы игры.
сколь помню, был большой набор исполняемых кусков в файле, из которого копированием в память формировались цепочки исполнения, на начало которых CALL'ом передавалось управление, а в конце был обязательно RET.
периодически цепочки переформировывались.

Comments

[Ternick]

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

[pfg21]

Ternick, сейчас это даже в среде вирусов нее особо распространено.
гугули по словам - нформация не пропадает бесследно.

[Рональд Макдональд]

А у этой игрушки, часом, не был ASCII-интерфейс?

[pfg21]

Рональд Макдональд, давно дело было. не помню.
помню что изза такой уловки они сильно уменьшили объем потребляемой памяти. вместо большой функции с кучей if у них получилась маленькая но сложная псевдофункция.

Answer 2

[Stalker_RED]

программа на Haskell, которая выводит программу на Python, которая выводит программу на Ruby, которая выводит исходную программу на Haskell

q a b c=putStrLn $ b ++ [toEnum 10,'q','('] ++ show b ++ [','] ++ show c ++ [','] ++ show a ++ [')']
main=q "q a b c=putStrLn $ b ++ [toEnum 10,'q','('] ++ show b ++ [','] ++ show c ++ [','] ++ show a ++ [')']" "def q(a,b,c):print b+chr(10)+'q('+repr(b)+','+repr(c)+','+repr(a)+')'" "def e(x) return 34.chr+x+34.chr end;def q(a,b,c) print b+10.chr+'main=q '+e(b)+' '+e(c)+' '+e(a)+' '+10.chr end"

exec и eval есть в большинстве языков. писать в свой собственный exe-шник можно, я на pascal на win98 так сейвы сохранял прям внутри исполняемого файла, например. Потом на такие трюки начали ругаться антивирусы (очень уж похоже на работу вирусов), а позже и в операционках начали гайки закручивать, но в принципе это возможно. Непонятно только зачем.

Comments

[Ternick]

Не совсем то, что я имел в виду исходя из примера или я не понял суть.

[Алексей Харченко]

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

Answer 3

[d-stream]

Сейчас с самомодифицирующимся [машинным] кодом стало заметно похуже. Точнее не сейчас, а примерно со времен protected mode в ключе x86 архитектур: сегмент кода как правило на аппаратном уровне становится защищенным для записи и чтобы все-таки в такие сегменты писать - надо несколько исхитриться, поборов противодействие во первых аппаратной защиты кода, во-вторых управление процессами ос.

А раньше - да, только не ленивый творил и самораспаковывающиеся/самодешифруемые вариации, когда "волной" коды чуть впереди cs дешифровались по несколько байт, а особый полиморфизм достигался когда народ по своего рода маркерам генерил вариации кода, выполняющие идентичные действия. В основном изгалялись вирусописатели - для начала чтобы сигнатуры не ловились в файлах, потом попозже - в загруженных сегментах. Ну и писатели защит, чтобы было сложнее взломать защиту. Могу ошибаться, но похоже до сих пор хаспы/сентинелы пользуют сходные навыки (что иногда приводит к синему экрану))

Answer 4

[Inviz Custos]

и по идее, это одно из направлений анти реверсинга.

Направление "защиты от реверсинга" достаточно давно ушло в сторону виртуализации кода.
Такие инструменты как Themida, VMProtect, Enigma, etc при минимальных затратах времени и (самое главное) умении пользоваться этими инструментами - позволяют достаточно надежно защитить критические части приложения.
На данный момент лучшими инструментами (сугубо личное мнение, сформированные на основе опыта использования различных протекторов, а также на отзывах самих реверсеров) являются продукты Oreans Technologies (WinLicense, Themida, Code Virtualizer).
Сильные виртуальные машины (которых более десятка) + широкие возможности кастомизации позволяют доставить немало проблем реверсерам.

Answer 5

[#]

изучите тему Lisp

Answer 6

[Anton F]

Выглядит, что сейчас это заменено машинным обучением и обработкой данных, полученных от работы клиента с ПО, обратно в систему.
То есть игры, которые подстраиваются под ваш стиль прохождения или возможности. Или, например, DLSS 2.0 от NVidia, которая позволяет увеличивать картинку без видимых потерь качества, если разработчики натренируют алгороитм и тд
То есть поведение меняется изза внешних каких-то факторов. Сами машинные инструкции не меняются. Я думаю, что в эту сторону эволюционировало все.

Comments

[Stalker_RED]

Вопрос был о другом, изменение поведения программы в зависимости от внешних факторов - это вполне "обычное" поведение. Автор вопроса интересуется приемами, когда вот у вас в папке лежит exe-шник, но при запуске он сам себя меняет, и во время исполнения в памяти крутится ДРУГОЙ бинарник, отличающийся от того, что лежит в папочке.
Когда-то такие трюки было провернуть легко и они затрудняли работу всяким кейгенописателям. Сейчас и не затрудняют особо, и антивирусы ругаются, и даже ОС против.

[Ternick]

Stalker_RED, Я уже понял. Я понял, как он примерно должен выглядеть с поправкой на запреты системы. Пришлось использовать VirtualAlloc или VirtualProtect с типом доступа ReadWriteExecute и что-то я не заметил разницы. По факту ничего "усложняющего работу реверсера, я не нашёл", можно конечно написать пару трюков для обнаружения хитро сделанных отладчиков и проверять, что происходит вокруг приложения и думать, запускать свой "скрытый потенциал" или завершить процесс. У меня есть ещё один вопрос по этой теме, но о нём позже. А так ты прав, он совсем не в тему сообщение написал :)