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

Позже появился 80286 (с точки зрения хакера мало чем отличавшийся от своего предшественника), а вслед за ним и 80386, принесший принципиально новые возможности отладки. Точнее, "принципиально новые" только для платфор­мы Intel, а еще точнее — для этой линейки микропроцессоров, ибо большая часть из того, что появилось только в 80386, уже было реализовано давным-давно на других платформах, например на PDP. Однако это были большие, серьезные, дорогостоящие машины, которые в восьмидесятые годы никак нельзя было сравнивать с персоналками, коим и применения достойного еще не могли найти. Компания Intel первой решилась усилить возможности отладки на "домашнем компьютере", догадываясь, что пройдет совсем немного времени, прежде чем программное обеспечение усложнится настолько, чтобы реально потребовать той мощи, которая была заложена в 80386 чип.

Новый процессор полностью унаследовал все "прелести" реального режима, включая и автоматическую трассировку. Т.е. сохраняя полную совместимость "сверху-вниз". Полную, да не совсем. Изменилась реакция процессора на моди­фикацию сегментных регистров. 8086 ввел такое интересное понятие, как "потеря трассировочного прерывания", которое возникало всякий раз, как предыдущая команда изменяла любой сегментный регистр. При этом трассировочное прерыва­ние действительно терялось на одну команду. 80386 несколько изменил свое поведение. Теперь потеря происходила только при изменении сегмента стека SS. Впрочем, взгляните сами:

PUSH DS

POP DS

PUSH SS

POP SS

RET

Хотя я сильно сомневаюсь, что читателю будет легко найти XT в рабочем состоянии, но... Как говорится, охота пуще неволи. Побродите по радиорынкам, поищите старые материнские платы — быть может, вам и повезет. Иначе придется верить только на слово.

Как можно использовать потерю трассировочного прерывания? Например, можно помешать войти в ключевую процедуру:

push ss

pop ss

> CALL MyGodProc

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

Разумеется, современные отладчики все реже и реже используют автоматиче­скую трассировку: они пользуются аппаратными точками останова. Что это такое? Вообще-то эта книга не "Intel Architecture Software Developer's Manual", и подробного объяснения тут не будет. Любой уважающий себя разработчик должен подробно ознакомиться с документацией Intel в первоисточнике. В частности, процесс отладки описан в главе 14 технического руководства № 24319201, доступного на сайте Intel.corn.

Впрочем, дальнейшее изложение материала невозможно без понимания кон­цепций аппаратной отладки, поэтому ниже последняя будет поверхностно рас­смотрена.

Итак, 8086 микропроцессор не обеспечивал реального контроля за отлажива­емой программой. Контрольные точки модифицировали код, что вызывало ряд проблем с самомодифицирующимися программами. Кроме того, не было возмож­ности установить последние в ROM (очевидно, что ROM не подлежало модифи­кации).

Но в 80386 все кардинально изменилось. Теперь процессор предоставлял отладчику исчерпывающую информацию об отлаживаемом приложении и мог позволить контролировать каждый его шаг.

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

Иначе говоря, невозможно обнаружить правильно спроектированный отлад­чик или выйти из-под его контроля. К сожалению, таковых на сегодняшний день выпущено немного; мне достоверно известен только один: сир386, которому не научилась противостоять еще ни одна защита. Soft-Ice, к сожалению, оставляет часть своего кода в общем адресном пространстве с отлаживаемой программой и, что самое неприятное, позволяет ей свободно манипулировать отладочными регистрами, а значит снимать установленные отладчиком контрольные точки.

Поэтому в жизни каждого хакера рано или поздно наступает момент, когда для анализа некоторой защиты приходится садиться за написание собственного отладчика. Точнее даже не отладчика (создание которого потребовало бы много сил и ресурсов), а простого трассировщика, например для он-лайнового патчера или распаковщика (последнее наиболее вероятно).

Для написания такой утилиты не потребуется особых знаний и навыков. Обо всем позаботились инженеры Intel, вам остается только воспользоваться предла­гаемыми возможностями. Аппаратная отладка базируется на восьми специально выделенных для этой цели регистрах DRO-DR7. Чтение и запись их осуществля­ется командой MOV. Никаких других команд для манипуляций с этими регистра­ми не предусмотрено. Доступ к этим регистрам возможен только в следующих случаях:

• реальный режим процессора (Real-Mode);

• режим SMM (System Management Mode);

• защищенный режим, CPLO.

В противном случае будет сгенерировано исключение GPF (General Protection Fault). Отсюда видно, что управлять отладочными регистрами из прикладной программы Windows (исполняющейся в CPL3) никак не получится.

