Re: Hooking Keyboard

The standard (and correct) method is to register a system-wide hotkey using
"RegisterHotKey". This allows the system to handle the request without
dumping code into every running process. Using SetWindowsHookEx allows for
some very intrusive procedures such as trapping passwords entered into
password boxes. Try it and you'll see you can log the keys typed into any
password box. And that includes Online Banking web pages etc. Programs that
install system-wide hooks have the potential of doing more than just
bringing up GUI's on a hotkey (or keys). Not to mention the fact that if
there's a bug in your code then that bug will be propagated to the entire
system and into every running process. For instance I had a resource leak in
my global hook test and the only way to get the machine back back up and
running was to press the reset button. It is a very dangerous thing you are
doing if you plan to ship this code to innocent end users.

I installed a dictionary program called "Concise Oxford English Dictionary
(Eleventh Edition)" on my system and discovered that it was using
SetWindowsHookEx because it wanted to trap spelling mistakes in every
process and allow word lookups in every process. It took me a couple days to
remove the hook DLL from their app basically by replacing several system
DLLs it was using and overriding the call. The program is full of bugs and I
don't particularly want poorly written code in the address space of my apps.
And just to expose their awareness of what a crummy thing they were doing
they attempted to hide the fact by naming the hook DLL "COED11.DAT". Sure
enough COED11.DAT was appearing in every process on my system (you can see
this using process explorer from http://www.sysinternals.com/ which is a
great replacement for taskmanager and, in particular, shows everything
loaded into an applications's address space).

- Alan Carre

"Ben Menashe" <BenMenashe@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:994D6257-1096-44A0-8A89-C4A609F87EFB@xxxxxxxxxxxxxxxx
Interesting... I thought it was ok to use it to trap keys. Other
suggested
methods for doing what I need ? the service needs to 1) sense if there's
keyboard/mouse activity (so it can pause it's heavy operation in case a
user
is logged on) 2) detect keystrokes so it can bring up a GUI with a
password
that will allow the user to shut it down.

I actually got it to work using the LowLevel keyboard and mouse hooks.
The
reason it didn't work before is since my service didn't have a message
loop... once I added it works like a charm and doesn't seem to slow down
the
system.

The only issue left is that it does not work for terminal sessions. Any
ideas on that ?


"Alan Carre" wrote:

"Ben Menashe" <BenMenashe@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:48F87F09-BFA3-4BA6-8035-AEC491E48125@xxxxxxxxxxxxxxxx
I'm tryng to do something that should be simple but having the hardest
time.
Basically the NT service I'm writing needs to trap a keystroke, that it
will
use to detemine if the user is active.

So I created a DLL that uses SetWindowsHookEx to trap WH_KEYBOARD.

My service loads the DLL uses LoadLibrary and then gets the InstallHook
function using GetProcAddress.

It sets the hook properly. However, when the service is shutdown,
there's
always some random process in the OS that crashes... usually mmc.exe,
but
sometime taskmgr.exe. What's going on here? are they still hooked ?
I
did set my service to call UnhookWindowsHookEx upon exit, but that
didn't
solve the problem. If I take out the call to the DLL, there's no
issues
anymore.

btw, the other issue with it is that it doesn't trap keys for users
logged
into a terminal session. I've tried loading all the desktops and
setting
the
hook for each one and still no success.

Anyone accomplish this before ? I can post my code if needed. Can I
avoid
the DLL if I use the WH_KEYBOARD_LL ? I tried using that but couldn't
get
it
to trap anything...

I've written keyboard hooks just for fun, but I would never consider
using
one in a commercial application. Nor should you.

That said, this is a rather drastic procedure to determine if a user is
logged on (basically it amounts to installing 'foreign' code in every
single
running process, thereby affecting the stability of the system).
SetWindowsHookEx should only be used for debugging purposes and not for
shippable code (and unfortunately it is being used in more and more
programs
these days). As stated in the MSDN documentation:

[QUOTE]
"The system hooks are a shared resource, and installing one affects all
applications. All system hook functions must be in libraries. System
hooks
should be restricted to special-purpose applications or to use as a
development aid during application
debugging. Libraries that no longer need a hook should remove the hook
procedure. "
[/QUOTE]

And yes, closing down the hook procedure in your main app does not
gurantee
that the hook DLL will be unloaded instantly from other processes (and
you
should't be in there in the first place!).

[QUOTE]
UnhookWindowsHookEx:
The hook procedure can be in the state of being called by another thread
even after UnhookWindowsHookEx returns. If the hook procedure is not
being
called concurrently, the hook procedure is removed immediately before
UnhookWindowsHookEx returns.
[/QUOTE]






.

Quantcast