voidsec/driverbuddyreloadedDriver Buddy Reloaded — это плагин IDA Pro на Python, который помогает автоматизировать некоторые утомительные задачи реверс-инжиниринга драйверов Windows Kernel.
Способ установки зависит от версии IDA, поскольку встроенный менеджер плагинов (и, следовательно, инструмент hcli
и манифест ida-plugin.json) существует только в IDA 9.0 и выше. IDA 7.6 и 8.x не имеют менеджера плагинов
и сканируют только верхний уровень папки plugins.
hcli)Репозиторий содержит манифест ida-plugin.json, поэтому IDA 9.0+ загружает плагин из своей собственной поддиректории. Установите его с помощью:
hcli install .
hcli plugin install DriverBuddyReloaded
Это помещает плагин в подкаталог вашей папки пользовательских плагинов (например,
`%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` или `~/.idapro/plugins/DriverBuddyReloaded/`), оставляя
точку входа `DriverBuddyReloaded.py` *внутри* этого подкаталога. Это предполагаемая структура: IDA читает манифест,
загружает объявленную точку входа из подкаталога и добавляет подкаталог в `sys.path`, чтобы точка входа могла
импортировать пакет `DriverBuddyReloaded`, находящийся рядом. Вам **не** нужно перемещать `DriverBuddyReloaded.py` на верхний уровень.
Проверьте установку с помощью `hcli plugin status`, затем запустите IDA и убедитесь, что плагин появился в
`Edit -> Plugins` (проверьте окно Output на наличие ошибок Python при запуске).
Для установки из локальной копии для тестирования (например, после ваших изменений) выполните `hcli plugin install .` из
корня репозитория; `hcli plugin lint .` сначала проверяет манифест/структуру.
### IDA 7.6 / 8.x (ручное копирование)
В этих версиях нет менеджера плагинов, поэтому плагин, установленный через `hcli` в подкаталог, **не** будет обнаружен. Скопируйте
папку `DriverBuddyReloaded` и файл скрипта `DriverBuddyReloaded.py` напрямую на **верхний уровень** папки плагинов IDA,
например:
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`
В результате структура будет такой: `plugins\DriverBuddyReloaded.py` вместе с `plugins\DriverBuddyReloaded\` (папка пакета).
### Примечания
Если ваша IDA настроена на Python 2, запустите бинарный файл `idapyswitch` (находится в папке IDA), чтобы переключить её на Python 3.
**ПРИМЕЧАНИЕ:** Driver Buddy Reloaded работает на IDA 7.6+, 8.x (включая 8.4) и 9.0+ с Python 3. Все различия в API IDA, зависящие от версии (удаление `get_inf_structure`, модуля `ida_struct` и помощников `idc.*struc*` в IDA 9.0 и т.д.), обрабатываются внутренне слоем совместимости `DriverBuddyReloaded/ida_compat.py`.
## Быстрое использование
Чтобы использовать функцию автоматического анализа:
1. Запустите IDA и загрузите драйвер ядра Windows.
2. Перейдите в `Edit -> Plugins -> Driver Buddy Reloaded` или нажмите `CTRL+ALT+A`, чтобы запустить автоматический анализ.
3. Проверьте окно "Output" на наличие результатов анализа и окно **Driver Buddy Reloaded - Findings**, которое открывается
по завершении работы (двойной щелчок по строке переходит к её адресу).
4. Следующие файлы записываются в каталог DB IDA (все с префиксом `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-`):
- `findings.json` - машиночитаемые результаты (IOCTL, отмеченные функции, имена устройств, пултеги, цепочки вызовов, эвристики, аудит ACL устройства, символические ссылки, аудит экспортов, привилегированные опкоды)
- `report.html` - автономный HTML-отчёт, сгруппированный по степени серьёзности
- `pooltags.txt` - выгруженные пултеги в формате `pooltags.txt` для WinDbg
- `autoanalysis.txt` - полный текстовый журнал анализа (отражает окно Output)
Чтобы декодировать IOCTL:
1. Поместите курсор мыши на строку, содержащую предполагаемый код IOCTL.
2. Щёлкните правой кнопкой мыши и выберите `Driver Buddy Reloaded -> Decode IOCTL`; альтернативно нажмите сочетание клавиш `CTRL+ALT+D`.
Чтобы в любое время повторно открыть окно IOCTL или окно результатов (без повторного запуска анализа):
- Нажмите `CTRL+ALT+I`, чтобы открыть окно IOCTL.
- Нажмите `CTRL+ALT+F`, чтобы открыть окно результатов.
### Расширенное использование
- Каталог [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists) содержит списки потенциально опасных/проблемных функций, Windows API и опкодов; прилагается краткое описание, почему конкретная функция/API была включена в список. Вы можете редактировать список `custom`, добавляя специфичные для драйвера функции.
**Примечание**: `winapi_function_prefixes` будет выполнять частичное совпадение с началом имени функции (например, `Zw` будет соответствовать `ZwClose`, `ZwCommitComplete` и т.д.), в то время как `winapi_functions` будет выполнять только точное совпадение.
- В [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/find_opcodes.py) опция `find_opcode_data` (по умолчанию `False`)
подавляет совпадения опкодов, попадающие в секции данных
([issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11)). Установка её в `True` также выявляет
совпадения сырых байтов в данных; если реальный опкод был пропущен таким образом, переход по указанному адресу и переопределение
байтов как кода обычно восстанавливает его. Совпадения сообщаются так же, как и на любом другом этапе (окно результатов,
`findings.json`, `report.html`).
**Внимание**: установка в `True` генерирует больше ложных срабатываний!
## О Driver Buddy Reloaded
**Driver Buddy Reloaded** — это плагин IDA Pro на Python, который помогает автоматизировать некоторые утомительные задачи обратной разработки драйверов ядра Windows. Он имеет ряд удобных функций, таких как:
* Определение типа драйвера (WDM, KMDF, UMDF, WDF, Mini-Filter, Stream Minidriver, AVStream, PortCls)
* Поиск функций `DispatchDeviceControl` / `DispatchInternalDeviceControl` для **всех** типов драйверов
(сканирование `MajorFunction[IRP_MJ_DEVICE_CONTROL]` находит обработчик даже в минитфильтре/WDF-драйвере, который также
предоставляет устаревшее устройство управления, и даже когда назначение находится во вспомогательной функции, а не в `DriverEntry`)
* Заполнение общих структур для драйверов `WDF` и `WDM`
* Попытки идентифицировать и пометить такие структуры, как `IRP` и `IO_STACK_LOCATION`
* Пометка вызовов функций `WDF`, которые обычно остаются непомеченными
* Создание IDA-перечисления `IRP_MJ_FUNCTION` и его применение к слотам массива `MajorFunction` в `DriverEntry` (WDM)
* Поиск и декодирование кодов IOCTL
* Автоматическое многостратегическое сканирование идентифицированных функций-диспетчеров (не требует размещения курсора):
дерево декомпилятора (восстанавливает коды, скрытые таблицей переходов или бинарным поиском, которые никогда не появляются как
непосредственные значения), таблица переходов IDA, а также резервный метод сканирования непосредственных операндов (резервный метод запускается только для функции,
которая действительно читает IoControlCode IRP, поэтому неправильно идентифицированная вспомогательная библиотека не может пропустить свои
внутренние константы как ложные IOCTL)
* Значения NTSTATUS разрешаются динамически из базы типов IDA (с широким резервным набором жёстко заданных значений) и
**исходящие** IOCTL, которые драйвер просто отправляет нижестоящим (`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile`
/ ...) исключаются, чтобы их не приняли за собственную поверхность атаки драйвера
* Отметка функций, склонных к неправильному использованию
* Поиск потенциального `DeviceName` (сканирование mmap + резервный метод Strings IDA, с указанием исходного адреса)
* Выгрузка `Pooltags` (основной метод на основе импорта + резервный метод распространения регистров для тегов, размещённых в регистре)
* **Эвристические проверки уязвимостей** для каждого диспетчера и функций, которые он транзитивно вызывает: непроверенное копирование из пользовательского режима, TOCTOU/двойное чтение, использование после освобождения (внутри функции и между функциями через освобождённую глобальную переменную), отсутствие привилегированного шлюза, несоответствие IRQL, небезопасное отображение MDL, буферы, выделенные на стеке (`_alloca`), выделение пула без проверки размера, привилегированные инструкции CPU (ввод/вывод порта `in`/`out`, `mov cr*`), произвольная запись (write-what-where) и ссылки на `\Device\PhysicalMemory` (шаблон BYOVD) — см.
[Эвристические проверки уязвимостей](#heuristic-vulnerability-checks)
* **Аудит ACL устройств и отслеживание символических ссылок**: отмечает устройства, созданные с помощью `IoCreateDevice`, без дескриптора безопасности (доступные всем) / со слабыми SDDL `IoCreateDeviceSecure`, и декодирует целевые пути `IoCreateSymbolicLink`
* **Аудит экспортов**: отмечает экспорты драйвера с нулевыми внутренними перекрёстными ссылками (потенциальная поверхность атаки)
* **Оценка риска** для декодированных IOCTL для каждого IOCTL (приоритет `METHOD_NEITHER` / `FILE_ANY_ACCESS`, и повышение IOCTL
только для опасных стоков/опкодов, достижимых из **собственного** обработчика случая - `MmMapIoSpace`, `memcpy`,
`__writemsr`, портовый ввод/вывод, доступ к PCI-конфигурации - так что безвредный код в монолитном диспетчере больше не страдает от
опасных стоков родственного обработчика; когда атрибуция неточна, повышение ограничено, а не принудительно до CRITICAL) и
представление всех результатов по степени серьёзности в кликабельном окне результатов (двойной щелчок для перехода к адресу)
* **Отслеживание цепочек вызовов** от диспетчеров/обработчиков IOCTL до опасных стоков (эвристическое, на основе имени)
* Экспорт результатов в машиночитаемый **JSON** файл и автономный **HTML** отчёт
### Поиск DispatchDeviceControl
Инструмент может автоматически находить и идентифицировать подпрограмму `DispatchDeviceControl`. Эта функция используется для маршрутизации всех
входящих кодов `DeviceIoControl` к конкретной функции драйвера, связанной с этим кодом. Автоматическая идентификация
этой функции значительно ускоряет поиск действующих кодов `DeviceIoControl` для каждого драйвера. Кроме того, при
исследовании возможных уязвимостей в драйвере из-за сбоя знание местоположения этой функции помогает сузить
фокус до конкретного вызова функции, связанного с кодом `DeviceIoControl`, вызвавшим сбой.
Если анализ прошёл успешно, некоторые подпрограммы будут переименованы следующим образом:
- `DriverEntry`: исходная первая рутина, предоставляемая драйвером, которая вызывается после загрузки драйвера. Она отвечает
за инициализацию драйвера.
- `Real_Driver_Entry`: обычно функция, в которую было передано управление из `DriverEntry`. Обычно в ней
инициализируется `DeviceName`.
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: если инструмент смог восстановить функции по некоторым конкретным
смещениям, функции будут переименованы соответствующим образом.
- `Possible_DispatchDeviceControl_#`: если инструмент не смог восстановить `DispatchDeviceControl`
или `DispatchInternalDeviceControl`, он применяет экспериментальный поиск, следуя потоку выполнения и проверяя
случаи, когда функция загружает известные адреса `IO_STACK_LOCATION` и `IRP`; это указывает на то, что функция
может быть DispatchDeviceControl. Поскольку это основано на эвристике, может быть возвращено более одного результата, и это чревато
ложными срабатываниями.
### Пометка структур WDM и WDF
Несколько структур драйвера являются общими для всех драйверов `WDM`/`WDF`. Инструмент способен автоматически идентифицировать эти
структуры, такие как `IO_STACK_LOCATION`, `IRP` и `DeviceObject`, и может помочь сэкономить время в процессе
реверс-инжиниринга и обеспечить контекст для областей драйвера, где эти функции используются.
### Поиск и декодирование кодов IOCTL
При реверсе драйверов часто встречаются коды IOCTL в ходе анализа. Эти коды, при декодировании,
раскрывают полезную информацию и могут привлечь внимание к определённым частям драйвера, где уязвимости, скорее всего,
существуют.
Щёлкнув правой кнопкой мыши по потенциальному коду IOCTL, появляется пункт контекстного меню (альтернативно можно использовать
сочетание клавиш `Ctrl+Alt+D`, когда курсор находится на строке, содержащей предполагаемый код IOCTL), и его можно использовать для декодирования
значения. Будет выведена таблица со всеми декодированными кодами IOCTL. Щёлкнув правой кнопкой мыши по декодированному коду IOCTL в представлении
дизассемблера, можно пометить его как недействительный; это сохранит любые не-IOCTL комментарии нетронутыми.
- Декодированные IOCTL выводятся в окно Output и перечисляются в окне IOCTL, окрашенном по степени серьёзности; после
автоматического анализа они также записываются в `findings.json` / `report.html`.
Автоматический анализ дополнительно запускает многостратегическое сканирование идентифицированных функций-диспетчеров для автоматического обнаружения IOCTL
без необходимости ручного размещения курсора. Для каждого диспетчера он использует декомпилятор Hex-Rays
(когда доступен) для чтения меток switch-case и констант сравнения `==`/`!=` непосредственно из восстановленного
потока управления, возвращаясь к метаданным таблицы переходов IDA, а затем к сканированию необработанных непосредственных операндов. Путь
декопилятора восстанавливает коды, которые никогда не встречаются буквально в дизассемблере - например, драйверы, чей диспетчер
компилятор реализовал в виде таблицы переходов (только база/граница таблицы сохраняются как непосредственные значения) или в виде дерева
сравнений бинарного поиска (промежуточные коды сохраняются только как дельты). На представительном корпусе это повысило восстановление
с 7/28 до 28/28 (HEVD) и с 4/17 до 17/17 (ALSysIO64) без ложных срабатываний.
### Отметка функций
Driver Buddy Reloaded содержит списки функций C/C++, опкодов и Windows API (определены в
директории [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists)), которые часто бывают уязвимы
или могут способствовать условиям переполнения буфера. Все найденные экземпляры сообщаются во время
автоматического анализа и могут помочь при поиске возможных путей кода, контролируемых пользователем, достигающих чувствительных функций.
### Поиск DeviceName
Инструмент автоматически пытается найти зарегистрированные пути устройств драйвера (`DeviceName`). Если пути не могут быть найдены при
просмотре строк Unicode внутри бинарного файла, аналитик может вручную попытаться использовать
[FLOSS](https://github.com/mandiant/flare-floss/) от Mandiant, чтобы попытаться найти обфусцированные пути.
### Выгрузка Pooltags
Во время автоматического анализа инструмент также выгружает `Pooltags`, используемые бинарным файлом, в формате, который работает
с `pooltags.txt`. Вывод затем можно скопировать и вставить в конец файла, а позже он будет использован WinDbg.
- Файл `DriverName.sys-DATE-TIME_STAMP-pooltags.txt`, содержащий все выгруженные Pooltags, будет записан в
каталог DB IDA.
### Эвристические проверки уязвимостей
Модуль `heuristics.py` запускается после трассировки цепочек вызовов и проверяет каждый диспетчер **и функции, которые он
транзитивно вызывает** - таким образом анализируются обработчики для каждого IOCTL, а не только пролог диспетчера. Сопоставление
вызываемых функций учитывает импорт (импортированный `call cs:__imp_<Name>` соответствует тому же имени, что и локальный вызов). Он выдаёт результаты в
категории **heuristic** (находки привилегированных инструкций используют категорию **opcode**):
| Проверка | Что отмечается | Серьёзность |
|---|---|---|
| Непроверенная пользовательская копия | `memcpy`/`RtlCopyMemory` и т.д. без рядом находящегося `ProbeForRead`/`ProbeForWrite`/безопасной строковой защиты | HIGH (обработчик), MEDIUM (другое) |
| TOCTOU / двойное чтение | повторное чтение поля указателя пользовательского режима на одном пути потока управления без промежуточного `ProbeForRead` (только для обработчиков METHOD_NEITHER, так что повторное чтение буферов ядра не отмечается) | MEDIUM |
| Использование после освобождения | повторное использование освобождённого указателя внутри функции (обход графа регистров) или глобальной переменной, освобождённой без обнуления и затем разыменованной из другой функции | HIGH |
| Отсутствие привилегированного шлюза | чувствительная операция (`ZwOpenProcess`/`MmMapIoSpace`/PCI-конфиг и т.д.), достижимая из диспетчера без `SeAccessCheck`/`SeSinglePrivilegeCheck`/проверки токена на любом пути | HIGH |
| Несоответствие IRQL | Вызов страничной / `Zw*` / `MmMap*`, когда также присутствует функция, повышающая IRQL | MEDIUM |
| Небезопасное отображение MDL | `MmMapLockedPages`/`MmProbeAndLockPages` и т.д. с `UserMode` в дизассемблере | HIGH, иначе MEDIUM |
| Стековое выделение | Вызов `_alloca`/`_malloca`/`_chkstk` (большое или динамическое выделение на стеке) | LOW |
| Выделение пула без проверки размера | Вызов `ExAllocatePool*` без рядом находящейся защиты с безопасной арифметикой (шаблон переполнения целого числа перед выделением) | HIGH |
| Привилегированная инструкция | портовый ввод/вывод (`in`/`out`), перемещение управляющих/отладочных регистров (`mov cr*`/`mov dr*`), загрузка таблицы дескрипторов, `cli`/`sti`/`hlt`, достижимые из обработчика (примитив доступа к аппаратному обеспечению BYOVD) | CRITICAL (`out`) / HIGH (`in`) / MEDIUM |
| Произвольная запись (write-what-where) | сохранение через дважды разыменованный пользовательский указатель `*(*p) = c`; контролируемая копия `*p = *q` сообщается как более слабая зацепка | HIGH / MEDIUM |
| Ссылка на `\Device\PhysicalMemory` | Перекрёстная ссылка на строку объекта устройства физической памяти (шаблон BYOVD через `ZwOpenSection`/`ZwMapViewOfSection`) | HIGH (обработчик), MEDIUM (другое) |
Это **генераторы зацепок**, а не подтверждённые уязвимости. Относитесь к находкам HIGH/CRITICAL как к отправным точкам для
ручного анализа.
## Флаги функций
Все необязательные этапы анализа управляются `DriverBuddyReloaded/config.py`. Отредактируйте класс `Feature`, чтобы
включить или отключить их:
| Флаг | По умолчанию | Описание |
|---|---|---|
| `IOCTL_SCAN` | `True` | Обнаружение и декодирование IOCTL (сканирование диспетчера + резервный метод `IoControlCode`) |
| `IOCTL_DECOMPILER` | `True` | Использовать дерево Hex-Rays в сканировании диспетчера (восстанавливает коды таблицы переходов / бинарного поиска) |
| `HEURISTICS` | `True` | Эвристические проверки уязвимостей (см. таблицу выше) |
| `TOCTOU_CHECK` | `True` | Эвристика двойного чтения / TOCTOU |
| `UAF_DETECT` | `True` | Эвристика использования после освобождения (обход регистров внутри функции + глобальные переменные между функциями) |
| `ACL_AUDIT` | `True` | Отметить общедоступные `IoCreateDevice` / слабые SDDL `IoCreateDeviceSecure` |
| `SYMLINK_TRACK` | `True` | Декодировать целевые пути `IoCreateSymbolicLink` |
| `CALLCHAIN` | `True` | Трассировка цепочек вызовов BFS от обработчиков до опасных стоков |
| `EXPORTS_AUDIT` | `True` | Отметить экспорты драйвера с нулевыми внутренними перекрёстными ссылками |
| `POOLTAG_FALLBACK` | `True` | Сканер пултегов с распространением регистров (используется, когда сканирование на основе импорта ничего не находит) |
| `IRP_MJ_ENUM` | `True` | Создаёт перечисление `IRP_MJ_FUNCTION` IDA и применяет его к слотам `MajorFunction` (только WDM) |
| `RISK_SCORING` | `True` | Оценка риска IOCTL (веса METHOD/ACCESS + повышение для стоков для каждого обработчика) |
| `RESULTS_WINDOW` | `True` | Показать окно результатов Driver Buddy Reloaded после анализа |
| `JSON_EXPORT` | `True` | Запись `findings.json` |
| `HTML_REPORT` | `True` | Запись `report.html` |
| `SEGMENT_OPCODE_SCAN` | `False` | Линейное сканирование опкодов сегмента (шумное, отключено по умолчанию) |
## Тестирование
Три уровня, от быстрого до тщательного:
- **Чисто Python регрессия** (IDA не требуется) - охватывает всю логику, не затрагивающую живую базу данных: ```
python tests/test_dbr.py
DBR_SDK=900 python tests/test_dbr.py # simulate the IDA 9.0 import paths
.sys и выводит таблицу пройдено/не пройдено: pwsh tests/run_cross_version.ps1.pwsh tests/run_golden.ps1 перезапускает полный анализ на чистой копии каждого эталонного драйвера в tests/drivers/ и сравнивает результаты с зафиксированным базовым файлом tests/drivers/<driver>.golden.json (без учета порядка по категории, заголовку, серьезности и коду/методу/доступу IOCTL). Любое дополнительное обнаружение (ложное срабатывание), пропущенное обнаружение (ложное отрицание) или изменение серьезности приводит к сбою выполнения. Повторно создавайте золотой эталон только тогда, когда изменение намеренно изменяет результаты, и просматривайте diff. Золотые эталоны привязаны к сборке декомпилятора IDA, с которой они были получены (8.4), поэтому запускайте регрессию с этой версией.CTL_CODE с помощью _is_valid_ctl_code(): поле DeviceType (биты 31-16) должно быть ненулевым, а значение не должно совпадать с известным кодом NTSTATUS или сигналом 0xFFFFFFFF (DWORD)-1 (константа сравнения, встречающаяся в реальных диспетчерах, например, WinRing0). Это исключает счетчики циклов, маленькие непосредственные значения и коды ошибок, сохраняя все допустимые IOCTL, включая пользовательские типы устройств (0x8000+). Тот же фильтр применяется ко всем четырем путям обнаружения: сканирование перекрестных ссылок IoControlCode и три сборщика диспетчеров (декомпилятор ctree, восстановление таблицы переключения IDA и сканирование необработанных непосредственных операндов).DriverBuddyReloaded/config.py.DispatchDeviceControl работает только для драйверов x64find_opcode_data (по умолчанию ) подавляет совпадения опкодов, попадающие в секции данных. Переключение его на также выявляет необработанные совпадения байтов в данных, что чревато ложными срабатываниями; если реальный опкод был пропущен, переход по указанному адресу и переопределение байтов как кода обычно восстанавливает его. Совпадения сообщаются как на любом другом этапе (окно результатов, , ).FalseTruefindings.jsonreport.html