Как подключить драйвер к стеку устройств?

Я новичок в написании драйверов, пробую научиться писать драйвер фильтр. Взял пример из DDK \src\general\toaster\filter - по принципу - самый простой. Не могу понять как драйвер определяет к какому PDO он подключается?

 

IoGetDeviceObjectPointer вернет верхний элемент стека для нужного девайса. IoAttachDevice или IoAttachDeviceToDeviceStack подключаются к нему.
Из DDK:

Или можешь подключиться вручную в любое место стека с помощью корректировки AttachedDevice и DeviceObjectExtension->AttachedTo, но это уже дебри и не для новичков.

 

Это понятно, но как узнать верхний элемент КАКОГО СТЕКА получать? IoGetDeviceObjectPointe что ей передавать?

 

PUNICODE_STRING с именем девайса, чью вершину стека мы хотим получить

 

Сначала в систему устанавливается toaster\bus посредством запуска toaster\inf\bus.inf или Панель управления -> Установка оборудования. Он создает виртуальную шину, а сам является так называемым перечислителем (enumerator). Садится в корень PnP-дерева.

toaster\inf\bus.inf
[Models]
"Toaster Bus Enumerator"=ToasterBus_Inst, root\busenum

Когда к нему приходит IOCTL_BUSENUM_PLUGIN_HARDWARE (из toaster\exe\enum), он имитирует, что в его шину воткнули новый девайс, создает для него PDO и говорит PnP менеджеру, что у него на шине произошли изменения.

IoInvalidateDeviceRelations( ..., BusRelations );

PnP менеджер начинает шустрить в поисках драйвера, который должен рулить этим девайсом и находит toaster\func, если его inf уже был установлен или дергает пользователя, чтоб он ему указал нужный inf.

А фильтр садится в стек если были использованы toaster\inf\toasterf.inf или связка toaster\inf\toaster.inf + toaster\inf\filter.inf, т.к. в этом случае он прописывается в реестре фильтром и PnP менеджер это увидит.

Т.е. фильтр пассивен он просто ждет, когда PnP менеджер его загрузит и вызовет его AddDevice процедуру, где он и получит указатель на PDO.

 

Four-F

Уф... Допустим=)... А если вместо Toaster Bus я хочу использовать USB, как мне исправить данный пример из DDK?

 

Тогда тебе лучше взять другой пример из DDK src\wdm\usb\filter

 

Я посмотрел src\wdm\usb\filter.

NTSTATUS DriverEntry(
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath - Как формируется эта строка?
)
...
NTSTATUS VA_AddDevice(
IN PDRIVER_OBJECT driverObj,
IN PDEVICE_OBJECT physicalDevObj - Откуда берется этот *PDO?
)
Т.е. мне не понятно, как драйвер определяет что он подключается к PDO USBbus?

 

Отличный вопрос Я бы сам не отказался поиметь исходник драйвера, реализующего виртуальную USB шину. Тут курить, курить и курить...

 

- к сожалению я не курю=) и хочу разобраться в этом вопросе...

- может я не верно выразился...
Есть некое устройство, подключаемое по USB, мне надо реализовать драйвер перехватывающий пакеты DeviceIOControl и сказать пользователю: "я их поймал"=)...

 

Замени DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] на свой и обрабатывай, потом передавай управление оригинальному.

 

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

На ntdev.h1.ru был пример NDIS файрвола на основе фильтрации IRP пакетов с помощью перехвата точек входа в MajorFunction.

 

Да никак он не определяет! Это не его забота. PnP менеджер его грузит и дает ему этот самый PDO. Перечитай ещё раз мой первый пост в этом топике.

 

mohito
К твоему фильтру прийдут IRP того устройства (или класса устройств), на которое он (твой драйвер) установлен как фильтр. На что ему ставиться - как раз и указывается в inf файле (или посредством SetupAPI - "ручками" ставишь туда, куда хочешь, в зависимости от условий конкретной задачи).
Вроде так.
Надеюсь - поможет.
Удачи!

 

ksu_ant - огромное спасибо, именно твой пост внес ясность в мой маленький мозг=)

Four-F - так же спасибо за ответы... просто видимо с высоты твоего опыта, не заметны те маленькие проблемы которые могут возникать у начинающих и ставить их в тупик...

Остальным тоже СПАСИБО=)

 

А чем собственно не устраивает вариант с заменой DispatchControl обработчика?

Параллельно вопрос: в чем разница между перехватом пакетов через подмену DriverObject->MajorFunction[IRP_MJ_XXX] и IoAttachDevice?

 

Не устраивает тем, что надо написать драйвер фильтр.
чем разница между перехватом пакетов через подмену DriverObject->MajorFunction[IRP_MJ_XXX] и IoAttachDevice?
Разница хотя бы в том, что в первом случае необходимо модифицировать код чужого драйвера, а это не законно.

 

Разница хотя бы в том, что в первом случае необходимо модифицировать код чужого драйвера, а это не законно
О чем ты? ничего не надо модифицировать и тем более творить что-то незаконное. Достаточно сделать так:

Код (Text):

1. IoGetDeviceObjectPointer(&deviceName, FILE_READ_ATTRIBUTES, &fileObject, &deviceObject);
2. driverObject = (PDRIVER_OBJECT)deviceObject->DriverObject;
3. OriginalRoutine = driverObject->MajorFunction[IRP_MJ_XXX];
4. driverObject->MajorFunction[IRP_MJ_XXX] = FilterRoutine;
5. ObDereferenceObject(fileObject);

 

А мой вопрос состоит в следующем: насколько я понимаю IoGetDeviceObjectPointer вернет верхнее устройство из стэка, и IoAttachDevice также цепляет к верхнему устройству, так в чем тогда разница?

 

ни в чем.