Крутой протектор – не беда

Ms-Rem (Ms-Rem@yandex.ru)

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

Третий подход предполагает написание драйвера, который будет перехватывать отладочные прерывания сам и передавать их отладчику, после чего ты решишь, передавать прерывание защите или нет. Естественно, это тоже потребует написания плагина к SoftIce'у. Я обычно придерживаюсь этого подхода, он особенно удобен при взломе Star Force, который использует int 3 для вызова своей виртуальной машины в ring0. Этот вызов легко отделяется от срабатывания точки останова, что позволяет легко распределять возникающие прерывания между защитой и отладчиком.

А вообще это еще цветочки. В ring0-протекторах можно встретить кучу других более опасных приемов. Например, попробуй трассировать ring0-код при ESP = 0 - получишь синий экран. Это связано с тем, что при возникновении отладочного прерывания адрес возврата заносится в ring0-стек потока, а если по этому адресу не оказывается памяти, то возникает исключение.

Или, например, можно встретить отключение аппаратных прерываний с помощью перепрограммирования чипсетного контроллера прерываний. Если отладчик всплывает при вырубленных прерываниях, то остается только нажать reset, так как компьютер зависнет намертво. Бороться с этим можно опять же написанием драйвера, который включает прерывания перед вызовом отладчика.

К сожалению, такими "сюрпризами" богаты все современные ring0-протекторы, поэтому нужно уметь вовремя распознать и обойти их. Арсенал антиотладочных приемов в ring0 постоянно расширяется, и от них спасет только хорошее знание защищенного режима работы процессора и внимательный анализ кода протектора.

Если захочешь потренироваться во взломе ring0-протекторов, я написал небольшой crackme, который использует все описанные здесь приемы. Распаковывается он просто, но код, проверяющий серийник, спрятан с помощью ring0-штучек. Закейгенить этот пример пока еще никто не смог, так что у тебя есть шанс стать первым. Сrackme найдешь на диске с журналом.

Метаморф и полиморф

Вот пример легко понятного кода:

push eax

push 0

push 0

push ebx

call MessageBoxA

А если вместо этой гениальной простоты ты встречаешь путаницу вроде

xchg [edi], dl

add al, 30h

xlat

call 1234h

call 3456h

or al, 4a

знай, что ты встретился с метаморфом или полиморфом в защите. Полиморф обычно просто добавляет в код мусорные инструкции, чтобы затруднить дизассемблирование и анализ кода, а метаморф старается целиком изменить вид кода, сохраняя при этом оригинальный алгоритм его работы, для чего он заменяет инструкции их синонимами, состоящими в свою очередь из одной или нескольких других инструкций. Большая часть нового кода, производимого метаморфом, обычно нужна для работы программы, доля мусорного кода у него весьма мала. У полиморфа все наоборот. Естественно, декодировать метаморф значительно сложнее. Прежде чем делать это, нужно разобраться, как он работает.

Сердцем любого метаморфа обязательно является дизассемблер. С его помощью происходит разделение защищаемого кода, после чего, как уже говорилось выше, производится замена всех инструкций на синонимы или небольшие куски кода, несущие тот же смысл. Причем замена может делаться неоднократно. Число проходов (циклов замены) морфера называется глубиной морфинга. Чем она больше, тем более запутанным будет выходной код. После морфинга инструкции компилируются обратно в машинный код. Авторы метаморфов считают, что большая глубина морфинга осложнит анализ кода, но мой опыт подсказывает мне обратное. Сложность декодирования метаморфа целиком зависит от первичного алгоритма морфера и от того, сколько комбинаций инструкций он способен выдать на одну оригинальную инструкцию. Увеличение же числа этих комбинаций повышением глубины морфинга ничего хорошего не дает: все равно после написания анализатора можно будет снять метаморф в несколько проходов так же, как он и накладывался.