Windows message hooks are generally familiar. It is widely used. It is familiar with the use of keyboard hooks to obtain the keyboard input of the target process, so as to obtain various types of passwords for ulterior motives. Is there a way for a friend to prevent his software from being monitored by others' global hooks? The answer is yes, but there are also some defects.
First, let's take a look at how global hooks inject other processes.
The message hook is provided by the Win32 subsystem. Its core component uses ntusersetwindowshookex to provide users with system services for setting message hooks. Users can use it to register global hooks. When the system obtains certain events, such as user buttons and keyboard drivers, it transmits scanning codes to the keyevent processing function of win32k. The processing function determines whether there is a corresponding hook, and then callhook. At this point, the system obtains the hook object information. If the target process does not load the corresponding DLL, it will load it (using the keusermodecallback "call" User routine, which is different from the APC call, it is a copy of the interrupted return environment, and its call is "immediate ).
After entering the kiusercallbackdispatcher in the user State, kiusercallbackdispatcher obtains the required functions and Parameters Based on the transmitted data, and then calls them. For the above example, to load the hook DLL, The loadlibraryexw is called, and then enters ldrloaddll. After loading, the result is returned. The subsequent steps are not described.
From the above discussion, we can come up with the simplest anti-intrusion solution: hook the corresponding API before loading the hook DLL to make loading fail, but there is a defect: the system will not give up because of one failure. Every time a message is generated, the system will try to load the DLL in your process to call the hook. This has some slight impact on the performance, but it should not be felt. The remaining problem is that not all loadlibraryexws should be intercepted, which is easy to solve, such as determining the return address. The following is an example of how to add some judgments so that some hook DLL files that can be loaded are loaded.
Here, the hook api uses Microsoft's detours library, which can be modified on its own.
The following is the program code:
Typedef hmodule (_ stdcall * loadlib )(
Lpcwstr lpwlibfilename,
Handle hfile,
DWORD dwflags );
Extern "C "{
Detour_trampoline (hmodule _ stdcall real_loadlibraryexw (
Lpcwstr lpwlibfilename,
Handle hfile,
DWORD dwflags ),
Loadlibraryexw );
}
Ulong USER32 = 0;
Hmodule _ stdcall mine_loadlibraryexw (
Lpcwstr lpwlibfilename,
Handle hfile,
DWORD dwflags)
{
Ulong ADDR;
_ ASM mov eax, [EBP + 4]
_ ASM mov ADDR, eax
If (USER32 & 0xffff0000) = (ADDR & 0xffff0000 ))
{
Return 0;
}
Hmodule res = (loadlib (real_loadlibraryexw ))(
Lpwlibfilename,
Hfile,
Dwflags );
Return res;
}
Bool processattach ()
{
Detourfunctionwithtrampoline (pbyte) real_loadlibraryexw,
(Pbyte) mine_loadlibraryexw );
Return true;
}
Bool processdetach ()
{
Detourremove (pbyte) real_loadlibraryexw,
(Pbyte) mine_loadlibraryexw );
Return true;
}
Canti_hookapp: canti_hookapp () file: // call processattach before using the user interface service
{
USER32 = (ulong) getmodulehandle ("user32.dll ");
Processattach ();
}