Hello everyone,
I am new to the keyboard/ input stack.
I wanted to know whether the following are possible:
To capture data entered from the keyboard irrespective of the keyboard type (USB, PS/2 or virtual ) from a single keyboard filter driver?
To know the context of process. Basically i want to know the application (thread) to which this data will be sent?
Thank you.
Tushar.
yes, that is very easy. If you install the kbdfiltr example as a class filter example below kbdclass you will get data for each keyboard. You can optionally remove the PS2 specific IOCTL support, but it does no harm by staying in the driver
no, not possible at all. keyboard input is read by the raw input thread (RIT). The RIT then takes care of posting the data as windows messages to the correct thread.
Why do you need to know the app?
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, February 26, 2008 8:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Keyboard filter and process context
Hello everyone,
I am new to the keyboard/ input stack.
I wanted to know whether the following are possible:
To capture data entered from the keyboard irrespective of the keyboard type (USB, PS/2 or virtual ) from a single keyboard filter driver?
To know the context of process. Basically i want to know the application (thread) to which this data will be sent?
Thank you.
Tushar.
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
Thank you very much Doron.
Actually i want to provide a safe channel for some applications.
The objective is to encrypt an input (say i will change ‘a’ to ‘b’ etc. in the driver) and then decrypt it in the application.
In this way even if someone installs a key logger using SetWindowsHookEx, it would get the enrypted input.
Is there a way to do this stuff?
Thank you.
Tushar.
If you use the KMDF version of the kbdfiltr example it shows you how to create a device object that the application can open. You can use this device object as a direct channel to the application but note that this is a custom solution and the app must be aware of how to open this device. Also note that the application will be getting raw scan codes, not translated VKs, so the application will have more work to do to process the right input. Furthermore, if it has a UI and text boxes, it gets more complicated b/c you will then have to fabricate input messages to these controls.
Note that a km key logger will still be able to thwart what you are doing. If an app can set a global hook, I am pretty sure it can do a lot more to you. Also, if there is a UM key logger it means it is in process and it could still thwart what you are trying to do. It could hook any file io functions (ReadFile, WriteFile, DeviceIoControl, CreateFile) and still thwart your “encryption”.
In the end, I do not think you will get any type of security using this type of solution
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, February 26, 2008 9:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Keyboard filter and process context
Thank you very much Doron.
Actually i want to provide a safe channel for some applications.
The objective is to encrypt an input (say i will change ‘a’ to ‘b’ etc. in the driver) and then decrypt it in the application.
In this way even if someone installs a key logger using SetWindowsHookEx, it would get the enrypted input.
Is there a way to do this stuff?
Thank you.
Tushar.
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
wrote in message news:xxxxx@ntdev…
> 2. To know the context of process. Basically i want to know the
> application (thread) to which this data will be sent?
>
>
In usermode you generally can find out where keyboard data is going by using
GetFocus which gives the handle of the window that has keyboard input focus.
Before you can use that you may need a combination of GetForeGroundWIndow,
GetWindowThreadProcessId and AttachThreadInput.
I don’t know what you are doing but consider using a usermode hook such as
WH_KEYBOARD_LL. I believe this hook is a solution which registers itself
with the keyboard driver while WH_KEYBOARD and other solutions require to be
placed in DLL which get injected into other processes.
/Daniel
Provide an invisible keyboard for the application. The app must know of its
existence and use it. I would consider having the app create a keyboard on
the screen with random key locations each time it is used. Then the mouse
can click on the appropriate keys to provide the input. You would have to
make the shift key sticky so if it is pressed, it is remembered for the next
key press only. You might want to make the caps lock key make every key
uppercase or just put any valid special character as separate keys that have
no shifted counterparts.
wrote in message news:xxxxx@ntdev…
> Thank you very much Doron.
>
> Actually i want to provide a safe channel for some applications.
> The objective is to encrypt an input (say i will change ‘a’ to ‘b’ etc. in
> the driver) and then decrypt it in the application.
> In this way even if someone installs a key logger using SetWindowsHookEx,
> it would get the enrypted input.
>
> Is there a way to do this stuff?
>
> Thank you.
> Tushar.
>
wrote in message news:xxxxx@ntdev…
> In usermode you generally can find out where keyboard data is going by
> using GetFocus which gives the handle of the window that has keyboard
> input focus. Before you can use that you may need a combination of
> GetForeGroundWIndow, GetWindowThreadProcessId and AttachThreadInput.
>
I forgot to mention that AttachThreadInput only works only with windows and
threads on the current desktop so this may need more work.
/Daniel
> 2. To know the context of process. Basically i want to know the application
(thread) to which this data will be sent?
Impossible. This decision is made much later on much more upper layer.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> In this way even if someone installs a key logger using SetWindowsHookEx, it
would get the enrypted input.
And if the key logger uses a filter driver too?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com