книги хакеры / журнал хакер / 111_Optimized

Ламерский способ запуска программ в режиме совместимости

внутри aclayers.dll, а не в реестре. То есть, возможности «рукотворного» добавления новых записей в AppCompatibility достаточно жестко ограничены архитектурой системы, однако, если не лезть в исправление тяжелых конфликтов, предоставленного функционала хватает с головой. Библиотека USER32.DLL (обертка вокруг драйвера WIN32K.SYS, реализующая пользовательских интерфейс вместе с графической подсистемой) также обращается к AppCompatibility из API-функции ClientThreadSetup, которая в свою очередь вызывается из API-функции UserClientDllInitialize, подготовляющей оконную и графическую подсистему для использования в контексте конкретного приложения с учетом его требований к обратной совместимости:

ФрагменткодаUSER32.DLL,обращающийсяк

AppCompatibility

aRegistryMach_5:

unicode 0,\ <\Registry\Machine\System\ CurrentControlSet\C>

unicode 0,\ <ontrol\Session Manager\ AppCompatibility>,0

Вот в эту часть кода лучше не лезть. Оконная подсистема Висты претерпела значительные изменения, но разобраться, какие именно изменения разваливают ранее написанную программу намного сложнее, чем кажется. Тут одного отладчика и дизассемблера явно недостаточно! Необходимо трассировать программу под новой и старой системой, сравнивая результаты прогонов, представляющих собой огромные log-файлы с кучей непонятных строк.

Что нового в Висте и Server 2008

Microsoftпредупреждает:использованиенедокументированныхAPI-функ- цийиструктурданныхопаснодлявашегоздоровья!Воттолькопрограммистычихатьхотелинасвоездоровье(всмысле,насовместимость)иведут крайненездоровыйобразжизни(стилькодирования),буквальнонашпигованныйнедокументированнымивозможностями.Иведьнеотхорошей жизни!

Взять хотя бы функцию OpenThread, отсутствующую в первой редакции стандарта win32 API, разработчики которого умышленно изъяли ее в целях безопасности. Мол, нечего открывать чужие потоки, а если поток хочет, чтобы его открыли — пускай передает свой дескриптор через один из многочисленных механизмов, имеющихся в распоряжении программиста. ОК, вообразим себе поток, созданный зловредным вирусом, который (в здравом уме и трезвой памяти) явным образом передает свой дескриптор антивирусам (а для этого еще и протокол взаимодействия вируса с антивирусом придумать нужно и стандартизовать, чтобы все ему подчинялись), мол, братья антивирусы, проверьте меня, пожалуйста и, убедившись, что я действительно вирус, а не полезная программа, тут же прибейте меня без суда и следствия. А вот дудки! Никакой вирус сотрудничать с антивирусом не будет и без OpenThread разработчикам последних

xàêåð 03 /111/ 08

#endif

; KPROCESS

; DirectoryTableBase

069

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

Другое существенное отличие от XP — механизм рандомизации адресного пространства — Address Space Layout Randomization или, сокращенно, ASLR, впервые появившийся в мире UNIX и скопированный фирмой Microsoft для затруднения хакерских атак. Ну нападки на Висту прекращаться не собираются, а вот системные динамические библиотеки теперь отображаются в память по случайным адресам, выбираемым на стадии загрузки операционной системы. Стек и куча также рандомизированны. Приложения, написанные до Висты, грузятся по адресам, прописанным в их заголовке, а вот для новых приложений имеется возможность задействовать ASLR и для самого исполняемого модуля. Но все-таки вернемся к старым программам. Может ли рандомизация служить причиной отказа их работоспособности — Microsoft полагает, что нет, но практика выявляет обратное.

Вот вполне типичная ситуация — программист сохраняет некоторые структуры данных на диск, в которых оказываются (по чистой случайности, конечно) указатели на локальные переменные, расположенные в стеке. На XP, где стек всегда начинается с одного и того же адреса, ошибка (а это именно ошибка) никак не проявляется и все работает. Но стоит только попасть такой программе на Висту, как она начинает падать стремительным домкратом. Тоже самое относится и к рандомизации кучи. А уж как рандомизация затрудняет отладку, можно даже не говорить. Программистские форумы буквально пестрят вопросами: как отключить рандомизацию? Официально — никак. Но не будет спешить с выводами, а лучше рассмотрим еще одну интересную особенность Висты — запрет на исполнение кода в стеке. Впервые этот механизм появился в XP SP2 при обязательной аппаратной поддержке со стороны процессоров, реализовавших пресловутые биты NX/XD, позволяющие управлять атрибутом Executable на уровне отдельных страниц. До этого x86 поддерживали атрибут исполняемый исключительно на уровне селекторов, то есть, учитывая плоскую модель памяти Windows, не поддерживали его вообще. И хотя win32 API предполагает наличие подобного атрибута, программистам было хорошо известно, что x86 процессоры реально поддерживают только два атрибута — атрибут на доступ и атрибут на запись, таким образом, PAGE READ тождественен PAGE EXECUTE. Большинство программ, исполняющих код в стеке или куче, довольствовались атрибутом на чтение и все работало. Но вот пришли злые дядьки и постановили: дальше так жить нельзя, типа от этого вирусы разводятся, shell-код выполняется и вообще. Так появился механизм DEP (Data Execution Prevention), предотвращающий исполнение данных там, где по мнению создателей Windows, они исполняться не должны. В XP SP2 по умолчанию защищались лишь системные компоненты.

