Это драйвер звукового сигнала, встроенный в Windows: когда что-то идет не так, он делает гудок. Функция инициализации, которая всегда вызывается при загрузке драйвера (это единственная функция такого рода), находится по сдвигу 0xf7adb66c . Если бы этот драйвер был заражен, нас бы интересовал код, который размещен по данному адресу, поскольку во время загрузки он вызывается первым. Иногда вредоносное ПО прячет в этой функции весь свой зараженный код.

Настройка символов Windows

Символы привязаны к конкретной версии анализируемого файла и могут меняться

скаждым обновлением или заплаткой. Если как следует сконфигурировать отладчик WinDbg, он сможет обращаться к серверу компании Microsoft и автоматически получать подходящие символы для отлаживаемых файлов. Вы можете указать путь к файлу с символами, выбрав пункт меню File Symbol File Path (Файл Путь к файлу

ссимволами). Чтобы позволить WinDbg использовать для поиска символов интер- нет-сервер, введите следующий путь:

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

SRV обозначает сервер, c:\websymbols — это путь к локальному кэшу с информацией о символах, а URL-адрес указывает на местоположение сервера с символами от компании Microsoft.

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

Отладка ядра на практике

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

вфайл, но он позволяет обойти некоторые системы защиты и запутать аналитиков безопасности, которые по привычке ищут вызовы CreateFile и WriteFile

впользовательском режиме. Обычные функции платформы Win32 не так просто использовать в режиме ядра, что создает трудности для злоумышленников, но

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

NtCreateFile и NtWriteFile.

Изучение кода в пользовательском пространстве

В нашем примере компонент пользовательского пространства создает драйвер, который, находясь в ядре, считывает и записывает файлы. Для начала мы откроем пользовательский код в IDA Pro, чтобы узнать, с помощью каких функций он взаимодействует с драйвером (листинг 10.4).

Листинг 10.4. Создание службы для загрузки драйвера

Процедура управления службами говорит о том, что драйвер загружается в функции CreateService. Заметьте, что в качестве параметра типа dwService используется значение 0x01. Это признак того, что данный код является драйвером.

В листинге 10.5 также видно, что с помощью вызова CreateFileA создается файл, чтобы получить дескриптор устройства. Имя файла, помещенное в стек, хранится в регистре EDI (здесь не показано, что в EDI загружается строка \\.\FileWriterDevice, которая является именем объекта, созданного драйвером для доступа из пользовательского пространства).

Листинг 10.5. Получение дескриптора, принадлежащего объекту устройства

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

Анализ кода, работающего в режиме ядра

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

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

ПРИМЕЧАНИЕ

При использовании VMware для отладки ядра вы будете часто наблюдать загрузку и выгрузку модуля KMixer.sys. Это нормально и никак не связано

свредоносной активностью.

Вследующем примере в окне отладчика видно, как в ядро загружается драйвер FileWriter.sys. Скорее всего, он заражен.

ModLoad: f7b0d000 f7b0e780 FileWriter.sys

Чтобы определить, какой код вызывается из зараженного драйвера, нам нужно найти его объект. Поскольку нам известно имя драйвера, мы можем воспользоваться командой !drvobj. Пример вывода показан в листинге 10.7.

Листинг 10.7. Просмотр объекта загруженного драйвера

kd> !drvobj FileWriter

Driver object (827e3698) is for:

Loading symbols for f7b0d000 FileWriter.sys -> FileWriter.sys

*** ERROR: Module load completed but symbols could not be loaded for FileWriter.sys \Driver\FileWriter

Device Object list: 826eb030

ПРИМЕЧАНИЕ

Иногда команда !drvobj завершается неудачно или же объект драйвера имеет другое имя. В качестве альтернативы можно воспользоваться командой !object \Driver, которая перечисляет все объекты в корневом пространстве

\Driver (см. главу 7).

Объект драйвера хранится по адресу 0x827e3698 . Получив эту информацию, мы можем просмотреть его структуру с помощью команды dt (листинг 10.8).

