Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

articles:windbg-rpc [2017/09/05 02:55] (текущий)
Строка 1: Строка 1:
 +====== WinDbg-Rpc ======
 +<​sub>​{{WinDbg-Rpc.odt|Original file}}</​sub>​
 +
 +====== отладчик windbg как API- и RPC-шпион ======
 +
 +крис касперски ака мыщъх, ака souriz, akanezumi, akaelraton, no-email
 +
 +**ранние версии ****windbg****'​а от ****Microsoft**** не пользовались у хакеров большой популярностью и все дружно налегали на ****soft****-****ice****,​ но теперь,​ когда поддержка последнего прекращена и он обречен на медленное,​ но неотвратимое умирание,​ возникает вопрос:​ как дальше жить и чем ломать?​ тем временем,​ ****windbg**** сильно повзрослел и хотя это кал, по целому ряду характеристик он обгоняет ****soft****-****ice****. сейчас мыщъх покажет как использовать ****windbg**** в качестве ****API****- и ****RPC****-шпиона.**
 +
 +===== введение =====
 +
 +API- и RPC-шпионы входят в активный инструментарий хакера. Эти орудия борьбы должны быть всегда остро заточенными и стоять наготове к десантированию в тыл врага для сбора информации о вызываемых функциях. Зная какие функции (и с какими аргументами) вызывает защита,​ мы можем ставить точки останова,​ всплывая отладчиком в непосредственной близости от штаб-квартиры врага. Если же этой информации у нас нет, точки останова приходится вставить вслепую,​ гадая какой именно API-функцией воспользовалась программа. В частности,​ одних только функций для чтения текущей даты (необходимой защите для определения периода истечения триала) существует с полдесятка и без шпиона нет никакой возможности угадать какой именно из них воспользовался разработчик.
 +
 +Тоже самое относится и к RPC-вызовам (RemoteProcedureCalls – Удаленные Вызовы Процедур),​ своеобразном фундаменте множества служб, к числу которых принадлежит и служба печати,​ да и не только она одна.
 +
 +В общем, без шпионов ломать становится совсем хреново. Но… soft-ice не предоставляет таких возможностей и приходится использовать сторонние средства,​ большинство из которых способы шпионить только за честными программами,​ но столкнулись с защитами начинают мести такую пургу, что прямо метель. К тому же, неудобно каждый раз выходить из отладчика,​ чтобы запустить очередную утиль. Намного комфортнее держать весь хакерский арсенал в одном месте.
 +
 +…и этим местом постепенно становиться **Microsoft**** ****Windows Debugger**,​ поддерживающий множество полезных расширений на все случаи жизни и, естественно,​ позволяющий писать нужные нам расширения самостоятельно.
 +
 +Преодолевая стойкое убеждение перед продукцией Microsoft, все же скачаем этого зверя и посмотрим на что он способен.
 +
 +===== >>>​ врезка где брать и почем =====
 +
 +MicrosoftWindowsDebugger (далее по тексту просто WinDeb) входит в состав множества продуктов:​ PlatformSDK,​ DDK, WDF, а так же поставляемся вместе с самостоятельным пакетом "​DebuggingToolsforWindows",​ занимающим чуть больше 15 Мбайт,​ причем версия WinDeb из комплекта "​DebuggingToolsforWindows"​ обычно самая свежая и содержащая наибольшее количество всяких полезных расширений.
 +
 +Скачать ее можно с http://​www.microsoft.com/​whdc/​devtools/​debugging (32-битная и 64-битные версии). Microsoft устроила бесплатную раздачу,​ не требуя даже проверки подлинности копии Windows. Во всяком случае пока… В любом случае,​ пакет "​DebuggingToolsforWindows"​ валяется на многих сайтах,​ правда далеко не всегда первой свежести.
 +
 +{{windbg-rpc_Image_0.png}}
 +
 +Рисунок 1 бесплатнаяраздача Debugging Tools ссайта Microsoft
 +
 +===== первое знакомство с WinDbg =====
 +
 +Отладчик WinDbg представлен в двух "​ипостасях":​ i386kd.exe (для 64-битной версии — ia64kd.exe) — консольный kernel-debugger (см. рис. 2),​ отлаживающий _только_ драйвера вместе с дампами памяти ядра и требующий как минимум двух машин, связанных com-шнурком или взаимодействующим через сеть. Если двух машин нет, можно воспользоваться VM Ware, поддерживающий виртуальные сетевые адаптеры и позволяющей загонять com-порт (виртуальный,​ естественно) в пайп. Несмотря на то, что i386kd.exe – довольно мощная и хорошая штука (подробно описанная у Шрайбера в его "​Недокументированных возможностях Windows 2000"​) для наших хакерских целей она не потребуется.
 +
 +{{windbg-rpc_Image_1.png}}
 +
 +Рисунок 2 i386kd — консольная версия ядерного отладчика от Microsoft
 +
 +WinDbg.exe (см. рис.3) – представляет собой типичное GUI-приложение (уже тошнит,​ да?), довольствующееся одним компьютером и позволяющее отлаживать прикладные приложения,​ анализировать дампы памяти,​ шпионить за событиями происходящими системы. А вот для отладки драйверов опять-таки понадобиться второй компьютер,​ соединенный сетью или шнурком,​ но мы обойдемся и без шнурка.
 +
 +{{windbg-rpc_Image_2.png}}
 +
 +Рисунок 3 графическая версия ядерного/​прикладного отладчика от Microsoft
 +
 +Много полезной информации содержится в справочном файле debugger.chm,​ который полезно прочитать _до_ запуска отладчика,​ чтобы не задавать на форумах глупых вопросов и не ломиться в открытые двери. Возможности WinDbg намного больше,​ чем это кажется на первый взгляд,​ просто до них через меню и прочие интерфейсные штучки _не_ добраться!
 +
 +ОК, начинаем рыть в глубь. В каталогах w2kchk и w2kfre валяются модули расширения для Windows 2000,​ конструктивно выполненные в виде динамических библиотек. Содержащие обоих каталогов идентично и разница между ними заключается в том, что "​*chk"​ работает с отладочной версией ядра (checkingbuild),​ а с "​*fre"​ – с финальной (release).
 +
 +Посмотрим,​ что у нас здесь находится:​
 +
 +Содержимоепапки C:\Program Files\Debugging Tools for Windows\w2kfre
 +
 +13.08.2005 ​ 20:19  <​DIR> ​ .
 +
 +13.08.2005 ​ 20:19  <​DIR> ​ ..
 +
 +06.02.2004 ​ 01:38  105 499 acpikd.dll
 +
 +06.02.2004 ​ 01:38  179 227 gdikdx.dll
 +
 +06.02.2004 ​ 01:38  2 304 541 kdex2x86.dll
 +
 +06.02.2004 ​ 01:38  447 005 kdextx86.dll
 +
 +06.02.2004 ​ 01:38  42 011 ndiskd.dll
 +
 +06.02.2004 ​ 01:38  85 533 ntsdexts.dll
 +
 +06.02.2004 ​ 01:38  78 364 rpcexts.dll
 +
 +06.02.2004 ​ 01:38  24 091 scsikd.dll
 +
 +06.02.2004 ​ 01:38  170 013 userexts.dll
 +
 +06.02.2004 ​ 01:38  302 620 userkdx.dll
 +
 +06.02.2004 ​ 01:38  106 524 vdmexts.dll
 +
 + 11 файлов ​ 3 845 428 байт
 +
 + 2 папок ​ 995 536 896 байт свободно
 +
 +Листинг 1 модули расширения для WinDbg, предназначенные для Windows 2000
 +
 +Назначение большинства модулей можно определить по их названию или на худой конец (не путать конец с мышиным хвостом!) загрузить непонятный модуль в отладчик и вызывать его хелп (чуть позже мы покажем,​ как это делается). А пока заглянем в каталог winxp, хранящий расширения,​ специфичные для Windows XP:​
 +
 +Содержимоепапки C:\Program Files\Debugging Tools for Windows\winxp
 +
 +13.08.2005 ​ 20:19  <​DIR> ​ .
 +
 +13.08.2005 ​ 20:19  <​DIR> ​ ..
 +
 +21.01.2004 ​ 10:43  73 728 acpikd.dll
 +
 +28.06.2002 ​ 15:47  4 841 default.tmf
 +
 +24.02.2004 ​ 13:01  285 696 exts.dll
 +
 +19.02.2004 ​ 18:19  1 096 192 kdexts.dll
 +
 +21.01.2004 ​ 12:30  66 048 minipkd.dll
 +
 +21.01.2004 ​ 12:52  83 968 ndiskd.dll
 +
 +19.02.2004 ​ 18:20  51 200 ntsdexts.dll
 +
 +21.01.2004 ​ 12:25  335 360 rpcexts.dll
 +
 +21.01.2004 ​ 12:30  61 952 scsikd.dll
 +
 +16.09.2003 ​ 19:41  16 467 system.tmf
 +
 +21.01.2004 ​ 13:09  262 144 traceprt.dll
 +
 +21.01.2004 ​ 10:48  154 112 vdmexts.dll
 +
 +21.01.2004 ​ 10:37  12 800 w64cpuex.dll
 +
 +21.01.2004 ​ 10:37  7 168 w64ia32xcpuex.dll
 +
 +21.01.2004 ​ 10:37  14 336 wamd64cpuex.dll
 +
 +21.01.2004 ​ 10:26  50 176 wmitrace.dll
 +
 +21.01.2004 ​ 10:37  77 312 wow64exts.dll
 +
 + 17 файлов ​ 2 653 500 байт
 +
 + 2 папок ​ 995 532 800 байт свободно
 +
 +Листинг 2 модули расширения для WinDbg, предназначенные для Windows XP
 +
 +Как видно, набор расширений для XP намного богаче,​ но мыщъх все равно не изменит своей любимой Windows 2000,​ под которой сидел, сидит и будет сидеть,​ а когда же она окончательно одряхлеет,​ мигрирует на FreeBSD, тем более, что расширения,​ ответственные за шпионах,​ хранятся в каталоге winext общим для всех систем.
 +
 +Содержимоепапки C:\Program Files\Debugging Tools for Windows\winext
 +
 +13.08.2005 ​ 20:19  <​DIR> ​ .
 +
 +13.08.2005 ​ 20:19  <​DIR> ​ ..
 +
 +24.02.2004 ​ 13:01  612 864 ext.dll
 +
 +24.02.2004 ​ 13:01  174 592 kext.dll
 +
 +**19.02.2004 ​ 18:44  228 864 logexts.dll**
 +
 +13.08.2005 ​ 20:19  <​DIR> ​ manifest
 +
 +24.02.2004 ​ 13:01  53 760 uext.dll
 +
 +21.01.2004 ​ 12:28  22 528 wdfkd.dll
 +
 + 5 файлов ​ 1 092 608 байт
 +
 + 3 папок ​ 995 524 608 байт свободно
 +
 +Листинг 3 модули расширения для WinDbg, предназначенные для осей всех типов
 +
 +Файл с ничего не говорящим именем logexts.dll — это и есть шпионский компонент (ну для шпионов маскироваться — вполне нормально и ничего удивительно тут нет).
 +
 +Теперь что касается самого WinDeb. Раскладку окон, цвет и гарнитуру шрифтов каждый может настроить под свой вкус, поскольку в конфигурации по умолчанию с отладчиком долго работать невозможно,​ иначе глаза опустятся куда-то в район хвоста,​ а для хакеров глаза — второй инструмент после серого мозгового вещества!
 +
 +Так что первое,​ что нужно сделать с WinDeb это настроить его под свой _собственный_ вкус (а вкусы, как известно,​ у всех разные).
 +
 +===== техника API-шпионажа =====
 +
 +В состав Platform SDK изначально входило какое-то подобие API-шпиона (точнее,​ _пародия_ на API-шпиона),​ расположенного в \Microsoft Platform SDK\Bin\WinNT\Apimon.Exe,​ однако он выдавал только общую статистку по API-вызовам без учета их хронологии (см. рис. 4),​ и постоянно падал при попытке загрузить в него что-то более сложнее чем notepad (см. рис. 5). Короче,​ для взлома Apimon.exe не годился. Однозначно!
 +
 +{{windbg-rpc_Image_3.png}}
 +
 +Рисунок 4 отчет ApiMon'​а о количестве вызовов API-функций,​ совершенных подопытной программой
 +
 +{{windbg-rpc_Image_4.png}}
 +
 +Рисунок 5 крах ApiMon'​а при попытке скормить ему FAR, упакованный ASPack'​ом
 +
 +Посмотрим на Windbg – что же в нем изменилось?​ Забегая вперед,​ скажем — абсолютно все! Microsoft предоставила нам сложный и могущественный инструмент,​ способный решать широкий круг задач и противостоять различным антиотладочным приемам,​ которыми понапичканы современные защитные механизмы.
 +
 +Короче,​ будем считать,​ что мыщъх вас соблазнил. Приступаем к экспериментом (не путать с экскрементами!) Первым делом загружаем в отладчик файл, за которым мы будем шпионить,​ например,​ все тот же Блокнот. Делается это так: file  open executable  notepad.exe или, как вариант,​ <​CTRL-E>,​ notepad.exe. На крайняк файл можно загрузить из командной строки. Только не нажимайте раскрывающуюся папку на панели инструментов — это все равно не поможет,​ т. к. она предназначена для работы с исходными текстами и их окружением,​ которых в нашем распоряжении естественно нет (если бы они были — стали бы мы тут извращаться со шпионажем?​!).
 +
 +CommandLine:​ C:​\WINNT\NOTEPAD.EXE ​
 +
 +Symbol search path is: *** Invalid ***
 +
 +****************************************************************************
 +
 +* Symbol loading may be unreliable without a symbol search path.  *
 +
 +* Use .symfix to have the debugger choose a symbol path.  *
 +
 +* After setting your symbol path, use .reload to refresh symbol locations. *
 +
 +****************************************************************************
 +
 +Executable search path is: 
 +
 +ModLoad: 01000000 01010000 ​ notepad.exe
 +
 +ModLoad: 77f80000 77ffd000 ​ ntdll.dll
 +
 +ModLoad: 76ae0000 76b1e000 ​ C:​\WINNT\system32\comdlg32.dll
 +
 +ModLoad: 772c0000 77326000 ​ C:​\WINNT\system32\SHLWAPI.DLL
 +
 +ModLoad: 79060000 790c5000 ​ C:​\WINNT\system32\ADVAPI32.dll
 +
 +ModLoad: 79430000 794e4000 ​ C:​\WINNT\system32\KERNEL32.dll
 +
 +ModLoad: 770f0000 77168000 ​ C:​\WINNT\system32\RPCRT4.dll
 +
 +ModLoad: 77f40000 77f7f000 ​ C:​\WINNT\system32\GDI32.dll
 +
 +ModLoad: 77e10000 77e79000 ​ C:​\WINNT\system32\USER32.dll
 +
 +ModLoad: 78000000 78045000 ​ C:​\WINNT\system32\msvcrt.dll
 +
 +ModLoad: 71710000 71794000 ​ C:​\WINNT\system32\COMCTL32.DLL
 +
 +ModLoad: 7ce80000 7d0c6000 ​ C:​\WINNT\system32\SHELL32.DLL
 +
 +ModLoad: 777d0000 777ee000 ​ C:​\WINNT\system32\WINSPOOL.DRV
 +
 +ModLoad: 79500000 79511000 ​ C:​\WINNT\system32\MPR.DLL
 +
 +(510.508): Break instruction exception - code 80000003 (first chance)
 +
 +eax=00000000 ebx=00071f04 ecx=00000009 edx=00000000 esi=7ffdf000 edi=00071f70
 +
 +eip=77f9193c esp=0006f984 ebp=0006fc98 iopl=0 ​ nv up ei pl nz na pe nc
 +
 +cs=001b ​ ss=0023 ​ ds=0023 ​ es=0023 ​ fs=003b ​ gs=0000 ​ efl=00000202
 +
 +*** ERROR: Symbol file could not be found. ​ Defaulted to export symbols for ntdll.dll - 
 +
 +ntdll!DbgBreakPoint:​
 +
 +77f9193c cc  int  3
 +
 +Листинг 4 неверное определение точки входа при загрузке исполняемого файла в WinDbg
 +
 +Отладчик послушно загружает файл, отображая все динамические библиотеки,​ перечисленные в таблице импорта,​ отображает содержимое регистров и в EntryPoint устанавливаем точку останова. На самом деле, это мы думаем,​ что отладчик установил точку останова в EntryPoint, а в действительности… все обстоит совсем не так! Судя по адресу 77F9193Ch, лежащему глубоко внутри NTDLL.DLL, это не совсем EntryPoint, точнее _совсем_ _не_ EntryPoint, а native-API функция DbgBreakPoint,​ которую можно трассировать до конца света, но так ни к чему и не придти. Приходится выкручиваться и применять всякие недетские извращения (впрочем,​ для хакеров они вполне типичны).
 +
 +Загружаем notepad.exe в наш любимый hiew.exe (или любой другой hex-редактор по вкусу),​ жмем на <​ENTER>​ для перехода в hex-режим,​ давим <F8> для отображения заголовка и переходим в истинную точку входа по <F5>, адрес которой (в моем случае равный 1006420h) высвечивается в левом верхнем углу экрана (см. рис. 6).
 +
 +{{windbg-rpc_Image_5.png}}
 +
 +Рисунок 6 определение подлинной точки входа с помощью hiew'​а
 +
 +Возвращаемся в WinDbg и, находясь в окне команд (такая строчка с деловито мерцающим курсором),​ пишем "​BP 1006420",​ устанавливая точку останова,​ после чего жмем <F5> (или даем команду "​g"​ – в смысле "​goto",​ продолжение выполнения) и ждем развития событий. А события ждать себя не заставляют (см. листинг 5):​
 +
 +0:000> BP 1006420
 +
 +0:000> g
 +
 +ModLoad: 75e00000 75e1a000 ​ C:​\WINNT\system32\IMM32.DLL
 +
 +ModLoad: 10000000 10005000 ​ C:​\WINNT\system32\wmfhotfix.dll
 +
 +Breakpoint 0 hit
 +
 +eax=00000000 ebx=7ffdf000 ecx=00010101 edx=ffffffff esi=0009a0f0 edi=017af640
 +
 +eip=01006420 esp=0006ffc4 ebp=0006fff0 iopl=0 ​ nv up ei pl zr na po nc
 +
 +cs=001b ​ ss=0023 ​ ds=0023 ​ es=0023 ​ fs=0038 ​ gs=0000 ​ efl=00000246
 +
 +notepad+0x6420:​
 +
 +01006420 55  push  ebp
 +
 +Листинг 5 ручная установка бряка на истинную точку входа
 +
 +Отладчик подгружаем еще две динамические библиотеки (одна из которых — wmfhotfix.dll – заплатка от Ильфака),​ радостно сообщает,​ что "​Breakpoint 0 hit" (сработала точка останова),​ выводит значения регистров (ну куда же без них) и первую машинную команду,​ стоящую в точке входа — push ebp.
 +
 +Команда "​u"​ позволит дизассемблировать остальные команды,​ следующие за ней, помогая убедиться,​ что мы действительно находимся там, где нужно:
 +
 +0:000> u
 +
 +notepad+0x6420:​
 +
 +01006420 55  push  ebp
 +
 +01006421 8bec  mov  ebp,esp
 +
 +01006423 6aff  push  0xff
 +
 +01006425 6888180001 ​ push  0x1001888
 +
 +0100642a 68d0650001 ​ push  0x10065d0
 +
 +0100642f 64a100000000 ​ mov  eax,​fs:​[00000000]
 +
 +01006435 50  push  eax
 +
 +01006436 64892500000000 ​ mov  fs:​[00000000],​esp
 +
 +Листинг 6 дизассемблирование окрестностей точки входа
 +
 +Теперь,​ когда все подготовительные мероприятия завершены,​ необходимо подключить модуль расширения. Для этого даем команду "​**!****load ****<​**//​**name**//​**>​**",​ где "​name"​ имя модуля расширения без "​.dll"​ (в данном случае — "​logexts"​) и полностью вся команда выглядит так:
 +
 +0:000> !load logexts
 +
 +Листинг 7 загрузка модуля расширения,​ ответственного за шпионаж API-функций
 +
 +Отладчик проглатывает ее как ни в чем не бывало и создается впечатление,​ что ничего не происходит. Но это не так! Чтобы убедиться,​ что модуль расширения успешно загружен,​ вызовем его локальную справку,​ набрав команду "​!logexts.help":​
 +
 +0:000> !logexts.help
 +
 +Windows API Logging Extensions ​ v2.09
 +
 +Main control:
 +
 + !loge [dir]  Enable logging. Output directory optional.
 +
 + !logi [dir]  Initialize but don't enable logging.
 +
 + ​!logd ​ Disable logging.
 +
 +Output:
 +
 + ​!logo ​ List output settings.
 +
 + !logo [e|d] [d|t|v] ​ Enable/​disable output:
 +
 + d - Debugger
 +
 + t - Text file
 +
 + v - Verbose log
 +
 +Categories:
 +
 + ​!logc ​ List all categories.
 +
 + !logc p #  List APIs in category #.
 +
 + !logc [e|d] *  Enable/​disable all categories.
 +
 + !logc [e|d] # [#] [#] ...  Enable/​disable category #.
 +
 +Buffer access:
 +
 + !logb p  Print buffer contents to debugger.
 +
 + !logb f  Flush buffer to log files.
 +
 +Module inclusion/​exclusion:​
 +
 + ​!logm ​ Display module inclusion/​exclusion list.
 +
 + !logm [i|x] [DLL] [DLL] ... Specify module inclusion/​exclusion list.
 +
 +Листинг 8 выдача справки по "​шпионским"​ командам
 +
 +Ого! Сколько тут всего, хорошего и разного! С одного захода это даже не разгрызть,​ но мы все-таки попробуем. Команда "​!loge [dir]"​ активирует шпионаж за API-функциями,​ при желании позволяя указать каталог,​ в котором будет автоматически создана поддиректория LogExts для хранения логов. Логи могут писаться как в текстовом,​ там и в двоичном формате (формат вывода задается командой "​!logo"​),​ причем имя лога соответствует имени исполняемого файла за которым он шпионил (например,​ "​noTEPAD.EXE.txt"​ — да-да, вот именно в таком регистре он и записывается).
 +
 +Вызванная без параметров,​ команда "​!logo"​ выводит текущий формат лога. Чтобы включать текстовой формат,​ необходимо набрать "​!logo e t",​ а чтобы включить все три параметра,​ необходимо трижды вызывать "​!logo"​ с разными ключами. К сожалению,​ конструкцию "​!logo e dtv"​ отладчик не переваривает. Редиска!
 +
 +Для сокращения размеров лога и выкидывания заведомо ненужной информации,​ WinDbg поддерживает категории API-вызовов,​ список которых можно вывести на экран командой "​!logc":​
 +
 +0:000> !logc
 +
 +Categories:
 +
 + 1 AdvApi32 ​ Enabled
 +
 + 2 AtomFunctions ​ Enabled
 +
 + 3 AVIFileExports ​ Enabled
 +
 + 4 Clipboard ​ Enabled
 +
 + 5 ComponentObjectModel ​ Enabled
 +
 + 6 DebuggingAndErrorHandling ​ Enabled
 +
 + 7 DeviceFunctions ​ Enabled
 +
 + 8 Direct3D ​ Enabled
 +
 + 9 DirectDraw ​ Enabled
 +
 + 10 DirectPlay ​ Enabled
 +
 + 11 DirectSound ​ Enabled
 +
 + 12 GDI  Enabled
 +
 + 13 HandleAndObjectFunctions ​ Enabled
 +
 + 14 HookingFunctions ​ Enabled
 +
 + 15 IOFunctions ​ Enabled
 +
 + 16 MemoryManagementFunctions ​ Enabled
 +
 + 17 Multimedia ​ Enabled
 +
 + 18 Printing ​ Enabled
 +
 + 19 ProcessesAndThreads ​ Enabled
 +
 + 20 RegistryFunctions ​ Enabled
 +
 + 21 Shell  Enabled
 +
 + 22 StringManipulation ​ Enabled
 +
 + 23 ThreadLocalStorage ​ Enabled
 +
 + 24 User32 ​ Enabled
 +
 + 25 User32StringExports ​ Enabled
 +
 + 26 Version ​ Enabled
 +
 + 27 WinSock2 ​ Enabled
 +
 +Листинг 9 просмотр категорий API-функций
 +
 +Как видно, всего имеется 27 категорий и для просмотра функций,​ входящих в каждую из категорий можно воспользоваться командой "​!logic p #",​ где "#"​ – номер категории,​ например,​ 16 — MemoryManagementFunctions.
 +
 +0:000> !logc p 16
 +
 +MemoryManagementFunctions:​
 +
 + ​AllocateUserPhysicalPages ​ KERNEL32.DLL
 +
 + ​FreeUserPhysicalPages ​ KERNEL32.DLL
 +
 + ​GetProcessHeap ​ KERNEL32.DLL
 +
 + ​GetProcessHeaps ​ KERNEL32.DLL
 +
 +
 +
 + ​OpenFileMappingA ​ KERNEL32.DLL
 +
 + ​OpenFileMappingW ​ KERNEL32.DLL
 +
 + ​UnmapViewOfFile ​ KERNEL32.DLL
 +
 +Листинг 10 просмотр имен API-функций,​ входящих в категорию MemoryManagementFunctions (для экономии места приведен только фрагмент)
 +
 +Для шпионажа за определенными категориями функций даем команду:​ "​!logc e #​ #​ #",​ где "​e"​ – включить ("​enable"​) шпионаж,​ а "#"​ – перечень категорий. Ключ "​d"​ (от "​disable"​),​ соответственно,​ означает исключить данную категорию (категории) API-функций из круга подозреваемый и не шпионить за ними. Команда "​!logc e *"​ включает все категории (и это основной режим шпиона в котором гоняют его хакеры при первом знакомстве с ломаемой программой).
 +
 +При желании можно указать перечень динамических библиотек за которыми (не)следует следить. Зачастую это намного проще, чем возиться с категориями. Отображением списка текущий "​поднадзорных"​ библиотек занимается команда "​!logm":​
 +
 +0:000> !logm
 +
 +Included modules:
 +
 + ​USER32.DLL  ​
 +
 + ​GDI32.DLL  ​
 +
 + ​ADVAPI32.DLL  ​
 +
 +Листинг 11 просмотр списка динамических библиотек за которыми осуществляется шпионаж
 +
 +Просматривая этот список,​ мы с удивлением обнаруживаем в нем отсутствие KERNEL32.DLL – базовой ядерной библиотеки,​ содержащей максимум интересующих нас функций. Попытка включить ее в список командой "​!logm i KERNEL32.DLL"​ приводит к появлению многоэтажного матерного ругательства:​ мол, KERNEL32.DLL обязательно должна быть исключена и включению не подлежит:​
 +
 +0:000> !logm i KERNEL32.DLL
 +
 +KERNEL32.DLL is mandatory for exclusion so it can't be included.
 +
 +Included modules:
 +
 +Листинг 12 категорический отказ отладчика шпионить за KERNEL32.DLL
 +
 +На самом деле, стоит только нажать <F5>, как в логе (параллельно выводимом на экран и в файл) появится перехваченные имена API-функций,​ принадлежащих KERNEL32.DLL:​
 +
 +Thrd 4c4 010029BD GetProcAddress( NULL "​RegisterPenApp"​) -> NULL [FAIL]
 +
 +Thrd 4c4 77E202F2 LoadLibraryExW("​INDICDLL.dll"​ NULL ALTERED_SRCH_PATH) -> 0x6E380000
 +
 +Thrd 4c4 77106CF2 GetProcAddress( 0x77F80000 "​NtQuerySystemInformation"​) -> 0x77F889DC
 +
 +Thrd 4c4 77106D0D GetProcAddress( 0x77F80000 "​NtOpenFile"​) -> 0x77F886AC
 +
 +Thrd 4c4 77106D1A GetProcAddress( 0x77F80000 "​RtlInitUnicodeString"​) -> 0x77FABE9C
 +
 +Thrd 4c4 77E202F2 LoadLibraryExW("​PDSHELL.DLL"​ NULL ALTERED_SRCH_PATH) -> 0x00F30000
 +
 +Thrd 4c4 77E202F2 LoadLibraryExW("​SSSensor.dll"​ NULL ALTERED_SRCH_PATH) -> 0x013B0000
 +
 +Thrd 4c4 76AE1DAB GetProcAddress( 0x79430000 "​GetUserDefaultUILanguage"​) -> 0x7947106B
 +
 +Thrd 4c4 7CEAAF39 GetProcAddress( 0x77E10000 "​GetSystemMetrics"​) -> 0x77E33277
 +
 +Thrd 4c4 7CEAAF4A GetProcAddress( 0x77E10000 "​MonitorFromWindow"​) -> 0x77E2920B
 +
 +Thrd 4c4 7CEAAF5B GetProcAddress( 0x77E10000 "​MonitorFromRect"​) -> 0x77E20D54
 +
 +Thrd 4c4 7CEAAF6C GetProcAddress( 0x77E10000 "​MonitorFromPoint"​) -> 0x77E2A0F2
 +
 +Thrd 4c4 7CEAAF7D GetProcAddress( 0x77E10000 "​EnumDisplayMonitors"​) -> 0x77E1F61D
 +
 +Thrd 4c4 7CEAAF8E GetProcAddress( 0x77E10000 "​EnumDisplayDevicesW"​) -> 0x77E18A08
 +
 +Thrd 4c4 7CEAAFAE GetProcAddress( 0x77E10000 "​GetMonitorInfoW"​) -> 0x77E2A07E
 +
 +Листинг 13 фрагмент "​шпионского"​ протокола,​ содержащего всю необходимую нам инфу
 +
 +В наше распоряжение попадают номера потоков (thrd), адреса вызова API-функций вместе с передаваемыми ими аргументами. По приведенному выше фрагменту лога видно, что вызвав функцию GetProcAddress(NULL "​RegisterPenApp"​) по адресу 010029BDh, "​Блокнот"​ погрузился в пучину системных библиотек,​ лежащих далеко за пределами принадлежащей ему области адресов. Но это не главное. Главное то, что шпион от Microsoft работает и успешно шпионит,​ практически ни в чем не уступая большинству своих конкурентов,​ а кое в чем их даже и обгоняя!
 +
 +===== техника RPC-шпионажа =====
 +
 +RPC-шпионаж осуществляется во всем аналогично API-шпионажу (ну, практически аналогично),​ только вместо logexts используется расширение rpcexts, загружаемое командой "​!loadrpcexts"​ и выдающее справку по своим ключам командой "​!rpcexts.help"​.
 +
 +Ключи же это настолько обширны,​ что требуют для своего описания целой статьи... или все-таки не требуют?​ В большинстве случаев встроенного хелпа вполне достаточно!
 +
 +{{windbg-rpc_Image_6.png}}
 +
 +Рисунок 7 загрузка расширения rpcexts, ответственного за RPC-шпионаж (и не только шпионаж!) и выдача справки по нему
 +
 +===== заключение =====
 +
 +Мы рассмотрели всего лишь два расширения отладчика WinDbg из… очень многих! Ну так чего же мы сидим? Чего ждем?! Загружаем все расширения одно за другим,​ даем команду "​!name.help",​ смотрим,​ курим, читаем,​ втыкаем,​ после чего экспериментируем постигая все новые границы и мысленно сравнивая возможности WinDbg с soft-ice.
 +
 +Но, несмотря ни на что, soft-ice все-таки жало. Хороший был отладчик...
 +
 +