Hi OSR Community!
Before you help I want to warn you that this is not a commercial product but rather something
for my own purposes. So if you feel you need to explain too much to have me understand
writing a proper keyboard driver just tell me and I will stop asking.
But I intend not to attend to a OSR consulting or a seminary because I’m studying electrical engineering
and not driver writing. The following is just for hobby purposes and understanding Windows better:
I’m currently attempting to write a PROPER WDM model filter driver for the keyboard device type.
Hence, I’d like to not fall back to undocumented functions or fields such as
ObReferenceObjectByName and pDeviceObject->DeviceObjectExtension with its “Lower” or “Attached” device object fields.
My filter driver should be capable of detecting which device arrived
and should then automatically attach to any newly arrived device of the keyboard type.
In msdn I found a function IoRegisterPlugPlayNotification which seems to do exactly that.
The DEVICE_INTERFACE_CHANGE_NOTIFICATION contains a unicode string with the symbolic link name in it.
This symbolic link is then transformed into a usual device name by leveraging
ZwOpenSymbolicLinkObject and ZwQuerySymbolicLinkObject.
Now, I wanted to get an initial pointer to the corresponding device stack by
calling IoGetDeviceObjectPointer.
The problem is now, IoGetDeviceObjectPointer fails with NTSTATUS
STATUS_SHARING_VIOLATION if I specify ACCESS_MASK of both FILE_READ_DATA or even 0,
which is the lowest access I can imagine. A brief reversing showed that IoGetDeviceObjectPointer
calls the ZwOpenFile call in order to get a FILE_OBJECT pointer on which in turn IoGetRelatedDeviceObject is
called. However, I assume that the ZwOpenFile call fails because this call not just returns a handle to
a FILE_OBJECT (out of an imaginary FILE_OBJECT pool) but rather leads to an IRP_MJ_CREATE
being created which is then sent to the foreign device object to ask for consent! And likely,
the driver controlling the device object (in my case a HID USB device)
tells me something like “No! GTFO here, I already have a device, I will never let you obtain another pointer or handle!”
(exclusive access mode)
Hence, I am now stuck. How am I supposed to get a device object pointer
somewhere into the target device stack if I cannot open the device normally and if it cannot
use the ObReferenceObjectByHandle with a ObSymbolicLinkObjectType* type?
In order to make the attachment work I would need to convert the symbolic link or the derived
target name SOMEHOW into an arbitrary PDEVICE_OBJECT pointing somewhere into the current target
device stack, according to the current symbolic link target.
TL;DR
How do I correctly write a keyboard filter driver aware of devices arriving in the future if I cannot attach my device
using IoAttachDevice or IoGetDeviceObjectPointer & IoAttachDeviceByDeviceStackSafe, and if I cannot
obtain a pointer into the corresponding device stack to the supplied symbolic link?
The only chance I have is forcing the attach to work even if the keyboard filter denies,
in terms of temporarily patching its IRP_MJ_CREATE routine, so it
will no longer return STATUS_SHARING_VIOLATION, but since this is an extreme ugly hack I wished
there was a documented solution.
I wanted to peek into the “kbfiltr” example but couldn’t find the WDM version, but I am almost
certain that Microsoft spent a notification routine there…
Is there a documented way to get a DEVICE_OBJECT pointer without the corresponding driver’s consent?
Since I am in kernelland I should be able to do what I want and If I want to open any device object
for me there is no reason to block that 
If you think that I’m too unexperienced or too stupid, read the intro sentence…
It is just for me, you’re not going to give your knowledge away for then being
screwed by my better product! So no concurrence threat here.
Best Regards
Microwave89
P.S. Maybe you can also point me to some in your opinion valuable sources…