The eternal kbfiltr question

Hello all, I’m pretty much a beginner in Windows kernel programming, but
I’ve inherited the work of someone who just left the company, and I’ve been
working on it for a couple weeks, reading the windows internals books etc
but now am still stuck, so I have to ask the kind of questions which I know
you get asked all the time, but which none of the answers worked for me.

The code in question was an old-style keyboard filter driver which used
IoAttachDevice. It was never that great apparently, because it
apparently assumed that the keyboard was on KeyboardClass0. I was tasked
with updating it to make it work for Vista and for for USB devices. Now if
you can just humor me for a second, my first question is that I looked at my
physical Vista system with devicetree.exe and it implied that the USB
keyboard is on KeyboardClass1 (because that was associated with kbdhid).
When I run the old code, it will attach to KeyboardClass0 just fine, but not
actually see any callbacks as it does on a PS2 system. But if I change the
code to attach to KeyboardClass1, IoAttachDevice returns 0xc0000043 =
STATUS_SHARING_VIOLATION. I have googled around and have NO idea how I could
possibly get around that error. Since like I said I’m new to kernel
programming, I would like to modify as little code as possible so that I
don’t break something, so I’m wondering if anyone has any thoughts on how to
get around such an error?

Now, that said, it seems like everyone who asks such a question is just
told, use kbfiltr! OK, I guess I could port the callback code into kbfiltr,
but I’m even having troubles with that. I have the 7600 build of the DDK,
and all I changed before compiling was adding some DbgPrints to _IsrHook and
_ServiceCallback. I compile it, I install it (in a VM with a PS2 keyboard)by
manually navigating to the keyboard in Device Manager, and it seems to
install OK. I then reboot, attach WinDbg to the VM, make sure I set the mask
to allow me to see all DbgPrint messages. And I do see other DbgPrint
messages from kbfiltr, but no per-keystroke prints from _IsrHook or
_ServiceCallback. This is pretty crazy to me, because I had previously used
the WDM version of the kbfiltr code which is in the 6001 DDK, and it printed
out stuff on a per-keystroke basis when I did the exact same steps. The only
thing different as far as I can tell is that now the thing in
src/input/kbfiltr is the WDF version, and the WDM version isn’t anywhere in
the DDK. So it’s crazy that an out of the box, basically unmodified kbfiltr
from the new DDK would not work on a PS2 keyboard (I haven’t even tried on
the physical system yet). So I’ve got to be doing something wrong. Anyone
have any ideas? I tried manually adding “kbfiltr” before “kbdclass” in the
UpperFilters registry key in the documentation too, but that just makes me
lose keyboard access when I reboot the VM :frowning:

(And if anyone wants to preempt my next question, even if I get it working
on PS2, will it work on USB? It seems to imply it will, but the
documentation says you “may” remove the PS2 functionality to get USB
support, but it’s not clear if you *have* to remove the PS2 callbacks like
the ISR hook, or if you can just leave them in there as deadcode in a USB
deployment so that you can have a single device which works with both PS2
and USB.)

Thank you all.

Arkady Rossovich

Will we regret if we help you? Is this yet another keylogging trojan? :slight_smile:
–pa

“Arkady Rossovich” wrote in message
news:xxxxx@ntdev…
> Hello all, I’m pretty much a beginner in Windows kernel programming, but
> I’ve inherited the work of someone who just left the company, and I’ve
> been
> working on it for a couple weeks, reading the windows internals books etc
> but now am still stuck, so I have to ask the kind of questions which I
> know
> you get asked all the time, but which none of the answers worked for me.
>
> The code in question was an old-style keyboard filter driver which used
> IoAttachDevice. It was never that great apparently, because it
> apparently assumed that the keyboard was on KeyboardClass0. I was tasked
> with updating it to make it work for Vista and for for USB devices. Now if
> you can just humor me for a second, my first question is that I looked at
> my
> physical Vista system with devicetree.exe and it implied that the USB
> keyboard is on KeyboardClass1 (because that was associated with kbdhid).
> When I run the old code, it will attach to KeyboardClass0 just fine, but
> not
> actually see any callbacks as it does on a PS2 system. But if I change the
> code to attach to KeyboardClass1, IoAttachDevice returns 0xc0000043 =
> STATUS_SHARING_VIOLATION. I have googled around and have NO idea how I
> could
> possibly get around that error. Since like I said I’m new to kernel
> programming, I would like to modify as little code as possible so that I
> don’t break something, so I’m wondering if anyone has any thoughts on how
> to
> get around such an error?
>
>
> Now, that said, it seems like everyone who asks such a question is just
> told, use kbfiltr! OK, I guess I could port the callback code into
> kbfiltr,
> but I’m even having troubles with that. I have the 7600 build of the DDK,
> and all I changed before compiling was adding some DbgPrints to _IsrHook
> and
> _ServiceCallback. I compile it, I install it (in a VM with a PS2
> keyboard)by
> manually navigating to the keyboard in Device Manager, and it seems to
> install OK. I then reboot, attach WinDbg to the VM, make sure I set the
> mask
> to allow me to see all DbgPrint messages. And I do see other DbgPrint
> messages from kbfiltr, but no per-keystroke prints from _IsrHook or
> _ServiceCallback. This is pretty crazy to me, because I had previously
> used
> the WDM version of the kbfiltr code which is in the 6001 DDK, and it
> printed
> out stuff on a per-keystroke basis when I did the exact same steps. The
> only
> thing different as far as I can tell is that now the thing in
> src/input/kbfiltr is the WDF version, and the WDM version isn’t anywhere
> in
> the DDK. So it’s crazy that an out of the box, basically unmodified
> kbfiltr
> from the new DDK would not work on a PS2 keyboard (I haven’t even tried on
> the physical system yet). So I’ve got to be doing something wrong. Anyone
> have any ideas? I tried manually adding “kbfiltr” before “kbdclass” in the
> UpperFilters registry key in the documentation too, but that just makes me
> lose keyboard access when I reboot the VM :frowning:
>
> (And if anyone wants to preempt my next question, even if I get it working
> on PS2, will it work on USB? It seems to imply it will, but the
> documentation says you “may” remove the PS2 functionality to get USB
> support, but it’s not clear if you have to remove the PS2 callbacks like
> the ISR hook, or if you can just leave them in there as deadcode in a USB
> deployment so that you can have a single device which works with both PS2
> and USB.)
>
> Thank you all.
>
> Arkady Rossovich
>

