Статья Динамический анализ бинарных файлов: GDB, x64dbg, WinDbg — от брейкпоинта до обхода антиотладки

Три слоя XOR-шифрования, два вызова VirtualAlloc и проверка NtQueryInformationProcess на ProcessDebugPort - такой набор встретился мне в PE-сэмпле при разборе инцидента в прошлом квартале. Коллега параллельно ковырял ELF-дроппер того же семейства в GDB с pwndbg. Одна задача, два отладчика, два принципиально разных workflow. Отладчик - не вопрос вкуса, а вопрос платформы, формата бинаря и конкретного этапа runtime анализа исполняемых файлов. Ниже разберу, когда и зачем применять каждый из трёх инструментов динамического анализа бинарных файлов, и покажу приёмы, которые работают на реальных задачах - от CTF-pwn до incident response.

Место отладчика в цепочке реверс-инжиниринга бинарных файлов​

Динамический анализ бинарных файлов не существует в вакууме. Его место в workflow зависит от задачи, и если вы открываете отладчик первым - скорее всего, потеряете время.

Анализ малвари (IR / threat intelligence):

1. Первичная сортировка - песочница, базовый behavioural analysis
2. Статический анализ - IDA Pro или Ghidra для восстановления структуры
3. Динамический анализ в отладчике - распаковка, деобфускация IAT (T1140), извлечение C2-адресов, анализ поведения процессов
4. Создание IoC и detection rules (YARA, Sigma)

CTF / exploit development:

1. Статический анализ - определение уязвимого участка (переполнение стека CWE-121, heap overflow CWE-122, use-after-free CWE-416)
2. Динамический анализ - верификация гипотезы, трассировка выполнения программы до уязвимой функции
3. Написание и отладка эксплойта

Пентест / red team:

1. Получение бинаря защитного решения или целевого приложения
2. Динамический анализ - поиск обходов, анализ хуков, проверка ограничений песочниц
3. Разработка evasion-техники

В каждом сценарии отладчик - инструмент третьего-четвёртого шага. Без предварительного статического анализа отладка превращается в бессмысленный степпинг. Без понимания kill chain - неясно, зачем ставить брейкпоинт именно сюда.

Требования к окружению​

Параметр	GDB + pwndbg	x64dbg + ScyllaHide	WinDbg Preview
ОС	Linux (Ubuntu 20.04+, Kali 2023+)	Windows 10 21H2+	Windows 10 21H2+
RAM (минимум)	2 ГБ	4 ГБ	8 ГБ (kernel debug - 16 ГБ)
Установка	apt install gdb, pwndbg - клон с GitHub	Релиз с github.com/x64dbg, плагины вручную	Microsoft Store или Windows SDK
Плагины	pwndbg или peda (не оба одновременно)	ScyllaHide (антиантиотладка), xAnalyzer (аннотации API)	MEX, символы с msdl.microsoft.com
Сеть	Не требуется	Не требуется	Символы - интернет или локальный кеш
Изоляция	VM обязательна при анализе малвари	VM обязательна, сеть host-only	VM; kernel debug - две машины или Hyper-V

Все три отладчика работают локально. Облачные варианты (отладка через удалённый gdbserver) возможны, но для анализа вредоносного ПО не рекомендуются из соображений OPSEC.

Отладка бинарей GDB: ELF, CTF и Linux-малварь​

GDB - штатный отладчик для ELF. Без плагинов работать с ним - упражнение в терпении: ни нормального отображения стека, ни подсветки регистров, ни автоматического парсинга heap chunks. pwndbg превращает это страдание в рабочий инструмент.

Практический workflow​

Типичная последовательность при решении CTF-pwn или анализе Linux-дроппера:

1. Загрузка и проверка защит: gdb ./target, затем checksec (pwndbg покажет NX, PIE, RELRO, canary)
2. Брейкпоинт на точку интереса: b main или b *0x401234
3. Запуск с аргументами: r arg1 arg2
4. Пошаговое выполнение: ni (не заходя в call), si (step into)
5. Просмотр памяти: x/20gx $rsp (20 qword от вершины стека), x/s 0x402000 (строка)
6. Модификация регистра на лету: set $rip = 0x401300

Аппаратные брейкпоинты - ключевая техника при работе с самомодифицирующимся кодом. Программные (b) записывают int3 (0xCC) в память, и если малварь проверяет целостность собственного кода - обнаружит подмену. Аппаратные (hb *addr) используют регистры DR0-DR3 процессора и не модифицируют память целевого процесса. Разница принципиальная: 0xCC в коде - это как красный флаг для любого сэмпла с self-checksumming.

gdb ./packed_sample
pwndbg> b *main
pwndbg> r
pwndbg> hb *0x00401a3f
pwndbg> watch *0x7fffe000
pwndbg> c
pwndbg> x/10i $rip
pwndbg> telescope $rsp 8
pwndbg> vmmap

