Отладка программ с помощью WinDbg

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

Начиная с Windows XP, движок отладки включен непосредственно в операционную систему. Он состоит из двух DLL: dbgeng.dll и dbghelp.dll. Кроме непосредственно средств отладки, среди которых и WinDbg, движок отладки используется в том числе «Доктором Ватсоном» (drwtsn32.exe).

Eще по теме: Защита приложения от отладки

Отладка под Windows

Средство отладки для Windows состоит из четырех приложений, использующих dbgeng.dll:

• cdb и ntsd — отладчики пользовательского режима с консольным интерфейсом. Они различаются только одним: при запуске из существующего консольного окна ntsd открывает новое консольное окно, a cdb этого не делает;
• kd — отладчик режима ядра с консольным интерфейсом;
• WinDbg может использоваться как отладчик либо пользовательского режима, либо режима ядра, но не одновременно. Утилита предоставляет графический интерфейс.

Следовательно, непосредственно WinDbg — это только оболочка для отладки с помощью движка.

Второй — вспомогательный файл dbghelp.dll, который используется внешними тулзами для исследования внутренностей Windows. Под внешними тулзами мы понимаем, например, OllyDbg, Process Explorer от Sysinternals Марка Руссиновича.

У WinDbg есть две версии: классическая и UWP. Первая устанавливается вместе с набором тулз Debugging Tools for Windows. Этот набор содержит две версии WinDbg, соответственно предназначенные для отладки 32-разрядных и 64-битных приложений. UWP-версию можно скачать из Windows Store, она имеет только 32-битную версию. Обе 32-разрядные версии абсолютно равноценны, не считая того, что в UWP-версии имеется продвинутый пользовательский интерфейс «Десятки» (кстати, весьма удобный при работе на большом экране).

Для наших экспериментов я буду применять последний. Разницы в их использовании практически нет, разве что могут немного различаться команды в пользовательском интерфейсе (именно надписи на элементах интерфейса, но не команды встроенного языка — их логическая нагрузка не изменяется).

Отладка с WinDbg

С помощью WinDbg загрузим ломаемый нами файл passCompare1.exe через пункт меню Launch executable или Open Executable в классическом приложении. В дальнейшем я не буду приводить аналоги команд —  сами разберетесь.

Сразу после открытия исполняемого файла WinDbg загрузит приложение, в окне Disassembly отладчика появятся дизассемблированные команды, а в окне Command отобразятся результаты их выполнения.

После создания окна приложения еще до вывода каких-либо данных выполнение прерывается на инструкции int 3 — это программная точка останова. Многие новички считают, что выполнение программы начинается с функции main или WinMain. Этому их учат в школе, либо они сами черпают такие сведения из учебников по C. Конечно, это неправда. Прежде чем попасть в функцию main конкретного приложения, процессор зарывается в дебри системного кода загрузчика образов, выполняет горы инструкций инициализации приложения внутри Windows, подключения различных библиотек и прочего. Поэтому такой бряк не означает вход в main нашей программы. Если взглянуть в окошко дизассемблера, мы увидим, что прерывание произошло в системной функции LdrpDoDebuggerBreak модуля ntdll.

Первым делом загрузим отладочную информацию для компонентов операционной системы. Для этого в командную строку введем

Данная команда определяет папку, указанную в параметре, куда отладчик при необходимости загрузит отладочные символы для подсистем Windows. После этого надо отправить команду для загрузки или обновления файлов:

После чего WinDbg загрузит нужные данные с серверов Microsoft.

Кроме того, можно воспользоваться уже имеющейся отладочной информацией, для этого существует команда .sympath+ <путь к директории>. Если файл с отладочными символами находится в одной папке с исполняемым файлом, он подхватится автоматически. Еще можно взять файлы исходного кода, но в таком случае проще воспользоваться отладчиком, входящим в среду разработки.

Таким образом, если натравить отладчик на дебажную версию passCompare1 и при достижении первой точки останова поставить бряк на функцию main, написав

