Включение отладчика ядра windows

жучек, bug

Некоторые устройства, которые мы разрабатываем, требуют написания драйвера устройства для ОС Windows или Linux. Написание драйвера устройства – это не совсем формат нашего сайта, но возможно эта статья будет кому-то полезна. Речь пойдет даже не о написании драйвера, а об отладке драйвера в ОС Windows. Я вот уже две недели как погрузился в отладку драйвера одного устройства.. Не очень простое дело..

Итак, предположим, нам захотелось заглянуть внутрь ядра Windows, посмотреть, как оно работает. Ну или допустим мы написали драйвер нашего устройства, а он не работает или работает неправильно. Нужно посмотреть отладчиком ядра, что происходит.

Прежде всего нужно подготовить «среду» для отладки.
Понадобится 2 компьютера с ОС Windows: первый компьютер – это тот который будет подвержен отладке, второй компьютер – это тот, с помощью которого будет вестись отладка. В терминологии Microsoft первый компьютер называется Target, а второй – это Host.

Эти два компьютера нужно соединить между собой для передачи отладочной информации. Есть несколько способов:

  • использовать специальный майкрософтовский отладочный USB кабель. Не думаю, что вы его легко найдете.
  • использовать кабель FireWire. Это уже проще. Некоторые компьютеры имеют такой разъем, ну или можно найти PCI плату с разъемом FireWire. У меня сейчас в ПК есть такой разъем на материнской плате, а вот в ноутбуке – нет. Так что этот способ так же отпадает.
  • самый простой способ – последовательный порт. Не очень хорошо в смысле скорости передачи, зато просто организовать.

Вот мое рабочее место для отладки:

Соединение компьютеров для отладки WinDbg

Слева – Target, инспектируемый компьютер.
Справа – Host, ноутбук отладчика.

В ноутбук подключен кабель USB и программатор MBFTDI. В этом случае мы его будем  использовать просто как переходник USB2COM. То есть для ноутбука это как последовательный порт. Правда есть ньюанс – выходные уровни программатора MBFTDI не соответствуют стандартным в последовательном порту. Поэтому я еще подключил преобразователь уровней, на микросхеме MAX232 (нашел его среди старых железок, у нас для них целый ящик в офисе).

Теперь нужно настроить Target. У меня здесь Windows 7 64х битная.
Запускаем окно командной строки CMD от имени администратора и в нем выполняем команды:

>bcdedit /debug on
>bcdedit /dbgsettings serial debugport:n baudrate:rate

У меня debugport:COM1 и baudrate:115200
Это в общем и есть вся настройка инспектируемого компьютера.
Теперь на нем нужно просто выполнить перезагрузку.

Далее настроим хост – у меня это ноутбук.
Здесь нужно установить программу отладчика WinDbg.
Программа отладчика есть в составе Windows Driver Kit (WDK) или в составе Microsoft Software Developer Kit.  Все это можно взять с сайта Microsoft https://msdn.microsoft.com/en-us/windows/hardware/hh852365 вполне легально и бесплатно.

У меня на ноутбуке так же Windows 7 x64. Я установил WDK и там в составе есть нужный мне отладчик.

Запускаю WindDbg. Выбираем пункт меню File -> Kernel Debug и появляется окошко:

Настройка отладчика WinDbg

Выбираю скорость передачи 115200 и имя последовательного порта. В принципе все готово.

На ноутбуке Host в программе WinDbg есть командная консоль, достапная через меню View -> Command. Появляется командная строка отладчика.

Любая высокая технология для наблюдателя со стороны мало отличима от магии..

На хосте в программе WinDbg нажимаю Ctrl+Break и компьютер Target останавливается! То есть полностью стоят все процессы и потоки Windows. Можно попить чайку.

В консоли отладчика можно выполнять различные команды. Команд много, у них много параметров, конечно я не смогу их все описать. В конце концов для этого есть вполне вменяемая инструкция-help самой программы WinDbg.

Самые простые команды:

>u – показать дизассемблированный код в месте, где произошла остановка процессора. Ну или “u <adr>” – посмотреть код по адресу.

>d <adr/reg> – показать дамп памяти по адресу или по регистру.

>r <reg> — показать содержимое регистра процессора.

>t – выполнить одну инструкцию процессора.

>p – выполнить инструкцию процессора или целую процедуру, если инструкция call.

Более того, в отладчике конечно можно установить точки останова различного типа.

Самый простой пример:

>bp <adr> — остановка ядра, когда процессор достигнет указанного адреса.

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

Отмена всех точек останова – команда «bc *»

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

Например, мы написали драйвер для ОС Windows. Скомпилировали его debug версию. Вместе с файлом драйвера mydrv.sys компилятор генерирует еще файл с соответствующей символьной информацией mydrv.pdb.

Зайдем в меню отладчика File -> Symbol File Path.. и в диалоговом окне добавим путь к нашему файлу PDB.

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

>bp mydrv!DriverEntry – остановить ядро, когда произойдет вызов функции DriverEntry нашего драйвера mydrv.

Кроме этого, очень полезно подключить к отладчику еще и символьную информацию самого ядра Windows. Конечно, версий виндовсов много, есть разные сборки и где найти символьную информацию именно соответствующую вашей Target ОС Windows?

Проще всего, в командной строке отладчика выполнить команду

> .sympath SRV*c:\localsymbols*https://msdl.microsoft.com/download/symbols

При этом, нужные файлы отладки  (именно нужной версии) будут выкачаны через интернет к вам на диск в папку c:\localsymbols прямо с сервера Microsoft.

Теперь, можно уже более осмысленно дебажить и само ядро.

Хотите посмотреть, как выглядит, например, функция USBPORTSVC_CompleteIsoTransfer драйвера usbport.sys? Нет проблем:

windbg

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

Например, очень многие системные структуры данных в ядре Windows снабжаются «сигнатурой» — специальной строкой, обычно из 4 символов. Таким образом, функции ядра имеют возможность легко проверить переданные им указатели на структуры являются верными или нет. Вот в коде на картике выше есть вызов функции USBPORT_AssertSig. Уже по названию функции становится примерно понятно, что она делает – проверяет указатель, действительно ли он указывает на структуру с нужной сигнатурой.

Вот еще что. При вызовах функций ядра  Windows обычно первые четыре параметра функций передаются в регистрах RCX, RDX, R8 и R9. Похоже остальные параметры, если их больше четырех, передаются функциям в стеке.

Отладка собственного драйвера может быть еще проще, так как имеются исходные тексты самого драйвера. Укажите к ним путь в диалоговом окне отладчика Source Search Path и можно будет выполнять по шагам не отдельные команды процессора, а целые строки программы C/C++. Так же становятся доступны для просмотра локальные переменные функций и прочая отладочная информация.

Вообще отладчик WinDbg дает широкие возможности для отладки своих драйверов, а так же возможность для изучения вообще ядра ОС Windows.




Поделиться через


Средства отладки для Windows поддерживают отладку локального ядра. Это отладка в режиме ядра на одном компьютере. Иными словами, отладчик работает на том же компьютере, на котором выполняется отладка.

Настройка локальной отладки Kernel-Mode

Сведения о настройке локальной отладки в режиме ядра см. в разделе Настройка локального Kernel-Mode Отладка на одном компьютере вручную.

Запуск сеанса отладки

Использование WinDbg

Откройте WinDbg от имени администратора. В меню Файл выберите Отладка ядра. В диалоговом окне Отладка ядра откройте вкладку Локальные . Нажмите кнопку ОК.

Вы также можете запустить сеанс с WinDbg, открыв окно командной строки от имени администратора и введя следующую команду:

windbg -kl

Использование KD

Откройте окно командной строки с правами администратора и введите следующую команду:

kd -kl

Недоступные команды

