I want to read from my Keyboard-Input-Device (Win32 Device Namespaces, \\.\). How can I decide which device is responsible for my keyboard. I can browse the available devices with the tool WinObj but I can not decide which device is the correct one.
I found an example where the device for input can be read/open with the function C++ function CreateFile("\\\\.\\interception00", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL).
On my PC there is no interception-device aviable. I looked with WinObj on an other PC and there were 20 interception-devices aviable. Why are these interception-devices not aviable on my PC ?
I'm not sure that you can read the keyboard input with "CreateFile()", I've never tried to anyway. But to get the DeviceID of your keyboard programmatically you would want to query the 'Win32_Keyboard' class with the "IWbemServices::GetObject()" method. I'm on a Mac right now, or I would happily give you an example of how to do this.
to store the device ID in your clipboard and make it a lot easier to paste statically in your code. This is so that you can focus on one thing at a time. COM+ has something of a learning curve so if you don't know it then I'd say come back to it later.
There are the advantages of this solution over the SetWindowsHookEx()-solution listed. It seems to me that the interception-API is the way to go because it meets all my requirements.
But, like in the first post described, I can't find any interception-devices on my PC so I need to read from an alternative device. But which one ???
Your answer is right there in the GitHub ReadMe that the author linked to:
TFA wrote:
Drivers can be installed through the command line installer, but driver installation requires execution inside a prompt with administrative rights.
Run install-interception without any arguments inside an console executed as administrator and it will give instructions for installation.
So the interception devices are driver interfaces. If you don't see them on your machine it's because you haven't installed those drivers. I'm still not sure how the author managed to sign these drivers. But in case he's just full of hot air, or his exploit was patched\certificate revoked, you can still play around with this by putting your VM, and I STRONGLY suggest ONLY loading unsupported kernel mode drivers like this in a VM, in debug mode with bcdedit /bootdebug : https://msdn.microsoft.com/en-us/library/windows/hardware/ff542205(v=vs.85).aspx