Борьба с отладчиком

Mario555

Спецвыпуск: Хакер, номер #057, стр. 057-084-5

Это были, в принципе, все наиболее распространенные трюки, используемые ring3-протекторами для обнаружения ring3-отладчиков. Существуют также ненадежные антиотладочные трюки вроде проверок, которые могут быть применены только при определенных условиях (версия Windows (9x/Nt) или наличие администраторских привилегий).

Антитрассировка

Антитрассировкой я буду называть процесс, который мешает отлаживать (читай "исследовать/взламывать") программу, но не запрещает простой запуск программы под отладчиком, то есть противостоит действиям взломщика, а не отладке вообще.

Использование замеров времени

Об этом я уже рассказывал выше, поэтому здесь приведу конкретный пример. Для получения чистой IAT во многих протекторах нужно править что-либо в процедуре заполнения этой самой IAT. В Armadillo нужно занопить всего один условный переход, но для этого ты должен предварительно найти его (даже если знаешь, где искать, все равно потратишь время) плюс поставить бряк на конец процедуры (чтобы восстановить измененные байты). Короче, затратить промежуток времени, очень большой по сравнению с тем, сколько эта процедура выполняется без вмешательств. И арма проверяет это время.

На куске кода видно, что по адресу 3DA7BA вызывается GetTickCount, а несколько ниже по адресу 3DA7D7 происходит сравнение результата с допустимым значением: если меньше или равно, то JBE выполняется, и все OK; если больше, то не выполняется и в переменную [EBP-26CC] записывается единица, которая сигнализирует о том, что некто копается в процедуре обработки импорта. При этом протектор не будет выдавать никаких сообщений об отладчике и т.п., а под шумок заведомо ошибочно выполнит заполнение IAT, и придется потратить время, чтобы найти эту проверку.

Защита от обычных CC-бряков

Когда исследуешь протектор, ставить бряки на начало API-функции (как советуют в некоторых статьях bp addr_api), мягко говоря, опрометчиво. Почти все защиты проверяют, по крайней мере, исследуется первый байт вызываемой функции на присутствие байта CCh.

Есть и простенькие проверки, как, например, в SoftDefender.

Тупо проверяются первые пять байт. Взломщику в этом случае нужно ставить бряк на середину или на конец (ret) функции. Однако бывают и сложные проверки (например в ExeCryptor2 или ASProtect), когда почти вся основная ветвь вызываемой API дизассемблируется и, соответственно, проверяется целиком на наличие CCh. В таких случаях нужно либо ставить точку останова куда-нибудь вглубь API-функции (в call'ы), либо воспользоваться другим типом бряка, например на доступ к памяти. Но байт CCh ищут не только в API. Когда ты выполняешь Step over (<F8> в Olly) через какой-нибудь call, на следующую за ним команду отладчик ставит CCh-бряк. И он может быть легко обнаружен в подпрограмме внутри call'а, поэтому в таких случаях взломщику предстоит использовать не Step over, а вручную ставить бряк куда-нибудь после call, но не на первую после него команду, и выполнять RUN (<F9>).

Защита от точек останова на доступ к памяти (BPM)