Не все команды доступны в сеансе отладки локального ядра. Как правило, вы не можете использовать команды, которые приводят к остановке целевого компьютера, даже на мгновение, так как вы не можете возобновить операцию.

В частности, нельзя использовать следующие команды:

  • Команды выполнения, такие как g (Go), p (Step), t (Trace), wt (Trace and Watch Data), tb (Trace to Next Branch), gh (Go с обработкой исключений) и gn (Go с исключением не обрабатывается)

  • Команды завершения работы и дампа файла, такие как .crash, .dump и .reboot

  • Команды точки останова, такие как bp, bu, ba, bc, bd, be и bl

  • Регистрация команд отображения, таких как r и варианты

  • Команды трассировки стека, такие как k и варианты

Если вы выполняете отладку локального ядра с помощью WinDbg, все эквивалентные команды меню и кнопки также будут недоступны.

Доступные команды

Доступны все команды ввода и вывода в памяти. Вы можете свободно считывать данные из пользовательской памяти и памяти ядра. Вы также можете записывать данные в память. Убедитесь, что запись не выполняется в неверную часть памяти ядра, так как это может привести к повреждению структур данных и часто приводит к тому, что компьютер перестает отвечать (т. е. аварийно завершает работу).

Трудности при выполнении отладки локального ядра

Отладка локального ядра — очень деликатная операция. Будьте осторожны, чтобы не повредить или не сбой системы.

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

Драйверы в режиме ядра и операционная система Windows часто отправляют сообщения в отладчик ядра с помощью DbgPrint и связанных функций. Эти сообщения не отображаются автоматически во время отладки локального ядра. Их можно отобразить с помощью расширения !dbgprint .

LiveKD

Средство LiveKD имитирует отладку локального ядра. Это средство создает файл дампа «snapshot» памяти ядра, фактически не останавливая ядро во время выполнения этого snapshot. (Таким образом, snapshot может не отображать ни одного мгновенного состояния компьютера.)

LiveKD не входит в пакет средств отладки для Windows. LiveKd можно скачать с сайта Windows Sysinternals.

Для проведения отладки ядра необходимо подключиться к компьютеру с помощью нуль-модемного кабеля или модемного соединения. Компьютер, выполняющий отладку, будет называться “Host”, а название “Target” получит проблемный компьютер.

Оба компьютера должны работать под управлением одной и той же версии Windows, а символьные файлы для компьютера Target должны быть установлены на компьютере Host. Символьные файлы предоставляются на установочном компакт-диске Windows в каталоге Support\Debug.

Для включения отладки необходимо внести изменения в файл BOOT.INI на компьютере Target.

  1.  Поменяйте атрибуты файла BOOT.INI:

attrib c:\boot.ini – r – s

  2.  Отредактируйте этот файл и в строку запуска Windows добавьте параметр /debug (для того, чтобы сообщить системе о необходимости загрузки в оперативную память отладчика ядра при загрузке Windows). Дополнительными параметрами являются /Debugport, сообщающий системе, какой порт COM необходимо использовать (по умолчанию COM2) и /Baudrate — для указания скорости передачи данных (по умолчанию указана скорость 19200 бод, но лучше использовать 9600). Например:

[operating systems]
multi(0)disk(0)rdisk(0)partition(0)\WINDOWS=»Windows NT» /debug /debugport=com2 /baudrate=9600

  3.  Сохраните файл.

  4.  Установите предыдущие атрибуты файла BOOT.INI:

attrib c:\boot.ini +r +s

В данном примере компьютер Target разрешил соединение через порт COM2 со скоростью 9600 бит/с.

Компьютер Host должен быть настроен с использованием параметров, необходимых для проведения отладки. Кроме того, должны быть установлены символьные файлы. Для их установки перейдите в каталог \support\debug на установочном компакт-диске и введите следующую команду:

expndsym <CD-ROM>: <целевой диск и каталог>

Например:

expndsym f: d:\symbols

Установка может занять некоторое время. Помните, что если на компьютер Target были установлены пакеты обновлений, символьные файлы этих пакетов также следует установить на компьютер Host. Символьные файлы для пакетов обновлений можно загрузить с сайтега компании Microsoft.

Следующей стадией является настройка переменных окружения, необходимых для отладки, например, переменных, указывающих расположение символьных файлов и т.д. Далее представлено описание этих переменных.

Описание системных переменных

_NT_DEBUG_PORT

Порт COM, который должен использоваться для отладки (например, COM2)

_NT_DEBUG_BAUD_RATE

Скорость соединения (например, 9600 бит/с). Убедитесь в том, что указанная скорость соответствует скорости, настроенной на целевом компьютере

_NT_SYMBOL_PATH

Расположение символьных файлов (каталог, в который они были распакованы с помощью утилиты expndsym)

_NT_LOG_FILE_OPEN

Имя файла, который будет использоваться для протоколирования сеансов отладки (необязательная переменная)

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

echo off
set _nt_debug_port=com2
set _nt_debug_baud_rate=9600
set _nt_symbol_path=d:\symbols\i386
set _nt_log_file_open=d:\debug\logs\debug.log

Теперь необходимо скопировать программное обеспечение отладки ядра, которое расположено в каталоге support\debug\<процессор> на установочном компакт-диске (support\debug\I386). Проще всего скопировать весь каталог полностью, поскольку он имеет небольшой размер (около 2,5 Мбайт). Для платформы I386 используется отладчик, который поставляется в виде файла I386KD.EXE. Отладчик запускается с помощью команды I386KD. Для ввода команды нажмите комбинацию клавиш <Ctrl+C> и подождите, пока появится приглашение командной строки kd>.

жучек, bug

Некоторые устройства, которые мы разрабатываем, требуют написания драйвера устройства для ОС Windows или Linux. Написание драйвера устройства – это не совсем формат нашего сайта, но возможно эта статья будет кому-то полезна. Речь пойдет даже не о написании драйвера, а об отладке драйвера в ОС Windows. Я вот уже две недели как погрузился в отладку драйвера одного устройства.. Не очень простое дело..

Итак, предположим, нам захотелось заглянуть внутрь ядра Windows, посмотреть, как оно работает. Ну или допустим мы написали драйвер нашего устройства, а он не работает или работает неправильно. Нужно посмотреть отладчиком ядра, что происходит.

Прежде всего нужно подготовить «среду» для отладки.
Понадобится 2 компьютера с ОС Windows: первый компьютер – это тот который будет подвержен отладке, второй компьютер – это тот, с помощью которого будет вестись отладка. В терминологии Microsoft первый компьютер называется Target, а второй – это Host.

Эти два компьютера нужно соединить между собой для передачи отладочной информации. Есть несколько способов:

  • использовать специальный майкрософтовский отладочный USB кабель. Не думаю, что вы его легко найдете.
  • использовать кабель FireWire. Это уже проще. Некоторые компьютеры имеют такой разъем, ну или можно найти PCI плату с разъемом FireWire. У меня сейчас в ПК есть такой разъем на материнской плате, а вот в ноутбуке – нет. Так что этот способ так же отпадает.
  • самый простой способ – последовательный порт. Не очень хорошо в смысле скорости передачи, зато просто организовать.

Вот мое рабочее место для отладки:

Соединение компьютеров для отладки WinDbg

Слева – Target, инспектируемый компьютер.
Справа – Host, ноутбук отладчика.

В ноутбук подключен кабель USB и программатор MBFTDI. В этом случае мы его будем  использовать просто как переходник USB2COM. То есть для ноутбука это как последовательный порт. Правда есть ньюанс – выходные уровни программатора MBFTDI не соответствуют стандартным в последовательном порту. Поэтому я еще подключил преобразователь уровней, на микросхеме MAX232 (нашел его среди старых железок, у нас для них целый ящик в офисе).

Теперь нужно настроить Target. У меня здесь Windows 7 64х битная.
Запускаем окно командной строки CMD от имени администратора и в нем выполняем команды:

