Windows hook function detailed

In this lesson, we'll learn how to use Windows hook functions. The Windows hook function is so powerful that you can detect other processes and change the behavior of other processes.
Theory:
The Windows hook function can be considered one of the main features of Windows. With them, you can capture events that occur with your own processes or other processes. With hooks, you can give Windows a callback function that handles or filters events, also known as the hook function, which Windows will call every time an event of interest to you occurs. There are two kinds of hooks: local and remote.
Local hooks only hook up events of your own process.
A remote hook can also hook up events that occur in other processes. There are two kinds of remote hooks:
Thread-based IT captures events from a particular thread in another process. In short, it is an event that can be used to observe the occurrence of a particular thread in another process.
System-wide will capture event messages that will occur for all processes in the system.
Installing the hook function will affect the performance of the system. The system hooks for monitoring system-wide events are particularly noticeable. Because the system will call your hook function when it handles all related events, your system will obviously slow down. It should be used carefully and unloaded immediately after use. Also, because you can intercept messages from other processes in advance, it will affect other processes once your hook function is out of the question. Remember: Being powerful also means being responsible when you use it.
Before we use the hook function correctly, we'll explain how the hook function works. When you create a hook, Windows first creates a data structure in memory that contains information about the hook and then adds the structure to the existing hook list. The new hooks will be added to the old front. When an event occurs, if you install a local hook, the hook function in your process will be invoked. If it is a remote hook, the system must insert the hook function into the address space of the other process, to do this requires that the hook function must be in a dynamic link library, so if you want to use a remote hook, you must put the hook function into the dynamic link library. Of course there are two exceptions: Log hooks and work logs to replay the hooks. The hook function for both hooks must be in the thread where the hook is installed. The reason is: These two hooks are used to monitor the lower level of hardware events, since the recording and playback, all of the events are of course in order. So if you put the callback function in the DLL, the input events are recorded in several threads, so we can't guarantee the correct order. The solution is to put the hook function into a single thread, such as the thread that installs the hook.
There are a total of 14 hooks, the following is the time they are called:
Wh_callwndproc when SendMessage is invoked
Wh_callwndprocret when the SendMessage call returns
Wh_getmessage when GETMESSAGE or PeekMessage is invoked
Wh_keyboard when you call GetMessage or PeekMessage to query for Wm_keyup or WM_KEYDOWN messages from a message queue
Wh_mouse when you call GetMessage or PeekMessage to query mouse event messages from message queues
Wh_hardware when you call GetMessage or PeekMessage to query for a non-mouse, keyboard message from a message queue
Wh_msgfilter When a dialog box, menu, or scroll bar is to process a message. The hook is local. It is designed for control objects that have their own message-handling processes.
Wh_sysmsgfilter, like Wh_msgfilter, is just a system-wide
Wh_journalrecord when Windows obtains messages from the hardware queue
Wh_journalplayback when an event is requested from the system's hardware input queue
Wh_shell when it comes to the Windows shell event, for example, the taskbar needs to redraw its button.
WH_CBT when computer-based training (CBT) events occur
Wh_foregroundidle is used by Windows itself and is rarely used by general applications
Wh_debug is used to make the hook function error-removing
Now that we know some basic theories, we are now beginning to explain how to install/uninstall a hook.
To install a hook, you can call the Setwindowhookex function. The prototype of the function is as follows:
SetWindowsHookEx Proto Hooktype:dword, Phookproc:dword, Hinstance:dword, Threadid:dword
Hooktype is one of the values listed above, such as: Wh_mouse, Wh_keyboard
Phookproc is the address of the hook function. If you are using a remote hook, you must put it in a DLL or put it in your own code
HInstance the instance handle of the DLL that contains the hook function. If it is a local hook, the value is null
ThreadID is the ID number of the thread you want to monitor after you install the hook function. This parameter can determine whether the hook is local or system wide. If the value is null, then the hook will be interpreted as system-wide, so it can monitor all processes and their threads. If you specify a thread ID number in your own process, the hook is a partial hook. If the thread ID is the ID of a thread in another process, the hook is a global remote hook. Here are two special cases: Wh_journalrecord and wh_journalplayback always represent the local system-wide hooks and are localized because they are not necessarily placed in a DLL. Wh_sysmsgfilter is always a system-wide remote hook. In fact, it is similar to the Wh_msgfilter hook, if the parameter ThreadID set to 0, they are exactly the same.
If the function call succeeds, the handle of the hook is returned in the EAX, or null is returned. You must save the handle because we want it to unload the hook later.
To uninstall a hook, call the Unhookwidowhookex function, which has only one argument, which is the handle of the hook you want to uninstall. Returns a value other than 0 in EAX if the call succeeds, otherwise null is returned.
Now that you know how to install and uninstall a hook, next we'll look at the hook function.
Windows will call the hook function whenever the message event type of the hook you install occurs. For example, the hook you have installed is the wh_mouse type, so whenever a mouse event occurs, the hook function is invoked. Regardless of the type of hook you install, the hook function prototype is the same:
HookProc Proto Ncode:dword, Wparam:dword, Lparam:dword

NCODE Specifies whether the message needs to be processed
WParam and LParam include additional messages for this message
HookProc can be thought of as a placeholder for a function name. As long as the prototype of the function is consistent, you can give the function any name. As for the above parameters and return value of the specific meaning of various types of hooks are not the same. Such as:
Wh_callwndproc
Ncode can only be hc_action, it represents a message sent to a window
WParam, if not 0, represents the message being sent
LParam pointers to Cwpstruct-type structure variables
Return value: Not used, returns 0
Wh_mouse
Ncode for Hc_action or Hc_noremove
WParam an event message containing the mouse
LParam pointers to MouseHookStruct-type structure variables
Return value: Returns a non-0 value if no processing returns 0
So you have to query your WIN32 API guide to get a detailed definition of the parameters of different types of hooks and the meaning of their return values. Here's another question to note: All the hooks are chained to a list, and the recently added hooks are placed on the head of the list. When an event occurs, Windows follows the order of calls from the header of the chain to the end of the linked list. So your hook function is responsible for uploading the message to the hook function in the next chain. Of course you may not, but you'd better understand why. In most cases, it is best to pass the message event so that other hooks have the opportunity to handle the message. Call the next hook function to call function CallNextHookEx. The prototype of the function is as follows:
CallNextHookEx Proto Hhook:dword, Ncode:dword, Wparam:dword, Lparam:dword
Hhook is the handle of your own hook function. Use this handle to traverse the hook chain.
Ncode, WParam and lParam you simply pass the incoming parameters to CallNextHookEx.
Note that for remote hooks, the hook function must be placed in the DLL, and they will be mapped from the DLL to the other process space. When a Windows mapping DLL goes to another process space, the data segment is not mapped. In short, all processes share only the DLL's code, and for data segments, each process will have its own copy. This is a problem that can easily be overlooked. You might take it for granted that values saved in a DLL can be shared among all the processes that map the DLL. In general, because each process that maps the DLL has its own data segment, your program works well in most cases. But the hook function is not. For the hook function, the data segment of the DLL is required to be the same for all processes. This allows you to set the data segments to be shared, which can be achieved by specifying the properties of the segment in the link switch. You can do this in MASM:
/section:<section Name>, S
The initial segment name is. Data, and the uninitialized segment name is. BSS. ' Add you want to write a DLL that contains a hook function, and you want to have its uninitialized data segments shared among all the processes, you have to do this:
Link/section:.bss,s/dll/subsystem:windows .....
S represents that the segment is a shared segment.