Всем доброго времени суток. Сегодня речь пойдёт о полезности протекторов в защите программ от взлома и анализа. Многие переоценивают их значение в защите, в голом виде они представляют собой немного усложнённую версию UPX, которую просто геморройно распаковывать.
В этой статье мы коснёмся следующих пунктов:
1) Почему протекторы не помогут защитить слабый код даже с виртуализацией.
2) Как изучить и пропатчить код программы без распаковки и патча самого файла.
3) Какой протектор выбрать для защиты своего ПО.
Начнём с первого пункта, предположим мы сделали мини-крякми со следующим кодом:
Мы защитили функцию виртуализацией через маркеры, и, казалось бы, теперь код безопасен от лёгкого патча. Это так, но лишь от части. Не стоит забывать что протекторы виртуализовывают лишь ту функцию или её часть, которую вы отметили маркерами. То есть под защиту попадут лишь те инструкции, которые находятся в функции main, код функций, которые вызываются внутри маркеров, затронут не будет.
В примере выше функция ComparePass не будет защищена, и это уже критическая уязвимость. Подобные места можно встретить в любой защите, чаще всего это функции каких либо библиотек, главное уметь их правильно искать, но это тема отдельной статьи.
И так, в самом верху мы видим скомпилированную функцию ComparePass; компилятор сам заинлайнил strcmp. Ниже мы видим защищённую функцию main с VM Entry в виртуальную машину VMProtect’a. Как только мы нашли уязвимое место — пропачтить его лишь дело техники, выглядеть это будет вот так:
В регистр EAX всегда записывается результат функции, в нашем случае мы всегда возвращаем 1 (true). То есть мы сделали следующее:
Теперь функция всегда будет возвращать true, вне зависимости от ведённого пароля.
Переходим к следующему пункту: патчинг кода. Оригинальный код программы всегда распаковывается в память для выполнения, наша задача дождаться этого момента и сделать патч. Самый простой вариант это написать свой патчер (лоадер), который дождётся распаковки кода в память и сделает нужные действия. Вот код лоадера для нашего примера:
- Создаём процесс CrackMe.exe.
- Находим базовый адрес главного модуля.
- Читаем память которая чуть ниже инструкций, которые мы будем патчить (потому что проверка может слишком рано сработать).
- Записываем наш патч.
В качестве примера приведу так же слитый исходник чита XONE:
Практически аналогичная ситуация с нашим CrackMe: есть единая функция для проверки лицензии, которая просто возвращает true/false. Даже не смотря на то что функция Check виртуализирована — всё равно остаётся возможность лёгкого пачта. Думаю из этой статьи вы поняли, что насколько бы не был сложен алгоритм авторизации, если для проверки используется if (func() = = true) — то для обхода подобных защит достаточно найти нужное место и перезаписать буквально 6 байт.
Так какой же протектор выбрать для защиты своего ПО? На момент написания данной статьи самым сильным на мой взгляд является 3-ая версия VMProtect’a. Его антиотладку не обойти через большинство плагинов для отладчика, а также у него довольно неудобная ВМ для трассировки (особенно в x32 приложениях). Если VMProtect плохо работает с вашим кодом — выбирайте Themida/WinLicense. Самым слабым решением на мой взгляд является The Enigma Protector, её можно без особых проблем распаковать руками и с небольшим скриптом для импортов. Но не забывайте: ключевую роль в защите играет именно то, как вы пишете свой код. Хорошо написанный код накрытый энигмой будет в разы сложнее ломать, чем слабый и накрытый VMProtect’ом, поэтому над выбором протектора можно особо сильно не задумываться. Выбирайте тот, который наиболее стабильно работает с вашим кодом.