>bcdedit /debug on
>bcdedit /dbgsettings serial debugport:n baudrate:rate

У меня debugport:COM1 и baudrate:115200
Это в общем и есть вся настройка инспектируемого компьютера.
Теперь на нем нужно просто выполнить перезагрузку.

Далее настроим хост – у меня это ноутбук.
Здесь нужно установить программу отладчика WinDbg.
Программа отладчика есть в составе Windows Driver Kit (WDK) или в составе Microsoft Software Developer Kit.  Все это можно взять с сайта Microsoft https://msdn.microsoft.com/en-us/windows/hardware/hh852365 вполне легально и бесплатно.

У меня на ноутбуке так же Windows 7 x64. Я установил WDK и там в составе есть нужный мне отладчик.

Запускаю WindDbg. Выбираем пункт меню File -> Kernel Debug и появляется окошко:

Настройка отладчика WinDbg

Выбираю скорость передачи 115200 и имя последовательного порта. В принципе все готово.

На ноутбуке Host в программе WinDbg есть командная консоль, достапная через меню View -> Command. Появляется командная строка отладчика.

Любая высокая технология для наблюдателя со стороны мало отличима от магии..

На хосте в программе WinDbg нажимаю Ctrl+Break и компьютер Target останавливается! То есть полностью стоят все процессы и потоки Windows. Можно попить чайку.

В консоли отладчика можно выполнять различные команды. Команд много, у них много параметров, конечно я не смогу их все описать. В конце концов для этого есть вполне вменяемая инструкция-help самой программы WinDbg.

Самые простые команды:

>u – показать дизассемблированный код в месте, где произошла остановка процессора. Ну или “u <adr>” – посмотреть код по адресу.

>d <adr/reg> – показать дамп памяти по адресу или по регистру.

>r <reg> — показать содержимое регистра процессора.

>t – выполнить одну инструкцию процессора.

>p – выполнить инструкцию процессора или целую процедуру, если инструкция call.

Более того, в отладчике конечно можно установить точки останова различного типа.

Самый простой пример:

>bp <adr> — остановка ядра, когда процессор достигнет указанного адреса.

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

Отмена всех точек останова – команда «bc *»

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

Например, мы написали драйвер для ОС Windows. Скомпилировали его debug версию. Вместе с файлом драйвера mydrv.sys компилятор генерирует еще файл с соответствующей символьной информацией mydrv.pdb.

Зайдем в меню отладчика File -> Symbol File Path.. и в диалоговом окне добавим путь к нашему файлу PDB.

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

>bp mydrv!DriverEntry – остановить ядро, когда произойдет вызов функции DriverEntry нашего драйвера mydrv.

Кроме этого, очень полезно подключить к отладчику еще и символьную информацию самого ядра Windows. Конечно, версий виндовсов много, есть разные сборки и где найти символьную информацию именно соответствующую вашей Target ОС Windows?

Проще всего, в командной строке отладчика выполнить команду

> .sympath SRV*c:\localsymbols*https://msdl.microsoft.com/download/symbols

При этом, нужные файлы отладки  (именно нужной версии) будут выкачаны через интернет к вам на диск в папку c:\localsymbols прямо с сервера Microsoft.

Теперь, можно уже более осмысленно дебажить и само ядро.

Хотите посмотреть, как выглядит, например, функция USBPORTSVC_CompleteIsoTransfer драйвера usbport.sys? Нет проблем:

windbg

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

Например, очень многие системные структуры данных в ядре Windows снабжаются «сигнатурой» — специальной строкой, обычно из 4 символов. Таким образом, функции ядра имеют возможность легко проверить переданные им указатели на структуры являются верными или нет. Вот в коде на картике выше есть вызов функции USBPORT_AssertSig. Уже по названию функции становится примерно понятно, что она делает – проверяет указатель, действительно ли он указывает на структуру с нужной сигнатурой.

Вот еще что. При вызовах функций ядра  Windows обычно первые четыре параметра функций передаются в регистрах RCX, RDX, R8 и R9. Похоже остальные параметры, если их больше четырех, передаются функциям в стеке.

Отладка собственного драйвера может быть еще проще, так как имеются исходные тексты самого драйвера. Укажите к ним путь в диалоговом окне отладчика Source Search Path и можно будет выполнять по шагам не отдельные команды процессора, а целые строки программы C/C++. Так же становятся доступны для просмотра локальные переменные функций и прочая отладочная информация.

Вообще отладчик WinDbg дает широкие возможности для отладки своих драйверов, а так же возможность для изучения вообще ядра ОС Windows.

Уровень сложностиСредний

Время на прочтение12 мин

Количество просмотров10K

Помимо дизассемблирования, существует и другой способ исследования программ — отладка. Изначально под отладкой понималось пошаговое исполнение кода, также называемое трассировкой. Сегодня же программы распухли настолько, что трассировать их бессмысленно — мы моментально утонем в омуте вложенных процедур, так и не поняв, что они, собственно, делают. Отладчик не лучшее средство изучения алгоритма программы — с этим эффективнее справляется интерактивный дизассемблер (например, IDA).

Пят­надцать лет назад эпи­чес­кий труд Кри­са Кас­пер­ски «Фун­дамен­таль­ные осно­вы хакерс­тва» был нас­толь­ной кни­гой каж­дого начина­юще­го иссле­дова­теля в области компь­ютер­ной безопас­ности. Одна­ко вре­мя идет, и зна­ния, опуб­ликован­ные Кри­сом, теря­ют акту­аль­ность. Редак­торы «Хакера» обновляют ­этот объ­емный труд, чтобы перенес­ти его из вре­мен Windows 2000 и Visual Studio 6.0 во вре­мена Windows 10 и Visual Studio 2019.

Результатом стал цикл статей «Фундаментальные основы хакерства». Перед тобой уже во второй раз обновленная вторая статья из этого цикла (на «Хакере» также доступна первая в новой редакции).

Весь цикл с учетом всех обновлений вышел в виде книги «Фундаментальные основы хакерства. Анализ программ в среде Win64». Купить ее можно на сайте «Солон-пресс».

Книга «Фундаментальные основы хакерства. Анализ программ в среде Win64»

Книга «Фундаментальные основы хакерства. Анализ программ в среде Win64»

Способности отладчиков

Первым делом надо разобраться в перечне основных функциональных возможностей типовых отладчиков (без этого невозможно их осмысленное применение):

  • отслеживание обращений на запись, чтение и исполнение к заданной ячейке (региону) памяти, далее по тексту именуемое бряком (брейком);

  • отслеживание обращений на запись и чтение к портам ввода-вывода (уже неактуально для современных операционных систем, запрещающих пользовательским приложениям проделывать такие трюки, — это теперь прерогатива драйверов, а на уровне драйверов реализованы очень немногие защиты);

  • отслеживание загрузки DLL и вызова из них таких-то функций, включая системные компоненты (как мы увидим далее, это основное оружие современного взломщика);

  • отслеживание вызова программных и аппаратных прерываний (большей частью уже неактуально — не так много защит балуется с прерываниями);

  • отслеживание сообщений, посылаемых приложением окну;

  • и, разумеется, контекстный поиск в памяти.

Как именно это делает отладчик, пока знать необязательно, достаточно знать, что он это умеет, и все. Куда актуальнее вопрос, какой отладчик умеет это делать.

Герои прошлого

В прошлом в качестве отладчика хакеры использовали широко известный SoftICE. Это был действительно мощный инструмент, и даже по прошествии многих лет лучше него ничего не было изобретено. Неоспоримым его преимуществом была возможность отладки ядра Windows с помощью одного компьютера. Между тем, не без давления Microsoft, в 2006 году его разработка была прекращена. А поскольку SoftICE очень сильно зависел от операционной системы Windows, в более поздних ее версиях он просто не работает. Последней версией Windows, в которой можно пользоваться SoftICE, была Windows XP SP 2. В SP 3 он уже не функционировал, а в Vista и Windows 7 и подавно.