по команде g мы продолжим выполнение и, когда отладчик достигнет поставленной точки останова (начало функции main), в окне дизассемблера увидим, что листинг разделен на сегменты, в заголовке которых находятся имена функций (в частности main). В релизной версии этого не будет. Если же мы поставим точку останова по адресу начала модуля + адрес точки входа, то мы попадем не в начало функции main, а в системный загрузчик — функцию mainCRTStartup, подготовленную компилятором.

Кроме Microsoft, мало кто предоставляет отладочные символы, так что не будем привыкать к легкой жизни. Тем более WinDbg специально заточен для отладки программ без отладочной информации и исходного кода — применим его по назначению. Между тем, если приглядеться к окошку дизассемблера повнимательнее, можно заметить, что в отличие от дизассемблера dumpbin, который мы использовали в прошлой статье, WinDbg распознает имена системных функций, чем существенно упрощает анализ.

Точки останова могут быть двух типов: программные и аппаратные. С первыми мы уже встречались. В программе их может быть любое количество. Для своей работы они модифицируют память исполняемого процесса, то есть в том месте, где должен стоять бряк, отладчик запоминает ассемблерную инструкцию и заменяет ее на int 3. Из-за того что программная точка останова изменяет память, ее не везде можно установить. В этом заключается ее основной недостаток.

Главная команда для установки программной точки останова — bp. Для получения списка установленных точек служит команда bl, а для удаления — команда bc, параметром которой является индекс точки останова. Звездочка в качестве параметра удаляет все бряки. Команды be и bd, соответственно, включают и выключают брейк-пойнты.

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

Аппаратные бряки могут ставиться в любое место памяти процесса. Таким образом, они лишены недостатка программных бряков. Остальные регистры предназначены для хранения условий доступа — срабатывания точек останова, например чтение, запись, исполнение. Малое количество — основной недостаток аппаратных бряков. Для установки аппаратной точки останова используется команда ba с тремя параметрами: тип доступа, размер и адрес.

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

• встроенные команды служат для отладки процесса и записываются без лидирующего символа, к таким командам относятся g, bp, bd;
• метакоманды управляют работой отладчика, перед ними ставится символ точки, например .reload, .symfix, .cls;
• команды-расширения, загружаемые из внешних DLL, имеют в начале символ восклицательного знака, например !heap, !dh.

Поиск адреса

Давайте попробуем наскоро найти защитный механизм и, не вникая в подробности его функционирования, напрочь отрубить защиту. Вспомним, по какому адресу расположен в памяти оригинальный пароль. Заглянем в дамп секции .rdata, где хранится пароль. Оригинальный пароль myGOODpassword находится по смещению 0x402100. Попробуем вывести находящиеся по этому адресу в памяти данные:

Cуществует большое количество команд для отображения содержимого памяти. Мы использовали dc, потому что она показывает значения двойных слов и символы ASCII.

Что мы видим? Неинициализированные данные. Раньше (до «Висты») кодокопателям было проще. Windows загружала образы в виртуальную память по определенному при компиляции адресу. Для проверки достаточно несколько раз запустить приложение под Windows XP (построенное соответствующим компилятором), между запусками понадобится перезагрузка системы, так как без нее и «Десятка» будет загружать одно и то же приложение по одному и тому же адресу и сравнивать адреса начала модуля, полученные с помощью того же SoftICE по команде mod -u. Соответственно, секции тоже размещались по одним и тем же адресам. А теперь нам придется самим искать секцию .rdata уже не на диске, а в памяти. Легко сказать, но сделать еще проще!

Найдем, по какому адресу расположен наш модуль в памяти. Для этого в отладчике введем lmf m passcompare1 (второй параметр — имя модуля, адрес которого надо определить). В результате на своем компе я получил:

Отсюда следует, что начало нашего модуля находится по адресу 0xCF0000. После каждой перезагрузки системы модуль конкретного приложения проецируется в различные адреса. Теперь выведем карту памяти нашего модуля, сведения обо всех секциях PE-файла: !dh passCompare1. Вывод команды довольно объемный.

!dh — в некотором роде аналог команды map32 из SoftICE, при этом первая предоставляет больше сведений. Найдем в выводе описание целевой секции .rdata:

