The problem points that the HOOK API should pay attention to when multi-threading

When using the inline HOOK API to intercept system APIs, there is no normal problem, but when it comes to multi-threading, it can be unpredictable to modify the IAT or jmp,2 methods, especially when you HOOK some complex large system software. Will be impatient by a memory error from time to time.

The more Hooks API, the more content to note, the recent implementation of the Hook FileSystem API, because it is a function in Kernel32, all involved in the file (Filename,filehandle) API will be hook, At the same time need to implement the overlapped function in the hook, and this function point is relatively complex, involving the completion of ports, events and other functions of the hook.

After hundreds of versions of the update debugging, currently initially stabilized, the following list of areas to be aware of, mainly related to the FileSystem API, other APIs (such as network API, memory API, etc.) may not be applicable:

1) from a stability point of view, it is recommended to use the JMP method to implement the hook API, the way to modify the IAT is not not, but too easy to be modified by other programs to cause instability problems, most anti-virus software will modify the IAT while protecting, so this method is easy to report virus, Either the hook fails, the IAT is patched, and there may be no problems with the small system or the low-volume API, but for the filesystem API, the individual is not recommended.

2) for Vista, WIN7 or more compatible: When the first hook in XP, everything is normal, when switching to WIN7, found that hook does not work, this is due to Vista, WIN7 more than the app in the original call Kernel32.DLL function, because the system Apppatch function, has been automatically redirected to KernelBase.dll, and Microsoft has a very strange approach, of course, is also due to compatibility considerations (that is, in the EXE right-click Properties to select Compatible Xp,vista transport , Apppatch automatically chooses which APIs to redirect, and some APIs exist in Kernel32 and kernelbase without knowing whether the redirection feature is imperfect or otherwise, two modules in the same app, even if the same API is called, It is also possible to jump to Kernel32 and kernelbase respectively, when the hook API is applied in JMP mode, because the function address is obtained by GetProcAddress, it is automatically redirected to Kernelbase. Therefore, you need to implement a GetProcAddress function yourself.

3) Multithreading synchronization problem: Personal recommendations using critical section rtl_critical_section, whether it is development efficiency or operational efficiency, critical section is preferred, for the post-hook API use of different process resources, but also in the use of critical section of the synchronization process, And then use other methods to implement it.

4) After multi-threaded hook often stuck to the problem, Windows FileSystem API There is a problem of nested calls, such as CopyFile internal calls CreateFile and other functions, KERNEL32 's CreateFile calls functions inside the Createfile,getfilesize function in Kernelbase that might call GetFileSizeEx, and so on, if you synchronize with one of the kernel objects in these functions, Must cause the card to die, so you need to consider these issues, such as when calling CopyFile, you need to synchronize with CreateFile using different kernel objects, and in Kernel32 CreateFile, It is necessary to lift the hook of the Kernelbase CreateFile.

5) in the hook and unhook process, you need to use the same kernel object to WriteProcessMemory synchronization protection, Failure to do so will result in some unexpected address memory data corruption in the process (this should be caused by the writeprocessmemory function that does not support multithreading).

The problem points that the HOOK API should pay attention to when multi-threading