070

К той же категории относится и механизм SafeSEH, впервые анонсированный в XP SP2, но реально доделанный лишь с выходом Висты. Его безопасность заключается в том, что обработчик исключений не может размещаться в стеке и, что самое неприятное, обработчик не может назначаться динамически.

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

— динамически назначают обработчик и кладут его в стек. На XP SP2 и Висте они, соответственно, работать не могут.

Археологические раскопки недр NTDLL.DLL выявляют весьма любопытный факт.

Системный загрузчик проверяет имена секций каждого запускаемого исполняемого файла (динамической библиотеки) и, если находит секцию с именем «.aspack», «.pcle», «.sforce», предпринимает ряд действий по обеспечению обратной совместимости и взводит флаги, вырубающие кучу защит, появившихся в Висте и не отключаемых легальным путем. Никаких других дополнительных проверок не выполняется. Достаточно совпадение имени секции — вот и все.

ФрагменткодаизNTDLL.DLLсименамсекцийPE-файладля которыхзадействуетсяспециальныйрежимсовместимости

sub_77F0B717+59

Сюрприз, да? Оказывается, если упаковать проблемную программу упаковщиком ASPack (кстати говоря, скупленным фирмой Star Force), то шансы, что она заработает под Вистой существенно возрастут. А можно и не упаковывать, а просто взять в руки hiew и переименовать секцию

«.text» (или «.CODE») в «.aspack».

Секции с именами «.sforce» принадлежат файлам, защищенным протектором Star Force (странно, что Microsoft вообще знает об этой недоделке), для совместимости с которым приходится не только вырубать кучу защит, но даже эмулировать особенности поведения некоторых недокументированных API-функций и структур данных. Короче, «.sforce» намного круче,

чем «.aspack»!

Кому принадлежит имя «.pcle», я не знаю. Поиск по Интернету ничего вразумительного не дал, но если есть желание поэкспериментировать, то можно воспользоваться и им.

Короче, берем HIEW, загружаем в него конфликтное приложение, нажатием на <ENTER> переходим в hex-режим, давим на <F3> для активации редактирования и меняем имя кодовой секции (обычно «.text» или

«.CODE») на «.sforce» (см. рис. 5).

Сохраняем изменения по <F9> и выходим. Если файл использует контрольную сумму для проверки своей целостности, ее можно пересчитать с помощью утилиты editbin.exe, входящей в комплект поставки Microsoft Visual Studio, запущенной с ключом «/RELEASE». z

xàêåð 03 /111/ 08

Крис Касперски

ладчика работает через MS Debugging API, страдающий кучей врожденных ограничений, оставляющий за собой множество трудноудаляемых следов и представляющий легкую мишень для антиотладочных технологий. Для борьбы с последними приходится писать довольно сложные плагины, зачастую работающие на уровне нулевого кольца (то есть устанавливающие свой собственный драйвер). Другой недостаток

— графический интерфейс, причем часть действий выполняется только мышью, ненавистной хакерам старого поколения, предпочитающим консоль и клаву.

Olly Debugger 2.00с pre-alpha 3

Экспериментальный отладчик с полностью переписанным debug engine и жестко урезанным функционалом (по сравнению с версией 1.10). Тем не менее, debug engine по-прежнему использует MS Debugging API и это ring-3 отладчик со всеми вытекающими отсюда ограничениями.

IDA Pro Advanced 5.2

Включает в себя довольно примитивный ring-3 отладчик, работающий через MS Debugging API (в NT) и через библиотеку ptrace (в UNIX), что делает ее легкой добычей для защитных механизмов. Готовых антиантиотладочных плагинов под ИДУ раз два и обчелся, но при наличии SDK всегда можно написать свой собственный (правда, вместе с этим придется писать еще кучу недостающего функционала, уже реализованного у конкурентов). Пожалуй, единственное преимущество интегрированного отладчика — возможность отладки подопытного кода прямо «на месте» (just in the place), без выхода из дизассемблера. Поддерживаются как графические, так и консольные режимы (в UNIX — только консоль). IDA Pro

— коммерческий продукт, причем большинство «варезных» версий, гуляющих в сети, работают крайне нестабильно и постоянно падают, поэтому имеет смысл остановиться на бесплатной (и, естественно, нереально урезанной) версии

4.9.

Microsoft Debugger 6.8.4.0