Хакеры, конечно, приуныли, но не стали посыпать голову пеплом, а начали изобретать альтернативные отладчики. Последовала эпоха расцвета новых отладчиков. Но какая картина на этом поле сейчас? Нет ни одного нового хорошего отладчика! Передовым среди всех был коммерческий Syser китайских разработчиков. Ему пророчили светлое будущее, возможность заменить SoftICE, но где он сейчас? Может быть, пара копий сохранилась где-то на файловых свалках, но он давно не развивается.

Сейчас по большому счету у хакера есть выбор только из двух по-настоящему годных отладчиков: WinDbg и x64dbg. Последний годится лишь для исследования приложений пользовательского режима, тогда как с помощью WinDbg можно заниматься и ядерной отладкой Windows. Но в этом случае придется использовать два компьютера, объединенных проводом или по локальной сети.

Современный инструмент кодокопателя

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

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

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

  • kd — отладчик режима ядра с консольным интерфейсом;

  • WinDbg может использоваться как отладчик пользовательского режима либо режима ядра, но не одновременно. У WinDbg есть графический интерфейс.

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

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

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

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

Способ 0. Бряк на оригинальный пароль

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

Файлы с примерами можно скачать с GitHub.

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

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

Прежде чем попасть в функцию main конкретного приложения, процессор зарывается в дебри системного кода загрузчика образов, выполняет горы инструкций инициализации приложения внутри Windows, подключения библиотек и прочего. Поэтому произошедший бряк не означает вход в main нашей программы. Если взглянуть в окошко дизассемблера, мы увидим, что прерывание произошло в системной функции LdrpDoDebuggerBreak модуля ntdll.

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

.symfix d:\debugSymbols

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

.reload

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

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

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

bp passCompare1!main

Теперь продолжим выполнение командой g. Когда отладчик достигнет поставленной точки останова (начало функции main), в окне дизассемблера увидим, что листинг разделен на сегменты, в заголовке которых находятся имена функций, в частности main.

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

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

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

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

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

  • встроенные команды служат для отладки процесса и записываются без лидирующего символа, к таким командам относятся g, bp, bd;

  • метакоманды управляют работой отладчика, перед ними ставится символ точки, например: .reload, .symfix, .cls;

  • команды-расширения, загружаемые из внешних DLL, имеют в начале символ восклицательного знака, например: !heap, !dh.

Поиск адреса

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

dc 0x140002280

Существует большое количество команд для отображения содержимого памяти: da, db, dd и прочие. Мы использовали dc, потому что она показывает значения двойных слов и ASCII-символы. Что мы видим? Неинициализированные данные.

Раньше (до Windows Vista) кодокопателям было проще. Windows загружала образы в виртуальную память по определенному при компиляции адресу. В этом легко убедиться: запустим приложение в Windows XP, затем при помощи того же SoftICE узнаем адреса секций (команда mod -u) и выпишем их. После перезагрузки системы и повторного запуска приложения увидим, что они останутся неизменными.

Начиная с Windows Vista, программы после перезапуска системы получают случайные адреса, а не те, что определены при компиляции. Поэтому нам придется самим искать секцию .rdata уже не на диске, а в памяти. Легко сказать, но сделать еще проще!

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

start             end                 module name
00007ff7`159b0000 00007ff7`159b8000   passCompare1 passCompare1.exe

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

!dh passCompare1 

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

SECTION HEADER #2
  .rdata name
    101C virtual size
    2000 virtual address
    1200 size of raw data
    1400 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40000040 flags
         Initialized Data
         (no align specified)
         Read Only

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

dc 0x7ff7159b0000 + 2000 

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

dc 0x7ff7159b2000 0x7ff7159b2300

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

00007ff7`159b2250  159b4040 00007ff7 159b40e0 00007ff7  @@.......@......
00007ff7`159b2260  ffffffff ffffffff ffffffff ffffffff  ................
00007ff7`159b2270  65746e45 61702072 6f777373 003a6472  Enter password:.
00007ff7`159b2280  4f47796d 6170444f 6f777373 000a6472  myGOODpassword..
00007ff7`159b2290  6e6f7257 61702067 6f777373 000a6472  Wrong password..
00007ff7`159b22a0  73736150 64726f77 0a4b4f20 00000000  Password OK.....
00007ff7`159b22b0  00000140 00000000 00000000 00000000  @...............

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

Поставим аппаратный бряк, он же бряк по доступу (break on access), так как при программном будет ошибка доступа к памяти, возникающая по причине попытки записи в секцию, доступную только для чтения, какой .rdata и является. А программному бряку надо модифицировать память.

ba r4 0x7ff7159b2280

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

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

00007ffb`5d375670 488b01               mov     rax, qword ptr [rcx]
00007ffb`5d375673 483b040a             cmp     rax, qword ptr [rdx+rcx]
00007ffb`5d375677 75bf                 jne     ucrtbase!strcmp+0x8 (7ffb5d375638)
00007ffb`5d375679 4e8d0c10             lea     r9, [rax+r10]
00007ffb`5d37567d 48f7d0               not     rax

В силу архитектурных особенностей процессоров Intel бряк срабатывает после инструкции, выполнившей «поползновение», то есть RIP указывают на следующую выполняемую команду. В нашем случае (выделенная строка) — jne ucrtbase!strcmp+0x8, а к памяти, стало быть, обратилась инструкция cmp rax, qword ptr [rdx+rcx]. А что находится в RAX? Поднимаем взгляд еще строкой выше — mov rax, qword ptr [rcx]. Можно предположить, что RCX содержит указатель на строку оригинального пароля (поскольку он вызвал всплытие отладчика), но не будем спешить с выводами, в сравнении еще присутствует указатель [rdx+rcx]. Куда указывает он? Проверить это в отладчике проще простого. Сначала проверим, куда указывает RCX:

0:000> dc rcx
00000093`bf5cfbd0  434e504b 000a2b2b 00000000 00000000  KPNC++..........

Оказывается, RCX указывает на введенный пользователем пароль! А куда указывает второй указатель?

0:000> dc [rdx+rcx]
00007ff7`159b2280  4f47796d 6170444f 6f777373 000a6472  myGOODpassword..

Здесь как раз притаился оригинальный пароль! Картина начинает приобретать очертания.

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

Выйдем из текущей функции, для этого надо два раза нажать кнопку Step Out в отладчике. В результате мы окажемся в функции main, сразу после сравнения строк:

0007ff7`159b10b2 488d15c7110000     lea     rdx, [passCompare1!`string' (7ff7159b2280)]
00007ff7`159b10b9 488d4c2420        lea     rcx, [buff{[0]} (rsp+20h)]
00007ff7`159b10be e88c0d0000        call    passCompare1!strcmp (7ff7159b1e4f)
00007ff7`159b10c3 85c0              test    eax, eax
00007ff7`159b10c5 7458              je      passCompare1!main+0xaf (7ff7159b111f)

В первой строчке приведенного листинга в регистр RDX записывается указатель на эталонный пароль. Чтобы проверить это, выполни команду dc 7ff7159b2280. Во второй строчке в регистр RCX помещается указатель на содержимое строкового буфера, в который записывается введенный пользователем пароль. После вызова strcmp следует test, проверяющий на ноль регистр EAX. Знакомые места! Помнишь, мы посещали их дизассемблером? Далее следует JE, совершающий прыжок на основе предыдущего условия.

Алгоритм действий прежний — запоминаем адрес команды TEST для последующей замены ее на XOR или записываем последовательность байтов.

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

