Скачать windbg на русском для windows 10

Где скачать и как установить Debugging Tools for Windows

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

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

Типы аварийных дампов памяти Windows

На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:

• Мини дамп памяти (Small memory dump) (256 КБ). Этот тип файла включает минимальный объем информации. Он содержит только сообщение об ошибке BSOD, информацию о драйверах, процессах, которые были активны в момент сбоя, а также какой процесс или поток ядра вызвал сбой.
• Дамп памяти ядра (Kernel memory dump). Как правило, небольшой по размеру — одна треть объема физической памяти. Дамп памяти ядра является более подробным, чем мини дамп. Он содержит информацию о драйверах и программах в режиме ядра, включает память, выделенную ядру Windows и аппаратному уровню абстракции (HAL), а также память, выделенную драйверам и другим программам в режиме ядра.
• Полный дамп памяти (Complete memory dump). Самый большой по объему и требует памяти, равной оперативной памяти вашей системы плюс 1MB, необходимый Windows для создания этого файла.
• Автоматический дамп памяти (Automatic memory dump). Соответствует дампу памяти ядра с точки зрения информации. Отличается только тем, сколько места он использует для создания файла дампа. Этот тип файлов не существовал в Windows 7. Он был добавлен в Windows 8.
• Активный дамп памяти (Active memory dump). Этот тип отсеивает элементы, которые не могут определить причину сбоя системы. Это было добавлено в Windows 10 и особенно полезно, если вы используете виртуальную машину, или если ваша система является хостом Hyper-V.

Как включить создание дампа памяти в Windows?

С помощью Win+Pause откройте окно с параметрами системы, выберите «Дополнительные параметры системы» (Advanced system settings). Во вкладке «Дополнительно» (Advanced), раздел «Загрузка и восстановление» (Startup and Recovery) нажмите кнопку «Параметры» (Settings). В открывшемся окне настройте действия при отказе системы. Поставьте галку в чек-боксе «Записать события в системный журнал» (Write an event to the system log), выберите тип дампа, который должен создаваться при сбое системы. Если в чек-боксе «Заменять существующий файл дампа» (Overwrite any existing file) поставить галку, то файл будет перезаписываться при каждом сбое. Лучше эту галку снять, тогда у вас будет больше информации для анализа. Отключите также автоматическую перезагрузку системы (Automatically restart).

В большинстве случаев для анализа причины BSOD вам будет достаточно малого дампа памяти.

Теперь при возникновении BSOD вы сможете проанализировать файл дампа и найти причину сбоев. Мини дамп по умолчанию сохраняется в папке %systemroot%minidump. Для анализа файла дампа рекомендую воспользоваться программой WinDBG (Microsoft Kernel Debugger).

Установка WinDBG в Windows

Утилита WinDBG входит в «Пакет SDK для Windows 10» (Windows 10 SDK). Скачать можно здесь.

Файл называется winsdksetup.exe, размер 1,3 МБ.

WinDBG для Windows7 и более ранних систем включен в состав пакета «Microsoft Windows SDK for Windows 7 and .NET Framework 4». Скачать можно здесь.

Запустите установку и выберите, что именно нужно сделать – установить пакет на этот компьютер или загрузить для установки на другие компьютеры. Установим пакет на локальный компьютер.

Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows.

После установки ярлыки WinDBG можно найти в стартовом меню.

Настройка ассоциации .dmp файлов с WinDBG

Для того, чтобы открывать файлы дампов простым кликом, сопоставьте расширение .dmp с утилитой WinDBG.

1. Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы:
   cd C:Program Files (x86)Windows Kits10Debuggersx64
windbg.exe –IA
   
   для 32-разрядной системы:
   C:Program Files (x86)Windows Kits10Debuggersx86
windbg.exe –IA
2. В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с WinDBG.

Настройка сервера отладочных символов в WinDBG

Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.

Настройте WinDBG на использование Microsoft Symbol Server:

• Откройте WinDBG;
• Перейдите в меню File –> Symbol File Path;
• Пропишите строку, содержащую URL для загрузки символов отладки с сайта Microsoft и папку для сохранения кэша:
  SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols
  В примере кэш загружается в папку E:Sym_WinDBG, можете указать любую.
• Не забывайте сохранить изменения в меню File –> Save WorkSpace;

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

SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:Symbols

Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages.

Анализ аварийного дампа памяти в WinDBG

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

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

Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 0xXXXXXXXX (указываются в одном из вариантов — STOP: 0x0000007B, 02.07.2019 0008F, 0x8F). В нашем примере код ошибки 0х139.

Полный справочник ошибок можно посмотреть здесь.

Отладчик предлагает выполнить команду !analyze -v, достаточно навести указатель мыши на ссылку и кликнуть. Для чего нужна эта команда?

• Она выполняет предварительный анализ дампа памяти и предоставляет подробную информацию для начала анализа.
• Эта команда отобразит STOP-код и символическое имя ошибки.
• Она показывает стек вызовов команд, которые привели к аварийному завершению.
• Кроме того, здесь отображаются неисправности IP-адреса, процессов и регистров.
• Команда может предоставить готовые рекомендации по решению проблемы.

Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды !analyze –v (листинг неполный).

