tutorial 24: windows hooks
we will learn about windows hooks in this tutorial. windows hooks are very powerful. with them, you can poke inside other processes and sometimes alter their behaviors.
download the example here.
theory:
windows hooks can be considered one of the most powerful features of windows. with them, you can trap events that will occur, either in your own process or in other processes. by "hooking", you tell windows about a function, filter function also called hook procedure, that will be called everytime an event you're interested in occurs. there are two types of them: local and remote hooks.- local hooks trap events that will occur in your own process.
- remote hooks trap events that will occur in other process(es). there are two types of remote hooks
- thread-specific traps events that will occur in a specific thread in other process. in short, you want to observe events in a specific thread in a specific process.
- system-wide traps all events destined for all threads in all processes in the system.
you have to understand how a hook works before you can use it efficiently. when you create a hook, windows creates a data structure in memory, containing information about the hook, and adds it to a linked list of existing hooks. new hook is added in front of old hooks. when an event occurs, if you install a local hook, the filter function in your process is called so it's rather straightforward. but if it's a remote hook, the system must inject the code for the hook procedure into the address space(s) of the other process(es). and the system can do that only if the function resides in a dll. thus , if you want to use a remote hook, your hook procedure must reside in a dll. there is two exceptions to this rule: journal record and journal playback hooks. the hook procedures for those two hooks must reside in the thread that installs the hooks. the reason why it must be so is that: both hooks deal with the low-level interception of hardware input events. the input events must be recorded/playbacked in the order they appeared. if the code of those two hooks is in a dll, the input events may scatter among several threads and it is impossible to know the order of them. so the solution: the hook procedure of those two hooks must be in a single thread only i.e. the thread that installs the hooks.
there are 14 types of hooks:
- wh_callwndproc called when sendmessage is called
- wh_callwndprocret called when sendmessage returns
- wh_getmessage called when getmessage or peekmessage is called
- wh_keyboard called when getmessage or peekmessage retrieves wm_keyup or wm_keydown from the message queue
- wh_mouse called when getmessage or peekmessage retrieves a mouse message from the message queue
- wh_hardware called when getmessage or peekmessage retrieves some hardware message that is not related to keyboard or mouse.
- wh_msgfilter called when a dialog box, menu or scrollbar is about to process a message. this hook is local. it's specifically for those objects which have their own internal message loops.
- wh_sysmsgfilter same as wh_msgfilter but system-wide
- wh_journalrecord called when windows retrieves message from the hardware input queue
- wh_journalplayback called when an event is requested from the system's hardware input queue.
- wh_shell called when something interesting about the shell occurs such as when the task bar needs to redraw its button.
- wh_cbt used specifically for computer-based training (cbt).
- wh_foregroundidle used internally by windows. little use for general applications
- wh_debug used to debug the hooking procedure
