对抗hook－defeating_hooks
----------------------------------------------------------------------------------(1) Defeating IAT or export table modification AND/OR In-line function hooking [1]---------------------------------------------------------------------------------- - recall that Import/Export table modification does : modify the IAT or export address table of the targeted process and all the modules (DLLs) that process/app uses each process and module has its own IAT that contains the function addresses of functions that process/module uses so we replace the addresses in that IAT with addresses to our hooking fxns but this method has to take into consideration that some functions will be dynamically loaded, e.g. thatdll = LoadLibrary( somedll.dll ) then addy = GetProcAddress( thatdll, SomeFunction ) - so to fully hook would require hooking GetProcAddress so that it returns the hooked function address rather than the actual function addy - could also modify the export address table of the desired DLLs; this this will cause GetProcAddress(...) to return the addys we desire So: GetProcAddress( thatdll, SomeFunction ) looks at the EAT of thatdll for SomeFunction; if we have altered the EAT to have our fxn address, then our fxn addy will be returned instead of the real fxn addy - recall that inline function hooking does : overwrite start of the hooked API function with a jmp instruction that causes execution to be transferred to our function ('the replacement function') DEFEATING BOTH OF THESE APPROACHES : - manually read ntdll.dll and kernel32.dll into memory using CreateFile, ReadFile - we'll call these manually loaded images 'file images' - the memory images of ntdll.dll and kernel32.dll are what have been modified - iterate through the EAT of the file images of ntdll.dll and kernel32.dll -- for each function exported, get that function's length * N -- then compare the first N bytes of each of that function from the file image and the memory image -- restore each hooked function by copying the relevant bytes from the file image to the memory image - iterate through the IAT of the memory image of kernel32.dll -- for each imported function from ntdll.dll, check that the address of this function hasn't been modified -- if it has been modified, restore the IAT entry from the file image - obtain the function address of CreateProcessA using the file image of kernel32.dll - execute desired EXE (app) using CreateProcessA NB: relies on fact that only memory image of app and DLLs modified and that the actual file on disk (e.g. ntdll.dll) is not changed - also seems to rely on fact that disk image of our executable hasn't been changed (i.e. had its IAT overwritten on disk)-------------------------------------------------------------------(2) Evading userland hooks - problems w/hooking implementations [2]------------------------------------------------------------------- (a) incomplete hooking : don't hook BOTH ANSI and Unicode versions of function - ansi fxn names end in A, e.g. CreateProcessA(...) - unicode versions end in W, e.g. CreateProcessW(...) - ansi functions usually just wrappers which call unicode versions - e.g. hook CreateFileA(...) so then attacker just calls CreateFileW(...) instead (b) not hooking deeply enough - kernel32.dll has a lot of functions that are mostly wrappers for ntdll functions - so if only hook kernel32.dll functions and NOT ntdll.dll functions, hooking can be bypassed via calling the ntdll functions directly - e.g. GetProcAddress from kernel32.dll and LdrGetProcedureAddress from ntdll.dll (c) hooking function f but NOT hooking function g which f calls - e.g. may hook WinExec(...) - but this is what WinExec(...) call path looks like : WinExec(...) --> CreateProcessA(...) --> CreateProcessInternalA(...) - if just hook WinExec(...) and CreateProcessA(...) and NOT CreateProcessInternalA(...) then attacker can just call that last fxn and evade detection - CreateProcessInternalA(...) is exported by kernel32.dll so attacker could look for its addy via loading kernel32.dll and iterating through that module's EAT - also this refers to problem mentioned in (1) whereby say some function f lives in DLL d but f itself calls function g which lives in DLL d' - so we need to recursively be hooking not only our target functions but ensuring that any functions THOSE TARGET FUNCTIONS call are likewise hooked (d) detecting installation of in-line function hooks - most win32 api functions begin with a 5-byte preamble XP : pre-SP2 55; push ebp 8bec; mov ebp, esp ... XP : post-SP2 8bff; mov edi, edi (?) -- pg. 75 of Hoglund Rootkits book 55; push ebp 8bec; mov ebp, esp ... - after in-line function hooking, a function preamble will look like : e8 xx xx xx xx ; call xx xx xx xx 54 ; push esp 53 ; push ebx 56 ; push esi 57 ; push edi or instead of call will have jmp (e9) - so before program P (which wants to bypass hooking) calls function f, P looks at the code at f; if it looks like a normal preamble, call f else if the first instruction is a call or a jmp to some address, then likely in-line function hooking is at work so don't call f or do something else... but in any event the hooking has been detected --> putting this into detours terminology, basically what the attacker would do after probabilistically detecting the hook (above) is search for the table which contains the original 5-byte preamble --> recall that for detours we have a target function T, a detour function (replacement function) D, and a trampoline function TR where when T is called, instead D is called then TR is called which calls T --> so attacker would attempt to call TR then T -- bypassing Dsince TR and T must live in the app memory somewhere --> or instead attacker can have its own preamble (keep track of the original preamble) then call the target function + 5 bytes, so we jump over the 'jmp xx xx xx xx' or 'call xx xx xx xx' function which is our inline function hook (hook hopping)==> won't work if another function in the call path is also hooked, e.g. if do hook hopping on WinExec but then WinExec calls CreateProcess and haven't done hook hopping on CreateProcess, then evasion fails - so would need to call CreateProcess using stored preamble and do hook hopping on functions called by WinExec (e) implementations which overwrite preambles must change the write bits on that code ... so that the preamble can be overwritten with the jmp or call instruction; but some such implementations never reset the writable bit on these code preambles ... so attacker can overwrite overwritten preamble with original preamble! (f) IAT patching - attacker overwrites IAT before hooking mechanism does detection - then hooking mechanism will hook desired functions and make those functions jump to replacement functions then to the 'original API function' -- but 'the original api function' isn't really, it's the function address already overwritten by the attacker - so the attacker acts as first mover - alters the api addy to X - then when hooker comes in, it will alter api addy to Y where the code at Y does whatever then calls X - in particular the systems being attacked here call various ntdll.dll functions in order to obtain memory page information so the idea is to replace those core functions used by the attackee with functions replaced by the attacker - context is that attackee is doing buffer overflow protection - and is using ntdll.dll functions for this purpose (rather than supplying its own versions of these functions) (g) write code which replaces functionality of functions exported by ntdll.dll - have already discussed how most ntdll.dll functions basically : push args move the syscall number to eax move pointer to userland stack to edx int 2e - well attacker can write code which essentially replicates the functionality of those ntdll.dll functions - so if hook was of all ntdll.dll functions, then attacker can bypass that detection + of course this doesn't work against kernel-land hooking ... where the actual hooking doesn't come into play until *after* int 2e is executed * requires knowing the syscall numbers of desired kernel syscalls as well as the method signature for each such kernel syscall (type and number and order of arguments to that kernel syscall so as to conform to it)----------------------------(3) Evading kernel hooks [3]---------------------------- - basically kernel-level hooks (in NT/2k/XP/2003) rely on modifying the SSDT - so this basically restores the SSDT from the disk image of ntoskrnl.exe - the methods for doing this restoration mirror closely those which are used to alter the SSDT in the first place obviously assumes that kernel hooking done via overwriting memory image of ntoskrnl.exe data structures (e.g. KiServiceTable) and that disk image of ntoskrnl.exe is legit. - requires some address conversion from original addys on disk image to RVAs++++++++++++References :++++++++++++(1) Anti API hooking http://www.security.org.sg/code/antihookexec.html(2) Evading userland hooks and Evading kernel hooks http://www.phrack.org/phrack/62/p62-0x05_Bypassing_Win_BufferOverflow_Protection.txt(3) Defeating native API hookers http://www.security.org.sg/code/SIG2_DefeatingNativeAPIHookers.pdf