Тем не менее в Windows 10 мы даже не можем надеяться, что находящиеся по определенным адресам байты, найденные в памяти с помощью отладчика, будут по тем же адресам находиться в файле на диске. Когда программа выполняется, все ее секции проецируются в адресное пространство виртуальной памяти, которое кардинально отличается от начальной. В Vista и последующих системах в дело вступает механизм ASLR (Address Space Layout Randomization), который, используя MMU (Memory Management Unit), случайным образом изменяет расположение в адресном пространстве процесса важных структур данных. ASLR в некоторых случаях вполне успешно борется с переполнением буфера, возвратом в библиотеку и другими типами атак.

Авторы: Крис Касперски, Юрий Язев

Помимо дизассемблирования, существует и другой способ исследования программ — отладка. Изначально под отладкой понималось пошаговое исполнение кода, также называемое трассировкой. Сегодня же программы распухли настолько, что трассировать их бессмысленно — мы моментально утонем в омуте вложенных процедур, так и не поняв, что они, собственно, делают. Отладчик не лучшее средство изучения алгоритма программы — с этим эффективнее справляется интерактивный дизассемблер (например, IDA).

Пят­надцать лет назад эпи­чес­кий труд Кри­са Кас­пер­ски «Фун­дамен­таль­ные осно­вы хакерс­тва» был нас­толь­ной кни­гой каж­дого начина­юще­го иссле­дова­теля в области компь­ютер­ной безопас­ности. Одна­ко вре­мя идет, и зна­ния, опуб­ликован­ные Кри­сом, теря­ют акту­аль­ность. Редак­торы «Хакера» обновляют ­этот объ­емный труд, чтобы перенес­ти его из вре­мен Windows 2000 и Visual Studio 6.0 во вре­мена Windows 10 и Visual Studio 2019.

Результатом стал цикл статей «Фундаментальные основы хакерства». Перед тобой уже во второй раз обновленная вторая статья из этого цикла (на «Хакере» также доступна первая в новой редакции).

Весь цикл с учетом всех обновлений вышел в виде книги «Фундаментальные основы хакерства. Анализ программ в среде Win64». Купить ее можно на сайте «Солон-пресс».

Книга «Фундаментальные основы хакерства. Анализ программ в среде Win64»

Книга «Фундаментальные основы хакерства. Анализ программ в среде Win64»

Способности отладчиков

Первым делом надо разобраться в перечне основных функциональных возможностей типовых отладчиков (без этого невозможно их осмысленное применение):

  • отслеживание обращений на запись, чтение и исполнение к заданной ячейке (региону) памяти, далее по тексту именуемое бряком (брейком);

  • отслеживание обращений на запись и чтение к портам ввода-вывода (уже неактуально для современных операционных систем, запрещающих пользовательским приложениям проделывать такие трюки, — это теперь прерогатива драйверов, а на уровне драйверов реализованы очень немногие защиты);

  • отслеживание загрузки DLL и вызова из них таких-то функций, включая системные компоненты (как мы увидим далее, это основное оружие современного взломщика);

  • отслеживание вызова программных и аппаратных прерываний (большей частью уже неактуально — не так много защит балуется с прерываниями);

  • отслеживание сообщений, посылаемых приложением окну;

  • и, разумеется, контекстный поиск в памяти.

Как именно это делает отладчик, пока знать необязательно, достаточно знать, что он это умеет, и все. Куда актуальнее вопрос, какой отладчик умеет это делать.

Герои прошлого

В прошлом в качестве отладчика хакеры использовали широко известный SoftICE. Это был действительно мощный инструмент, и даже по прошествии многих лет лучше него ничего не было изобретено. Неоспоримым его преимуществом была возможность отладки ядра Windows с помощью одного компьютера. Между тем, не без давления Microsoft, в 2006 году его разработка была прекращена. А поскольку SoftICE очень сильно зависел от операционной системы Windows, в более поздних ее версиях он просто не работает. Последней версией Windows, в которой можно пользоваться SoftICE, была Windows XP SP 2. В SP 3 он уже не функционировал, а в Vista и Windows 7 и подавно.

Хакеры, конечно, приуныли, но не стали посыпать голову пеплом, а начали изобретать альтернативные отладчики. Последовала эпоха расцвета новых отладчиков. Но какая картина на этом поле сейчас? Нет ни одного нового хорошего отладчика! Передовым среди всех был коммерческий Syser китайских разработчиков. Ему пророчили светлое будущее, возможность заменить SoftICE, но где он сейчас? Может быть, пара копий сохранилась где-то на файловых свалках, но он давно не развивается.

Сейчас по большому счету у хакера есть выбор только из двух по-настоящему годных отладчиков: WinDbg и x64dbg. Последний годится лишь для исследования приложений пользовательского режима, тогда как с помощью WinDbg можно заниматься и ядерной отладкой Windows. Но в этом случае придется использовать два компьютера, объединенных проводом или по локальной сети.

Современный инструмент кодокопателя

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

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

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

  • kd — отладчик режима ядра с консольным интерфейсом;

  • WinDbg может использоваться как отладчик пользовательского режима либо режима ядра, но не одновременно. У WinDbg есть графический интерфейс.

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

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

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

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

Способ 0. Бряк на оригинальный пароль

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

Файлы с примерами можно скачать с GitHub.

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

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

Прежде чем попасть в функцию main конкретного приложения, процессор зарывается в дебри системного кода загрузчика образов, выполняет горы инструкций инициализации приложения внутри Windows, подключения библиотек и прочего. Поэтому произошедший бряк не означает вход в main нашей программы. Если взглянуть в окошко дизассемблера, мы увидим, что прерывание произошло в системной функции LdrpDoDebuggerBreak модуля ntdll.

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

.symfix d:\debugSymbols

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

.reload

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

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

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

bp passCompare1!main

Теперь продолжим выполнение командой g. Когда отладчик достигнет поставленной точки останова (начало функции main), в окне дизассемблера увидим, что листинг разделен на сегменты, в заголовке которых находятся имена функций, в частности main.

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

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

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

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

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

  • встроенные команды служат для отладки процесса и записываются без лидирующего символа, к таким командам относятся g, bp, bd;

  • метакоманды управляют работой отладчика, перед ними ставится символ точки, например: .reload, .symfix, .cls;

  • команды-расширения, загружаемые из внешних DLL, имеют в начале символ восклицательного знака, например: !heap, !dh.

Поиск адреса

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

dc 0x140002280

Существует большое количество команд для отображения содержимого памяти: da, db, dd и прочие. Мы использовали dc, потому что она показывает значения двойных слов и ASCII-символы. Что мы видим? Неинициализированные данные.

Раньше (до Windows Vista) кодокопателям было проще. Windows загружала образы в виртуальную память по определенному при компиляции адресу. В этом легко убедиться: запустим приложение в Windows XP, затем при помощи того же SoftICE узнаем адреса секций (команда mod -u) и выпишем их. После перезагрузки системы и повторного запуска приложения увидим, что они останутся неизменными.

Начиная с Windows Vista, программы после перезапуска системы получают случайные адреса, а не те, что определены при компиляции. Поэтому нам придется самим искать секцию .rdata уже не на диске, а в памяти. Легко сказать, но сделать еще проще!

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

start             end                 module name
00007ff7`159b0000 00007ff7`159b8000   passCompare1 passCompare1.exe

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

!dh passCompare1 

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

SECTION HEADER #2
  .rdata name
    101C virtual size
    2000 virtual address
    1200 size of raw data
    1400 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40000040 flags
         Initialized Data
         (no align specified)
         Read Only

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

dc 0x7ff7159b0000 + 2000 

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

dc 0x7ff7159b2000 0x7ff7159b2300

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

