буфер клавиш kbdclass

Будьте добры, подскажите, ПОЖАЛУЙСТА, где находятся скан-коды клавиш перед вызовом функции KeyboardClassRead?

 

Llirik
Обычно нигде они не находятся... я бы сказал, что в голове пользователя, но обычно он не в курсе кодов клавиш.
При вызове KeyboardClassRead возвращается STATUS_PENDING и IRP продолжает висеть до нажатия клавиши. После нажатия клавиши (пропуская генерацию и обработку прерывания и добавление обработчика в очередь DPC) либо kbdhid.sys либо i8042prt.sys уже на уровне DPC вызывает KeyboardClassServiceCallback, передавая ей указатель на структуру KEYBOARD_INPUT_DATA, которую KeyboardClassServiceCallback копирует в висящий IRP, после чего завершает его.

 

а как тогда перехватить KEYBOARD_INPUT_DATA до завершения IRP??

 

Llirik
Фильтр — классический метод. Смысла приводить ссылку на известную статью нет, т.к. Вы её уже читали.
По проблемам фильтра USB-клавиатуры подсказать не могу, т.к. не пробовал.

 

А я пробовал, не подключается к стеку USB-клавы. мало того. что делать если клавиатуры 2 или больше? к стеку каждой подключаться? замучаешься. вот я и ищу более универсальное решение

 

А это относится ко всем фильтрам, прописанным в параметре UpperFilters ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318} ?

 

Llirik
В процитированном посте нет ни одного слова о фильтрах. К фильтрам ничего из сказанного не относится. Речь шла только о функциях драйвера класса kbdclass.sys.

 

почему же тогда это не работает?

Код (Text):

1. FiDO_DispatchRead proc uses esi edi ebx pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP
2.     .if gggfSpy
3.      mov esi, pIrp
4.      assume esi:ptr _IRP
5.  
6.  
7.     .if [esi].IoStatus.Status == STATUS_SUCCESS
8.    
9.         mov edi, [esi].AssociatedIrp.SystemBuffer
10.         assume edi:ptr KEYBOARD_INPUT_DATA
11.        
12.         mov ebx, [esi].IoStatus.Information
13.    
14.  
15.         .while sdword ptr ebx >= sizeof KEYBOARD_INPUT_DATA
16.            
17.             ;.if [edi].MakeCode == 48h
18.             ;.IF [edi].Flags == 1
19.             ;.if KeyFlags == FALSE
20.             ;and KeyFlags, TRUE
21.             ;.else
22.             mov [edi].MakeCode, 48h
23.             ;and KeyFlags, FALSE
24.             ;.endif
25.             ;.endif
26.             ;.endif
27.             add edi, sizeof KEYBOARD_INPUT_DATA
28.             sub ebx, sizeof KEYBOARD_INPUT_DATA
29.         .endw
30.         assume edi:nothing     
31.  
32.     .endif
33.     .if [esi].PendingReturned
34.         IoMarkIrpPending esi
35.     .endif
36.  
37.     assume esi:nothing
38.  
39.     mov eax, STATUS_SUCCESS
40.  
41.  
42. .endif
43.      invoke FiDO_DispatchPassThrough, pDeviceObject, pIrp
44.     ret
45.  
46. FiDO_DispatchRead endp

 

Llirik
Наверное, по тем же причинам, по которым работает всё остальное, о чём я не говорил в том посте.

 

не понял. у меня теперь драйвер-фильтр

 

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

В общем, проверять статус IRP ещё до того, как его кто-либо мог обработать, бессмысленно. И даже если управление зайдёт внутрь первого условия, то установленный MakeCode всё равно будет перезаписан в момент завершения IRP процедурой KeyboardClassServiceCallback. Короче говоря, всё, что делает Ваш FiDO_DispatchRead, — это передаёт IRP дальше по стеку (и то только в случае, если FiDO_DispatchPassThrough не был так же грязно испохаблен).

 

и что же делать?

 

как перехватить нажитие клавиш?

 

Llirik
Вы статью, видимо, не очень-то внимательно читали. Там всё описано до мелочей. В приходящий IRP устанавливается процедура завершения, а потом уже IRP переправляется дальше в драйвер kbdclass.sys. И вот когда kbdclass.sys захочет завершить этот IRP... да ну что я буду статью перепечатывать. Читайте.

 

а причём здесь kbdclass.sys? я к нему теперь не подключаюсь)

 

Llirik
Ага. Вместо этого Вы рассчитываете на мой высокоточный хрустальный шар. И что же за IRP вы обрабатываете? Тот, который шлёт kbdhid.sys нижележащим драйверам из KbdHid_StartRead? Если да, сути это не меняет: нужно ставить свою процедуру завершения и ждать, пока hidclass.sys вызовет IopfCompleteRequest.

 

l_inc, так?

Код (Text):

1. ReadComplete proc uses esi edi ebx pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP, pContext:PVOID
2.  
3.     mov esi, pIrp
4.     assume esi:ptr _IRP
5.  
6.     .if [esi].IoStatus.Status == STATUS_SUCCESS
7.    
8.         mov edi, [esi].AssociatedIrp.SystemBuffer
9.         assume edi:ptr KEYBOARD_INPUT_DATA
10.        
11.         mov ebx, [esi].IoStatus.Information
12.  
13.         .while sdword ptr ebx >= sizeof KEYBOARD_INPUT_DATA
14.            
15.             movzx eax, [edi].MakeCode
16.             mov ScanCode, eax
17.  
18.             movzx eax, [edi].Flags
19.             mov KeyFlags, eax
20.            
21.             add edi, sizeof KEYBOARD_INPUT_DATA
22.             sub ebx, sizeof KEYBOARD_INPUT_DATA
23.         .endw
24.  
25.         assume edi:nothing     
26. ;   inc fScanCode  
27.     .endif
28.     .if [esi].PendingReturned
29.         IoMarkIrpPending esi
30.     .endif
31.  
32.     assume esi:nothing
33.  
34.     lock dec g_dwPendingRequests
35. call SetValueKey2
36.     mov eax, STATUS_SUCCESS
37.     ret
38.  
39. ReadComplete endp
40.  
41. ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
42. FiDO_DispatchRead proc pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP
43. ;   .if gggfSpy
44.         lock inc g_dwPendingRequests
45.  
46.     IoSetCompletionRoutine pIrp, ReadComplete, NULL, TRUE, TRUE, TRUE
47. ;;;  and gggfSpy, FALSE
48. ;.endif
49.          push pIrp
50.             push pDeviceObject
51.      call FiDO_DispatchPassThrough
52.     ret
53.  
54. FiDO_DispatchRead endp

Тоже неполучается(

 

Llirik
Вы так и не сказали, чьи IRP берёте.

 

Мой фильтр прописан в параметре UpperFilters ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}

 

Llirik
Да-да. Я понял, что ответ мне, но вопрос скорее не ко мне. Я не в курсе того, что происходит в реестре (пусть кто-нибудь другой отвечает ). В глаза бросается, что процедура завершения неверно устанавливается (следующий драйвер получит в стеке IRP ерунду), но вполне вероятно, что это далеко не единственная проблема.