Драйвер имеет следующие точки входа:

§ DriverEntry

§ DriverUnload

§ AddDevice

§ Функции для обработки пакетов IRP

§ ISR

DiverEntry

Процедура DiverEntry должна присутствовать в любом драйвере. На данную процедуру возложена функция начальной инициализации и определение остальных точек входа в драйвер. Она выполняется в момент загрузки драйвера. В драйверах WDM значение этой функции значительно уменьшилось, большая часть работы возлагается на функцию AddDevice. Для регистрации точек входа в драйвер DriverEntry должна заполнить соответствующие поля в структуре объекта драйвера. Указатель на эту структуру передается в функцию.

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

Поле DriverExtension->AddDevice необходимо заполнить адресом процедуры AddDevice.

Массив MajorFunctions заполняется адресами процедур обработки IRP пакетов. Процедура, зарегистрированная под номером N, обрабатывает IRP пакет с кодом N. Обычно драйверы используют не все эти процедуры, а регистрируют только нужные. Остальные же элементы массива заполняются адресом процедуры, выполняющей передачу пакета ниже по стеку драйверов.

AddDevice

Данная функция регистрируется, если драйвер поддерживает PnP. Одна из главных обязанностей AddDevice - это создание объекта устройства FDO и если необходимо подключение его к стеку драйверов устройства. Данная функция может создать несколько объектов устройств и подключить их к разным стекам. Более того, некоторые устройства FDO могут существовать, не будучи в связке с PDO. Они часто содаются для управления драйвером.

DriverUnload

Процедура DriverUnload необходима для того, чтобы сделать драйвер выгружаемым. В драйверах «в стиле NT» на эту процедуру возложен весь процесс выгрузки. Она обязана удалить все символьные ссылки, все объекты устройств, отключить (если нужно) прерывания от объектов, очистить память за собой. В PnP драйверах все эти действия возложены на обработчик пакетов IRP_MJ_PNP.

Процедуры обработки пакетов IRP

Функции, адреса которых записаны в массиве MajorFunctions, вызываются диспетчером ввода / вывода для обработки соответствующих запросов от клиентского драйвера (пользовательских приложений или модулей уровня ядра). Эти запросы оформляются в виде специальных структур - IRP пакетов.

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

Заголовок IRP пакета:

§ Поле IoStatus типа IO_STATUS_BLOCK содержит два подполя

§ Status содержит значение, которое устанавливает драйвер после обработки пакета.

§ В Information чаще всего помещается число переданных или полученных байт.

§ Поле AssociatedIrp. SystemBuffer типа void* содержит указатель на системный буфер для случая если устройство поддерживает буферизованный ввод / вывод.

§ Поле MdlAddress типа PMDL содержит указатель на MDL список, если устройство поддерживает прямой ввод вывод.

§ Поле UserBuffer типа void* содержит адрес пользовательского буфера для ввода / вывода.

§ Типа Cancel типа BOOLEAN - это индикатор того, что пакет IRP должен быть аннулирован.

Стек IRP пакета

Основное значение ячеек стека IRP пакета состоит в том, чтобы хранить функциональный код и параметры запроса на ввод / вывод. Для запроса, который адресован драйверу самого нижнего уровня, соответствующий IRP пакет имеет только одну ячейку стека. Для запроса, который послан драйверу верхнего уровня, Диспетчер ввода / вывода создает пакет IRP с несколькими стековыми ячейками - по одной для каждого FDO.

Каждая ячейка стека IRP содержит:

§ MajorFunction типа UCHAR - это код, описывающий назначение операции

§ MinorFunction типа UCHAR - это код, описывающий суб-код операции

§ DeviceObject типа PDEVICE_OBJECT - это указатель на объект устройства, которому был адресован данный запрос IRP

§ FileObject типа PFILE_OBJECT - файловый объект для данного запроса

Диспетчер ввода / вывода использует поле MajorFunction для того, чтобы извлечь из массива MajorFunction нужную для обработки запроса процедуру.

Каждая процедура обработки IRP пакетов должна в качестве параметров иметь:

§ Указатель на объект устройства, для которого предназначен IRP запрос

§ Указатель на пакет IRP, описывающий этот запрос

Возвращает такая функция значение типа NTSTATUS, содержащее результат обработки.

Функция обработки пакетов IRP_MJ_DEVICE_CONTROL

Эти функции позволяют обрабатывать расширенные запросы от клиентов пользовательского режима. Такой запрос может быть сформирован посредством вызова функции DeviceIoControl. Каждый IOCTL запрос имеет свой код. Этот код передается как параметр функции DeviceIoControl. Код IOCTL - это 32_битное число.

Запросы IOCTL служат чаще всего для обмена данными между драйвером и приложением. Для передачи данных в Windows предусмотрены 4 способа

§ METHOD_BUFFERED

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

§ METHOD_IN_DIRECT и METHOD_OUT_DIRECT

Необходимые страницы пользовательского буфера загружаются с диска в оперативную память и блокируются. И с помощью DMA осуществляется передача данных между устройством и пользователем.

§ METHOD_NEITHER

При данном методе передачи не производится проверка доступности памяти, не выделяются промежуточные буфера и не создаются MDL. В пакете IRP передаются виртуальные адреса буферов в пространстве памяти инициатора запроса ввода / вывода.

Функция обработки пакетов IRP MJ READ

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

Функция обработки пакетов IRP MJ PNP

Данная функция должна обрабатывать запросы от менеджера PnP.

ISR

Данная точка входа вызовется при, когда произойдет прерывание, на которое зарегистрирована эта ISR функция. Вызов может произойти в любом контексте: как ядра, так и пользовательского процесса. Здесь драйвер может либо дожидаться следующего прерывания (с какой-либо целью), либо запросить отложенный вызов процедуры (Deferred Procedure Call), DPC

1.6 Анализ методов решения задачи

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

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

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

Формализация постановки задачи:

§ Необходимо написать драйвер-фильтр верхнего уровня для драйвера клавиатуры.

§ Драйвер-фильтр должен перехватывать IRP пакеты, содержащие скэнкоды нажатых и отпущенных клавиш, переопределять, если необходимо, скэнкоды на скэнкоды других клавиш. Он должен удалять записи, соответствующие отключенным клавишам.

§ Решение о том, какие клавиши должны быть переопределены или отключены, принимается в соответствии со списком замен, который хранится в памяти ядра.

§ Для установки списка замен используется пользовательское приложение, которое пересылает в драйвер список замен.

§ Драйвер должен быть драйвером PnP.

§ Драйвер-фильтр не должен тормозить ввод с клавиатуры и работу всей системы в целом. Драйвер-фильтр должен обеспечить надежную работу системы.

2. Конструкторский раздел

2.1 Точки входа разрабатываемого драйвера-фильтра

Поскольку разрабатываемый драйвер-фильтр является драйвером PnP, то должен иметь следующие точки входа:

§ DriverEntry

§ DriverUnload

§ AddDevice

§ Функции для обработки пакетов IRP

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

DiverEntry

В данной работе процедура DriverEntry выполняет следующие действия:

· Заполнение массива MajorFunctions. Регистрируется процедура обработки пакета на чтение, процедура обработки IOCTL запросов, процедуры обработки запросов от менеджера PnP и менеджера питания. Остальные элементы массива заполняются адресом функции MyPassNext, которая пропускает пакеты ниже по стеку.

· Регистрация процедуры AddDevice. В данной работе она называется MyAddDevice.

· Регистрация процедуры DriverUnload, называющейся MyUnload.

· Выделение памяти для хранения массива замен клавиш. Одна запись массива занимает 4 байта, а максимум может быть только 103 замены (клавиша Pause/Break не в счет). Значит максимальный объем массива равен 412 байт. DriverEntry сразу выделяет при загрузке эти 412 байт. Не имеет смысла экономить и выделять память динамически при каждой инициализации массива, поскольку 412 - это очень мало, и система не будет тратить время на освобождение и выделение памяти при каждой инициализации.

· Инициализация некоторых глобальных переменных: AltPressed, CtrlPressed, KeyPause.

DriverEntry регистрирует только необходимые процедуры. Поскольку проект представляет собой драйвер-фильтр верхнего уровня, и в нем нет необходимости обрабатывать прерывания, то не производится регистрация DriverStartIo, процедур ISR и DPC.

AddDevice

В данной работе функция MyAddDevice создает одно функциональное устройство с именем \\Device\\MyFilter. При создании устройства происходит резервирования места для хранения адреса устройства, расположенного ниже в стеке драйверов. Это сделано для того, чтобы при разрушении стека драйверов передать запрос PnP на демонтаж нижестоящему драйверу. Созданное устройство подключается к стеку драйверов клавиатуры. Это делается с помощью функции IoAttachDeviceToDeviceStack. Это стандартная функция Windows, она принимает PDO и указатель на структуру подключаемого FDO. FDO занимает место в стеке драйверов сразу после объекта, находящегося в вершине стека. Теперь подключаемый FDO становится вершиной стека. Нельзя подключится к стеку когда он уже сформирован, поэтому необходимо подключится к нему в определенный момент. Очередность загрузки драйверов описана в реестре Windows. Программа установки производит необходимую регистрацию. Структура этой программы описана ниже.

Для того чтобы пользовательское приложение смогло обратиться к драйверу (для загрузки в драйвер списка замен или для получения списка замен, которые драйвер осуществляет в данный момент) для FDO должно быть зарегистрировано DOS имя. Используя это имя приложение сможет послать драйверу IOCTL запрос. Для регистрации такого имени создается строка юникод со значением \\DosDevices\\MyFilter и применяется функция IoCreateSymbolicLink. Ее параметрами является только что созданная строка и имя FDO, которое обслуживает наш драйвер. Теперь \\DosDevices\\MyFilter - это DOS имя созданного FDO устройства.

Страницы: 1, 2, 3