Kernelmode драйвер имитации дёргания мышкой и клавиатурой

Я так и думал, что не будет. Поэтому и хочу создать виртуальную мышь

Если бы Вы читали статью Four-F`а про фильтр, то знали бы, что у Kbdhid.sys нет функции обрабатывающей запрос IRP_MJ_CREATE, поэтому и не удаётся подключиться к USB стеку

 

mcbain
Вся суть в следующем пруфкоде:

Код (Text):

1. DEVICE_TEMPLATE aDeviceTemplate[DEVICE_TYPE_MAX + 1] = {
2.     // DEVICE_TYPE_MOUSE
3.     {
4.         sizeof(GENERIC_DEVICE_INFO)+sizeof(MOUSE_DEVICE_INFO),    // cbDeviceInfo
5.         &GUID_CLASS_MOUSE,                                        // pClassGUID
6.         PMAP_MOUCLASS_PARAMS,                                     // uiRegistrySection
7.         L"mouclass",                                              // pwszClassName
8.         DD_MOUSE_DEVICE_NAME_U L"0",                              // pwszDefDevName
9.         DD_MOUSE_DEVICE_NAME_U L"Legacy0",                        // pwszLegacyDevName
10.         IOCTL_MOUSE_QUERY_ATTRIBUTES,                             // IOCTL_Attr
11.         FIELD_OFFSET(DEVICEINFO, mouse.Attr),                     // offAttr
12.         sizeof((PDEVICEINFO)NULL)->mouse.Attr,                    // cbAttr
13.         FIELD_OFFSET(DEVICEINFO, mouse.Data),                     // offData
14.         sizeof((PDEVICEINFO)NULL)->mouse.Data,                    // cbData
15.         ProcessMouseInput,                                        // Reader routine
16.         NULL                                                      // pkeHidChange
17.     },
18.     // DEVICE_TYPE_KEYBOARD
19.     {
20.         sizeof(GENERIC_DEVICE_INFO)+sizeof(KEYBOARD_DEVICE_INFO), // cbDeviceInfo
21.         &GUID_CLASS_KEYBOARD,                                     // pClassGUID
22.         PMAP_KBDCLASS_PARAMS,                                     // uiRegistrySection
23.         L"kbdclass",                                              // pwszClassName
24.         DD_KEYBOARD_DEVICE_NAME_U L"0",                           // pwszDefDevName
25.         DD_KEYBOARD_DEVICE_NAME_U L"Legacy0",                     // pwszLegacyDevName
26.         IOCTL_KEYBOARD_QUERY_ATTRIBUTES,                          // IOCTL_Attr
27.         FIELD_OFFSET(DEVICEINFO, keyboard.Attr),                  // offAttr
28.         sizeof((PDEVICEINFO)NULL)->keyboard.Attr,                 // cbAttr
29.         FIELD_OFFSET(DEVICEINFO, keyboard.Data),                  // offData
30.         sizeof((PDEVICEINFO)NULL)->keyboard.Data,                 // cbData
31.         ProcessKeyboardInput,                                     // Reader routine
32.         NULL                                                      // pkeHidChange
33.     },
34.     // Add new input device type template here
35. };

 

Да, я вообще редко читаю чьи-то статьи. Эта?

Если речь идёт о WDM-фильтре, то Create не нужен, т.к. аттач будет в AddDevice(), главное установиться правильно в реестре, а если про legacy-фильтр, то во-первых, получить адрес девайсов классового драйвера можно и по-другому (пусть и не очень документировано), во-вторых там в статье никакой конкретики нет, кроме той, что якобы какая-то проблема с sharing, которая, возможно, решается использованием IoCreateFile() с правильными флагами.

 

x64, Во первых, я сам когда-то открывал Kbdhid.sys в IDA и к своему удивлению не нашел ни одной функции диспетчеризации. Во вторых, где Вы собираетесь прописывать его в реестре? если там где и Kbdclass прописан, то какие IRP_MJ_READ Вы собираетесь там ловить?)

 

Вроде уже со всем разобрался, пытаюсь выполнить всё примерно по схеме №1 из поста #7.

Но такой вопрос: что конкретно заставляет классовые драйверы мыши и клавиатуры посылать IOCTL_INTERNAL_MOUSE_CONNECT (и т.д. для клавиатуры) функциональному драйверу? Как оно узнаёт что появился новый драйвер котороый может обрабатывать этот запрос?

Просто создать устройство FILE_DEVICE_MOUSE по ходу недостаточно...

 

Она есть и называется KbdHid_Create(), смотри внимательнее. Так или иначе, в документации сказано, что CSR открывает драйвер порта (вероятно, имеется в виду через девайсы классового драйвера) в эксклюзивном режиме, так что таки да, скорее всего, чтобы получить указатель непосредственно на девайсы классового драйвера, придётся воспользоваться недокументированными методами. Хотя можно попробовать использовать для этих целей IoGetDeviceInterfaces(), но боюсь что это возможно только уже после загрузки классового драйвера, иначе пройдясь по цепочке вверх от PDO мы всё равно не найдём его девайсов, если будем действовать слишком рано.

Да, верно, туплю, WDM-фильтр имелся в виду который на драйвера портов вешается, как и классовый драйвер, и с этим вариантом вообще никаких проблем нет, тем более, что по документации только он и возможен. Кстати, а какие такие особенные преимущества-то даёт вариант с аттачем к классовому драйверу вместо портового? Что-то я не догоняю.

 

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

 

Уже пытался, единственное что нашёл это

Код (Text):

1. NTSTATUS
2. MouseAddDeviceEx(
3.     IN PDEVICE_EXTENSION    ClassData,
4.     __in PWSTR               FullClassName,
5.     IN PFILE_OBJECT         File
6.     )
7.  /*++ Description:
8.   *
9.   * Called whenever the Mouse Class driver is loaded to control a device.
10.   *
11.   * Two possible reasons.
12.   * 1) Plug and Play found a PNP enumerated Mouse.
13.   * 2) Driver Entry found this device via old crusty legacy reasons.

Теперь непонятно как программно сделать чтобы PnP нашёл новую мышку...

Если всё-таки строго следовать первому вариануе который написал x64, то как мне наилучшим способом найти первый (ну или любой) функциональный драйвер мышы/клавы чтобы к нему подключиться в стек?

Ну и теперь самое интересное - есть ещё один очень грязный способ это сделать - просто тупо взять и скопировать функцию VOID MouseClassServiceCallback в свой драйвер (благо исходники лежат открыто и документированы) и вызывать её давая ей нужный DEVICE_OBJECT. Ведь вся информация лежит в Device Extension, и по идее совершенно неважно, где находится функция с ним работающая, в настоящем mouclass.c или в моём драйвере... Осталось точно проверить что формат структуры DEVICE_EXTENSION оди и тот же в разных версиях винды, чтобы моя фейковая функция смогла с ним работать. (но по ходу так и есть, это драйвер вроде уже 10 лет не менялся, но надо тестить) никто так не делал?


klzlk,

Ничего не понял, это что?

 

Mika0x65
Получилось исправить ошибку? Я сделал примерно также, натаскал по кусочкам из твоего кода и разных других статей, вроде всё правильно, а всё равно, либо вылетает, либо BSOD

Вроде бы ошибка в том как написаны процедуры обработки MajorFunction.
Я пробовал так: не обрабатывал вообще никакие кроме Default, и её обрабатывал в ответ на каждый запрос. Пробовал делать как у тебя и ещё экспериментрировать с тем что в ней писать, всё равно либо вылетает либо зависает. NextLowerDevice никогда не NULL, это проверял...

 

mcbain
Не, я пока отложил, может завтра займусь. А насчет вылетов -- трудно так сказать, надо код видеть. И коды BSoD'ов с minidump'ами.

 

Если кому-то интересно, пока я проверил, что mouclass!MouseClassRead успешно вызывается и выполняется, когда мой драйвер загружен. Почему не приходят нажатия пока не ясно...

 

mcbain можете выложить получившийся у вас код для имитации нажатия мыши из ехе? очень нужно