vmmap показывает карту виртуальной памяти - незаменима при анализе распаковщиков, когда нужно увидеть, куда mmap или mprotect выделил исполняемый регион. telescope отображает стек с автоматической разыменовкой указателей - за секунду видно, где лежат адреса возврата и аргументы. До pwndbg приходилось всё это собирать вручную из x/ и info proc mappings. Сейчас - одна команда.

Ограничения GDB​

• Windows PE - GDB через Wine или MinGW-сборку работает, но это скорее хак, чем решение. Для PE - x64dbg или WinDbg, без вариантов
• Антиотладка через ptrace - Linux-малварь вызывает ptrace(PTRACE_TRACEME), под отладчиком вызов вернёт ошибку. Обход: catch syscall ptrace, затем при срабатывании на выходе из syscall - set $rax = 0 (x86_64), чтобы имитировать успешный вызов. Альтернатива - LD_PRELOAD с библиотекой, перехватывающей ptrace()
• Нет kernel-mode - для ядра Linux нужен KGDB или QEMU с gdb stub
• Производительность - пошаговая трассировка через si медленная на обфусцированном коде с миллионами junk-инструкций. Если сэмпл напичкан мусорными опкодами - готовьтесь ждать

Отдельный момент: GDB присутствует в каталоге GTFOBins - при наличии SUID-бита или sudo-правил его можно использовать для чтения файлов и выполнения команд. Стоит помнить при Linux privilege escalation.

x64dbg: анализ malware и распаковка PE​

x64dbg - open-source отладчик для Windows, фактический стандарт для user-mode отладки исполняемых файлов Windows. OllyDbg не обновлялся с 2013 года, x64 не поддерживает - Оля, к сожалению, не доросла. x64dbg занял эту нишу и закрепился.

Практический workflow​

Workflow при анализе упакованного сэмпла (по материалам исследования Varonis по x64dbg):

Подготовка. Перед загрузкой в x64dbg - переименовать бинарь и разместить по пути, куда малварь себя копирует (информация из ProcMon). Если малварь проверяет аргументы командной строки - добавить через File → Change Command Line. Конкретный пример: сэмпл переименовал себя в loadatangent.exe, скопировался в %LOCALAPPDATA%\loadatangent\ и добавил аргумент --82621c98. Без воспроизведения этих условий вы попадёте в ветку «я под анализом». Малварь просто свернёт лавочку и тихо завершится.

Анализ IAT. Правый клик → Search for → Current Module → Intermodular calls. При обфускации IAT (T1027) изначально видна одна-две записи. Остальное скрыто - и вот тут начинается самое интересное.

Брейкпоинты на API. В командной строке x64dbg:

bp CreateMutexW
bp VirtualAlloc
bp InternetConnectW
bp WriteFile
g

Имена API регистрозависимы. После срабатывания - Ctrl+F9 (Execute till return) или Run to user code для возврата из системной DLL в код малвари. Плагин xAnalyzer автоматически аннотирует параметры функций: для CreateMutexW параметр lpName показывает имя мьютекса - прямой IoC для отчёта.

ScyllaHide: обход антиотладки​

ScyllaHide патчит PEB (Process Environment Block) и перехватывает NtQueryInformationProcess, NtSetInformationThread, GetTickCount и другие API, используемые для Debugger Evasion (T1622). Без этого плагина динамический анализ вредоносного ПО уровня выше учебного - бесконечный ручной обход одних и тех же проверок. Раньше это съедало часы, сейчас ScyllaHide закрывает 80% случаев автоматически.

Настройка: ScyllaHide → Options - профиль «Basic» покрывает большинство сэмплов. Для сложных случаев - «Custom» с включённой подменой PEB, NtQueryInformationProcess и NtClose.

Ограничения x64dbg​

• Только user-mode - kernel-драйверы и BSOD-анализ не его задача
• Нет полной символьной информации - в отличие от WinDbg, не загружает .pdb с серверов Microsoft
• Не для .NET - управляемые приложения требуют dnSpy; x64dbg покажет JIT-compiled код без контекста
• Детектируемость - окна и процесс x64dbg обнаруживаются через FindWindow и проверку имени. ScyllaHide закрывает часть векторов, но не все. Продвинутые сэмплы проверяют ещё и timing, и наличие характерных DLL в адресном пространстве

WinDbg: трассировка kernel-mode и crash dumps​

WinDbg - отладчик Microsoft для ситуаций, когда user-mode инструмента недостаточно. Интерфейс WinDbg Preview наконец-то перестал выглядеть как артефакт из 2003 года, но кривая обучения всё ещё крутая.

Когда WinDbg, а когда x64dbg​

Типичная ошибка - анализировать user-mode PE в WinDbg. Технически возможно, но интерфейс ориентирован на командную строку, нет графического представления ассемблера с подсветкой переходов, нет ScyllaHide. Для user-mode PE x64dbg банально быстрее.

WinDbg выигрывает при:

