C / C++ / MFC

10-Mar-10 13:01

Hi all,

I'm curious as to whether there are methods to detect forms of hooking on windows. I've been trying the WH_DEBUG hook to no success, code is below and it crashes every app under the explorer.exe tree.

HHOOK debughook;
LRESULT CALLBACK DebugProc(int nCode,WPARAM wParam,LPARAM lParam){
	return CallNextHookEx(debughook,nCode,wParam,lParam);
}

int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
	debughook=SetWindowsHookEx(WH_DEBUG,DebugProc,hInstance,0);

Any help with that would be appreciated, as well as any other suggestions on hook detection. My original goal was to make an effective keylogger detection app, but as of now that doesn't seem very likely anymore.

Thanks.

edit: is there any reason why a global IAT patch doesn't seem to work on SetWindowsHookExA?

modified on Wednesday, March 10, 2010 8:24 PM

Baltoro10-Mar-10 13:55

10-Mar-10 13:55

This is an excellent question. If you search over at MSDN you will discover: Win32 Hooks[^]
The problem is that, if you want to detect ALL hooks, you're going to have to think about the Hooking techniques. The sneakiest hooks do NOT use the standard available Windows techniques. And, of course, Windows does not want you interferring in its Hooking Chain, so they don't provide you with an easy method of monitoring hook activity.

hxhl9510-Mar-10 14:25

10-Mar-10 14:25

Of course. In fact, I haven't even considered going into kernel land yet, only usermode methods of detecting hooks.

The article is interesting but I can't seem to use any of that to detect installed hooks. Confused | :confused:

Baltoro11-Mar-10 9:39

11-Mar-10 9:39

There is also a complete reference on Windows Hooks over at MSDN: HOOKS[^]. I'd guess that you've already read it.

Baltoro11-Mar-10 9:49

11-Mar-10 9:49

In the book, "Rootkits: Subverting the Windows Kernel", by Greg Hoglund, the author devotes an entire chapter to Hooks, and in particular, IAT hooking, which is probably the best way to detect malicious code. I have copied a section here to give you an idea. He discusses hooking in terms of a rootkit injected into a remote computer.

Import Address Table Hooking
The simpler of the two userland hooking processes is called Import Address Table hooking. When an application uses a function in another binary, the application must import the address of the function. Most applications that use the Win32 API do so through an IAT, as noted earlier. Each DLL the application uses is contained in the application's image in the file system in a structure called the IMAGE_IMPORT_DESCRIPTOR. This structure contains the name of the DLL whose functions are imported by the application, and two pointers to two arrays of IMAGE_IMPORT_BY_NAME structures. The IMAGE_IMPORT_BY_NAME structure contains the names of the imported functions used by the application.
When the operating system loads the application in memory, it parses these IMAGE_IMPORT_DESCRIPTOR structures and loads each required DLL into the application's memory. Once the DLL is mapped, the operating system then locates each imported function in memory and overwrites one of the IMAGE_IMPORT_BY_NAME arrays with the actual address of the function.
Once your rootkit's hook function is in the application's address space, your rootkit can parse the PE format of the target application in memory and replace the target function's address in the IAT with the address of the hook function. Then, when the function is called, your hook will be executed instead of the original function.
You can see that this is a very powerful yet rather simple technique. It does have its drawbacks, though, in that it is relatively easy to discover these types of hooks. On the other hand, hooks like these are used frequently, even by the operating system itself in a process called DLL forwarding. Even if someone is trying to detect a rootkit hook, determining what is a benign hook as opposed to a malicious hook is difficult.
Another problem with this technique has to do with the binding time. Some applications do late-demand binding. With late-demand binding, function addresses are not resolved until the function is called. This reduces the amount of memory the application will use. These functions may not have addresses in the IAT when your rootkit attempts to hook them. Also, if the application uses LoadLibrary and GetProcAddress to find the addresses of functions, your IAT hook will not work.

Looking for Hooks

Baltoro11-Mar-10 10:34

11-Mar-10 10:34

I have copied a brief section here about the general techniques involved in looking for User Mode IAT hooks, again, from "Rootkits: Subverting the Windows Kernel". I have left out the description of Inline Hooks, because they are implemented in assembly language and require some experience in disassembling.

Looking For Hooks
A memory-based detection method is to look for hooks within the operating system and within processes. There are many places where a hook can hide, including the following:
Import Address Table (IAT)
System Service Dispatch Table (SSDT), also known as the KeServiceDescriptorTable
Interrupt Descriptor Table (IDT) with one per CPU
Drivers' I/O Request Packet (IRP) handler
Inline function hooks
The basic algorithm for identifying a hook is to look for branches that fall outside of an acceptable range. Such branches would be produced by instructions like call or jmp. Defining an acceptable range is not difficult (for the most part). In a process Import Address Table (IAT), the name of the module containing imported functions is listed. This module has a defined start address in memory, and a size. Those numbers are all you need to define an acceptable range.
Likewise for device drivers: All legitimate I/O Request Packet (IRP) handlers should exist within a given driver's address range, and all entries in the System Service Dispatch Table (SSDT) should be within the address range of the kernel process, ntoskrnl.exe.
Finding Interrupt Discriptor Table (IDT) hooks is a bit more difficult, because you do not know what the acceptable ranges should be for most of the interrupts. The one you know for sure, however, is the INT 2E handler. It should point to the kernel, ntoskrnl.exe.
Inline hooks are the hardest to detect, because they can be located anywhere within the function—requiring a complete disassembly of the function in order to find them—and because functions can call addresses outside the module's address range under normal circumstances. In the following sections, we will explain how to detect SSDT, IAT, and some inline hooks.

