Отладка ядра windows 10 что это

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

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

Символы для отладки ядра

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

Для использования любого средства отладки в режиме ядра с целью исследования внутреннего устройства структуры данных ядра Windows (списка процессов, блоков потоков, списка загруженных драйверов, информации об использовании памяти и т. д.) вам нужны правильные файлы символов и, как минимум, файл символов для двоичного образа ядра — Ntoskrnl.exe. Файлы таблицы символов должны соответствовать версии того двоичного образа, из которого они были извлечены. Например, если установлен пакет Windows Service Pack или какое-нибудь исправление, обновляющее ядро, нужно получить соответствующим образом обновленные файлы символов.

Загрузить и установить символы для различных версий Windows нетрудно, а вот обновить символы для исправлений удается не всегда. Проще всего получить нужную версию символов для отладки путем обращения к специально предназначенному для этого серверу символов Microsoft, воспользовавшись для этого специальным синтаксисом для пути к символам, указываемом в отладчике. Например, следующий путь к символам заставляет средства отладки загрузить символы с интернет-сервера символов и сохранить локальную копию в папке c:\symbols:srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Подробные инструкции по использованию символьного сервера можно найти в файле справки средств отладки или в Интернете на веб-странице http://msdn.microsoft.com/en-us/windows/hardware/gg462988.aspx.

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

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

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

Отладка в Windows 10: основные принципы и методы

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

Основные принципы отладки в Windows 10:

1. Идентификация проблемы: Важно понимать, что именно вызвало ошибку или неправильное поведение программы или системы. Для этого можно использовать журнал событий Windows, отчеты об ошибках или другие инструменты регистрации событий.
2. Воспроизведение проблемы: Чтобы убедиться, что проблема действительно существует, ее необходимо воспроизвести. На этом этапе необходимо записать все необходимые данные для последующего анализа.
3. Анализ проблемы: После воспроизведения проблемы необходимо проанализировать полученные данные, чтобы выявить источник проблемы. К этим данным могут относиться стек вызовов, значения переменных и другие отладочные сообщения.
4. Решение проблемы: После анализа данных можно приступить к исправлению ошибки или проблемы. Это может потребовать изменения кода, настройки системы или устранения других проблемных факторов.
5. Тестирование исправлений: После внесения изменений необходимо протестировать программу или систему, чтобы удостовериться, что проблема была успешно устранена.

Основные методы отладки в Windows 10:

• Инструменты отладки Windows: В Windows 10 доступны различные инструменты отладки, такие как Visual Studio, WinDbg, Debugging Tools for Windows (комплект инструментов для отладки).
• Отладка приложений: Для отладки приложений в Windows 10 можно использовать интегрированную среду разработки (IDE) Visual Studio, которая предоставляет широкий набор функций отладки, таких как пошаговое выполнение кода, точки останова, просмотр значений переменных и многое другое.
• Отладка системы: Для отладки системы Windows 10 можно использовать инструменты, такие как Task Manager (Диспетчер задач), Event Viewer (Журнал событий), Performance Monitor (Монитор производительности) и другие. Они позволяют отслеживать активность системы, процессы, использование ресурсов и другие параметры.
• Логирование и отчеты об ошибках: В Windows 10 предусмотрен механизм записи журналов событий, который может использоваться для регистрации ошибок, предупреждений и других событий в системе. Также можно создавать отчеты об ошибках, которые помогут разработчикам и поддержке идентифицировать и исправить проблемы.

Выводы:

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

Как настроить окружение для отладки в Windows 10

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

1. Убедитесь, что ваш компьютер работает на операционной системе Windows 10. Если нет, обновите систему до необходимой версии.
2. Установите необходимые компоненты разработки. Для отладки приложений вам понадобятся Visual Studio и Windows SDK. Вы можете загрузить их с официального сайта Microsoft.
3. Настройте отладочный режим для вашего приложения. Для этого откройте проект в Visual Studio, перейдите в свойства проекта и выберите настройки отладки. Установите необходимые опции, например, символы отладки и опцию «Отладка кода».
4. Подключите устройство для отладки. Если вы планируете отлаживать приложение на реальном устройстве, убедитесь, что оно подключено к компьютеру и включен режим разработчика.
5. Запустите отладчик в Visual Studio. Выберите ваше приложение в списке доступных процессов и нажмите кнопку «Отладка».
6. Изучайте отладочную информацию и исправляйте ошибки. В Visual Studio вы можете использовать различные инструменты отладки, такие как точки останова, пошаговое выполнение кода и просмотр переменных.

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

Основные методы отладки в Windows 10

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

1. Windows Диспетчер задач

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

2. Журнал событий Windows

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

3. Командная строка

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

4. Visual Studio и WinDbg

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

5. Инструменты разработчика Windows

• Инструменты разработчика Windows — коллекция инструментов, предоставляемых Microsoft для анализа и отладки системы.
• Они включают такие инструменты, как Windows Performance Analyzer, Windows Performance Recorder, Windows Debugger, Windows Performance Toolkit и другие.
• Эти инструменты могут быть полезны для анализа производительности, обнаружения утечек ресурсов и других проблем в системе.

Вопрос-ответ

Какую роль играет отладка в Windows 10?

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

Какие инструменты отладки доступны в Windows 10?

В Windows 10 доступно несколько инструментов отладки, таких как отладчик WinDbg, Visual Studio Debugger, Windows Performance Toolkit, PowerShell Debugging Tools и другие. Каждый из этих инструментов предлагает уникальные возможности для анализа и исправления ошибок.

Как отлаживать приложения в Windows 10?

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

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

Что такое режим отладки в Windows 10

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

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

Как его включить?

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

• Откройте «Параметры» через меню «Пуск».

• Перейдите в раздел «Обновление и безопасность», а затем – «Восстановление».

• Под заголовком «Особые варианты загрузки» нажмите на кнопку «Перезагрузить сейчас».

На заметку. Также вы можете открыть дополнительное меню, зажав клавишу «Shift» при выборе варианта «Перезагрузка» в «Пуске».

В случае правильного выполнения указанных действий компьютер перезагрузится, а при следующем включении вы увидите синий экран с выбором действий. Можно нажать на кнопку «Продолжить», чтобы запустить ПК в стандартном режиме, но нас интересует Debugging, поэтому действуйте иначе:

• Перейдите в раздел «Поиск и устранение неисправностей».

• Выберите «Дополнительные параметры», а затем – «Параметры загрузки».

• Найдите в списке пункт, отвечающий за отладку, и нажмите на клавишу, которая отвечает за ее активацию (как правило, это клавиша «F1»).

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

Возможные проблемы

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

• Щелкните ПКМ по иконке «Пуск».
• Откройте Командную строку с правами Администратора.
• Введите запрос «bcdedit /set advancedoptions true».

• Нажмите на клавишу «Enter».

Следом произойдет перезапуск, и расширенные параметры откроются в принудительном порядке. Еще одна проблема связана с выходом из отладки. Чтобы компьютер включался в стандартной конфигурации, необходимо обработать запрос «deletevalue». Впечатать «bcdedit /deletevalue advancedoptions» в вышеупомянутой Командной строке или на появившемся синем экране выбрать опцию «Продолжить».



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

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

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

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

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

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

Весь цикл с учетом всех обновлений вышел в виде книги «Фундаментальные основы хакерства. Анализ программ в среде 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 в некоторых случаях вполне успешно борется с переполнением буфера, возвратом в библиотеку и другими типами атак.

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