对抗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 D
	since 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