you are probably getting STATUS_SHARING_VIOLATION only for usb HIDs because kbdclass sends the creates down the stack and the hidclass driver atually enforces file sharing semantics based on the requested access. since the keyboard is already opened by the RIT for READ access, your call to IoAttachDevice will also ask for read access and fail. this works for ps2 b/c the drivers below kbdclass do not enforce file sharing semantics.

as for _IsrHook and _ServiceCAllback, have you put a breakpoint on them to make sure that they are being called and that you are in the ps2 stack for that instance of your driver? these callbacks do not apply to the HID stack. BUT these callbacks are set in the stack the ps2 driver starts. IoAttachDevice when you are not a pnp filter is well after start.

what it boils down to is this: if you want to support usb HIDs (or any other bus HIDs like bluetooth), you need to be a class upper filter driver and handle pnp. you cannot be a legacy driver which attaches to stacks by name.

d


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Arkady Rossovich [xxxxx@gmail.com]
Sent: Wednesday, September 23, 2009 4:20 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] The eternal kbfiltr question

Hello all, I’m pretty much a beginner in Windows kernel programming, but I’ve inherited the work of someone who just left the company, and I’ve been working on it for a couple weeks, reading the windows internals books etc but now am still stuck, so I have to ask the kind of questions which I know you get asked all the time, but which none of the answers worked for me.

The code in question was an old-style keyboard filter driver which used IoAttachDevice. It was never that great apparently, because it apparently assumed that the keyboard was on KeyboardClass0. I was tasked with updating it to make it work for Vista and for for USB devices. Now if you can just humor me for a second, my first question is that I looked at my physical Vista system with devicetree.exe and it implied that the USB keyboard is on KeyboardClass1 (because that was associated with kbdhid). When I run the old code, it will attach to KeyboardClass0 just fine, but not actually see any callbacks as it does on a PS2 system. But if I change the code to attach to KeyboardClass1, IoAttachDevice returns 0xc0000043 = STATUS_SHARING_VIOLATION. I have googled around and have NO idea how I could possibly get around that error. Since like I said I’m new to kernel programming, I would like to modify as little code as possible so that I don’t break something, so I’m wondering if anyone has any thoughts on how to get around such an error?

Now, that said, it seems like everyone who asks such a question is just told, use kbfiltr! OK, I guess I could port the callback code into kbfiltr, but I’m even having troubles with that. I have the 7600 build of the DDK, and all I changed before compiling was adding some DbgPrints to _IsrHook and _ServiceCallback. I compile it, I install it (in a VM with a PS2 keyboard)by manually navigating to the keyboard in Device Manager, and it seems to install OK. I then reboot, attach WinDbg to the VM, make sure I set the mask to allow me to see all DbgPrint messages. And I do see other DbgPrint messages from kbfiltr, but no per-keystroke prints from _IsrHook or _ServiceCallback. This is pretty crazy to me, because I had previously used the WDM version of the kbfiltr code which is in the 6001 DDK, and it printed out stuff on a per-keystroke basis when I did the exact same steps. The only thing different as far as I can tell is that now the thing in src/input/kbfiltr is the WDF version, and the WDM version isn’t anywhere in the DDK. So it’s crazy that an out of the box, basically unmodified kbfiltr from the new DDK would not work on a PS2 keyboard (I haven’t even tried on the physical system yet). So I’ve got to be doing something wrong. Anyone have any ideas? I tried manually adding “kbfiltr” before “kbdclass” in the UpperFilters registry key in the documentation too, but that just makes me lose keyboard access when I reboot the VM :frowning:

(And if anyone wants to preempt my next question, even if I get it working on PS2, will it work on USB? It seems to imply it will, but the documentation says you “may” remove the PS2 functionality to get USB support, but it’s not clear if you *have* to remove the PS2 callbacks like the ISR hook, or if you can just leave them in there as deadcode in a USB deployment so that you can have a single device which works with both PS2 and USB.)

Thank you all.

Arkady Rossovich
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer