Пояснительная записка к Wizard template драйвера типа WDM (часть 3)

Глава 2. Что мы получаем.

п1. Чем полна наша коробочка.
Итак, запустили мастер в работу со всеми необходимыми настройками и получили проект, состоящий из 6-и файлов. Пусть имя проекта, заданное в командной строке мастера было FirstDrv, тогда проект будет содержать файлы:

* FirstDrv.c, FirstDrv.h соответственно, файл исходного кода и заголовка проекта, в которых, в дальнейшем, и будет содержаться исходный код драйвера режима ядра; фактически, только эти файлы и будут изменяться в ходе разработки проекта, а также другие, которые уже создадите Вы
* FirstDrv.dsw, FirstDrv.dsp - соответственно, файл рабочего пространства и файл проекта VS 6.0
* FirstDrv.rc ресурсный файл проекта; напомню, что этот файл нельзя открывать стандартным редактором ресурсов VS 6.0, т.к. он не может правильно обработать сложные макросы, и, поэтому, выдаст ошибку
* FirstDrv.ico этот файл не требует дополнительных комментариев


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

п1.1. Вот это стол на нем сидят, вот это стул на нем едят!
Выражаясь проще, взглянем же на данные нам природой возможности работать. А работать мы можем, опираясь на исходный код, который станет для нас базой, исходным пунктом в разработке.

Самое главное, в какие ворота идти. Посмотрим в проект и видим, что вход в драйвер имеет очень странное название DriverEntry, ну а если глянуть в настройки проекта, то можно заметить следующую запись: entry/DriverEntry@8. Именно последнее и указывает на то, что точкой входа является DriverEntry(), которая принимает в качестве входных параметров 8 байт, передаваемых ей через стек. Это точно отвечает прототипу DriverEntry(), объявленному в FirstDrv.c, а он требованиям к точке входа драйвера. Это и есть наши ворота.

Открываем настежь врата и идем по дороге из желтого кирпича прямо в Изумрудный город. А там мы найдем, что ничего особенного тут нет просто создание символьной связи, установка обработчиков на необходимые IRP и процедуры обработки подготовки к выгрузке драйвера.

Я считаю, что далее нет смысла что-либо объяснять, ибо сам код все скажет. Добавлю лишь одно: способ, который использован там для создания объекта-устройства не самый лучший и может быть заменен более универсальным, но и более сложным. Для этого вместо создания объекта-устройства в DriverInitialize() лучше создать обработчик pDriverObject->DriverExtension->AddDevice, хотя со мной можно поспорить.

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

На этом краткий обзор исходных файлов можно закончить. Дальше уже Вам предстоит решать какой код добавлять и что обрабатывать. К проекту можно добавлять файлы, удалять их из него, менять настройки (но я не советую этого делать) и вообще работать с ним как с обычным проектом VS 6.0. Дерзайте.

Дополнение. Контроль еще контроль!
Народная мудрость гласит: Семь раз отмерь, один - отрежь - это слышали практически все еще в детстве, но, как оказалось, древние опять правы. Нет, они не знали про ЭВМ, но основополагающие принципы понимали. Так к чему это я, казалось бы, а вот к чему. Дело в том, что нечто полученное в результате компиляции может оказаться чем угодно, но не драйвером. Все дело в том, что в самом файле содержаться некоторые флажки, указывающие на принадлежность его к элите драйверов. Из своего опыта знаю, что эти флажки и то, из каких секций состоит исполняемый модуль, крайне важно и отдельно оговорено в, я надеюсь, известном Вам PE формате. Кто-то скажет, что, мол, опять народ надувают, так нет есть способ проверить и это. Поэтому я рекомендую каждому проверять то, что у него получается и в какие секции исполняемого файла оно идет.

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

* В разделе IMAGE_OPTIONAL_HEADER (PE_ OPTIONAL_HEADER) поле Subsystem должно быть равным 1 (==NATIVE), означающее, что исполняемый файл не требует подсистемы для своего пользовательского интерфейса (т.е. скорее всего это драйвер)
* Должна обязательно присутствовать секция кода с именем INIT, и она не должна быть пустой.
* Желательно еще посмотреть и на флажки Magic(==0x010B) и Machine, последний должен содержать код типа процессора, который может исполнять этот файл (т.е. код типа Вашего процессора). Более подробно о формате PE можно посмотреть MSDN и/или книгу М. Питрека Секреты системного программирования в Windows 95.


Программ, выводящих такую информацию море, но для тех, у кого вообще ничего нет, могу предложить нечто подобное своего производства или PEview от Wayne J. Radburn.


Автор: lekarion