00007ff7`159b2250  159b4040 00007ff7 159b40e0 00007ff7  @@.......@......
00007ff7`159b2260  ffffffff ffffffff ffffffff ffffffff  ................
00007ff7`159b2270  65746e45 61702072 6f777373 003a6472  Enter password:.
00007ff7`159b2280  4f47796d 6170444f 6f777373 000a6472  myGOODpassword..
00007ff7`159b2290  6e6f7257 61702067 6f777373 000a6472  Wrong password..
00007ff7`159b22a0  73736150 64726f77 0a4b4f20 00000000  Password OK.....
00007ff7`159b22b0  00000140 00000000 00000000 00000000  @...............

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

Поставим аппаратный бряк, он же бряк по доступу (break on access), так как при программном будет ошибка доступа к памяти, возникающая по причине попытки записи в секцию, доступную только для чтения, какой .rdata и является. А программному бряку надо модифицировать память.

ba r4 0x7ff7159b2280

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

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

00007ffb`5d375670 488b01               mov     rax, qword ptr [rcx]
00007ffb`5d375673 483b040a             cmp     rax, qword ptr [rdx+rcx]
00007ffb`5d375677 75bf                 jne     ucrtbase!strcmp+0x8 (7ffb5d375638)
00007ffb`5d375679 4e8d0c10             lea     r9, [rax+r10]
00007ffb`5d37567d 48f7d0               not     rax

В силу архитектурных особенностей процессоров Intel бряк срабатывает после инструкции, выполнившей «поползновение», то есть RIP указывают на следующую выполняемую команду. В нашем случае (выделенная строка) — jne ucrtbase!strcmp+0x8, а к памяти, стало быть, обратилась инструкция cmp rax, qword ptr [rdx+rcx]. А что находится в RAX? Поднимаем взгляд еще строкой выше — mov rax, qword ptr [rcx]. Можно предположить, что RCX содержит указатель на строку оригинального пароля (поскольку он вызвал всплытие отладчика), но не будем спешить с выводами, в сравнении еще присутствует указатель [rdx+rcx]. Куда указывает он? Проверить это в отладчике проще простого. Сначала проверим, куда указывает RCX:

0:000> dc rcx
00000093`bf5cfbd0  434e504b 000a2b2b 00000000 00000000  KPNC++..........

Оказывается, RCX указывает на введенный пользователем пароль! А куда указывает второй указатель?

0:000> dc [rdx+rcx]
00007ff7`159b2280  4f47796d 6170444f 6f777373 000a6472  myGOODpassword..

Здесь как раз притаился оригинальный пароль! Картина начинает приобретать очертания.

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

Выйдем из текущей функции, для этого надо два раза нажать кнопку Step Out в отладчике. В результате мы окажемся в функции main, сразу после сравнения строк:

0007ff7`159b10b2 488d15c7110000     lea     rdx, [passCompare1!`string' (7ff7159b2280)]
00007ff7`159b10b9 488d4c2420        lea     rcx, [buff{[0]} (rsp+20h)]
00007ff7`159b10be e88c0d0000        call    passCompare1!strcmp (7ff7159b1e4f)
00007ff7`159b10c3 85c0              test    eax, eax
00007ff7`159b10c5 7458              je      passCompare1!main+0xaf (7ff7159b111f)

В первой строчке приведенного листинга в регистр RDX записывается указатель на эталонный пароль. Чтобы проверить это, выполни команду dc 7ff7159b2280. Во второй строчке в регистр RCX помещается указатель на содержимое строкового буфера, в который записывается введенный пользователем пароль. После вызова strcmp следует test, проверяющий на ноль регистр EAX. Знакомые места! Помнишь, мы посещали их дизассемблером? Далее следует JE, совершающий прыжок на основе предыдущего условия.

Алгоритм действий прежний — запоминаем адрес команды TEST для последующей замены ее на XOR или записываем последовательность байтов.

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

Тем не менее в Windows 10 мы даже не можем надеяться, что находящиеся по определенным адресам байты, найденные в памяти с помощью отладчика, будут по тем же адресам находиться в файле на диске. Когда программа выполняется, все ее секции проецируются в адресное пространство виртуальной памяти, которое кардинально отличается от начальной. В Vista и последующих системах в дело вступает механизм ASLR (Address Space Layout Randomization), который, используя MMU (Memory Management Unit), случайным образом изменяет расположение в адресном пространстве процесса важных структур данных. ASLR в некоторых случаях вполне успешно борется с переполнением буфера, возвратом в библиотеку и другими типами атак.

Авторы: Крис Касперски, Юрий Язев

Содержание

  1. 10 способов улучшить режим отладки ядра в Windows 10
  2. Как активировать режим отладки ядра в Windows 10
  3. Узнайте, что такое режим отладки ядра Windows 10
  4. Подготовка к активации режима отладки ядра
  5. Шаги подготовки к активации режима отладки ядра:
  6. Активация режима отладки ядра в настройках Windows 10
  7. Использование отладчика для работы с ядром операционной системы
  8. Преимущества и ограничения режима отладки ядра Windows 10
  9. Основные команды и функциональность отладчика ядра
  10. Как использовать режим отладки ядра Windows 10 для решения проблем

10 способов улучшить режим отладки ядра в Windows 10

Если вы являетесь опытным пользователем Windows, вероятно, слышали о таком термине, как «режим отладки ядра». Режим отладки ядра является мощным инструментом, предоставляемым Windows 10, который позволяет разработчикам и опытным пользователям получить расширенный доступ к функциям и процессам операционной системы.

В режиме отладки ядра можно выполнить множество задач, включая анализ потока данных, отслеживание ошибок и исследование проблем, возникающих на компьютере с Windows 10. Он предоставляет полный контроль над ядром операционной системы, позволяя работать с низкоуровневыми функциями и решать сложные проблемы.

Режим отладки ядра Windows 10 является важным инструментом для разработчиков программного обеспечения, так как он позволяет им отлавливать и исправлять ошибки в своих приложениях. Он также полезен для системных администраторов, которые могут использовать его для работы с операционной системой, анализа проблем и оптимизации производительности.

Если вы желаете воспользоваться режимом отладки ядра Windows 10, необходимо учесть, что это продвинутый инструмент, требующий определенных знаний и навыков. Неправильное использование режима отладки ядра может привести к потере данных или даже повреждению операционной системы.

В этой статье мы рассмотрим основные аспекты режима отладки ядра Windows 10, включая его функции, способы активации и использования. Мы также расскажем о его потенциальных рисках и мероприятиях безопасности, которые следует принять при работе с ним.

Для активации режима отладки ядра в Windows 10 необходимо выполнить несколько простых шагов. Во-первых, убедитесь, что на вашем компьютере установлена версия операционной системы Windows 10 Pro или Windows 10 Enterprise. Данная функциональность недоступна в версиях Windows 10 Home и Windows 10 S. При необходимости можно обновить операционную систему до соответствующей версии.

Затем откройте «Панель управления» и перейдите в раздел «Система и безопасность». В этом разделе найдите и выберите «Система», после чего перейдите во вкладку «Дополнительные параметры системы». В появившемся окне выберите вкладку «Дополнительно» и нажмите на кнопку «Переменные среды».

В открывшемся окне выберите переменную среды «_NT_SYMBOL_PATH» и нажмите на кнопку «Изменить». В поле «Значение переменной» введите путь к папке, в которой будет храниться информация для отладки. Обычно это путь к каталогу с символьными файлами отладки.

Узнайте, что такое режим отладки ядра Windows 10

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

Преимущества режима отладки ядра Windows 10:

  • Обнаружение ошибок: Режим отладки ядра позволяет детектировать и исправлять ошибки в работе операционной системы Windows 10. Благодаря этому, разработчики и администраторы могут улучшить стабильность и производительность системы.
  • Анализ процессов и драйверов: С помощью режима отладки ядра можно получить подробную информацию о работе процессов и драйверов в системе. Это позволяет выявить и устранить проблемы, связанные с неправильной работой приложений и устройств.
  • Тестирование и оптимизация: Режим отладки ядра Windows 10 предоставляет возможность тестировать и оптимизировать различные аспекты операционной системы. Это позволяет повысить ее производительность и устойчивость перед выходным релизом.

