Капитуляция защитных механизмов

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

Хакер, номер #085, стр. 085-110-6

Возвращаемся к строке 002000CFh (той самой, в которой мы исправили условный переход) и прокручиваем экран дизассемблера вверх до тех пор, пока не встретим следующую перекрестную ссылку start+AFj, ведущую к строке 2000ACh. Посмотрим, что у нас там?

Мина с детонатором

LOAD:002000AC call loc_2002C9 ; проверка пароля и своего CRC

LOAD:002000B1 xor ebx,dword_200296 ; анализ результатов

LOAD:002000B7 jz short loc_2000CC ; все ок

LOAD:002000B9

LOAD:002000B9 loc_2000B9: ; CODE XREF: start+C7?j

LOAD:002000B9 mov ecx,offset aWrongPasswordS;"\n Wrong password, sorry"

Оторвать мой хвост! Еще одна проверка и еще один условный переход, расположенный по адресу 2000B7h. Как видно, он анализирует значение, возвращенное функцией loc_2002C9, сравнивая его с двойным словом dword_200296, и если loc_2002C9() ^ dword_200296 != 0, условный переход не выполняется, и управление получает подпрограмма, выводящая ругательное сообщение на экран. Что делает функция loc_2002C9? Да какая нам разница! Судя по всему, занимается проверкой целостности кода, которую нам обещал создатель крэкмиса. Чтобы ее обезвредить, мы должны заменить JZ на JNZ, инвертировав младший бит байта, расположенного по адресу 2000B7h. Вычитая базовый виртуальный адрес сегмента, мы получим физическое смещение, по которому этот байт располагается в ELF-файле (в нашем случае оно равно B7h), где находится байт 85h. Инвертируем младший бит, превращая его в 84h, сохраняем изменения, выходим из HTE, запускаем timy-crackme. Как это так опять не запускается?! Вот что значит хачить вслепую!

Возвращаемся к нашему первому условному переходу 2000CFh и пытаемся проанализировать, что именно он проверяет. Мы видим, что с вершины стека стягивается двойное слово и проверяется на равенство нулю. А кто его туда положил?! Переходим по перекрестной ссылке наверх и видим, что в строке 20009Ch на вершину стека забрасывается содержимое регистра EBX.

То был бикфордов шнур, а это - динамит

LOAD:0020009C loc_20009C: ; CODE XREF: start:loc_200099?j

LOAD:0020009C push ebx ; сохранить ebx в стеке

// А чему равен сам EBX? Ответ дает очередная перекрестная ссылка, ведущая нас к следующему коду:

LOAD:0020007B mov edx,1

LOAD:00200080 int 80h ; Linux - sys_ptrace

LOAD:00200082 sub ebx,eax ; анализ возвращенного значения

LOAD:00200084 test eax, eax ; отладчик обнаружен?

LOAD:00200086 jz short loc_200099 ; отладчика нет, все чисто

Вот оно! Системный вызов sys_ptrace! Оказывается, что наш условный переход в строке 2000CFh проверял совсем не пароль, а... наличие отладчика (программа, которая уже отлаживается, не может вызывать ptrace, сказанное, разумеется, распространяется только на те отладчики, что работают через ptrace). Но это не совсем так. Точнее, совсем не так. Как только отладчик напарывается на условный переход 200086h, на экран выводится разочаровывающее сообщение Sorry but the process seems to be trace («извините, но процесс, похоже, трассируется»), и до «нашего» условного перехода 2000CFh дело просто не доходит!