Finding IAT Hooks
IAT hooks are extremely popular with current Windows rootkits. IAT hooks are in the userland portion of a process, so they are easier to program than kernel rootkits, and do not require the same level of privilege. Because of this, you should make sure your detection software looks for IAT hooks.
Finding IAT hooks is very tedious, and implementing a search for them requires many of the techniques covered in previous chapters. However, those steps are relatively straightforward. First, change contexts into the process address space of the process you want to scan for hooks. In other words, your detection code must run within the process you are scanning.
Next, your code needs a list of all the DLLs the process has loaded. For the process, and every DLL within the process, your goal is to inspect the functions imported by scanning the IAT and looking for function addresses outside the range of the DLL the function is exported from. After you have the list of DLLs and the address range for each one, you can walk each IAT of each DLL to see whether there are any hooks. Particular attention should be paid to Kernel32.dll and NTDLL.DLL. These are common targets of rootkits, because these DLLs are the userland interface into the operating system.
If the IAT is not hooked, you should still look at the function itself to determine whether an inline hook is present.

hxhl9511-Mar-10 13:29

11-Mar-10 13:29

"Also, if the application uses LoadLibrary and GetProcAddress to find the addresses of functions, your IAT hook will not work."

Does that mean if I compare the addresses of HookedFunction() and LoadLibrary(HookedFunction) I would be able to detect IAT hooks in my process?

If so, any suggestions on how I might generalize this to every running process?

Baltoro13-Mar-10 10:47

13-Mar-10 10:47

hxhl95,
The chapter about hooks from the Rootkits book by Hoglund is lengthy, and goes into great detail describing the most common hooking techniques used by malicious code. Rather than post the entire chapter (which would be HUGE), I just copied brief selections to give you an idea of what the general concept is. I left out a bunch of explanatory material. Alot of interesting information about the techniques used by malicious software are explained on: Rootkit[^]
But, if you are trying to detect unauthorized hooks in your process address space (or others on the Local Machine), the concept is examine the address range of the DLL that exports the function called in the IAT of your process (the DLLs are all dynamically loaded by the system into your process address space), and determine if the address actually listed in the IAT corresponds to that range.
If the process instead calls LoadLibrary and GetProcAddress to load the DLL on demand, the address entry in the IAT will NOT exist, so any malicious injected DLL code could not possibly overwrite the IAT address. (Actually, I'm unsure if the Operating System creates a temporary IAT entry at this point, but, I assume that it doesn't.)
Go to SysInternals and download Process Explorer[^](FREE) to get a graphic representation of which dynamically loaded DLLs exist in your Process addesss space. Also,VMMap[^] is a very useful utility for understanding process address space memory allocations.
An excellent overview of the Portable Executable format and its structures when loaded into memory is located at: Peering Inside the Portable Executable, Matt Pietrek[^]

hxhl9513-Mar-10 10:49

VS2005 & VS2008 DLL Compilation issues

13-Mar-10 10:49

Yes, I've been exploring that and I think I can continue from here.

Thanks a lot for your help Baltoro! Big Grin | :-D

masnu10-Mar-10 7:56

masnu

10-Mar-10 7:56

Hi guys,

I have VS2005 and VS2008 installed on my development machine. Whenever I develop a DLL I have to link with the /MT (Multi-Threaded) option if I want to use it on any other machine. If I compile the DLL on a machine with VS2005 only, however, I don't have to use the /MT option, I can use the /MD (Multi-Threaded DLL) and the DLL can be used on any machine.

Has anyone else come across this? Is there a way to resolve this?

Thanks.

CPallini10-Mar-10 8:01

CPallini

10-Mar-10 8:01

You should deploy the runtime on the target machines, see [^].
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

masnu10-Mar-10 9:19

masnu

10-Mar-10 9:19

Thanks but I have already installed the VC++ 2005 and 2008 runtime libraries on the target machine. That doesn't help, though. I am developing on a Windows 7 machine. Should that make a difference?

CPallini10-Mar-10 10:24

CPallini

10-Mar-10 10:24

What is the error you get?

image processing toolkits | batch image processing

C^hris L^osinger10-Mar-10 8:13

C^hris L^osinger

10-Mar-10 8:13

/MD means: all that MFC/C-runtime stuff will live in a set of external DLLs which i will ship with my application.

MT means: put all that MFC/C-runtime stuff into the DLL itself so i don't have to distribute the runtime libraries with my application.