Как стать автором
Обновить

Комментарии 26

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

Это ирония? Как код хотя бы с переименованными в кашу идентификаторами может легче читаться? Не говоря уже про код с другими защитами.

Любой код на Perl после обфускации выглядит лучше, чем до — известно же!!! :)

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

Эта фраза в общем случае неверна. Для скритовых языков, которые уезжают потребителю в виде исходных кодов, — да, согласен. А для компилируемых — обфускация увеличивает код и делает его менее эффективным. Можно выкрутить с упаковщиками типа upx, но у них изначальная задача другая — не скрыть код, а «оптимизировать» его по размеру, а то, что бинарь становится невозможно отдизасмить с полтычка — это побочный эффект


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

Ну, правильно. Потому что сейчас весь софт делается клиент-серверным. Вся проприетарная логика уходит на сторону сервера. Клиент же ею не обладает, он использует серверную часть как «чёрный» ящик. Чтобы усложнить жизнь пользователю — везде втыкаем сертификаты и шифрование протокола, авторизацию доступа к API. Попробуй взломай, называется. Минусы — такой подход не натягивается на произвольно взятую задачу.

Для скритовых языков, которые уезжают потребителю в виде исходных кодов, — да, согласен.

И я с этим согласен. Мне кажется замечательно можно обфуксить программы, написанные на скриптовом языке Tcl. Там для этого имеются богатейшие возможности! Или любую другую программу завернуть на Tcl.

Салют saipr — а есть какой-нибудь интересный пример этого?

Бессмысленная статья. Автор видимо не в курсе, что существуют деобфускаторы которые восстанавливают код в изначальном виде. Например de4dot «знает» почти все популярные коммерческие и бесплатные обфускаторы, делая такой вид защиты абсолютно бесполезным.

Я тоже не в курсе. Подскажите, а как восстановить код в изначальный вид, если идентификаторы заменены на случайные и инфа о них утерена?

Приветствую, это к теме reverseeng — как я думаю речь идет про восстановление данных через кластера внутренних элементов, могу на досуге в лс скинуть пару интересных тем по этим вещам ;) А если быть честным, со стороны ИБ, — любые данные восстанавливаются, за исключением данных, которые затерты нулями по кластеру и применением специальных методов.

С помощью машинного обучения? Информация об именах берётся из логики программы? Что такое кластера внутренних элементов? И все равно это не будет изначальный код.

Но он будет эквивалентен...

В данном случае оригинальные названия идентификаторов никак не восстановить. Но зачем нужны именно оригинальные названия идентификаторов? Если сам код, вся логика и работа всё равно получается полностью аналогичные оригинальному? Какая разница что в оригинале переменная называлась j, а тут согласно логике её обозвали i?
Но зачем нужны именно оригинальные названия идентификаторов? Если сам код, вся логика и работа всё равно получается полностью аналогичные оригинальному?

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


Какая разница что в оригинале переменная называлась j, а тут согласно логике её обозвали i?

В этом случае действительно не важно, но это вырожденный случай. Уместней было бы привести пример, когда классы Parser, Handler, LicenseChecker переименовались во что-то типа kh4hkjh2k, q23fef23f2, njd345gh.

Самое страшное при таких преобразованиях кода — это принцип аналогичный «переименование регистров». Когда она и та же «физическая» переменная будет в разных частях кода иметь разное содержание, причём именно по логике. И наоборот — одно и то же значение может кочевать по разным «физическим» переменным.

Мне кажется из нормальных современных обфускаторов для DotNet всего два: Babelfor и Eazfuscator. Какой бы вы выбрали и почему?

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

Приветствую, интересно описано, а есть что-то из собственной практики и видов обфускации, которые реально были применены и воздействовали от НДВ и/или reverseeng?


Отдельно хотел бы уточнить про контрольные суммы файлов и как идет предотвращение внедрения бит в потоки типа elf-файлов?


Интересует пример практики или ваше видение, — отдельное спасибо за детализацию и углубение)


Буду рад прочитать несколько интересных и опытных предотвращений эксплойтов, вне коммерческой тайны ;)

Можно немного вопросов и критики?
1. По каждому пункту неплохо бы привести примеры какие-нибудь. А то получается, что статья состоит из общих фраз, даже в Википедии примеры есть.
2. Непонятен пример в КДПВ — к нормально читаемому виду такой текст приводится очень быстро.
3. Лично я знаю только одну программу с когда-то обфусцированным кодом — Скайп, неплохо бы еще примеров.
4. Получается, что основная ценность статьи — в ссылках. Это конечно хорошо, но как-то э… недостаточно.
Так же, алгоритмы обфускации активно используются не только для затруднения анализа кода, но и для уменьшения размера программного кода, что, в свою очередь, активно используется при разработке различных веб-сервисов и баз данных.
Если вы определяете обфускацию как запутывание и затруднение понимания, то в таком случае она не используется для уменьшения размера кода. Размер уменьшается различными приёмами, и код потом уже может выглядеть как обфусцированный, но может при этом оставаться понятным.

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

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


Из интересного по теме:


Помню довольно долгое время не могли зареверсить клиент дропбокса, потому что он был написан на Python и скомпилирован кастомным компилятором с измененными оп-кодами (opcode remapping).


В результате зареверсили-таки (линк кому интересно) но в целом техника мне понравилась.


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

картинка найс 10/10

Мое гугл-фу ведет на какие-то китайские блоги и форумы. В процессе копирования оригинальная картинка исказилась (торчащий хвост волос был гладкий и круглый в оригинале):


Вот почему в коде надо использовать пробелы, а не табы :-Р
Интерестно, с 2015 года этот рынок программ обфиксации как-то растет или быстро стагнирует с повальным переходом всех на Open source?
Еще в контестах применяется при решении заданий в российских университетах
Обфускация это так же глупо как бороться с криминалом пытаясь следить за сообщениями в мессенджерах, бесполезно и работает только против дурачков. Зачем это нужно не понятно, да будут немного меньше ломать, но на самом деле ломают также просто ценность людей которые умеют это делать выросла.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории