Приемы против отладчиков реального режима

Чтобы понять, как противодействовать отладчикам реального режима, необ­ходимо изучить сам процесс отладки. 8086 процессор предоставлял для этого одну команду, один флаг и две исключительные ситуации. Не слишком густо, но прожить можно.

Легче всего понять концепцию контрольных точек останова исполнения программы. Для этого используется однобайтовый код ОхСС. Когда процессор встречает его, он вызывает исключительную ситуацию (в просторечии "дергает прерыванием") int 0х3. При этом в стеке запоминается регистр флагов, указатель текущего кодового сегмента (регистр CS), указатель команд (регистр IP), запре­щаются прерывания (очищается флаг FI) и сбрасывается флаг трассировки.

Что из этого следует? Отлаживаемая программа полностью, включая все аппаратные прерывания, "замораживается" и поступает в монопольное распоряжение процессора, а значит и отладчика. Последнему доступен весь код програм­мы и операционной системы(!) для чтения, анализа и даже модификации. Отлад­чик может также изменять значение регистров и указателя команд. При этом доступ к последнему осуществляется через стек. Содержимое стека при входе в int 0х3 будет следующим:

IPß-------------SP

CS

Регистр флагов

Обычно отладчики сразу сохраняют все регистры, а потом обращаются к ним через стек или присваивают их локальным переменным. Эта информация вам пригодится, если возникнет необходимость написать собственный отладчик или его подобие.

Какими недостатками обладает предложенный метод? Самое неприятное в нем то, что точка останова непосредственно модифицирует код (при этом вынуждая отладчик сохранить измененный байт, чтобы потом была возможность вернуть его обратно). Поэтому для отлаживаемой программы не составит труда обнаружить этот факт и удалить точку останова. Для этого можно воспользоваться корректи­рующими кодами Рида-Соломона, которые позволяют определить местоположе­ние контрольного байта или использовать контрольную сумму кода для расшиф­ровки какого-нибудь фрагмента. Рассмотрим следующий пример crackl2.asm:

Repeat:

PUSH SI

XOR AХ,АХ

LEA SI, Start

Get_CRC;

LODSB

ADD AH,AL

CMP SL,offset Crypted

JB Get_CRC

POP SI

LODSB

 

XOR AL,AH

STOSB

CMP SI .offset _end

JB Repeat

Crypted:

Похоже на обычный расшифровщик, за исключением того, что ключ генери­руется на основе контрольной суммы исполняемого кода. Этим убиваются два зайца: невозможна никакая модификация кода и, главное, контрольные точки останова исказят результат. Воспользуемся, например, TurboDebuger-oM или даже Solt-ice.

Пошаговая трассировка программы никак не блокируется защитой, но очень утомительна. Попробуем установить точку останова. Но где? Ясно, что в строке Crypted ни в коем случае нельзя. Рассмотрим, что при этом произойдет:Обратите внимание на значение регистра AL — оно равно ОхСС. Контрольная точка исказила код, и теперь он уже не может быь корректно расшифрован. Однако установка контрольной точки в пределах расшифровщика исказит вычис­ляемую контрольную сумму его тела.

Это наглядно демонстрирует следующий дамп:

cs:0119 сmр si,0151

cs:011D jb 0105

cs:011F pop si

cs;0120 shl word ptr [bр+si-01],1

cs:0123 fst dword ptr[di]

cs:0125 stc

cs:0126 sbb bx,[bp+di-6676]

cs:012A wait

cs: 012B xchg bx, ax

cs:012C clc

cs:012D call EADO

Как мало этот мусор похож на работоспособный код! Разумеется, дальше трассировку продолжать бессмысленно. Так мы ни к чему не придем. Попробуем воспользоваться эмуляционным отладчиком, например сир386. Виртуальные кон­трольные точки никак не изменяют существующего кода, а поэтому не вносят никаких искажений ц его работу.

Но представляет интерес решить эту проблему менее мощными средствами. Самое простое — положить кирпич на клавишу F7 и идти пить чай, а тем временем программа будет расшифровываться.

Если же говорить серьезно, то необходимо дождаться расшифровки хотя бы первой инструкции. При этом допустима только пошаговая (F7). а не Step Over (F8) трассировка (последняя также устанавливает ОхСС в конце команды). Теперь можно безболезненно установить точку останова, так как код уже расшифрован и не модифицируется.

Этому, однако, можно воспрепятствовать, применив многопроходную расшиф­ровку кода. Это, конечно, сложнее программируется, но затраченные усилия с лихвой окупятся, так как под обычным отладчиком это уже не будет исполняться. Кроме того. шифровка затрудняет дизассемблирование. Обычные дизассемблеры вообще не смогут обработать код и выдадут что-то наподобие следующего листинга:

crackl2.1st Sourcer v5.10 9-Mar-99 1:53 pm page I

43C7:01lF 6C Dl 62 FF D9 15 db 6Ch,ODIh, 62h,OFFh,OD9h, 15h

43C7:0125 F9 1В 9В 8A 99 ЭВ db OF9h, IBh, 9Bh, 8Ah, 99h, 9Bh

43C7:012B 93 F8 ЕВ АО E9 E9 db 93h,OF8h,OE8h,OAOh,OE9h,OE9h

43C7:0131 F6 F8 db OF6h,OF8h

43C7;0133 57 38 76 7В 3В 7В db 'W8v(8xttx'

Впрочем, это не относится к IDA, который умеет обрабатывать скрипты. Например, следующий скрипт расшифрует весь необходимый код, позволяя дизассемблировать файл:

auto a,sym,ch;

sym=0 ;

for (а=0;а<Оx1Г;а++)

sym=sym+Byte (MK_FP (0х1000, OxlOO+a} ) ;

sym = sym s OnFF;

Message ("CRC= %x n", sym),

for (a-OxllF;a<Oxl51;a++)

{

ch = Byte(MK_Fp(OxlOOO,a));

ch = ch " sym;

PatchByte (HK_FP (0х1000, a) ,ch) ;

}

Аналогичным образом можно снять любую мыслимую шифровку. Подробнее об этом уже рассказывалось, и я не буду повторяться. Разве что для разнообразия приведу скрипт для HIEW, как для более распространенной утилиты. Для начала нам необходимо узнать контрольную сумму расшифровщика. Подсчитывать ее можно, например, в регистре BL, для чего достаточно одной команды

ADD BL,AL

HIEW, к сожалению, не поддерживает полностью автономных скриптов, поэтому необходимо вручную "провести" его от 0х0 до 1х1Е. Посмотрим теперь, какое значение имеет регистр BL. Если все сделано правильно, то там находится число ОхВ8. Попробуем расшифровать им остальной код:

XOR AL, ОхВВ

В результате получится следующее:

0000001F: В409 mov ah, 009

00000021: BA2701 mov dx,00127

00000024: CD21 int 021

00000026: C3 retn

00000020: 09 ВЙ 27 01-CD 21 C3 ^3-52 41 43 4B-20 30 78 31 Ц' =!^CRACK 0х1

00000030; 31 2E 20 8F-EO АЕ й3 EO-AO RC АС АО-20 A2 ЕВ AF 1. Программа вып 00000040: АЕ АВ AD A5-AD АО 20 ЕЗ-Е1 AF A5 E8-AD AE OD OA олнена успешно 00000050: 24--- $

Таким образом, приемы против отладчиков "прозрачны" для дизассемблеров. Конечно, дизассемблеры не эквивалентны отладчикам и даже частично не покры­вают возможности последних. Поэтому желательно все же найти способ заста­вить отладчик работать.

Напоминаю, что мы пока говорим о 8086 микропроцессоре и никаких аппарат­ных точек останова еще нет. Эмуляция может быть теоретически осуществима, но практически для нее не хватит ресурсов процессора. Можно, однако, посту­пить проще: перед каждой командой обращения к памяти контролировать досто­верность результата и при необходимости исправлять его. Это очень ресурсоем-кая операция, к тому же возможная только в режиме пошаговой трассировки (что само по себе сильно замедляло выполнение программы на первых процессорах): поэтому большинство отладчиков полагало, что среднему пользователю эти возможности не понадобятся, и не реализовывало их.

Казалось бы, сегодня, в век быстрых процессоров, мы должны были бы давно забыть об этом и устанавливать контрольные точки, где нам вздумается, не беспокоясь, что это может нарушить правильное выполнение программы. Однако ничего не изменилось за прошедший десяток лет. Вот грустный пример програм­мы под Win32. Почему грустный? Да потому, что штатным отладчиком с ним ничего нельзя будет сделать. Рассмотрим его подробнее:

Int main (int Argc, Char*, argv[])

Char c[]=”Hello World! n”;

_asm(

LEA ESI,From

LEA EDI,To

xor eax,eax

From:

MOV al,CS:[ESI]

INC ESI

ADD ah,al

cmp esi,edi

jb From:

LEA ESI,c

MOV EDI,ESI

Repeat:

LODSB

OR AL,AL

JZ To

XOR AL,AH

STOSB

jhp Repeat

To:

}

printf(c);

return 0;

}

He правда ли, этот пример почти полностью повторяет пример под MS-DOS десятилетней давности? Изменилась только одна команда — в Windows не так-то просто модифицировать исполняемый код, вместо этого программа расшифровы­вает данные-

Попробуйте установить контрольную точку в границах ассемблерного фраг­мента. Используется, к примеру, отладчик для MS VC 6.0 или даже Soft-Ice! И в том, и в другом случае строка 'Hello Word!' будет расшифрована некорректно и вместо ожидаемого приветствия на экране появится бессмысленный мусор. Любопытный факт! На протяжении всей истории существования платформы Intel отладчики повторяют одну и ту же ошибку, которую с успехом используют разработчики защит.

А теперь подумаем, что будет, если мы подсчитаем контрольную сумму всей программы, а не только одного расшифровщика, Правильно! Ни одной точки останова нельзя будет установить! Отладка обычными средствами станет невоз­можной! Впрочем, Soft-Ice позволяет установить аппаратные точки останова командой Ьрт (в отличие от Ьрх), и легко выйти из положения.

А вот отладчики от Borland и MicroSoft будут наталкиваться на непреодоли­мую преграду лени своих разработчиков. Впрочем, не будем строги к последним. Они рассчитывали все же нс на хакеров, а на прикладных разработчиков, в жизни которых подобной ситуации, может быть, никогда и не встретится.

Вообще, первоначально никто и не помышлял об агрессивных средствах контроля исполнения программ. Отладчик представлял собой мирное и уязвимое существо, уживающееся с исследуемым кодом в одном адресном пространстве и разделяющим общие ресурсы. Речь шла исключительно об отладке своих собст­венных программ, более того — специально рассчитанных на взаимодействие с отладчиком.

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

Защита может прочитать этот адрес и записать в обработчик немного (или много — кому как понравится) "мусора", убивая при этом отладчик. Разумеется, для этого необходимо выяснить, что это именно отладчик, а не что-то другое. По умолчанию Int 0х3 обрабатывается MS-DOS и обработчик состоит из одной команды IRET (OxCF). Если обнаруживается нечто иное, то с некоторой степенью вероятности это и будет отладчиком. Чтобы нейтрализовать последний, достаточ­но переустановить int 0х3 (и int 0х1 — но об этом ниже) на свой обработчик, в котором нужно вывести сообщение с просьбой нс отлаживать эту программу.

Впрочем, это может и не сработать. "Умные" отладчики могут отслеживать чтение программой таблицы векторов прерываний и "подсовывать" предыдущие значения обработчиков. Сегодня это умеет делать большинство из них, в том числе и Soft-Ice. Отметим также, что в Windows прикладной программе никто попросту не даст манипулировать векторами и это становится уже неактуально.

Отлаживаемая программа может также содержать опкод ОхСС, беспорядочно и в изобилии разбросанный по всему ее телу и при этом делающий что-то полезное. Например, обработчик int 0х3 может расшифровывать код или вызы­вать int 0х21. В результате произойдет конфликт ресурсов: отладчику и защите понадобится прерывание int 0х3 — каждому для своих нужд. Обычный отладчик при этом будет постоянно "всплывать" на каждом ОхСС, и если последнее установить в глубоко вложенном цикле, то отладка превратится в пытку. Однако у некоторых отладчиков можно отключить всплытие по точке останова. К таким отладчикам относится, например, trsutil Евгения Касперского.

Заметим, что это не в меньшей степени актуально и для платформы Windows. Наглядным примером может служить CRACK13, который при попытке запуска под отладчиком (скажем, интегрированным с MS VC) вызывает останов последнего, командой int 0х3. Забавно, но его разработчики не предусмотрели возмож­ности отключения этого действия.

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

Рассмотрим еще раз поведение процессора при встрече инструкции ОхСС — контрольной точки останова: он заносит в стек флаги и значение указателя команд и вызывает обработчик. Давайте представим, что при исполнении некото­рого критического фрагмента кода защита присвоила указателю стека нулевое значение. А стек, как известно, растет вверх, т.е. от старших адресов к младшим. Когда процессор, встретив int 0х3, попытается сохранить (занести) в стек регистр флагов, он не сможет этого сделать, так как стек уже исчерпан. Операционной системе ничего не останется сделать, как завершить некорректно работающее приложение, потому что восстановить его работоспособность уже будет невоз­можно.

Этот прием продемонстрирован в программе CRACK13. Однако в приведенном примере можно просто удалить команды xchg esp.eax, чтобы приложение успешно работало под отладчиком. Хорошая защита должна этому препятствовать. Здесь возможны множество путей. Например, можно подсчитывать контрольную сумму своего кода, а потом полученным значением расшифровывать некоторый фраг­мент. Впрочем, хакеру будет нетрудно расшифровать код вручную и удалить защищенный расшифровщик. Поэтому рекомендуется прибегать к динамической шифровке или читать данные командой pop. Действительно, рассмотрим следую­щую ситуацию:

H|E|L|L|O| |W|O|R|L|D|…..

^

|

|

esp-----popà

Если установить esp на начало строки, а потом последовательно извлекать из стека байт за байтом, то получим некий аналог LODSB, только более мощный, так как он может читать в любой регистр и оставляет esi нетронутым под нужды программы. При этом любое вмешательство отладчика в процесс приведет к затиранию читаемых данных и краху программы. Неплохо, очень неплохо, — в этом можно убедиться на примере CRACK13. Попробуйте запустить его под отладчиком! Но лучше не пробуйте, ибо ничего хорошего все равно не получится.

Немного поразмыслив, мы придем к выводу, что в данном случае POP AX можно безболезненно заменить на LODSW. Но нетрудно так спроектировать код, чтобы подобная замена была невозможна. Например, достаточно задействовать все свободные регистры, а также команду PUSH, ближайшим аналогом которой будет DEC EDISTOSW — несколько большая по длине и к тому же тесно связанная с флагом направления (который защита может умышленно изменить на противоположный) и с регистром АХ.

Что предпринять хакеру в такой ситуации? Пожалуй, воспользоваться дизас­семблером или эмулирующим отладчиком. Однако последних под Windows, похоже, еще не существует, поэтому остается только первое.

 

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

Но какое отношение имеет профилировщик ко взлому? И может ли он быть хоть чем-то полезен хакеру? Может, еще как! Особенно если это хороший профилировщик. Заметим, что защитный механизм написан целиком на ассемб­лере. С виду написан довольно аккуратно, но на деле коряво и неоптимально. Это позволяет с легкостью находить в исполняемом файле ассемблерные фрагменты. Возможно, что один из них — искомый защитный механизм.

Особенно это актуально на платформе Windows, где большинство грамотных защит пишутся на ассемблере, а не на языках высокого уровня. Оборотной стороной такого подхода становится открытость защитного кода. Как уже было показано выше, локализовать защитный механизм — это наполовину взломать его.

Практически все антиотладочные механизмы основаны на оригинальных при­емах программирования и не поддерживаются языками высокого уровня. Это вынуждает разработчика прибегнуть к ассемблеру. Пии этом многие (в том числе и старые) программисты забывают, что архитектура процессоров не стояла на месте и за последние несколько лет представления об оптимизации кардинально изменились. Код, оптимальный для 80486, не будет автоматически оптимальным для Pentium's. Необходимо позаботиться хотя бы о спаривании команд, без чего ассемблерная "заплатка" будет сильно выделяться на фоне оптимизированного компилятором кода.

Вторым отладочным механизмом 8086 процессора является поддержка трас­сировки исполнения программы. Трассировка — это пошаговое выполнение инструкций. Во времена 8086 она была единственным средством отладки про­грамм на процессорах того поколения. Организовывалась она с помощью "ловуш­ки". Под ее нужды выделялся один из флагов (TF — trace flag). Если он был установлен, то после выполнения каждой инструкции процессор генерировал исключение 1 (т.е. вызывал int 0х1). При этом он сохранял в стеке регистры флагов и указателя команд и при входе в обработчик автоматически очищал флаг трассировки, чтобы не привести систему к краху.

При этом отладчик никак не был защищен от агрессивных действий отлажи­ваемой программы. Описанные выше приемы применимы и к этому случаю. Так, чтобы войти в обработчик, int 0х1 требуется по крайней мере шесть байт стекового пространства. При этом стековыми регистрами свободно владеет отла­живаемая программа и нет никакой возможности зарезервировать эти шесть байт для отладчика. Как это может использовать защита, было показано выше.

Несовершенство механизма трассировки позволяло отлаживаемой программе не только обнаружить отладчик, но и выйти из-под его контроля. Действительно, регистр флагов мог читаться и модифицироваться отлаживаемой программой. Проверить, установлен ли флаг трассировки, защите ничего не стоило. После чего был резонный повод для отказа в работе. Однако хакер мог нейтрализовать такие проверки. Кроме того, отладчик может анализировать следующую инструкцию и если она воздействует на флаг трассировки, то эмулировать ее выполнение. Поэтому разработчики защит начали использовать весьма изощренные приемы, один из которых показан ниже (CRACK14):

PUSHF

MOV AX,2577h

MOV BP,SP

LEA DX,NewlntOx77

INC Byte ptr [BP+I]

INT 21h

POPF

INT 77h

Newlnt0x77:

NOP

MOV AL, [BP+I]

SHL Al, 7

ADD SP,6

LEA SI,Crypted

MOV CX, offset _end - offset Crypted

Repeat:

XOR Byte ptr [SI],AL

INC SI

LOOP Repeat

Crypted:

MOV АН, 9

LEA DX, About

INT 21h

RET

About DB 'Hello, Sailor!', ODh,OAh,'$'

Если этот фрагмент запустить под отладчиком, то расшифрованный код будет выглядеть следующим образом: