Detours （api hook）library介绍

++++++++++++++++++++++++In-line function hooking (see especially the Detours library from Hunt/Brubacher)++++++++++++++++++++++++Detours library (using it raw or unmodified): - user-level hooking only why? because what detours lib does is overwrite the first 5 bytes of the hooked function ... and if the hooked function lives in kernel space, then we'll get a fatal mem error when we try to overwrite these bytes --> confirm : c'est vrai. also the addys of kernel syscalls not accessible in same way that addys of win32 api are. so can't use existing framework to trivially obtain kernel function addys, i.e. those found in the SSDT. Even forgetting for a moment that operating as a userland program we wouldn't have sufficient permissions to change the permissions on such memory regions in the way that is done here for detours. ==> in summary, not trivial to adapt detours to work for kernel syscall hooking, is not clear that it would be better to adapt detours vs. to start from scratch for such a goal. - also check on whether detours is an NT/XP/2k/2003 only soln or whether also works on '9x ===> seems not. - works for all x86 versions of NT, Win2K, XP 'However, under Windows 95, Windows 98, and Windows ME, the DetourFunction* APIs do not work unless the program is running under a debugger (the process was created with the DEBUG_PROCESS flag on the call to the CreateProcess* APIs).' --> limitation derives from two sources: (1) non-support of Win '9x (including Win ME) for CreateRemoteThread(...) is why injdll doesn't work for Win '9x(2) the fact that shared virtual memory (which goes from 2 GB to 3 GB in Win '9x) is not copy-on-write. So VirtualProtect, VirtualProtectEx don't work on memory regions w/in that range. System DLLs are mapped into that area. So we can't (trivially) change the permission on memory regions containing win32 api functions... which means we can't overwrite the first five bytes of such functions to cause control to transfer to our detour function.==> note that if the process is created with the DEBUG_PROCESS flag, DLLs *are* mapped with copy-on-write protection... ==> so does VirtualProtect{Ex} still fail in such a case? if so, then even if we modify 'withdll.exe' to create the process with the DEBUG_PROCESS flag, we still can't use detours in its present form to hook Win '9x if not, then GetProcAddress(...) appears to operate differently for Win '9x apps run in Debug mode, i.e. it returns a debug thunk address, not the actual address - so, would take some work to adapt detours to follow the debug thunk to the actual code and overwrite that there? Appears that if we ONLY use 'withdll' with our target executables and use -d:traceapi and change <detours/src/creatwith.cpp> function DetourCreateProcessWithDll{A,W} to create the process with the DEBUG_PROCESS creation flag, that hooking will work on Win '9x. ==> Maybe there's still a hangup which maybe has to do with the fact that FlushInstructionCache(...) isn't supported for Win '9x or maybe it works correctly transparently. ====================================================================== So I think the deal here is that the problem comes in overwriting the first 5 bytes of target functions Target functions by and large live in DLLs DLLs live in shared virtual memory For Win '9x, shared virtual memory is from 2 GB to 3 GB And the function which changes the permissions on memory SO THAT 5 bytes of it can be overwritten DOESNT work for Win '9x for shared virtual memory - VirtualProtect, VirtualProtectEx for Win '9x (and ME) don't work for shared virtual mem (2GB to 3GB) - system DLLs are loaded into shared virtual mem - so if we want to change the code in one such DLL's function (which presumably also lives in that 2 GB to 3 GB space) then we'd need to first change the mem permissions on that area to READ/WRITE/EXEC - for Win '9x we cannot make that change via VirtualProtect nor VirtualProtectEx for any mem region w/in 2 GB to 3 GB I do believe that the 'withdll' functionality still works... to inject a DLL into a user process, however 'injdll' -- which injects a dll into an *existing* user process -- would NOT work since that fxnality relies on CreateRemoteThread which isn't supported for Win '9x 'While Windows NT, Windows 2000 and Windows XP always map DLLs into processes with copy-on-write mapping (which Detours needs in order to patch the binary image), Windows 95, Windows 98, and Windows ME only map DLLs with copy-on-write if the process was started with the DEBUG_PROCESS flag on the call to CreateProcess.' [README] 'Windows 95 doesn't implement copy-on-write in the operating system. With copy-on-write, the operating system will share a common code page in memory, but when a process writes to that memory, the memory is copied so that the individual process gets its own copy that will not interfere with any other process. In the Windows 95 architecture, any memory that is above the 2GB line is shared among all processes. If one process were to write a breakpoint to this shared memory area without the copy-on-write, the breakpoint would apply to all processes, not just the one being debugged.' ====================================================================== CreateRemoteThread(...) not supported for Win '9x - only supported for 2k, nt, xp - a means to injecting a DLL into a targeted process -- why is this necessary? -- absent this injection, you can't force a process to call your functions or, if it does, to be able to resolve those functions - we want to force a process to call LoadLibrary(...) with our DLL as the arg HANDLE CreateRemoteThread( HANDLE hProcess, // INLPSECURITY_ATTRIBUTES lpThreadAttributes, // INSIZE_T dwStackSize, // INLPTHREAD_START_ROUTINE lpStartAddress, // INLPVOID lpParameter, // INDWORD dwCreationFlags, // INLPDWORD lpThreadId // OUT ); // hProcess : a handle to the process in which this thread is to be created --> that handle must have the following access rights : (1) PROCESS_CREATE_THREAD (2) PROCESS_QUERY_INFORMATION (3) PROCESS_VM_OPERATION, PROCESS_VM_READ, PROCESS_VM_WRITE // lpThreadAttributes : pointer to security attributes of new thread --> specifies security descriptor for new thread --> if NULL, thread gets default security descriptor and the returned thread handle canNOT be inherited // dwStackSize : initial size of the new thread's stack in bytes --> if 0, uses default size for the executable // lpStartAddress : pointer to application-defined function to be // executed by the thread; represents starting address of the thread // in the remote process --> ThreadProc function : is an application-defined function - serves as starting address for a thread DWORD WINAPI ThreadProc( LPVOID lpParameter ); --> lpParameter : thread data passed to the function // lpParameter : pointer to var to be passed to thread function // dwCreationFlags : flags that control creation of the thread --> if 0, thread runs immediately after created // lpThreadId : pointer to a var that receives the thread ID --> if NULL, thread ID is not returned - So how do we use this? /* ------------------------------------------------------------ * So we write our own version of TheadProc which essentially * calls LoadLibrary on the string provided * ------------------------------------------------------------ */ DWORD WINAPI ThreadProc( LPVOID lpParameter ) { HMODULE targLib = LoadLibrary( lpParameter ); return targLib; } void main( ) { HANDLE hProcessForHooking = ; hThread = CreateRemoteThread( hProcessForHooking, NULL, // thread attrs 0, // stack size ThreadProc, // pointer to fxn to execute 'C:\\HookTool.dll', // argument to that fxn 0, // creation flags NULL ); // thread ID wont be returned } - so, the deal with detours is that there are a couple different functionalities on which other functionalities build +++++++++++++++++++++++++++++++++++++++++++++++++++++ withdll : is defined in <detours/samples/withdll.cpp> +++++++++++++++++++++++++++++++++++++++++++++++++++++ e.g. usage : withdll -d:traceapi.dll myexe.exe this will : (1) create a process with the specified app name and (optional) args - this process is created with the suspend flag so that it is initially suspended - this is done via : <detours/samples/creatwith.cpp> function : P = DetourCreateProcessWithDll{A,W} (2) then <detours/src/creatwith.cpp> function : InjectLibrary( P.hProcess, P.hThread, GetProcessAddress( GetModuleHandle{A,W}(kernel32.dll), LoadLibrary{A,W} ), traceapi.dll, strlen(traceapi.dll) + 1 ); which : (a) suspends the thread (b) gets the contents of the control registers (ESP, EIP, EBP, ...) -- which includes current stack pointer (ESP) -- sets nCodeBase = ESP - { space for our assembly code + space for our args } ==> we're going to write some assembly code and this is the address (within the addy space of the given process) where that code will begin (and so execution should begin) -- will create a buffer with assembly code instructions which will : (1) PUSH 'your_dll_name' onto the stack (2) CALL LoadLibrary (where (1) is arg to that call) (3) restore the EAX, EBX, ..., ESI, EDI, EBP, ESP, ... values to what they are in (b) (4) JMP <to original code start, EIP from (b)> -- then makes stack pointer point 4 below -- and instruction pointer point to where your code will be written to (nCodeBase) - changes permissions to read/write nCodeBase - writes starting at nCodeBase with above assembly code (which will cause app to LoadLibrary( yourdll ) then restore the registers to their current contents (before that call) then return to the code they were originally going to execute) - then calls FlushInstructionCache(...) to make sure that this new code (starting at nCodeBase) overwrites any existing code in memory for this process - then sets the thread context so that the new ESP and EIP will take hold - then resumes the thread's execution ==> basically inserts a LoadLibrary(...) call for an arbitrary DLL (specified by you via the command line) into the process's code so that this LoadLibrary is done before the process begins executing then the process returns to exec'ing its normal / original code. --> so the 64k question is : is this fxnality supported on Win '9x?- well, FlushInstructionCache in Win '9x has no effect- for Win '9x, VirtualProtectEx cannot be used on any mem region in shared virtual address space (0x8000000 - 0xbfffffff) -- which is from 2 GB to 3 GB in the virtual addy space -- as noted, this region is shared between processes -- system DLLs are loaded here, also memory mapped files are mapped here ==> So in this case the memory whose protection bits we want to change lives on the user stack, which is probably somewhere in the user virtual addy space (from 4 MB to 2 GB) - so we should be able to call VirtualProtectEx on that area - and we should be allowed to execute code that lives on the stack (in that location that we've just written w/our assembly code) - maybe the inability to call FlushInstructionCache to an effect is a deal breaker but, if not, seems that this functionality should hold for the win '9x model +++++++++++++++++++++++++++++++++++++++++++++++++++ injdll : is defined in <detours/samples/injdll.cpp> +++++++++++++++++++++++++++++++++++++++++++++++++++ e.g. usage : injdll -p:<pid> -d:traceapi.dll - this injects a DLL into an already-executing process (the PID of which is specified above as a command-line arg to this program) - this opens the specified process - then calls DetourContinueProcessWithDll{A,W} which is defined in <detours/src/creatwith.cpp> - and which does : calls InjectLibraryOld (also in <detours/src/creatwith.cpp>) which in turn calls CreateRemoteThread to inject the provided dll (from the command line, e.g. 'traceapi.dll' from above) ==> This (injdll) is the functionality that requires support forCreateRemoteThread and so is NOT supported for Win '9xexcept if the original process (which we are attempting to injecta DLL into was created in DEBUG mode, which is highly unlikely) - basically what this does is : (1) open specified process (2) allocates memory in that process with read/write permissions (3) writes ThreadFunc function and argument to it in that memory (4) then calls CreateRemoteThread -- passing function address and arg address where just wrote ThreadFunc to that (remote) process's address space as well as the name of the DLL to inject (5) then waits for that created thread to complete executing then closes the handle to it then returns ==> won't work for Win '9x since CreateRemoteThread(...) not supportedon that (those) platforms--------I. Intro--------Detours : library for intercepting arbitrary win32 binary functions (read: win32 api functions) on x86 machines - interception code applied dynamically at run-time - replaces first few instructions of target function (which we'll call OVERWRITTEN) with an unconditional jump to the user-provided detour function - then the trampoline function consists of: OVERWRITTEN then an unconditional jump to the remainder of the target function - the detour function can then invoke the target function as a subroutine via invoking the trampoline function - detours are inserted at execution time -- code of target function modified in memory - detours guaranteed to work 'regardless of the mehod used by the app or system code to locate the target function' -- think they really mean : 'regardless of whether the function is (in a library) that is statically linked, dynamically linked or delay loaded...'Detours also provides functions : - to edit the IAT of any binary - to inject a DLL into a new or an existing process -- then the injected DLL can can detour any win32 function 'whether in the application or system libraries' - to attach arbitrary data segments to existing binaries------------------II. Implementation------------------===================================A. Interception of binary functions=================================== - at runtime, detours replaces first few instructions of target function with an unconditional jump to user-provided detour function - when execution reaches the target function, control jumps directly to the user-supplied detour function - detour function does whatever - then detour function may return control to the source function (the original caller) OR may invoke the trampoline function - which invokes the target function without interception - when the target function completes, it returns control to the detour function - the detour function does whatever then returns control to the source function++++How?++++The detours library intercepts target functions by rewriting theirin-process binary image - rewrites target function - rewrites matching trampoline functionThe tramp function can be allocated dynamically or statically. - if statically, the trampoline always invokes the target function w/o the detour - before insert a detour, static trampoline contains single jump to target fxn - after insert detour, trampoline contains OVERWRITTEN and jmp to remainder of target function-----------------------To detour a function...----------------------- - alloc mem for dynamic tramp fxn (if no static tramp provided) - enable write access to both the target and the tramp - copies instructions from target to tramp until at least 5 bytes have been copied - then adds a jmp instruction at end of tramp to the first non-copied instruction of target fxn - restore original page permissions on both target and tramp - flushes CPU instruction cache==================================B. Payloads and DLL Import Editing==================================Attach arbitrary data segments to a win32 binary ('payloads')Edit DLL import address tablesDetours creates new section : .detours - between export table (the RVA of which is specified in the 0'th entry of the DataDirectory which itself is in the Optional Headers which are part of the IMAGE_NT_HEADERS of a PE file) and the debug symbols - debug symbols MUST reside last in a win32 binary - the .detours section contains a detours header record and a copy of the original PE header (PE header == IMAGE_NT_HEADERS) - if modifying the IAT, detours creates new IAT, appends it to the copied PE header, then makes the original PE header point to the new IAT -- 'makes the original PE header point to the new IAT' == change the RVA stored in the second entry in the Data Directory (which points to the IAT RVA) to contain the RVA of the new IAT in our .detours section - any data segments to be added are then written at the end of the .detours section then the debug symbols are appended - reversal easy : restor original PE header from .detours section then remove .detours section---------------------Why create a new IAT?--------------------- - preserves original IAT - new IAT can contain renamed import DLLs and functions or entirely new DLLs and functions --> can make YOUR DLL be the first one loaded when an app runs - question : so this is done at run-time? when, precisely? after the app has been loaded? or before? (before makes mor sense but how modify app's image in mem before that app has been loaded?)Detours also provides routines for enumerating the binary files mappedinto an address space; can also locate payloads w/in those mapped binaries - each payload identified by a 128-bit globally unique identifier (guid)OK. I think this actually modifies the binaries on disk ... not just in mem - which makes more sense----------------------------------------------Injecting a DLL into a new or existing process---------------------------------------------- - inject : detours writes LoadLibrary(...) call into the target process with VirtualAllocEx and WriteProcessMemory then invokes call with CreateRemoteThread ==> believe this is NOT supported on Win '9x : CONFIRM ==> and figure : can detours itself be used on a Win '9x machine?------------------III. Using Detours------------------User code must include the detours.h header file and link with detours.lib(1) to intercept a function with a static trampoline - create the trampoline with the DETOUR_TRAMPOLINE macro DETOUR_TRAMPOLINE( trampoline_prototype, target_name ) e.g. DETOUR_TRAMPOLINE( VOID WINAPI SleepTrampoline( DWORD ), Sleep ); fyi, Actual Sleep function signature (from windows.h, is in kernel32.dll): VOID Sleep( DWORD dwMilliseconds ); 'Note that for proper interception: the prototype, target, trampoline, and detour functions must all have exatly the same call signature including number of arguments and calling convention.' interecepting the target function : invoke DetourFunctionWithTrampoline with two args : (1) trampoline, (2) pointer to the detour function note that the target function is already encoded in the trampoline and so it not needed as an arg e.g. DetourFunctionWithTrampoline( (PBYTE)SleepTrampoline, (PBYTE)SleepDetour ); where VOID WINAPI SleepDetour( DWORD dw ) { return SleepTrampoline( dw ); }(2) to intercept a function with a dynamic trampoline - call DetourFunction with two arguments : (1) a pointer to the target function and a pointer to the detour function - e.g. #include <windows.h> #include <detours.h> VOID (*DynamicTrampoline)(VOID) = NULL; VOID DynamicDetour( VOID ) {return DynamicTrampoline(); } void main( void ) { VOID (*DynamicTarget)(VOID) = TargetFunction; DynamicTrampoline = (FUNCPTR)DetourFunction( (PBYTE)DynamicTarget, (PBYTE)DynamicDetour ); ... // below function can be used w/either static or dynamic tramps DetourRemoveTrampoline( DynamicTrampoline ); } - DetourFunction : allocates a new trampoline and inserts the appropriate interception code into the target functionStatic tramps very easy to use when target function is available as a linksymbol; DetourFindFunction : can find the pointer to a function when that functionis exported from a known DLL or if debugging symbols are available for thetarget function's binary. - takes two args : the name of the binary and the name of the function - first tries via LoadLibrary(...) and GetProcAddress(...) - then uses ImageHlp library to search available debugging symbols - the fxn pointer returned by DetourFindFunction can be given to DetourFunction to create a dynamic trampolineProgrammer's responsibility to make sure that no other threads areexec'ing in addy space while a detour is inserted or removed - one approach : call functions in the Detours library from a DLL main routine...--------------IV. Evaluation--------------Other approaches : (1) call replacement in app source code - calls to target fxn in app replaced with calls to detour fxn - requires access to source code (2) call replacement in app binary - modify app binary to replace calls to target fxn w/calls to detour fxn - requires being able to identify all applicable call sites -- requires symbolic info which may not be present in general binaries -- also would miss dynamically-linked calls to the target fxn (i.e. which work by loading dll then getprocaddress(...)) as well as calls which use late-demand binding? (3) DLL redirection - modify DLL import entries in binary to point to a detour DLL - fails to intercept DLL internal calls and calls on pointers obtained from GetProcAddress(...) (4) Breakpoint trapping - insert debugging breakpoint into the target function - have debugging exception handler invoke the detour function - but debugging exceptions suspend all application threads - requires second OS process to catch the debug exception ==> heavy performance penalty============References :============ http://research.microsoft.com/sn/detours/ http://research.microsoft.com/~galenh/Publications/HuntUsenixNt99.pdf http://www.sisecure.com/pdf/cs-2003-01.pdf+++++++++++++++++++Detours Usage Notes+++++++++++++++++++(1) withdll(2) setdll(3)