В целом, режим отладки ядра Windows 10 является мощным инструментом для обнаружения и исправления ошибок в операционной системе. Он является неотъемлемой частью процесса разработки и поддержки Windows 10, позволяя создавать и поддерживать более стабильные и эффективные системы.

Подготовка к активации режима отладки ядра

Активация режима отладки ядра Windows 10 может быть полезной для разработчиков и IT-специалистов, и она позволяет проводить отладку операционной системы на более глубоком уровне. Однако перед активацией режима отладки необходимо выполнить некоторую подготовку, чтобы избежать возможных проблем и обеспечить стабильную работу системы.

Первым шагом при подготовке к активации режима отладки ядра следует убедиться, что у вас установлена соответствующая версия отладочного пакета для вашей операционной системы Windows 10. Отладочный пакет предоставляет необходимые инструменты для работы с режимом отладки и может быть загружен с официального сайта Microsoft. Установка отладочного пакета позволит вам использовать все функции отладки ядра операционной системы и проводить детальный анализ ее работы.

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

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

Шаги подготовки к активации режима отладки ядра:

  • Убедитесь, что у вас установлена соответствующая версия отладочного пакета для операционной системы Windows 10.
  • Создайте точку восстановления системы для возможности быстрого восстановления в случае проблем.
  • Ознакомьтесь с инструкциями по активации режима отладки ядра и следуйте им тщательно.

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

Активация режима отладки ядра в настройках Windows 10

Режим отладки ядра представляет собой очень полезный инструмент для разработчиков и специалистов в области информационной безопасности. Он позволяет получить доступ к детальной информации о работе ядра операционной системы, что помогает в поиске и устранении ошибок, улучшении производительности и повышении надежности системы в целом. Активация режима отладки ядра в Windows 10 может быть осуществлена через специальные настройки.

Первым шагом для активации режима отладки ядра является открытие «Панели управления» в операционной системе Windows 10. Затем необходимо перейти в раздел «Система и безопасность», где можно найдет пункт «Система». После открытия этого раздела, нужно выбрать вкладку «Дополнительные параметры системы», где можно встретить пункт «Восстановление и отладка».

Внутри раздела «Восстановление и отладка» можно увидеть различные настройки, связанные с отладкой. Необходимо найти и нажать на кнопку «Настройка». После этого откроется окно с несколькими опциями, среди которых будет и опция «Отладка ядра». Для активации режима отладки ядра нужно выбрать эту опцию и сохранить изменения.

Теперь режим отладки ядра будет активирован в операционной системе Windows 10. Это позволит разработчикам и специалистам в области информационной безопасности получить доступ к мощному инструменту для работы с ядром операционной системы. Активированный режим отладки ядра предоставляет возможность отслеживать и анализировать работу системы на глубоком уровне, что позволяет обнаруживать и устранять различные проблемы, повышать надежность и оптимизировать работу ОС.

Использование отладчика для работы с ядром операционной системы

Отладчик ядра Windows представляет собой мощный инструмент, который позволяет разработчикам и системным администраторам работать с ядром операционной системы и отслеживать его поведение в режиме реального времени. Это особенно полезно при разработке и отладке драйверов и других компонентов операционной системы.

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

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

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

Преимущества и ограничения режима отладки ядра Windows 10

  • Полный контроль и доступ к ядру: Режим отладки ядра Windows 10 предоставляет разработчикам полный контроль над операционной системой. Они могут отслеживать процессы, контролировать ресурсы и анализировать работу системы на самом низком уровне.
  • Обнаружение и исправление ошибок: С помощью режима отладки ядра разработчики могут обнаруживать и исправлять ошибки, которые могут привести к сбоям системы. Они могут отслеживать краш-дампы, анализировать причины сбоев и разрабатывать соответствующие патчи и обновления.
  • Тестирование новых функций и драйверов: Режим отладки ядра также позволяет разработчикам тестировать новые функции, драйверы и обновления перед их выпуском. Они могут убедиться в их стабильной работе и обнаружить и исправить возможные проблемы до того, как они повлияют на конечного пользователя.

Несмотря на все преимущества, режим отладки ядра Windows 10 также имеет свои ограничения. Вот некоторые из них:

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

Основные команды и функциональность отладчика ядра

Вот несколько ключевых команд и функций, которые полезны при работе с отладчиком ядра Windows 10:

  • .thread – эта команда отображает информацию о текущем потоке, включая идентификатор, состояние, режим выполнения и приоритет.
  • .frame – эта команда отображает вызывающий фрейм, который представляет собой функцию или метод, вызванный в текущем контексте выполнения.
  • .step – эта команда позволяет перейти на следующую инструкцию в программе, которая будет выполнена.

Отладчик ядра Windows 10 также обладает другими полезными функциями. Например, с помощью команды !process вы можете получить дополнительную информацию о процессах операционной системы, включая список загруженных модулей и различные атрибуты процесса. Команда .exr отображает содержимое регистров, что может быть полезно для отслеживания значения регистра во время отладки. Кроме того, с помощью команды .reload можно перезагрузить символы отладки, что позволяет увидеть обновленную информацию о функциях и переменных в процессе отладки.

В конце концов, отладчик ядра Windows 10 предлагает обширные возможности для анализа и решения проблем на самом глубоком уровне операционной системы. Знание основных команд и функциональности отладчика ядра поможет разработчикам и специалистам по обеспечению качества успешно отлаживать и анализировать код, чтобы создавать более надежные и стабильные приложения для пользователей Windows 10.

Как использовать режим отладки ядра Windows 10 для решения проблем

Настройка режима отладки ядра Windows 10

Перед использованием режима отладки ядра необходимо настроить систему для работы в этом режиме. Для начала, вам понадобится установить отладочный соединительный драйвер (debugging connector driver) и настроить его в соответствии с вашими потребностями и требованиями. Затем, вам нужно будет подключить отладочное устройство (debugging device) к компьютеру, чтобы установить связь с ядром Windows 10. Обратитесь к документации или руководству пользователя вашего отладочного устройства для получения подробной информации о процессе.

Преимущества режима отладки ядра Windows 10

Режим отладки ядра Windows 10 предлагает ряд преимуществ, которые помогут вам решить проблемы операционной системы:

  • Понимание внутренней работы ОС: Режим отладки ядра позволяет вам увидеть, как работает операционная система на самом низком уровне, что помогает вам лучше понять ее принципы функционирования и взаимодействия с аппаратным обеспечением.
  • Обнаружение ошибок и уязвимостей: С помощью режима отладки ядра вы сможете исследовать и исправлять ошибки, обнаруживать уязвимости и проблемные области операционной системы, что увеличит ее стабильность и безопасность.
  • Оптимизация производительности: Режим отладки ядра предоставляет доступ к производительности системы и ресурсам, тем самым позволяя вам оптимизировать работу операционной системы и улучшить производительность приложений.

Использование режима отладки ядра Windows 10 — это важный инструмент для анализа и решения различных проблем операционной системы. Он позволяет разработчикам и специалистам в области информационной безопасности получить доступ к внутренним процессам и ресурсам Windows 10, что даёт возможность более эффективно устранять ошибки, находить уязвимости и оптимизировать производительность. Настройка режима отладки ядра и его использование требует определенных навыков и знаний, поэтому рекомендуется обратиться к руководству пользователя соответствующего отладочного устройства и специализированной литературе для получения дополнительной информации.

В пакет средств отладки для Windows входят современные отладочные инструменты, с помощью которых можно исследовать внутреннее устройство Windows. В самую последнюю версию в качестве составной части включен набор для разработки программного обеспечения — Windows Software Development Kit (SDK).

