0

Reading the API definition of SetWindowsHookEx, I see

Calling the CallNextHookEx function to chain to the next hook procedure is optional, but it is highly recommended; otherwise, other applications that have installed hooks will not receive hook notifications and may behave incorrectly as a result. You should call CallNextHookEx unless you absolutely need to prevent the notification from being seen by other applications.

So a password manager could simply register a hook, not call CallNextHookEx, then type the password and unregister the hook to restore the original behavior.

This technique is not listed in the answer to How easily are keyloggers foiled? or Methods of mitigating threats from keyloggers, so I wonder whether I am missing something obvious.

Community
  • 1
Thomas Weller
  • 3,246
  • 3
  • 21
  • 39

3 Answers3

2

I don't think you are missing anything obvious. The other article's question and answers actually focus on stopping the key logger sending messages out of the network.

The technique you're talking about is how an application, which knows it may be a target for a key logger, may stop the key logger getting the information in the first place.

JCx
  • 480
  • 2
  • 6
1

I am not 100% sure of what I am about to say, but most likely it is correct.

Messages are dispatched from source (S) and travel to the destination (D). Hooks (Hx) are logically located between those 2 points. Hooks can be used to process the travelling message for whatever purpose (for example, traffic filtering). With this in mind, we can visualize a working Windows system as follows:

(S)->(H1)->(H2)->...->(Hn)->(D)

When a hook is done with processing the message it passes it on to the next one, using CallNextHookEx, until no hooks are left. By not calling the next hook, you ensure that the message never reaches the destination (hence the warning from Microsoft).

The solution you propose would not work, because it would simply disrupt any message exchange between password manager and the user application. You can imagine a hook that does not forward the message as a firewall drop rule, all messages are discarded.

Another issue is that you can't always have access to the memory space of the process where the message is going. As a standalone passwors manager program you can't set hooks within other processes, such as firefox for example, while a keylogger can. Because of this you can't even set a hook in the first place.

user4294507
  • 333
  • 1
  • 2
1

The proposed technique isn't very helpful against keyloggers for two reasons:

  • It relies on the fact that the newly installed hook is executed before the keylogger's one so it won't always work even with hook-based keyloggers.
  • What is more important, only the simplest of keyloggers use SetWindowsHookEx. There are over a dozen different methods ranging from GetAsyncKeyState to patching kernel mode functions. Since hook-based key capture can be trivially detected by antivirus software, the actual malware keyloggers (as opposed to employee monitoring tools etc.) are likely to use something else.
DMWatson
  • 11
  • 2