На входе в MajorFunction внутри этой структуры находится указатель на первую запись в таблице этой функции. Таблица функции MajorFunction говорит нам о том, что происходит при вызове зараженного драйвера из пользовательского пространства. В каждой записи таблицы находится отдельная функция, представляющая определенный тип запроса; индексы записей, имеющие префикс IRP_MJ, можно найти в файле wdm.h. Например, если нужно узнать, какое смещение в таблице имеет код, который запускается при вызове из прикладного приложения функции

DeviceIoControl, то следует искать индекс IRP_MJ_DEVICE_CONTROL. В данном случае IRP_MJ_DEVICE_CONTROL имеет значение 0xe, а таблица функции MajorFunction

начинается со смещением 0x038 относительно начала объекта драйвера. Чтобы определить, какая функция вызывается для обработки запроса DeviceIoControl, используйте команду dd 827e3698+0x38+e*4 L1. 0x038 — сдвиг начала таблицы,

а 0xe — индекс записи IRP_MJ_DEVICE_CONTROL, умноженный на 4 (поскольку каждый указатель занимает 4 байта). Аргумент L1 говорит о том, что мы хотим оставить в выводе только значения типа DWORD.

Из приведенной выше команды мы узнали, что функция, вызываемая в ядре, имеет адрес 0xf7b0da66 (листинг 10.9). С помощью команды u можно проверить, являются ли корректными инструкции на этом участке памяти. В данном случае с ними все в порядке, но, если бы это было не так, это могло бы означать, что мы ошиблись при вычислении адреса.

Листинг 10.9. Поиск в объекте ядра функции для записи IRP_MJ_DEVICE_CONTROL

Теперь, получив адрес, мы можем либо загрузить драйвер в IDA Pro, либо создать для этой функции точку останова и продолжить ее анализ в WinDbg. Обычно проще начать исследовать функцию в IDA Pro и затем при необходимости продолжить дальнейший анализ в WinDbg. Просмотрев вывод IDA Pro для нашего зараженного драйвера, мы нашли код, представленный в листинге 10.10: он использует вызовы ZwCreateFile и ZwWriteFile для записи в файл из пространства ядра.

Листинг 10.10. Листинг кода для функции IRP_MJ_DEVICE_CONTROL

Вядре Windows используется структура UNICODE_STRING, которая отличается от строк с расширенными символами, традиционными для пользовательского пространства. Для создания строк в ядре применяется функция RtlInitUnicodeString .

Вкачестве второго параметра она принимает последовательность расширенных символов с NULL в конце, которая превращается в UNICODE_STRING.

Вфункцию ZwCreateFile передается имя файла \DosDevices\C:\secretfile.txt. Чтобы создать файл в режиме ядра, нужно указать полное имя объекта вместе с соответствующим корневым устройством. Для большинства устройств имя объекта начинается с \DosDevices.

DeviceIoControl — это не единственная функция, которая может передавать данные из пользовательского пространства в пространство ядра. То же самое можно делать с помощью вызовов CreateFile, ReadFile, WriteFile и т. д. Например, если пользовательское приложение делает вызов ReadFile для дескриптора устройства, ядро запускает функцию IRP_MJ_READ. В нашем примере мы нашли соответствие для запроса DeviceIoControl, добавив 0xe*4 в начало таблицы функции MajorFunction, поскольку IRP_MJ_DEVICE_CONTROL имеет значение 0xe. Чтобы найти функцию для запроса на чтение, в начало таблицы нужно добавить 0x3*4 вместо 0xe*4, потому что

IRP_MJ_READ равно 0x3.

Поиск объектов драйвера

В предыдущем примере мы увидели, как при запуске нашей вредоносной программы в пространство ядра загружается драйвер. Мы сделали вывод, что этот драйвер является зараженным. Иногда поиск объекта устройства вызывает трудности, но в таких случаях могут помочь определенные инструменты. Чтобы понять, как эти инструменты работают, нужно вспомнить, что пользовательские приложения взаи­ модействуют с устройствами, а не с драйверами. Вы можете идентифицировать объект устройства, находясь в пространстве пользователя, и затем с его помощью найти объект драйвера. Используя имя устройства, указанное в вызове CreateFile,