Deep parsing hooks and dynamic link libraries (top)

Download Source Codes-Kb

There is a lot of controversy over how to use and create hooks, and this article tries to clarify these issues.
Note: If you just use hooks within your own process, there will be no problem, this only happens when you use the system hooks.
 The key problem is the address space, where any object (including variables) created by code in a DLL function is owned by the thread or process that calls it. When a process loads a DLL, the operating system automatically maps the DLL address to the private space of the process, which is the virtual address space of the process, and copies a copy of the global data of the DLL to the process space. In other words, the global data of the same DLL owned by each process is private, the DLL becomes part of the process, executes as the process, and uses the stack of the process. This means that the data will be reinitialized. Typically, they will be zero.
 someone suggested storing the address of the data on the DLL. It is impossible. There are objections. Well, that's not impossible, but it's impossible to have any use for it. Even if you create a shared memory variable that is visible to all instances of the DLL, this variable only has practical significance in the process of storing it. For all other processes, this is just a string of bits, and if you try to use it as an address, the address is completely useless and even causes the program to crash for the process that the event is intercepted.
 The concept of this separate address space is a difficult concept to grasp. Let me use the picture to illustrate it.
 we have three processes here. Your process is displayed on the left. DLL has code, has data, and has a shared segment of data. Now when the hook DLL performs an event interception on process A, the system automatically maps the DLL address to the private space of the process, which is the virtual address space of the process, and also copies a copy of the global data of the DLL to the process space. Coincidentally, they will be moved to the same virtual address as process a. Process A has its own private copy data segment, so process a sees in "Data" either as private, or it cannot affect other processes (or is affected by other processes!). The trouble here is to share the data segment, which shows the red. The same memory page is indicated in your process and process a. Note that, coincidentally, these pages of memory appear on the same virtual address. If you are debugging your process and process A at the same time, and look at the &something in the shared data segment, and look at the same &something in the process A, you will see the same data, even if they are at the same address. If you use the debugger to change, you may see that the program changes the value of the &something, you can go to another process, check it, and see the new values that appear there.
 Let's take a look at what happens in process B. When an event is hooked in a process B, the DLL is mapped. The code is moved into a different address in B in the process. If you debug the process B, pay attention to the &something in the shared area, you will find that the &something address is different, but the &something content will be the same; Even if process B is seen at another address (virtual address). (This is in the same physical memory location). When I mention coincidence, "coincidence" means being planned; Windows always tries to shoot a DLL into the same virtual address, and it tries to do so, but it rarely succeeds.
 This means that if you hold a pointer to a callback function in a DLL, it may point to a different address when you actually run process a or process B. This also means that you will not be able to use mfc--in DLLs it cannot be an extended MFC DLL or an MFC DLL, because these DLLs (dynamic-link libraries) call MFC functions.
 so where is the MFC function? They are in your address space, not in process A or process B's address space. Because they may be written in Visual.basic, Java, or other languages, you must write Straight-c DLLs, and I recommend that you ignore the entire C runtime library., use only APIs. Replace strcpy or tcscpy with lstrcpy, replace strcmp or tcscmp with lstrcmp, and so on. How to get your DLL to communicate with its controlling server.
 a solution will use::P ostmessage or:: SendMessage function. (What I'm talking about here is the original API call, not MFC's call!) Whenever possible using::P Ostmessage, use it as much as possible prior to use:: SendMessage. Otherwise, if your process unfortunately stops, because everyone is blocked in a never return:: SendMessage, other processes will also stop, and then the entire system stops.
 you can also consider using information queues in shared memory areas, but that topic is beyond the scope of this article. In:: SendMessage or::P ostmessage, you cannot return a pointer (we will ignore the problem of returning a relative pointer to the shared memory area; that is beyond the scope of this article). This is because you can use any of the pointers indicated by the address either in the DLL or in the process of being hooked. (Process A or process B) so in your process, this pointer is completely useless. You can only return the address space via the information in WPARAM or lparam.