Здесь нас интересует четвертая строчка — виртуальный адрес. Теперь можно найти, где в памяти располагается .rdata, для этого надо сложить начальный адрес модуля и виртуальный адрес секции. Посмотрим, что там находится:

Уже теплее: читаемые символы. Пройдем глубже в секцию и распечатаем диапазон адресов:

А вот и наш пароль по адресу 0xCF2100! Дамп памяти процесса:

Выровняем вывод так, чтобы наш пароль отобразился с начала строки. Для этого к текущему адресу 0xCF2100 надо прибавить 8 — количество символов для смещения. Это будет его фактический адрес. Проверим наше предположение:

Есть контакт! Задумаемся еще раз: чтобы проверить корректность введенного пользователем пароля, защита, очевидно, должна сравнить его с оригинальным. А раз так, установив точку останова на чтении памяти по адресу 0xCF2108, мы поймаем за хвост сравнивающий механизм.

Сказано — сделано. Поставим аппаратный бряк, так как программный подарит нам ошибку доступа к памяти, возникающую из-за попытки записи в секцию, доступную только для чтения, каковой .rdata и является. А программному бряку надо модифицировать память.

• Первый параметр — тип доступа (r — чтение);
• второй параметр — количество байтов, подвергаемых операции;
• последний параметр — адрес.

По команде g продолжим отладку и введем любой пришедший на ум пароль, например KPNC++. Отладчик незамедлительно «всплывет»:

В силу архитектурных особенностей процессоров Intel бряк срабатывает после инструкции, выполнившей «поползновение», то есть EIP указывает на следующую выполняемую команду. В нашем случае — jne passCompare1!main+0x62, а к памяти, стало быть, обратилась инструкция cmp dl, byte ptr [ecx]. А что находится в dl? Поднимаем взгляд еще строкой выше — dl, byte ptr [eax].

Можно предположить, что ECX содержит указатель на строку оригинального пароля (поскольку он вызвал всплытие отладчика), тому подтверждение — первая строчка листинга, где в этот регистр помещается смещение 0xCF2108, по которому, как мы помним, находится эталонный пароль. В EAX в таком случае будет указатель на введенный пользователем пароль. Проверим наше предположение.

И правда — догадка оказалась верна. Теперь вопрос: а как это взломать? Вот, скажем, JNE можно поменять на JE. Или еще оригинальнее — заменить EAX на ECX. Тогда оригинальный пароль будет сравниваться сам с собой!

Продолжим трассировку и с помощью команды t пройдем по условному переходу (или внутрь функции). Мы тут же попадаем на инструкцию, выталкивающую Wrong Password на вершину стека:

Знакомые места! Помните, как мы посещали их дизассемблером? После этой инструкции вызывается функция printf. А если поднять взгляд на три строчки выше, мы обнаружим инструкцию test eax, eax, которая выполняет проверку на совпадение. Алгоритм действий прежний — запоминаем адрес команды TEST для последующей замены ее на XOR или записываем последовательность байтов.

Погодите! Не стоит так спешить! Можно ли быть уверенным, что эти байтики по этим самым адресам будут находиться в исполняемом файле? В Windows XP и версиях до нее на это в подавляющем большинстве случаев можно было хотя бы надеяться, но проверка не была лишней, поскольку, хотя системный загрузчик размещал модули по заранее определенным адресам, существовали хитрые защитные механизмы, загружавшие один и тот же модуль по двум разным адресам одновременно. В «Десятке» такой трюк не прокатывает, Windows видит, что это один и тот же модуль, и размещает его в памяти лишь единожды.

Тем не менее в «Десятке» мы даже не можем надеяться, что расположенные по определенным адресам байтики, найденные в памяти с помощью отладчика, будут по тем же адресам располагаться в файле на диске. Ибо в «Висте» и последующих системах в дело вступает механизм ASLR (address space layout randomization), который случайным образом изменяет расположение в адресном пространстве процесса важных структур данных. ASLR в некоторых случаях вполне успешно борется с переполнением буфера, возвратом в библиотеку и другими типами атакам. Лиха беда начало!

Еще по теме: Удаленная отладка вредоносных программ