Обзор эксплойтов

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

Хакер, номер #096, стр. 096-060-6

Для анализа дампа нам понадобятся отладчик Microsoft - i386kd.exe или его графический аналог - windbg.exe, входящие в состав как «слоноподобного» NTDDK, так и компактного Debugging Tools for Windows, бесплатно распространяемого Microsoft (www.microsoft.com/whdc/devtools/debugging/installx86.mspx) и занимающего порядка 15 Мб. Кстати говоря, это очень хорошие отладчики с богатыми возможностями и шикарными расширениями, оставляющими SoftICE далеко позади себя в плане функциональности. Так плагин logexts.dll позволяет вести мониторинг API-функций, а rpcexts.dll - RPC-вызовов. Но сейчас нам эти возможности не понадобятся, зато потребуются отладочные символы. Их можно скачать со специального сервера Microsoft, достаточно лишь создать командный файл следующего содержания:

Командный файл, запускающий отладчик для анализа дампа памяти

SET _NT_SYMBOL_PATH=SRV*С:\TEMP*http://msdl.microsoft.com/download/symbols

rem i386kd -z C:\WINNT\memory.dmp

rem windbg -z C:\WINNT\memory.dmp

Здесь C:\TEMP - каталог, куда будут складываться отладочные символы, автоматически скачиваемые отладчиком из сети; C:\WINNT\memory.dmp - путь к файлу дампа; REM - позволяет выбирать между консольным и графическим отладчиком по своему предпочтению. После загрузки дампа памяти в отладчик его окно будет выглядеть приблизительно так, как показано на скриншоте (раскладка окон должна настраиваться каждым пользователем индивидуально, в соответствии с его вкусами и потребностями).

Для выдачи дополнительной информации windbg предлагает нам ввести команду !analyze –v. Что ж, нас не нужно просить дважды. Вводим ее в командой строке, и вид отладчика тут же преображается.

Курсор дизассемблерного листинга останавливается строкой ниже nt!KeBugCheckEx, ничего не говоря нам об истинной локации сбоя. А вот командное окно говорит. Прокручиваем его мышью и видим:

Истинное место сбоя по данным встроенного анализа дампов

FAULTING_IP:

win32k!HmgIncrementShareReferenceCount+37

a0016b8e ff4004 inc dword ptr [eax+0x4]

Вот это уже ближе к телу! На самом деле сбой произошел в функции HmgIncrementShareReferenceCount, находящейся внутри драйвера win32k.sys по смещению 37h байт от ее начала, где оказалась команда inc dword ptr [eax+4h]. Но каким образом данные попали туда и как на них можно воздействовать? Чтобы отрыть истину, у нас есть 2 пути - загрузить win32k.sys в IDA Pro и дизассемблировать HmgIncrementShareReferenceCount или же установить на HmgIncrementShareReferenceCount точку останова и, вновь запустив exploit, начать трассировать ее, разбираясь, каким именно образом она «перерабатывает» данные секции GDI. Для этого нам понадобиться любой отладчик ядра - SoftICE или Microsoft i386kd, однако последний требует для отладки сразу две машины, соединенные COM-шнурком. Впрочем, одна из них может быть и виртуальной. VMWare позволяет пихать COM-порт в pipe, упрощая отладку. Основные принципы отладки описаны в «Технике отладки программ без исходных текстов», которую можно слить с моего ftp, написав первый exploit, который не грохает систему, а делает что-то полезное.