• Kernel debugging - отладка драйверов, rootkit-анализ, DKOM-техники. Тут альтернатив нет
• Crash dump анализ - разбор .dmp файлов командой !analyze -v (автоматически определяет причину BSOD)
• Полные символы - загрузка .pdb с msdl.microsoft.com через .sympath srv[I]c:\symbols[/I]https://msdl.microsoft.com/download/symbols и .reload
• Удалённая отладка - через pipe, COM-порт или сеть

Ключевые команды: bp kernel32!CreateFileW - брейкпоинт, kb - call stack с параметрами, r - регистры, db 0x1000 L32 - дамп 32 байт, u - дизассемблирование, .tlist - список процессов. Для присоединения к процессу: windbg -pn target.exe или .attach <PID> из консоли.

Сравнение отладчиков: trade-off таблица​

Критерий	GDB + pwndbg	x64dbg + ScyllaHide	WinDbg
Платформа	Linux (ELF)	Windows (PE, user-mode)	Windows (PE, kernel + user)
GUI	Минимальный (TUI)	Полноценный	Средний (Preview лучше)
Kernel debug	Нет	Нет	Нативно
Anti-debug bypass	Ручной (ptrace, LD_PRELOAD)	ScyllaHide - автоматический	Ручной
Crash dumps	Нет	Нет	Нативно
CTF pwn	Основной инструмент	Не применяется	Не применяется
Windows malware	Не применяется	Основной инструмент	Rootkits, kernel-малварь
Linux malware	Основной инструмент	Не применяется	Не применяется
Скриптинг	Python (pwndbg API)	Встроенный скриптовый движок	JavaScript, DML
Learning curve	Средняя (с плагином - низкая)	Низкая	Высокая
Когда НЕ использовать	Windows PE, kernel	Kernel, .NET, Linux	User-mode PE (x64dbg быстрее)

Антиотладочные техники и их обход​

Debugger Evasion (T1622, тактики Defense Evasion и Discovery по MITRE ATT&CK) - набор техник обнаружения отладчика, для которого тесты Atomic Red Team представлены только для Windows.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

На практике я обычно трачу 15–20 минут в Ghidra, чтобы найти эту точку. Это дешевле, чем час ковыряться с каждой проверкой по отдельности.

Что видит защита при динамическом анализе​

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

Что детектируется:

• Запуск gdb, x64dbg.exe, windbg.exe - прямой IoC для EDR (CrowdStrike Falcon, SentinelOne, Elastic), детектируется по имени процесса и хешу
• ptrace на Linux - логируется аудитом (auditd), некоторые EDR перехватывают этот syscall
• Модификация PEB, вызовы NtSetInformationThread(ThreadHideFromDebugger) - перехватываются через ETW на Windows 10+
• API DebugActiveProcess - штатный механизм присоединения, логируется

Что обычно не обнаруживается:

• Аппаратные брейкпоинты (DR0-DR3) - не оставляют следов в памяти процесса
• Чтение /proc/pid/maps и /proc/pid/mem - легитимная операция при наличии прав
• Анализ в изолированной VM без агента EDR - очевидно, но регулярно забывают настроить (и это самая частая ошибка)

Рекомендация: анализ вредоносного ПО проводить в изолированной VM без EDR-агента, с сетью в режиме host-only. Если задача - понять, как конкретный EDR хукает API для разработки evasion, эффективнее анализировать DLL агента статически в Ghidra, а не пытаться отлаживать процесс, который активно защищается от анализа. Препарировать мёртвую DLL проще, чем бороться с живым агентом.

Порог входа в динамический анализ бинарных файлов за последние три года снизился кратно. pwndbg превратил GDB из инструмента для терпеливых в удобную среду. x64dbg с ScyllaHide автоматизировал обход антиотладки, который раньше съедал часы. WinDbg Preview перестал пугать интерфейсом из прошлого тысячелетия. Но удобство создало опасную иллюзию - что для анализа достаточно загрузить бинарь и нажать F9.

Я регулярно вижу, как аналитики открывают сэмпл в отладчике и начинают трассировать с точки входа - без гипотезы, без предварительного взгляда в IDA или Ghidra. Результат предсказуем: часы бессмысленного степпинга по прологам CRT и циклам инициализации. Отладчик усиливает понимание, но не заменяет его. Час в Ghidra на раннем этапе экономит три часа в отладчике - статический анализ формирует гипотезу (где ставить брейкпоинт, какой API перехватывать, какой условный переход определяет ветку поведения), а динамический анализ эту гипотезу верифицирует.

Самый разрушительный антипаттерн - бесконечный степпинг без гипотезы. Самый эффективный подход - 20 минут в декомпиляторе, три точных брейкпоинта и 5 минут в отладчике до результата. Инструменты стали удобными. Мышление за аналитика они пока не делают. На WAPT эту связку «статика → гипотеза → три брейкпоинта» отрабатывают на реальных сэмплах в лабах.