Статья ASM. Драйверы WDM (3) – Пример Legacy драйвера

Ознакомьтесь с предыдущими частями «Введение в IRQL» и «Объекты драйверов».
Пробежавшись по макушкам фундаментальных основ, пришло время заняться практикой. Начнём, пожалуй, с Legacy, которых и по сей день водится с избытком в современных ОС. Как упоминалось ранее, они отличаются от WDM тем, что не поддерживают технологию Plug&Play, хотя в остальном нисколько не уступают последним. Другими словами, Legacy требуют ручной установки, не дружат с программным управлением питания, ну и так по мелочам. На Win7 можно было в меню «Диспетчера устройств» выбрать «Показать скрытые», и получить увесистый их список. Но начиная с Win10 единую базу убрали, а девайсы распихали по соответствующим пунктам, спрятав от нас подальше. Таким образом тема не-PnP-драйверов актуальна, а потому стоит уделить ей внимание.


Обосновано-ли использование ассемблера для драйверов?
Несмотря на то, что львиная доля ядра Ntoskrnl.exe написана на чистом Си и плюсах, это всё-же языки высокого уровня. В системе достаточно мест, где они не смогут справиться с задачей по определению, например прямое взаимодействие с регистрами ЦП. Поэтому отдельные части диспетчера памяти и планировщика потоков написаны именно на ассме, где он и выражает себя в полной мере. Ну и конечно это размеры бинарей на выходе из компилятора, которые будут как-минимум в 2 раза меньше сишных. Но есть и минусы – отсутствует реализованный на стороне компилятора сборщик мусора, автоанализ ошибок, заголовки с описанием структур, и прочее.

Кстати, как утверждает руководитель отдела Azure в Microsoft М.Руссинович, начиная с Win11 разрабы отказываются уже и от сишки, в пользу самобытного языка Rust. Написанные на нём модули можно найти по суффиксу(_rs) в именах, например так:



В этой части:

1. Структура драйвера
2. Точка входа DriverEntry()
3. Базовые процедуры DispatchRoutine
4. Ожидание команд от юзера DeviceIoControl()
5. Выводы

---

1. Структура файлов *.sys

Формат двоичных файлов драйвера Win ничем не отличается от привычных нам исполняемых *.exe, поскольку у них один прародитель РЕ (Portable-Executable). Если вскрыть их в любом РЕ-вьювере, можно обнаружить те-же секции кода/данных/импорта/экспорта и прочих. Просто в поле «Subsystem» опционального заголовка выставляется флаг «Native=1».


Второй момент – это текстовые строки. Дело в том, что ядро понимает только Unicode, хотя бывают и редкие исключения (например теги в пулах памяти, или отладочные сообщения). В приложениях юзера ANSI-строки адресуются явно, а здесь нужно заворачивать их в структуру UNICODE_STRING, и передавать получателю адрес этой структуры:


В ядре имеются более 50 функций, которые ожидают в аргументах линки на данную структуру – найти их в отладчике можно по маске x nt!*UnicodeString*. Это сравнение строк, преобразование из Unicode в ANSI, или из текста в число, и многое другое. Но в данном случае нам понадобится лишь RtlInitUnicodeString(), которая заполнит поля структуры валидными значениями:


Ну и в третьих – это невыгружаемые в своп критически важные секции кода/данных, а у остальных иногда выставляется атрибут «Discardable» (не нужны после загрузки образа в память). Например релоки загрузчик использует для правки абсолютных адресов, а по окончании этого процесса к секции .reloc никто не обращается от слова совсем. Чтобы она не болталась без дела в памяти, её без последствий можно просто затереть новыми данными. Аналогичная ситуация и с секцией INIT, которая представляет собой запакованный архив – после анпака можно без зазрения совести отправить её в корзину.


На запрос !dh (dump header) отладчик сбрасывает в лог РЕ-заголовок файла, ожидая аргументом базу образа в памяти (см. lmsm), при этом ключ /f оставляет в логе только информацию о заголовке, /s только секции, а в дефолте (без ключей) и то и другое:



2. Точка входа DriverEntry()

Процедура DriverEntry() первой получает управление от диспетчера ввода-вывода.
Её код должен проделать следующие операции:

1. IoCreateDevice() – создать подчинённое устройство.
2. IoCreateSymbolicLink() – зарегистрировать устройство в пространстве имён, чтобы можно было найти его по имени.
3. В поле «DriverUnload» структуры DRIVER_OBJECT записать указатель на процедуру выгрузки драйвера из памяти.
4. В массив «IRP_MJ_xx» структуры DRIVER_OBJECT записать линки на процедуры обслуживания запросов на в/в (выборочно).
5. Если всё прошло успешно, в регистре EAX вернуть диспетчеру значение STATUS_SUCCESS=0.

Здесь нужно отметить, что только Legacy драйвера создают устройство прямо на точке-входе, а для WDM предусмотрена спец.процедура AddDevice() (рассмотрим в сл.части). Связано это с тем, что диспетчер PnP проверяет обязательное поле в структуре DRIVER_OBJECT. DriverExtension.AddDevice, где и должен лежать указатель на процедуру добавления устройства (создав, она сразу аттачит девайс в стек драйверов). Но сейчас мы во власти Legacy и драйвер у нас монолитный, а потому AddDevice() не нужна.


Поскольку DriverEntry() выполняется в контексте системного потока «System», она не должна занимать много времени, и проделав на одном дыхании 5 этих пунктов, тут-же отчитаться перед диспетчером. С этого момента ОС отправляет дров в пул неактивных потоков в наборе «WorkingSet», и он даже не попадает в очередь планировщика. То-есть наступает полный штиль, до прихода на его имя запроса IRP (io-request-packet).

У процедуры 2 аргумента: в первый диспетчер передаёт линк на созданную им где-то структуру DRIVER_OBJECT, а во второй – указатель на куст в реестре, куда дров может сохранить свои настройки (пока нам не нужен). Вот пример реализации сказанного:


Как видим нет ничего особенного – главное обзавестись инклудом с описанием полей в структурах, от чего я вас избавил прицепив его в скрепку к статье. Теперь если запустить утилиту WinObj из пакета «SysinternalsSuite» Руссиновича (у меня Explorer от Four-F), можно с удивлением обнаружить в ней наш девайс «Codeby». По этому имени позже мы сможем открыть его на чтение/запись юзер-функцией CreateFile().



3. Процедуры обслуживания запросов DispatchRoutine

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

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

За некоторым исключением, почти все процедуры принимают от диспетчера 2 аргумента – это указатель на структуру DEVICE_OBJECT устройства, а так-же указатель на пакет запроса IRP, который собственно и адресован драйверу. В последнем хранится буквально вся информация о запросе на ввод-вывод:


Прочитав поле CurrentStackLocation получим линк на одноимённую структуру, где можно найти запрашиваемые коды операций Major/Minor, и что более важно – это параметры текущего запроса. Для них выделяется блок размером в 32-байта, а содержимое блока напрямую зависит от одного из 28-ми кодов IRP_MJ_xx. В своей процедуре DriverEntry() я договорился с диспетчером, что буду обслуживать всего три базовых запроса Create/Close/IoControl, а потому меня будут интересовать только их параметры.


Самая простая (и важная) процедура из всех – это Unload().
Как и следует из её названия, она озадачена выгрузкой образа драйвера из системной памяти. Код процедуры должен отменить всё, что было проделано внутри DriverEntry(). Если в своём примере я создавал ссылку при помощи IoCreateSumbolicLink(), значит должен затереть её чз IoDeleteSumbolicLink(), и т.д.

Кстати помимо официального способа выгрузки драйверов (посредством регистрации процедуры Unload) есть ещё и топорный – просто возвращаем диспетчеру в/в STATUS_DEVICE_CONFIGURATION_ERROR=0xC0000182, и он сам правильно разрулит ситуацию. Обратите внимание, что все процедуры DispatchXX обязательно должны быть выровнены в памяти на границу 16-байт:


Здесь я планирую обрабатывать только запросы IRP_MJ_CREATE/CLOSE/CONTROL – это стандартный минимум для Legacy драйверов, хотя в WDM обязательны ещё POWER+PNP. Когда софт пользователя откроет девайс «Codeby» чз CreateFile(), диспетчер пошлёт IRP в наш коллбек MJ_CREATE, а у драйвера появится возможность отловить этот момент. Дальнейшие действия зависят уже от назначения и функциональных особенностей драйвера, я-же просто выведу мессагу DbgPrint(). Аналогично и с процедурой MJ_CLOSE, только она перехватывает юзерскую CloseHandle() при освобождении дескриптора устройства.

На выходе нужна функция IoCompleteRequest() – сигнал диспетчеру, что «в Багдаде всё спокойно» и мы успешно обработали запрос. В модели WDM её аргумент IO_NO_INCREMENT=0 указывает, до какого значения нужно поднять приоритет запроса IRQL следующему драйверу в стеке. Здесь мы передаём нуль, т.е. оставить прежний (возможные варианты см.в скрепке).


Если заглянуть сейчас во-вьювер «DeviceTree», он покажет паспорт нашего мини-драйвера, в том числе: базу загрузки образа, его размер в памяти, обрабатываемые коды IRP_MJ_xx, отсутствие процедуры AddDevice(), и факт его монолитности, поскольку ни к кому не приаттачен в стеке драйверов.



4. Ожидание команд от юзера DeviceIoControl()

И вот со скоростью черепахи мы добрались до основной процедуры драйвера CodebyControl() – я специально оставил её на дессерт. Она реагирует на вызов DeviceIoControl() юзера, и ожидает в аргументе код самой операции IOCTL. Этот красавец с мускулатурой бодибилдера способен на многое, и является основным интерфейсом для взаимодействия с драйверами из пользовательского режима. Вот прототип этой Win32-API:


После успешного вызова этой API, драйверу придёт такая инфа:


Особого внимания заслуживает здесь 32-битный код операции, который состоит аж из шести частей.
В старшей половине с битами [31:16] кодируется тип устройства, которому адресуется запрос. В системе зарегано 64 типа с константами FILE_DEVICE_xx. Если мы обращаемся к одному из них, то старший бит(31) в коде запроса должен быть сброшен (см.рис.ниже). Если-же это придуманный нами какой-то левый девайс, то соответственно бит нужно будет взвести. В данном случае, при создании устройства чз IoCreateDevice() я указал системную константу FILE_DEVICE_UNKNOWN=0х22, и соответственно обращаться к нему должен именно под этим ником в коде IOCTL.


Таким образом, чтобы обратиться к своему устройству «Codeby» из юзермоды, в аргументе DeviceIoControl() я должен указать IOCTL=0x00220004, что подразумевает DEVICE_UNKNOWN, неограниченные права ANY_ACCESS, код операции 0x01, и метод передачи BUFFERED. Иначе диспетчер в/в не сможет найти адресат, и в лучшем случае тупо проигнорирует наш запрос. Имейте в виду, что драйверы плохо относятся к самодеятельности и народному творчеству, а потому лучше всегда придерживаться общих правил на уровне каждого бита.


В своём коллбеке CodebyControl() и беру из структуры IO_STACK_LOCATION переданный мне юзером код операции, и по его значению могу выполнять различные задачи. В данном случае юзер посылает только 0x01, но если учитывать разрядность всего поля 11-бит, то получаем 2^11=2048 возможных вариантов. Текущее значение IRQL я беру здесь напрямую из структуры процессора PCR, хотя можно было вызвать функцию ядра KeGetCurrentIrql(). На системах х32 доступ к этой структуре открывает сегментный регистр fs, а на системах х64 регистр gs:


Собрав всё вместе получаем следующую картину где видно, что драйвер благополучно похукал вызовы всех Win32API на стороне юзера Create/IoControl/Close, после чего диспетчер выгрузил его тушку из системной памяти ядра. Обратите внимание на адрес пакета IRP 0x81e0b140 – в рамках трёх операций внутри одного процесса диспетчер не удаляет его, а тупо перезаписывает содержимое новыми данными.



5. Заключение

По некоторым причинам я проводил тесты на вирт.машине WinXP x32, хотя переделать исходник под х64 не составит особого труда. Тут главной целью было донести до читателя суть, а реализация уже дело второе. Позже рассмотрим организацию драйверов WDM, работу с памятью, и физическими устройствами, а пока интриги больше нет – расходимся. В скрепку положил пример для компиляции ассемблером FASM, инклуды с основными структурами ядра для х32/64, а так-же софт, который использовал в данной статье. Всем удачи, пока!