GetHooks known issues for Windows x86 2k/XP/Vista/7/8
These are the known issues for gethooks v1.01 - Built on Dec 14 2011 at 00:48:09.
If you are looking for the GetHooks homepage click here.
FATAL errors on Windows 2000
I designed GetHooks to work on Windows 2000 but it looks as though I got an offset wrong somewhere. I have to debug GetHooks in Windows 2000 but that's proving to be a real chore, and maybe even impossible using Visual Studio 2010.
Error: ..\desktop.c line xxx, attach(): Failed to get a pointer to the DESKTOPINFO struct.
x64 support is not implemented. If you run GetHooks on Windows x64 it's likely it will fail. If you are running on Windows x86 and you see that error please run systeminfo and send me the output:
systeminfo | findstr "^OS Locale Type"
The snapshot store failed to initialize. (Duplicate pvWin32ThreadInfo)
GetHooks identifies the threads associated with a hook by matching each thread's kernel mode address with the kernel mode addresses stored in each HOOK structure. Rarely, for reasons I do not yet understand, two threads in user mode will have the same kernel mode address. This does not appear to be a bug in the program. I have witnessed this on Vista and 7 systems, and also once in a clean VM where I was running GetHooks for testing purposes.
Regrettably I have yet to find a solution to this issue. I suspect it is caused by the kernel reusing addresses or maybe structures. Unless I find a way to identify in user mode which duplicate thread info is correct and which is "stale" the program cannot accurately identify the thread. For now when GetHooks encounters such a situation it will terminate to avoid reporting incorrect results. A possible workaround until I find a solution might be in such a situation to report multiple associations, but so far I'm loathe to implement that.
Here's a screenshot of GetHooks dying on a FATAL:
If you want to help me find a solution, I would like to examine the thread environment blocks (TEBs) of your user mode programs that have threads that share the same kernel mode thread address. What you can do is set in your system environment GETHOOKS_DEBUG with a value of 1. If the error above is ever encountered GetHooks should dump the TEB of any thread that has a thread kernel address that is encountered more than once.
UNC paths are not supported. Defaulting to Windows directory.
GetHooks can be run from the command interpreter or directly (eg by double-clicking on it in explorer). If you do the latter GetHooks will pause before exit so the console window is not automatically closed. In this case if you are running GetHooks from a network share the command interpreter will warn you that "UNC paths are not supported" before pausing:
'\\vmware-host\Shared Folders\.GetHooks24958'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
Press any key to continue . . .
You can ignore that warning.
Error: ..\test.c line 451, find_most_preceding_kernel_HOOK(): HOOK chain exceeded maximum supported length.
The 'chain' test function is experimental. When you pass in a HOOK address on the command line the function must determine whether or not the HOOK is part of a chain, and where in the forwardly linked list (ie the hook chain) it is located. Then it attempts to reverse its way back up to the chain's head -- if it is not there already -- by calling find_most_preceding_kernel_HOOK(). Currently in versions 1.0 and 1.01 that function has a hard limit of max 100 HOOKs per chain.
I recently captured a WH_MOUSE hook chain owned/originated by Google Chrome 16.0.912.63 flashplayer thread that had hundreds of HOOKs chained together. I had never seen anything get that long that works. Future versions of GetHooks will have a limit of 65535 when tracing to the head of a HOOK chain (already fixed in the develop branch Jan 2012).
As a workaround you can run the chain function multiple times and each time it will give you an address at most 100 closer to the head. Following the example from above I check the thread and dump its hooks (logfile here. also available in verbosity 46 and 7.). I notice the hooks are all very similar so I pick one address at random to see how long its chain is.
gethooks -v 4 -z chain 0xFE7E1AF0
(result: max exceeded message and says first HOOK is at 0x00000000FE6827F0)
gethooks -v 4 -z chain 0x00000000FE6827F0
(result: max exceeded message and says first HOOK is at 0x00000000FE659FB8)
gethooks -v 4 -z chain 0x00000000FE659FB8
(result: no max exceeded message and says first HOOK is at 0x00000000FE7750F0)
gethooks -v 4 -z chain 0x00000000FE7750F0
(result: the full hook chain. logfile here. also available in verbosity 46 and 7.)
Send me any issues you encounter
Jay Satiro <raysatiro$at$yahoo{}com> and put GetHooks in the subject.
If you are looking for the GetHooks homepage click here.