Средства из этого набора могут использоваться для отладки как процессов пользовательского режима, так и процессов ядра.

ПРИМЕЧАНИЕ. Средства отладки Debugging Tools for Windows довольно часто обновляются и выпускаются независимо от версий операционной системы Windows, поэтому почаще проверяйте наличие новых версий.

СОВЕТ. Отладка в пользовательском режиме.

Средства отладки могут также использоваться для подключения к процессу пользовательского режима и для изучения и (или) изменения состояния памяти процесса. При подключении к процессу есть два варианта:

  • Навязчивый (Invasive). Если при подключении к запущенному процессу не даны специальные указания, для подключения отладчика к отлаживаемому коду используется Windows-функция DebugActiveProcess. Тем самым создаются условия для исследования и (или) изменения памяти процесса, установки контрольных точек и выполнения других отладочных функций. Windows позволяет остановить отладку без прерывания целевого процесса, если отладчик отключается без прерывания своей работы.
  • Ненавязчивый (Noninvasive). При таком варианте отладчик просто открывает процесс с помощью функции OpenProcess. Этот процесс не подключается к другому процессу в качестве отладчика. Это позволяет исследовать и (или) изменять память целевого процесса, но вы не можете устанавливать контрольные точки.

Со средствами отладки можно также открывать файлы дампа процесса пользовательского режима.

Для отладки ядра могут использоваться два отладчика: работающий в окне командной строки (Kd.exe) и имеющий графический пользовательский интерфейс, GUI (Windbg.exe). Оба отладчика предоставляют одинаковый набор команд, поэтому выбор всецело зависит от личных предпочтений. Эти средства позволяют выполнять три типа отладки ядра:

  • Открыть аварийный дамп-файл, созданный в результате аварийного завершения работы системы.
  • Подключиться к действующей, работающей системе и исследовать состояние системы (или установить контрольные точки, если ведется отладка кода драйвера устройства). Для этой операции нужны два компьютера — целевой и ведущий. Целевой компьютер содержит отлаживаемую систему, а ведущий — систему, на которой запущен отладчик. Целевая система может быть подключена к ведущей через нуль-модемный кабель, кабель IEEE 1394 или отладочный кабель USB 2.0. Целевая система должна быть загружена в режиме отладки (либо путем нажатия F8 в процессе загрузки и выбора пункта Режим отладки (Debugging Mode), либо путем настройки системы на запуск в режиме отладки, используя Bcdedit или Msconfig.exe). Можно также подключиться через поименованный канал, применяемый при отладке через виртуальную машину (созданную такими средствами, как Hyper-V, Virtual PC или VMWare), путем выставления гостевой операционной системой последовательного порта в качестве поименованного канального устройства.
  • Системы Windows позволяют также подключиться к локальной системе и исследовать ее состояние. Это называется «локальной отладкой ядра». Чтобы приступить к локальной отладке ядра с помощью отладчика WinDbg, откройте меню File (Файл), выберите пункт Kernel Debug (Отладка ядра), щелкните на вкладке Local (Локальная), а затем щелкните на кнопке OK. Целевая система должна быть загружена в отладочном режиме. Пример появляющегося при этом экрана показан на рис. 1.6. В режиме локальной отладки ядра не работают некоторые команды отладчика ядра (например, команда .dump, предназначенная для создания дампа памяти, хотя такой дамп можно создать с помощью рассматриваемого далее средства LiveKd).

локальная-отладка-ядра

Локальная отладка ядра

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

Отличным подсобным справочным материалом может послужить файл Debugger.chm, содержащийся в установочной папке отладчика WinDbg. В нем приводится документация по всем функциональным возможностям и расширениям отладчика ядра. В дополнение к этому команда dt (display type — отобразить тип) может отформатировать свыше 1000 структур ядра, поскольку в файлах символов ядра для Windows содержится информация о типах, которые отладчик может использовать для форматирования структур.

Эксперимент: Отображение информации о типах для структур ядра.

Чтобы вывести список структур ядра, чей тип информации включен в символы ядра, наберите в отладчике ядра команду dt nt!_*. Частичный образец вывода имеет следующий вид:

lkd> dt nt!_*

nt!_LIST_ENTRY

nt!_LIST_ENTRY

nt!_IMAGE_NT_HEADERS

nt!_IMAGE_FILE_HEADER

nt!_IMAGE_OPTIONAL_HEADER

nt!_IMAGE_NT_HEADERS

nt!_LARGE_INTEGER

Командой dt можно также воспользоваться для поиска определенных структур, используя заложенную в эту команду возможность применения символов-заместителей. Например, если ведется поиск имени структуры для объекта interrupt, нужно набрать команду dt nt!_*interrupt*:

lkd> dt nt!_*interrupt*

nt!_KINTERRUPT

nt!_KINTERRUPT_MODE

nt!_KINTERRUPT_POLARITY

nt!_UNEXPECTED_INTERRUPT

Затем, как показано в следующем примере, команду dt можно использовать для форматирования определенной структуры:

lkd> dt nt!_kinterrupt

nt!_KINTERRUPT

+0x000 Type : Int2B

+0x002 Size : Int2B

+0x008 InterruptListEntry : _LIST_ENTRY

+0x018 ServiceRoutine : Ptr64 unsigned char

+0x020 MessageServiceRoutine : Ptr64 unsigned char

+0x028 MessageIndex : Uint4B

+0x030 ServiceContext : Ptr64 Void

+0x038 SpinLock : Uint8B

+0x040 TickCount : Uint4B

+0x048 ActualLock : Ptr64 Uint8B

+0x050 DispatchAddress : Ptr64 void

+0x058 Vector : Uint4B

+0x05c Irql : UChar

+0x05d SynchronizeIrql : UChar

+0x05e FloatingSave : UChar

+0x05f Connected : UChar

+0x060 Number : Uint4B

+0x064 ShareVector : UChar

+0x065 Pad : [3] Char

+0x068 Mode : _KINTERRUPT_MODE

+0x06c Polarity : _KINTERRUPT_POLARITY

+0x070 ServiceCount : Uint4B

+0x074 DispatchCount : Uint4B

+0x078 Rsvd1 : Uint8B

+0x080 TrapFrame : Ptr64 _KTRAP_FRAME

+0x088 Reserved : Ptr64 Void

+0x090 DispatchCode : [4] Uint4B

Следует заметить, что при выполнении команды dt подструктуры (структуры внутри структур) по умолчанию не показываются. Для выполнения рекурсии подструктур нужно воспользоваться ключом –r. Например, воспользоваться этим ключом для вывода объекта прерывания ядра с показом формата структуры _LIST_ENTRY, хранящейся в поле InterruptListEntry:

lkd> dt nt!_kinterrupt -r

nt!_KINTERRUPT

+0x000 Type : Int2B

+0x002 Size : Int2B

+0x008 InterruptListEntry : _LIST_ENTRY

+0x000 Flink : Ptr64 _LIST_ENTRY

+0x000 Flink : Ptr64 _LIST_ENTRY

+0x008 Blink : Ptr64 _LIST_ENTRY

+0x008 Blink : Ptr64 _LIST_ENTRY

+0x000 Flink : Ptr64 _LIST_ENTRY

+0x008 Blink : Ptr64 _LIST_ENTRY

В файле справки Debugging Tools for Windows также объясняется, как настраиваются и используются отладчики ядра. Дополнительные подробности использования отладчиков ядра, предназначенные непосредственно для создателей драйверов устройств, могут быть найдены в документации по набору Windows Driver Kit.

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Пропадает курсор мыши windows 10 в игре
  • Debloat windows 10 tool
  • Как отключить postgresql server windows
  • Windows 11 баг с мышкой
  • Как отключить hvci в windows 11