What’s the actual difference between the 2? Mainly when it comes to each’s responsibility in the processing process
kbdclass - class driver for all keyboards. it implements the final service callback routine which takes the KEYBOARD_INPUT_DATA reported by the keyboard port driver and reports it to the win32 input thread.
kbdhid (not kbhidclass) - keyboard port driver which translates HID packets into KEYBOARD_INPUT_DATA. kbdhid is installed per instance.
> @Doron_Holan said: > kbdclass - class driver for all keyboards. it implements the final service callback routine which takes the KEYBOARD_INPUT_DATA reported by the keyboard port driver and reports it to the win32 input thread. > > kbdhid (not kbhidclass) - keyboard port driver which translates HID packets into KEYBOARD_INPUT_DATA. kbdhid is installed per instance. That makes sense! One more bit, is it the responsibility of the KeyboardClass driver to translate the make code to virtual key or is it the responsibility of the RIT?
the RIT translates the raw make codes into VKs and state. for instance, the caps key make code will go all the way up to the RIT and then the RIT will send the set LEDs IOCTL back down to the keyboard to toggle the keyboard LED.
1 Like
> @Doron_Holan said: > the RIT translates the raw make codes into VKs and state. for instance, the caps key make code will go all the way up to the RIT and then the RIT will send the set LEDs IOCTL back down to the keyboard to toggle the keyboard LED. Last one , the reason I was asking is I’m trying to implement a “keystroke scrambler” driver to protect our keystrokes from spyware the general idea is to encrypt the keystrokes as early as possible and decrypt them in the target protected application - since keyboard reads are initiated by the raw input thread is there a way to identify the original application that called GetMessage / trying to read keystrokes ? I mean, surely there is since tools like KeyScrambler that protect applications like chrome exist but I wonder how they such thing (encrypting keystrokes flowing to a specific application ) is possible 
Here we go again. If someone has enough access to your machine to intercept keystrokes at the kernel level, then it is already “game over”. It’s too late; there is nothing you can do. Whatever you do, they can undo, and they have already read your hard disk.
And no, it is not possible to identify in advance which keystrokes will go to which application. You are assuming a “pull” model – that nothing happens until the application does a read. That’s backwards. Keystrokes come in and get queued up in the input system. When there’s a read, it pops from the input queue, possibly quite a bit later.
More malware. If the application can use the characters entered via the keyboard, they must exist in its memory. The barrier to reading the values in an application running under the same security context is not high - it happens all the time when you use the clipboard. And if the user has permission to use the debug APIs or load code into the kernel, even fewer barriers exist
The same thing applies to logging the keystrokes after ‘decryption’.
the general idea is to encrypt the keystrokes as early as possible and decrypt them in the target protected application - since keyboard reads are initiated by the raw input thread is there a way to identify the original application that called GetMessage / trying to read keystrokes ? I mean, surely there is since tools like KeyScrambler that protect applications like chrome exist but I wonder how they such thing (encrypting keystrokes flowing to a specific application ) is possible
You didn’t read what I wrote. I will repeat. You are assuming that the system uses a “pull” model – that nothing happens until GetMessage forces the layers below it to act. That is exactly backwards. Keystrokes are pushed up by the keyboards when the keys are pressed. They get shoved upward and are queued up in a “pool” in the input system. GetMessage just pulls whatever is next from that pool. There is absolutely no connection between a keystroke arriving and GetMessage reading, and they don’t even have to happen in that order.
Even if you could figure out where the keystrokes eventually go, how exactly could encryption work in this case? IIRC keyboard scan codes are 16 bit numbers, there is no way to know when the user will press the next key, and they are time critical to deliver (within a few milliseconds), so what sort of encryption can be applied? None of the block encryption algorithms can work with data this small, and no stream algorithm is considered to be secure. That would imply some scheme where the scan code is replaced with a value not directly related to the key itself, but contains information on where to find the true value - index in an array, magic number etc. along with some other call like ReadFile. You can choose a very complex scheme, but eventually the real value has to end up in the process memory so it can be used. So anyone who has a debugger and enough time on their hands can defeat your scheme.
However you slice this, it is malware that provides only an illusion of protection. Because you can’t use this for anything but malware, I won’t tell you how to solve the problem you asked about - finding the destination for a keystroke - but if you really want to figure this out, everything you need to know is in the GDI documentation on MSDN
the general idea is to encrypt the keystrokes as early as possible and decrypt them in the target protected application - since keyboard reads are initiated by the raw input thread is there a way to identify the original application that called GetMessage / trying to read keystrokes ? I mean, surely there is since tools like KeyScrambler that protect applications like chrome exist but I wonder how they such thing (encrypting keystrokes flowing to a specific application ) is possible
9apps apk