[Tutorial][SourceCode] SEH/thread hooking
[Tutorial][SourceCode] SEH/thread hooking
Hey everyone,
I've been gone from this form for about 1 or 2 months (or more, I don't remember) During this time I learned a trick or two. Today I'm going to show you how you can apply a (crude) hook on another thread's SEH handler.
So here it goes, you can (after the mods approve) download all the files used in this tutorial in the attachments section below.
Introduction
I assume you have a moderate knowledge on these subjects:
1. Structured exception handling in windows
2. C++
3. Memory/Clock time management in windows (context switching)
4. Threads
5. The stack
Following this tutorial will be hard if you don't have a clue about one or more of the aforementioned subjects. However, since I won't dive too deep with this tutorial, you should be able to tag along with some help of google.
What's SEH hooking?
As you know, an EH handles exceptions/faults that sometimes randomly appear in your code/program. When a fault occurs windows transfers control to the most recently established Exception handler, the handler can chose if it wants to fix the fault or shove the problem to another lower/older handler. This method of dealing with exceptions is called Structured exception handling.
When a fault occurs windows looks for the thread information block (TIB) of the thread where the fault occurred. In the TIB windows finds a pointer to the next (the most recently established EH) EH. Windows calls this EH and provides all the necessary information to the EH for the EH to fix the problem. At this point the EH can chose if it wants to fix the fault or pass it along. If the EH choses to pass the exception down the chain windows looks for the pointer to the next EH, this pointer is always located 4h above the pointer to the EH. See this structure:
We intend to hook the SEH chain by either changing the Handler* to our code, or by adding another entry to the chain. For simplicity's sake I chose for the first option.
How can this be achieved?
As you may or may not know (depending if you met the requirements for this tutorial) The FS segment register points to a whole array of interesting things and structures in modern day windows(win 95+). We are interested in the 18Th element in FS. FS:[18h] points to the the current thread's TIB.
Remember that we could find the first entry to the SEH in our TIB? There's one problem however, FS only points to your own TIB, and I haven't found a way to correctly receive the contents of the FS register from another thread (GetThreadContext is bugged look here for further reading)
Luckily after a bit of digging in olly I found that the TIB's of all threads in a process cluster around a general offset(7EF[FFFFF-00000])
I made a little function in ASM (and put it in a library) that finds the TiB's of all threads in your process. You can find the library down below.
Hook it!
Ok, so now we have our target's TIB and with that a pointer to it's topmost SEH. In the TIB we can also find the ThreadID we can use for api calls like: SuspendThread, GetThreadContext, SetThreadContext and ResumeThread, etc, etc. While making my library I also took the liberty of writing a little Hook Function. This function forces our own handler on the other thread's chain (we overwrite it's first pointer)
Here's an example:
I've tested this on windows server 2008 r2 64bit( which = windows 7 64bit in all but name)
and I compiled it using VC++ 6.0
An application to test this code on is included in the zip file below.
When the hook is set (after ForceRemoteSEH()) you can write an int3 code to the place where you want your hook code to be executed.
eg. You can place an int3 opcode somewhere in a d3d function. When windows comes across this opcode it raises the Breakpoint Exception.
Your handler can then check if the exception is a debug exception, if it's not you can simply pass the exception down the chain.
Pros and cons
Pros:
1. Windows loads all data and things you might need (all registers the stack ,exception code,etc) into two data structures and supplies these two structures to you.
2. If you see that a real exception occurred you can just pass it along the chain, no need to worry about it.
3. No need to bother with proper reentry, you can just return and windows will continue execution where the exception occurred, and because the INT3 opcode is only 1 byte long, you don't need to bother much with restoring data either.
Cons:
1. It's not as efficient/fast as normal hooks, this won't be a problem unless you hook speed reliant functions.
2. It's unfeasible to check whether or not your handler is still the top most handler. Meaning that exceptions that occur have a slight chance of being handled before they come to your hook. Mind you, only a slight chance. Most exception handlers are very specific on what kind of faults they handle.
3. Sometimes you'll find that you hook the SEH of a function or api, once this function or api returns the SEH is lost and so is your hook. This can be avoided by following the chain down to the 3rd entry (which should be the first exception handler installed by the program itself) This EH is often an unhandled exception filter meaning that it would normally try to fix all exceptions that occur. Most of the times an INT3(or any INT opcode) is unhandled.
Virus scans
Virscan.org
NoVirusThanks.com
I used NoVirusThanks because Jotti was down.
I hope some of you guys try it out, I think with the right examination and with some toying around in the TIB you can come up with some very effective hook scheme.
-SCHiM
I've been gone from this form for about 1 or 2 months (or more, I don't remember) During this time I learned a trick or two. Today I'm going to show you how you can apply a (crude) hook on another thread's SEH handler.
So here it goes, you can (after the mods approve) download all the files used in this tutorial in the attachments section below.
Introduction
I assume you have a moderate knowledge on these subjects:
1. Structured exception handling in windows
2. C++
3. Memory/Clock time management in windows (context switching)
4. Threads
5. The stack
Following this tutorial will be hard if you don't have a clue about one or more of the aforementioned subjects. However, since I won't dive too deep with this tutorial, you should be able to tag along with some help of google.
What's SEH hooking?
As you know, an EH handles exceptions/faults that sometimes randomly appear in your code/program. When a fault occurs windows transfers control to the most recently established Exception handler, the handler can chose if it wants to fix the fault or shove the problem to another lower/older handler. This method of dealing with exceptions is called Structured exception handling.
When a fault occurs windows looks for the thread information block (TIB) of the thread where the fault occurred. In the TIB windows finds a pointer to the next (the most recently established EH) EH. Windows calls this EH and provides all the necessary information to the EH for the EH to fix the problem. At this point the EH can chose if it wants to fix the fault or pass it along. If the EH choses to pass the exception down the chain windows looks for the pointer to the next EH, this pointer is always located 4h above the pointer to the EH. See this structure:
Code:
struct Error_Handler{
dword* Next_Error_Handler; // this points to the next Error_Handler struct
dword* Handler; // this points to the Exception handler of this entry
}; //made by me, I couldn't find the original, but it's correct
We intend to hook the SEH chain by either changing the Handler* to our code, or by adding another entry to the chain. For simplicity's sake I chose for the first option.
How can this be achieved?
As you may or may not know (depending if you met the requirements for this tutorial) The FS segment register points to a whole array of interesting things and structures in modern day windows(win 95+). We are interested in the 18Th element in FS. FS:[18h] points to the the current thread's TIB.
Remember that we could find the first entry to the SEH in our TIB? There's one problem however, FS only points to your own TIB, and I haven't found a way to correctly receive the contents of the FS register from another thread (GetThreadContext is bugged look here for further reading)
Luckily after a bit of digging in olly I found that the TIB's of all threads in a process cluster around a general offset(7EF[FFFFF-00000])
I made a little function in ASM (and put it in a library) that finds the TiB's of all threads in your process. You can find the library down below.
Hook it!
Ok, so now we have our target's TIB and with that a pointer to it's topmost SEH. In the TIB we can also find the ThreadID we can use for api calls like: SuspendThread, GetThreadContext, SetThreadContext and ResumeThread, etc, etc. While making my library I also took the liberty of writing a little Hook Function. This function forces our own handler on the other thread's chain (we overwrite it's first pointer)
Here's an example:
I've tested this on windows server 2008 r2 64bit( which = windows 7 64bit in all but name)
and I compiled it using VC++ 6.0
Code:
#include <windows.h>
#include <iostream>
#include <string.h>
#pragma comment(lib, "RemoteThreadSEH.lib")
extern "C"{
void _stdcall ForceRemoteSEH(DWORD* NewHandler, DWORD ThreadID, DWORD* pThreadTIB);
void _stdcall ThreadTIBSniffer(DWORD* DumpAddress, DWORD* pNumberOfThreadsFound);
}
int MainThread();
int FakeHandlerHook();
BOOL APIENTRY DllMain( HANDLE hModule, DWORD fdwReason, LPVOID lpReserved ){
if( fdwReason == DLL_PROCESS_ATTACH){
CreateThread(0, 0, (LPTHREAD_START_ROUTINE)&MainThread, NULL, NULL, NULL);
return TRUE;
}
return TRUE;
}
int MainThread(){
DWORD NumberOfThreads = NULL;
DWORD* ptrer = (DWORD*)malloc( sizeof (char)*80 );
DWORD* PtrToNrThreads = &NumberOfThreads;
ThreadTIBSniffer(ptrer, PtrToNrThreads); // find all TIBS
DWORD ThreadID = NULL;
if(NumberOfThreads == NULL){
MessageBox(NULL, "No threads have been found!", "SCHiM", MB_OK);
return 0;
}
/* Debug, uncomment if you want to see how many threads have been found
char Buffer[100] = "";
std::string MboxOutString = "Number of threads found: ";
itoa((int)NumberOfThreads, &Buffer[0], 10);
MboxOutString += Buffer;
MessageBox(NULL, MboxOutString.c_str(), "SCHiM", MB_OK);
*/
DWORD* OurSEH = (DWORD*) &FakeHandlerHook;
__asm{ // this gets the ThreadID from the first thread's TIB
mov eax, ptrer
mov eax, [eax]
mov eax, [eax+24h]
mov ThreadID, eax // I forgot how to properly dereference pointers in C++ so I do it this way
}
ForceRemoteSEH(OurSEH, ThreadID, ptrer); // OurSEH = ptr to hook function
return 0;
}
int FakeHandlerHook(){ // this is where the SEH pointer will point to
MessageBox(NULL, "Remote SEH Hookage!", "SCHiM", MB_OK);
return 0;
}
When the hook is set (after ForceRemoteSEH()) you can write an int3 code to the place where you want your hook code to be executed.
eg. You can place an int3 opcode somewhere in a d3d function. When windows comes across this opcode it raises the Breakpoint Exception.
Your handler can then check if the exception is a debug exception, if it's not you can simply pass the exception down the chain.
Pros and cons
Pros:
1. Windows loads all data and things you might need (all registers the stack ,exception code,etc) into two data structures and supplies these two structures to you.
2. If you see that a real exception occurred you can just pass it along the chain, no need to worry about it.
3. No need to bother with proper reentry, you can just return and windows will continue execution where the exception occurred, and because the INT3 opcode is only 1 byte long, you don't need to bother much with restoring data either.
Cons:
1. It's not as efficient/fast as normal hooks, this won't be a problem unless you hook speed reliant functions.
2. It's unfeasible to check whether or not your handler is still the top most handler. Meaning that exceptions that occur have a slight chance of being handled before they come to your hook. Mind you, only a slight chance. Most exception handlers are very specific on what kind of faults they handle.
3. Sometimes you'll find that you hook the SEH of a function or api, once this function or api returns the SEH is lost and so is your hook. This can be avoided by following the chain down to the 3rd entry (which should be the first exception handler installed by the program itself) This EH is often an unhandled exception filter meaning that it would normally try to fix all exceptions that occur. Most of the times an INT3(or any INT opcode) is unhandled.
Virus scans
Virscan.org
NoVirusThanks.com
I used NoVirusThanks because Jotti was down.
I hope some of you guys try it out, I think with the right examination and with some toying around in the TIB you can come up with some very effective hook scheme.
-SCHiM
Originally Posted by .::SCHiM::.
