M/o/Vfuscator. Ночной кошмар реверсера

Когда-то давно наткнулся на интересный проект - M/o/Vfuscator от Chris Domas. Его необычность заключается в том, что все ассемблерные команды в исходнике преобразуются в набор команд MOV (и только их!!!), которые в результате выполняют то же самое действие, что и заменяемая команда. Никаких проверок, никаких условных переходов, никаких ветвлений алгоритма, вообще ничего, кроме сотен и тысяч последовательных инструкций MOV. Понятное дело, что размеры исходника и готовой программы распухают на порядки, но кого это в наше время волнует. Похоже на магию?

Читать статью целиком »

Исследование защиты программы srcProtector for PHP

srcProtector for PHP - неплохой обфускатор PHP-скриптов. Фукнционал похож на другие подобные изделия, но тут что-то новое сложно придумать. Переменные, функции и классы переименовываются в случайные, убираются переносы строк и комментарии, строки кодируются, опционально обфусцированные скрипты сжимаются и дополнительно шифруются. В незарегистрированной версии можно за раз обработать только 5 скриптов. Это единственное ограничение, но для больших проектов критическое.

Читать статью целиком »

Обфускация строк на PHP

За несколько лет исследований различных кодировщиков и обфускаторов PHP-скриптов я изучил все используемые в них приемы сокрытия значений текстовых строк. Это могут быть названия функций или какие-то данные, которые должны быть представлены в виде строки. Так вот, во всех разобранных крипторах и обфускаторах символы в строке кодировались всего лишь несколькими способами: вариации преобразования строки из последовательности base64, декодирование из URL-encoded символов, escape-последовательности, упаковка строки в бинарные данные или результат функции chr по ординалу символа. Все подобные преобразования легко поддаются статическому анализу и декодированию типа замены по регулярным выражениям, то есть надежность сокрытия данных стремится к нулю.

В очередной раз экспериментируя с PHP, я решил на практике проверить, как поведет себя оператор инкремента и декремента в случае нецифровых значений. Согласно документации, при выполнении инкремента строковых переменных PHP следует соглашениям Perl, и рассматривает строку как условное число с базой значащих символов в диапазоне [a-z], [A-Z] и [0-9], причем одновременно. Проще всего это понять на следующих примерах:Более интересные случаи для пограничных значений:Постфиксный или префиксный инкремент тут значения не имеет, результат в обеих случаях одинаковый. При этом обратное действие, то есть декремент, как постфиксный, так и префиксный, на содержимое строки никак не влияет.

Читать статью целиком »

Исследование защиты программы PHP LockIt!

Программа PHP LockIt! предназначена для защиты исходных текстов PHP-скриптов от исследования и модификации. В качестве защиты применяется обфускация имен функций и переменных, а также шифрование исходного кода. В более ранних версиях была еще возможность сжимать полученные скрипты, но разработчики по какой-то причине от этого отказались. Зашифрованные скрипты не требуют установки на сервер дополнительного программного обеспечения, поэтому PHP LockIt! пользуется большой популярностью как у зарубежных, так и у отечественных копирастов. Я давно наблюдаю за развитием этой защиты, и среди других аналогичных поделок она кажется мне наиболее стабильной и надежной. Мне даже довелось встретить китайскую подделку PHP LockIt!, когда интерфейс программы был изменен в редакторе ресурсов, копирайты исправлены на свои, а затем на изуродованный файл был навешан протектор. При этом полученный китайский гибрид позиционировался как авторская разработка и распространялся как самостоятельный продукт с другим названием.

Читать статью целиком »

Распаковка и расшифровка скриптов JavaScript

Эта статья - дополнение к статье про деобфускацию скриптов. Здесь будут рассмотрены основные принципы шифровки и упаковки, слабые места защит, способы ручного снятия, а также универсальные инструменты для автоматического снятия упаковщиков и навесной защиты со скриптов JavaScript. В последнее время все чаще исходный код скриптов шифруется или пакуется. Этим начали увлекаться Яндекс, DLE и другие популярные проекты, а красивые байки про "заботу о пользователях", "экономию трафика" и прочую чушь выглядят очень смешно. Что ж, если кому-то есть что скрывать, значит наша задача вывести их на чистую воду.

Начнем с теории. Из-за особенностей выполнения JavaScript все шифровщики и упаковщики, несмотря на их разнообразие, имеют всего два варианта алгоритма:или как вариант:Второй способ чаще всего используется для защиты исходного html-кода страницы, а также разными троянами для внедрения в страницу вредоносного кода, например скрытого фрейма. Оба алгоритма могут комбинироваться, "навороченность" и запутанность расшифровщика может быть любой, неизменным остается только сам принцип.

Читать статью целиком »