Поэтому для упрощения изложения материала все нижесказанное будет относиться только к реальному режиму и MS-DOS. Написание приложений, работающих в нулевом кольце операционной системы Windows, выходит за рамки данной книги и поэтому рассматриваться не будет. Интересующихся я отсылаю к MSDN. MicroSoft предоставила достаточно примеров программ, позволяющих если не освоить системное программирование, то по крайней мере использовать эти заготовки для своего кода.

Наиболее важным из всех отладочных регистров является DR7, который задает режимы работы всех четырех контрольных точек (а их может быть, к сожалению, только четыре) — см. рис. на следующей странице.

Биты Gx и Lx указывают на глобальность (локальность) контрольной точки. Бит Lx очищается при каждом переключении контекста задачи, а Gx — нет. Если тот или иной бит взведен, то это означает, что контрольная точка п установлена и остальные биты этого регистра уточняют условие ее срабатывания. (В реальном режиме оба флага равноценны и можно выбирать любой по вашему вкусу.)

Назначение флагов LE и GE здесь рассматривать не будем, отметим только, что Intel рекомендует устанавливать оба в единицу, чтобы ваши действия возымели должный эффект.

Пара бит R/W задает следующие условия срабатывания контрольной точки: а) Если бит DE регистра CR4 установлен:

R/W
	Прерывание по исполнению
	Прерывание по записи данных
	Прерывание по записи-чтению в порт ввода-вывода
	Прерывание по записи и чтению данных, но не исполнению

б) Если бит DE регистра CR4 сброшен:

R/W
	Прерывание по исполнению
	Прерывание по записи данных
	Не определено
	Прерывание по записи и чтению данных, но не исполнению

Заметим, что перехват обращения к портам ввода-вывода появился несколько позднее на процессорах Pentium. Ни 80386, ни 80486 еще не имели такой возможности.

Два бита LEN задают длину контрольной точки:

LEN
	1 байт
	2 байта
	Неопределено
	4 байта

Флаг DG (general detect enable) очень любопытен и заслуживает пристального рассмотрения. Он позволяет полностью защитить отладчик от агрессивных про­грамм. Как уже было сказано выше, манипуляции с отладочными регистрами в защищенном режиме возможны только в нулевом кольце защиты. На первый взгляд, это надежно защищает отладчик от попыток защиты модифицировать отладочные регистры или прочитать их и на этой основе сделать вывод о присутствии отладчика.

Но что если защита сама работает в нулевом кольце? Или в "голой" MS-DOS в реальном режиме? Неужели, как говорят, "сушите весла — приехали"? На самом деле инженеры Intel предусмотрели такой поворот событий и ввели новую возможность — перехват обращений к отладочным регистрам. Если флаг DG установлен, то любое обращение к DRO-DR7 вызовет отладочное исключение, т.е. передаст управление отладчику. Теперь последний может для сокрытия своего присутствия проэмулировать эту инструкцию или просто остановить работу (последнее, впрочем, не очень разумно).

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

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

Отметим этот очень важный момент. Вопреки распространенному заблужде­нию, проэмулировать отладочный регистр можно. Все эмуляция сводится лишь к переадресации регистров. Так, например, если отладчик использует DRO для своих нужд и к нему же обращается защита, то он может заменить DRO на DRI (к примеру) и при этом защите никак не удастся обнаружить такую подмену. Однако, когда защита потребует все четыре контрольные точки, отладчику придется отдать все свои ресурсы и самому остаться ни с чем. К счастью, подобных защит немного. Большинство из них просто используют отладочные регистры как регистры общего назначения или периодически заполняют их мусором. Разработчики, наверное, думают, что этим они страшно осложняют отладчику жизнь. На самом деле ничуть! Действительно, проэмулировать запись-чтение в отладочный регистр очень просто. Достаточно отслеживать обращения к нему и перенаправлять все вызовы в отдельную переменную. Защита может записывать, читать, сравнивать — и все это будет работать.

Вообще же существует не так много защит, манипулирующих отладочными регистрами. И это понятно. В Windows, например, чтобы "дотянуться" до них, необходимо спуститься на уровень нулевого кольца, что само по себе является нетривиальной задачей. Разработчики редко решаются на такой шаг. К тому же из нулевого кольца можно сделать нечто более оригинальное, чем попытаться отнять ресурсы у отладчика. Положим, мы их отнимем. Но какими усилиями! А что выиграем? Хакер возьмет в руки дизассемблер и, не испытывая больших затруднений, пройдет все уровни защиты.