Входит в состав WDK (Windows Driver Kit — бывший Driver Development Kit или DDK), а также в комплект Debugging Tools. Оба они бесплатны, но WDK намного больше по объему и требует предварительной регистрации для получения Windows Live ID (проверка валидности Windows при этом не осуществляется), в то время как Debugging Tools раздается без регистрации вместе с SDK, в которую входит документация, заголовочные файлы, библиотеки и несколько примеров, как надо писать плагины. К сожалению, сторонних плагинов под Microsoft Debugger очень немного.

Microsoft Debugger может работать как на прикладном уровне (ring 3), так и на уровне ядра. Вплоть до XP ядерная

Легендарный мягкий лед

отладка требовала, как минимум, двух машин, соединенных COM-шнурком, но теперь достаточно и одной. Поставляется в двух редакциях: windbg.exe — графический интерфейс и cdb.exe — интерфейс командой строки. И та и другая являются лишь тонкими обертками вокруг dbgeng.dll, в которой, собственно, и реализован основной отладочный «движок», документированный протокол обмена. Поэтому, чтобы в очередной раз не писать трассер с нуля, dbgeng.dll

можно использовать в качестве «фундамента» при написании универсальных распаковщиков исполняемых файлов.

SoftIce 2.6.0 (Build 336)

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

Названаяверсиянеявляетсяпоследней,ноонастабильнаи хорошосовместимасхакерскимиплагинами,«вгрызающими- ся»вотладчикбезвсякогоAPI(путемbit-hack’а).Сболеепоз- днимиверсиямихакерскиеплагинынесовместимы.Сдругой стороны,SoftICEподдерживаетплагины,написанныедляMS Debugger,авотобратнойсовместимости,увы,ненаблюдается. В настоящее время поддержка soft-ice прекращена и продукт похоронен. Он еще совместим с XP и Server 2003 (хотя на

Крис Касперски размышляет об антиотладке на 64-битных архитектурах

links

Olly-Debugger

www.ollydbg.de

IDA Pro 4.9 Freeware www.hex-rays.com

Syser www.sysersoft.com/ download.htm

GDB http://sourceware. org/gdb/download/

dvd

На нашем DVD ты найдешь полный комплект антиотладочного софта, который нам позволило выложить законодательство.

Внешний вид Olly Debugger

Syser за работой

info

Название «SoftICE»

позаимствовано из фантастического романа Уильяма Гибсона «Нейрома-

тик» (William Gibson: «Neuromantic»).

В роли льда там выступали защитные механизмы, которые хакерам приходилось рубить, соответственно, SoftICE — дословно

«мягкий лед» — это легкий хакинг.

многоядерных процессорах уже наблюдаются серьезные проблемы), но в долгосрочной перспективе SoftICE обречен и необходимо искать ему замену. Чем скорее, тем лучше!

Syser 1.95.19000.0894

Достойная альтернатива умирающему SoftICE. Ядерный отладчик, поддерживающий многопроцессорные машины и всю линейку NT-подобных систем — по Висту включительно. Это коммерческий продукт, написанный двумя китайскими хакерами — Wu YanFeng и Chen JunHao — предоставляющими всего лишь семидневный бесплатный триал. Оскорбительно мало, однако, поскольку я вливался в Syser team, то рассказывать о том, как ломать его — не собираюсь (хотя ломается он легко). В настоящий момент готовится книжка «Техника отладки II» с полной версией Syser’а на компакт диске, так что осталось лишь немного подождать, чтобы заполучить это чудо.

Нас ждет графический интерфейс, к которому поначалу трудно привыкнуть, но в остальном — это все тот же самый SoftICE, во всяком случае с точки зрения синтаксиса команд. Будучи в team’е, я работаю над усилением обороноспособности этого отладчика (в смысле стойкости против антиотладки). Плюс разрабатывается возможность подключения внешних плагинов (правда,

плагины для Syser’а мне неизвестны, кроме пары штук, написанных им самим в порядке эксперимента).

GDB 6.1

GNUDebugger—основнойотладчикподUNIX,ориентирован- ныйнасовершенноинойтипмышления,чемвсевышеперечисленныеотладчики.Этонепростоинтерактивныйотладчик, скорееэтостанокспрограммнымуправлением,гибкими мощныминтерфейсом.Отлаживатьсегопомощью«честные» программы—одноудовольствие,новпланеантиотладки делаобстоятплохо.GDBдаженепытаетсясопротивлятьсяи работаетчерезбиблиотекуptrace(котораянасамомделеникакаянебиблиотека,асистемныйвызов).GDBпринципиально неспособенотлаживатьпрограммы,которыенехотят,чтобыих отлаживали.Атакиепрограммымало-помалуначинаютпояв- ляться(взятьхотябыупаковщикисполняемыхфайловотShiva). Версия 6.1 собрана в 2004 году и к новым билдам, очевидно, не относится. Но так как основной debug engine реализован не в GDB, а сосредоточен в ядре системы, то номер версии решающего значения не имеет.

Естественно, помимо GDB существуют и другие отладчики, например, LinIce, но поскольку антиотладочные технологии под UNIX только-только начинают развиваться, для наших экспериментов вполне сгодиться и GDB. z