В прятки с отладчиком

Крис Касперски ака мыщъх

Хакер, номер #086, стр. 086-120-1

Пишем crackme, прячущий код на API-функциях

Сейчас мы будем заниматься увлекательным делом - писать crackme и пытать его на предмет взлома, а crackme будет молчать как партизан, потому что прячет защитный код в API-функциях, где до него не может дотянуться ни дизассемблер, ни дампер, ни даже отладчик. Это древний прием, уходящий своими корнями в эпоху MS-DOS, но ничуть не хуже работающий и в агрессивном мире Windows

[идея]

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

А давай просто спрячем защитный код там, где никто не станет его искать? Программные комплексы наших дней содержат миллионы строк кода и потому никогда не анализируются целиком. Если хакер встречает вызов API-функции LoadLibrary, то он искренне верит, что это действительно LoadLibrary, а не что-то еще. Теоретически в API-функцию можно заглянуть отладчиком, однако практически она представляет "черный ящик". Анализируя аргументы и последовательность вызовов API-функций (с помощью API-шпионов), хакер получает общее представление о работе защитного механизма, после чего редко приходится прибегать к отладчику/дизассемблеру.

Мыщъх предлагает защищаться так: берем какую-нибудь ненужную API-функцию, которая заведомо не используется, и копируем поверх нее свой собственный код (далее по тексту называемый X-кодом), выполняющий что-то полезное, например, проверяющий серийный номер. Выбирать лучше всего неброскую, ненапряженную функцию с названием не вызывающим у хакера никаких подозрений, GetTimeZoneInformation подойдет. Естественно, перед копированием необходимо присвоить памяти, где расположена функция, атрибут записи, что достигается вызовом VirtualProtect с флагом PAGE_EXECUTE_READWRITE, а после копирования вернуть исходные атрибуты защиты обратно.

Модификация API-функций носит сугубо локальный характер. Механизм Copy-on-Write автоматически расщепляет все измененные страницы, и потому изменения может увидеть только тот процесс, который их записал. Это значит, что за конфликты с другими процессами можно не волноваться. Заботиться о восстановлении оригинального содержимого API-функций также не нужно.

Поскольку адреса API-функций не остаются постоянными и чаще всего варьируются от одной системы к другой, X-код не может привязываться к своему расположению в памяти и должен быть полностью перемещаем. Чтобы не заморачиваться, можно разместить X-код внутри нашей программы, а в начало API-функции внедрить jump. Конечно, это будет более заметно. Стоит хакеру заглянуть отладчиком в API-функцию, как он тут же поймет, что она пропатчена, а вот при копировании X-кода поверх API-функции это уже не так очевидно.

Развивая мысль дальше, можно не затирать ненужное API, а взять популярную функцию типа CreateFile и слегка "усовершенствовать" ее, например, незаметно расшифровывать содержимое файла или просто помухлевать с аргументами. Допустим, программа открывает файл "file_1". X-код, внедренный в CreateFile, заменяет его на "file_2", передавая управление оригинальной CreateFile, – пусть она его открывает!

Содержание  Вперед на стр. 086-120-2
ttfb: 4.5931339263916 ms