1: kd>
!analyze -v

*****************************************************************************
* *
* Bugcheck Analysis *
* *
*****************************************************************************

Символическое имя STOP-ошибки (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)

Описание ошибки (Компонент ядра повредил критическую структуру данных. Это повреждение потенциально может позволить злоумышленнику получить контроль над этой машиной):

A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.

Аргументы ошибки:

Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved
Debugging Details:
------------------

Счетчик показывает сколько раз система упала с аналогичной ошибкой:

CUSTOMER_CRASH_COUNT: 1

Основная категория текущего сбоя:

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Код STOP-ошибки в сокращенном формате:

BUGCHECK_STR: 0x139

Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):

PROCESS_NAME: sqlservr.exe

CURRENT_IRQL: 2

Расшифровка кода ошибки: В этом приложении система обнаружила переполнение буфера стека, что может позволить злоумышленнику получить контроль над этим приложением.

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

Последний вызов в стеке:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Стек вызовов в момент сбоя:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9 : 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528 : nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50 : ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2 : nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiFastFailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482 : ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9 : nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d : 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951 : nt! ?? ::FNODOBFM::`string'+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac : 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600 : nt!IopSynchronousServiceTail+0x379
ffffd000`3a20d990 fffff804`0117d313 : ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380 : nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
000000ee`f25ed2b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`475307da

Участок кода, где возникла ошибка:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr [rsp+20h],0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: MachineOwner

Имя модуля в таблице объектов ядра. Если анализатору удалось обнаружить проблемный драйвер, имя отображается в полях MODULE_NAME и IMAGE_NAME:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

Если кликнете по ссылке модуля (nt), то увидите подробную информацию о пути и других свойствах модуля. Находите указанный файл, и изучаете его свойства.

1: kd>
lmvm nt

Browse full module list
Loaded symbol image file: ntkrnlmp.exe
Mapped memory image file: C:ProgramDatadbgsymntoskrnl.exe5A9A2147787000ntoskrnl.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.

Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.

Например:

Image path: SystemRootsystem32driverscmudaxp.sys
Image name: cmudaxp.sys

Откройте свойсва файла драйвера и проверьте его версию. В большинстве случаев проблема с драйверами решается их обнвовлением.

WinDbg — is a multipurpose debugger for the Microsoft Windows computer operating system, distributed by Microsoft. Debugging is the process of finding and resolving errors in a system; in computing it also includes exploring the internal operation of software as a help to development. It can be used to debug user mode applications, device drivers, and the operating system itself in kernel mode. Like the better-known Visual Studio Debugger it has a graphical user interface (GUI), but is more powerful and has little else in common.

WinDbg can be used for debugging kernel-mode memory dumps, created after what is commonly called the Blue Screen of Death which occurs when a bug check is issued. It can also be used to debug user-mode crash dumps. This is known as post-mortem debugging.

WinDbg can automatically load debugging symbol files (e.g., PDB files) from a server by matching various criteria (e.g., timestamp, CRC, single or multiprocessor version) via SymSrv (SymSrv.dll), instead of the more time-consuming task of creating a symbol tree for a debugging target environment. If a private symbol server is configured, the symbols can be correlated with the source code for the binary. This eases the burden of debugging problems that have various versions of binaries installed on the debugging target by eliminating the need for finding and installing specific symbols version on the debug host. Microsoft has a public symbol server that has most of the public symbols for Windows 2000 and later versions of Windows (including service packs).

Recent versions of WinDbg have been and are being distributed as part of the free Debugging Tools for Windows suite, which shares a common debugging back-end between WinDbg and command line debugger front-ends like KD, CDB, and NTSD. Most commands can be used as is with all the included debugger front-ends.

Previous versions Windbg:
— Windbg x86: dbg_x86_6.11.1.404.msi (v6.11)
— Windbg x64: dbg_amd64_6.11.1.404.msi (v6.11)
— Windbg IA64: dbg_ia64_6.11.1.404.msi (v6.11)

Versions included in SDK:
— Windows 7 SDK: win_7_sdk_and_netf3 (v6.11)
— Windows 7 SDK: win_7_sdk_and_netf4 (v6.12)
— Windows 8 SDK: win_8_1_sdk (v6.3)
— Windows 10 SDK: win_10_sdk (v10.0)
Select ‘Debugging Tools for Windows’ under ‘Common Utilities’ [?]

Windbg workspace and theme:
— Настройка WinDbg: habrahabr / Workspace: github √
— Customizing WinDbg: zachburlingame / Workspace: √

Other links:
— WinDbg: http://www.windbg.org
— WinDbg links: https://github.com/abarbatei/windbg-info

Версия: 6.11/6.12/6.3/10.0
Год выхода: 2017
Разработчик: Microsoft Software
Язык интерфейса: English
OC: Windows XP/Vista/7/8/10

Скачать: WinDbg v6.11.0001.404 [x86-x64] [for Win 7]
Скачать: WinDbg v6.12.0002.633 [x86-x64] [for Win 7]
Скачать: Windows v6.3.9600.16384 [x86-x64] [for Win 8.1]
Скачать: WinDbg v10.0.15063.468 [x86-x64] [for Win10]
Скачать: WinDbg v10.0.16299.15 [x86-x64] [for Win10]

Оглавление:

• Инструменты отладки для Windows 10 (WindDbg)

Видео: Маша и Медведь (Masha and The Bear) — Подкидыш (23 Серия) 2023

Время прочтения
4 мин

Просмотры 3.3K

Статья представляет собой мануал по тому как пользоваться Windbg. Будет рассмотрена «классическая» версия отладчика. Настроим внешний вид и изучим команды, которые можно использовать для исследования приложения.

Установка

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

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

• Установить директорию и сервер для отладочных символов Проще всего это сделать можно через меню: File → Symbol File Path. В открывшемся меню нужно прописать вот эту строку: «SRV*C:symbols*http://msdl.microsoft.com/download/symbols». Затем создать директорию C:symbols;

• Установить WorkPlace с удобной раскладкой рабочих панелей. Взять готовый Workspace можно отсюда. В итоге, если запустить для теста notepad.exe в отладчике, он будет выглядеть вот так:

Теперь можно перейти к исследованию команд. Откроем в отладчике файл и приступим.

Набор команд и анализ приложения

Полный справочник по всем командам отладчика можно найти по команде «.hh». Появится справка, как на рисунке ниже. Здесь можно вводить описание или конкретную команду.

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

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

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

Главные команды, которые станут глазами и ушами при исследовании данных в оперативной памяти — d? (b,c,a,p,w,q). Команда показывает дамп памяти по указанному адресу. Можно использовать конкретный адрес или регистр. Например, можно посмотреть как выглядит часть заголовка файла в памяти:

Команда !dh разбирает файл и показывает заголовки. Нам нужен файловый заголовок, поэтому добавим флаг -f. Если необходимо показать все данные о файловых и секционных заголовках, то можно не дополнять команду.

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

Локализуем точку входа с помощью суммирования базового адреса и информации из заголовка. Выполнить эту опирацию можно рядом команд: ? — выполнение выражения, uf — дизассемблирование функции, bp — установка точки останова. А теперь по порядку на примере:

Расчет адреса.

Дизассемблирование функции от адреса до ret команды.

Установка точки останова, кстати, чтобы управлять точками останова, можно менять последнюю букву команды. На рисунке показан пример установки точки останова и просмотр списка существующих точек через команду bl.

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

Как только алгоритм загрузчика ОС выполнит все подготовительные действия мы увидим в командной строке следующие данные:

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

Для поиска данных будем использовать команду s. Эта команда проводит поиск по определенному в команде объему данных. Соответственно чтобы получить данные о местоположении приглашения к вводу ключа, нужно указать всё адресное пространство исследуемого приложения. Так же необходимо указать тип данных, которые нужно искать.

Теперь, когда мы знаем адрес данных, которые используются, мы можем поставить точку останова, которая будет следить за доступом к данным. Сделать это можно с помощью команды ba. Для такой точки останова нужно указывать размер данных за которыми отладчик будет наблюдать, а там же адрес и тип доступа. Адрес должен быть выровнен по границе в 4 байта. После остановки снова нужно запустить приложение через команду g. На рисунке ниже показан вариант команды:

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

Из рисунка видно, что копирование строки для работы с ней выполняется библиотечной функцией, а её вызов был сделан из «For_Crackme+0x15f2».

2. Локализуем функцию проверки ключа. Функция проверки будет недалеко от предложения ввести данные пользователя. В прошлом этапе мы нашли смещение внутри функции до этой операции. Введем можифицированную команду uf — u для того чтобы посмотреть несколько команд после адреса "For_Crackme+0x15f":

Фрагмент кода не содержит дополнительных отладочных символов, поэтому просто просмотрим данные рядом:

• offset For_Crackme+0x40a2

• offset For_Crackme+0x40bb

Чтобы это сделать, используем команду db:

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

...
00401612 c744241c30372f31 mov     dword ptr [esp+1Ch],312F3730h
0040161a c7442420302f3937 mov     dword ptr [esp+20h],37392F30h
...

Если раскодировать константы, то мы получим вот такое значение: «07/10/97». Выполнить раскодирование может помочь команда .formats 312F3730h. Из списка форматов нас интересует Char или символьное представление. Стоит помнить, что данные в памяти хранятся в LittleEndian формате, поэтому если прочитать наоборот, то получатся данные необходимые для прохождения валидации.

Таким образом можно анализировать приложения с использованием Windbg и не прибегать к дополнительному инструментарию.

Статья написана в преддверии старта курса «Reverse-Engineering. Professional». Напоминаем о том, что завтра пройдет второй день бесплатного интенсива по теме «Пишем дампер процессов». Записаться на интенсив можно по ссылке ниже:

• ЗАПИСАТЬСЯ НА БЕСПЛАТНЫЙ ИНТЕНСИВ