Комментарии 26
Так же, алгоритмы обфускации активно используются не только для затруднения анализа кода, но и для уменьшения размера программного кода, что, в свою очередь, активно используется при разработке различных веб-сервисов и баз данных.
Эта фраза в общем случае неверна. Для скритовых языков, которые уезжают потребителю в виде исходных кодов, — да, согласен. А для компилируемых — обфускация увеличивает код и делает его менее эффективным. Можно выкрутить с упаковщиками типа upx, но у них изначальная задача другая — не скрыть код, а «оптимизировать» его по размеру, а то, что бинарь становится невозможно отдизасмить с полтычка — это побочный эффект
На мой взгляд, в наш век всё большую популярность приобретает разработка всевозможных веб приложений, которые мало нуждаются в обфускации в качестве метода защиты информации.
Ну, правильно. Потому что сейчас весь софт делается клиент-серверным. Вся проприетарная логика уходит на сторону сервера. Клиент же ею не обладает, он использует серверную часть как «чёрный» ящик. Чтобы усложнить жизнь пользователю — везде втыкаем сертификаты и шифрование протокола, авторизацию доступа к API. Попробуй взломай, называется. Минусы — такой подход не натягивается на произвольно взятую задачу.
Для скритовых языков, которые уезжают потребителю в виде исходных кодов, — да, согласен.
И я с этим согласен. Мне кажется замечательно можно обфуксить программы, написанные на скриптовом языке Tcl. Там для этого имеются богатейшие возможности! Или любую другую программу завернуть на Tcl.
Салют saipr — а есть какой-нибудь интересный пример этого?
Я тоже не в курсе. Подскажите, а как восстановить код в изначальный вид, если идентификаторы заменены на случайные и инфа о них утерена?
Приветствую, это к теме reverseeng — как я думаю речь идет про восстановление данных через кластера внутренних элементов, могу на досуге в лс скинуть пару интересных тем по этим вещам ;) А если быть честным, со стороны ИБ, — любые данные восстанавливаются, за исключением данных, которые затерты нулями по кластеру и применением специальных методов.
Но зачем нужны именно оригинальные названия идентификаторов? Если сам код, вся логика и работа всё равно получается полностью аналогичные оригинальному?
Это усложняет процесс и увеличивает время деобфускации. К тому же идентификаторы меняются при каждой сборке, поэтому переиспользовать предыдущую карту соответствий не выйдет.
Какая разница что в оригинале переменная называлась j, а тут согласно логике её обозвали i?
В этом случае действительно не важно, но это вырожденный случай. Уместней было бы привести пример, когда классы Parser
, Handler
, LicenseChecker
переименовались во что-то типа kh4hkjh2k
, q23fef23f2, njd345gh
.
Самое страшное при таких преобразованиях кода — это принцип аналогичный «переименование регистров». Когда она и та же «физическая» переменная будет в разных частях кода иметь разное содержание, причём именно по логике. И наоборот — одно и то же значение может кочевать по разным «физическим» переменным.
А вообще это постоянная борьба разработчиков обфускаторов и деобфускаторов, навряд ли есть универсальный деобфускатор, который будет разворачивать все будущие версии программ, завернутых новым обфускатором.
Приветствую, интересно описано, а есть что-то из собственной практики и видов обфускации, которые реально были применены и воздействовали от НДВ и/или reverseeng?
Отдельно хотел бы уточнить про контрольные суммы файлов и как идет предотвращение внедрения бит в потоки типа elf-файлов?
Интересует пример практики или ваше видение, — отдельное спасибо за детализацию и углубение)
Буду рад прочитать несколько интересных и опытных предотвращений эксплойтов, вне коммерческой тайны ;)
1. По каждому пункту неплохо бы привести примеры какие-нибудь. А то получается, что статья состоит из общих фраз, даже в Википедии примеры есть.
2. Непонятен пример в КДПВ — к нормально читаемому виду такой текст приводится очень быстро.
3. Лично я знаю только одну программу с когда-то обфусцированным кодом — Скайп, неплохо бы еще примеров.
4. Получается, что основная ценность статьи — в ссылках. Это конечно хорошо, но как-то э… недостаточно.
Так же, алгоритмы обфускации активно используются не только для затруднения анализа кода, но и для уменьшения размера программного кода, что, в свою очередь, активно используется при разработке различных веб-сервисов и баз данных.Если вы определяете обфускацию как запутывание и затруднение понимания, то в таком случае она не используется для уменьшения размера кода. Размер уменьшается различными приёмами, и код потом уже может выглядеть как обфусцированный, но может при этом оставаться понятным.
Если насчёт веба имелся в виду фронтенд, то скажу что нет смысла обфусцировать JavaScript. Потому что самому же будет сложнее разрабатывать, а злой дядя всегда может легко превратить код в нормальный или понять без превращений, особенно когда ему заплатили хорошо.
Понятно, что любая логика исполняемая на клиентской машине, может быть подвергнута реверс-инжинирингу, и обфускация это лишь попытка сделать реверс сложнее/дороже.
Из интересного по теме:
Помню довольно долгое время не могли зареверсить клиент дропбокса, потому что он был написан на Python и скомпилирован кастомным компилятором с измененными оп-кодами (opcode remapping).
В результате зареверсили-таки (линк кому интересно) но в целом техника мне понравилась.
На тот момент казалось перспективным способом обфускации — по сути написание программы на кастомном языке, для чего атакующему необходимо было бы зареверсить сам язык (рантайм, виртуальную машину итд) и написать для него декомпилятор.
Обфускация как метод защиты программного обеспечения