Однако мы забегаем вперед. Вернемся к описанию архитектуры отладки. Четыре регистра DRO-DR3 задают линейный физический адрес контрольной точки или порта ввода-вывода. На выбор адреса наложены некоторые ограничения. Так, если размер контрольной точки составляет слово, она должна располагаться по четному адресу. При двойном слове — по адресу, кратному четырем. Смысл этого станет ясен, если учесть, что поле LEN маскирует младшие биты регистра адреса. Это связано с микроархитектурой процессоров Intel и иногда может служить источником неудобств. Так, например, установить контрольную точку останова на слово, расположенное по адресу 0х13, просто невозможно. Адрес будет округлен до 0х10, и мы рискуем как натолкнуться на ложные обращения, так и пропустить искомые.Любопытно, что многие отладчики никак не отображают этот факт, чем вводят пользователя в заблуждение. Они никак не препятствуют установке точки останова по невыровненным адресам, а потом взломщик удивляется, когда контрольная точка не срабатывает.

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

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

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

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

Регистр DR6 — это регистр статуса. Четыре младших бита ассоциированы с четырьмя контрольными точками. Как только контрольная точка срабатывает, соответствующий бит регистра DR6 устанавливается в единицу. Любопытно, что даже если не установлен бит Gn (Ln) и точка останова не вызвала отладочного исключения, соответствующий бит регистра статуса все же будет установлен в единицу. Подумайте на досуге, как можно использовать эту тонкость архитектуры.

Флаг BD установлен, если следующая инструкция обращается к любому из отладочных регистров. При этом необходимо, чтобы бит GD регистра DR7 был равен единице, иначе ничего не произойдет. Заметим, что эмулятор должен правильно выставлять значение этого бита в соответствии с флагом GD. Обычно отлаживаемая программа сбрасывает последний. При этом BD, равный единице, красноречиво свидетельствует об активном отладчике, на что защита может соответствующе прореагировать. К сожалению, многие распространенные отлад­чики никак не учитывают этот факт. Но, с другой стороны, не так много разработчиков осведомлены об этой тонкости, и несовершенство отладчиков проблем обычно не вызывает.

Бит BS устанавливается во время пошаговой трассировки программы. Заме­тим, что если отлаживаемое приложение имеет доступ к DR6, то это еще один способ обнаружить трассировку. Иногда это встречается в различных вирусах и антивирусных мониторах с целью обнаружить и блокировать трассировку. При­чем это относится не только к DOS-программам, но к Windows-приложениям. Уже существуют вирусы, работающие в нулевом кольце, они могут как угодно манипулировать с отладочными регистрами.

Ненулевое значение флага ВТ говорит о том, что последнее исключение вызвано переключением задач. К отладочным регистрам это непосредственно не относится, поэтому и не рассматривается здесь подробно.

Важное замечание! Содержимое регистра DR6 никогда не очищается про­цессором. Поэтому он должен обнуляться отладчиком после считывания резуль­тата.

Понимание механизма отладки просто необходимо для хакера. Иначе совер­шенно невозможно бороться с антиотладочными приемами и писать свои трасси­ровщики. Впрочем, последнее все же пока остается экзотикой. Среди взломщиков еще мало хороших и грамотных специалистов, способных написать собственный отладчик или дизассемблер. Гораздо заманчивее взять готовый инструмент и, даже не ознакомившись с документацией, попытаться что-нибудь "отломить", руководствуясь каким-нибудь "туторалом", выловленным в Сети. Конечно, в некоторой степени я утрирую, но доля правды в этих словах есть, ибо в хакерских телеконференциях наиболее часто встречается вопрос: "как мне настроить Soft-Ice?" Печально, но большинство не стремится к глубоким познаниям. Они не нужны современному поколению, избалованному визуальным мышиным интер­фейсом.

Но хакер должен всегда мыслить на самом "низком" уровне — уровне микропроцессора и железа. Точнее, даже на уровне микроархитектуры процессо­ра, а не готовых к применению команд и регистров. В самом деле: почему контрольных точек только четыре? Почему поля LEN маскируют младшие биты адреса контрольной точки? С чем все это связано? К сожалению, на этот вопрос невозможно ответить в рамках данной книги. Для этого нужно подробно изучить архитектуру микропроцессора и взаимодействие отдельных его компонентов. При этом многие вопросы отпадут сами собой и мотивы разработчиков станут понят­ными.

Для закрепления изложенного материала предлагается рассмотреть пример crackIS, который устанавливает точку останова на чтение-запись по адресу 0х9000:0 (точнее, физическому адресу 0х90000), При этом раздастся предупреди­тельный сигнал. Программа не работает в DOS-окне в операционной системе Windows. Необходим режим эмуляции MS-DOS без установленных драйверов типа emm386.

Микропроцессоры Intel, начиная с Pentium предоставляют возможность уста­новления контрольной точки на порты ввода-вывода. Ранее их можно было перехватывать только в защищенном режиме, опираясь на привилегированность инструкций чтения-записи в порт. Разумеется, это было неудобно и недостаточно:поэтому в Pentium реализован механизм перехвата портов через контрольные точки. При этом сам порт необязательно должен физически существовать. Последнее позволяет не только эмулировать неподключенные устройства, но и писать драйверы под полностью виртуальное аппаратное обеспечение, что иногда реализуется некоторыми системами.

Следующий пример издает короткий звук при обращении к порту 1. Можно считать, что этим мы эмулируем некоторое несуществующее устройство. Или, что ближе к проблеме защиты информации, перехватываем обращение к порту, после чего последний переходит в наше распоряжение. (Например, так можно написать 100% эмулятор FDD и ключевой дискеты к нему, при этом ни одна защита не сможет отличить его от настоящего.)

Рекомендую поэкспериментировать с контрольными точками. Нетрудно убе­диться, какое это мощное средство и какие перспективы оно открывает. Как уже упоминалось выше, можно перехватывать обращения к портам и замещать существующее оборудование или эмулировать неподключенное. Так, например, можно проэмулировать электронный ключ "ХАСП" или любой другой. Ключевую дискету (вместе с дисководом). Если защита привязывается к серийному номеру IDE винчестера, то нетрудно перехватить его порты и выдавать ложную инфор­мацию, вводя защиту в заблуждение.

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

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

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

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

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

История "запирания" клавиатуры восходит к глубокой древности. Во времена PC/XT достаточно было лишь запретить прерывания, чтобы "убить" консольные отладчики наподобие Debug.com. Сейчас, конечно, это выглядит несколько наив­ным. Действительно, отладчику, запустившему приложение, скажем, на отдель­ном V86, совершенно безразлично, как оно манипулирует прерываниями. Однако тут разработчик упустил из виду, что, несмотря на полную изоляцию отладчика и приложения, клавиатура у них осталась общей.

Заглянем в руководство по контроллеру клавиатуры — что же может сделать защита с последней? Например, существует любопытная команда OxAD, блокиру-ющая клавиатуру. При этом нажатие клавиш не будет обрабатываться вплоть до момента разблокировки последней командой ОхАЕ. Этот пример реализован в crackiA. Попробуйте его пошагово трассировать. Очень много отладчиков, начи­ная с TurboDebuger, убьются этим приемом. Поэтому рекомендую запускать их из DOS-окна в операционной системе Windows, чтобы можно было безболезненно "прибить" зависшее окно мышью. Однако Soft-Ice на это не купится и клавиатуру не заблокирует — это еще раз подтверждает, что ребята из NuMega неплохо соображают.

Но и они кое-что упустили из виду. Действительно, у контроллера клавиатуры используется один и тот же порт как для задания адреса, так и для чтения-записи данных. Это уже любопытно. Получается, что после передачи кода команды контроллер клавиатуры не будет отрабатывать нажатие клавиш, пока не будет передан байт данных. Самое интересное, что отладчик не сможет определить причину "зависания" клавиатуры и не сможет корректно ее разморозить. Попро­буйте потрассировать пример cracklB, используя Soft-Ice 2.8 (заметим, что это последняя версия отладчика под MS-DOS). При этом после первой же команды записи в порт клавиатура зависнет! Так приложение может защищать критиче­ские куски кода от отладчиков.

Однако версия 3.2, например, превосходно справляется с этой проблемой, поскольку виртуализирует порты. Т.е. защита обращается не к физическому контроллеру клавиатуры, а к мнимому, точнее — к эмулируемому отладчиком. И при этом никак испортить настоящий не может.

Аналогичным разделенным ресурсом является монитор, а точнее видеоконт­роллер. Далеко не все отладчики способны корректно восстанавливать нестандар­тные видеорежимы. Это может быть использовано защитами, хотя, не столь часто. Видеокарточки во многом несовместимы, и в современных операционных систе­мах низкоуровневый доступ к ним очень ограничен. К тому же в Windows, например, монитор разделен между всеми приложениями, а не только между защитой и отладчиком, как это было когда-то в MS-DOS. Поэтому крайне маловероятно, что читатель столкнется с такой защитой на практике. Если же такое вдруг случится, то можно попробовать подключить второй монитор (Soft-Ice это поддерживает) или воспользоваться удаленной отладкой по сети или нуль-мо-демному кабелю, что поддерживает большинство отладчиков.