                Hooking DLLs using PEB
                 attack on protectors

                                S verom u Boga, deroko/ARTeam
                                
When each dll is loaded new entry is created in PEB_LDR_DATA to
describe state of .dll and also newly inserted data will be used
later on to access .dll via GetModuleHandle and LoadLibrary.

This is advantage for us because we can load our .dll with faked
export table and all calls to APIs will go trough our .dll and
endup in real .dll.

At offset 30h of TEB (Thread Environment Block) is located pointer
to PEB (Process Enironment Block), and at offset 0ch in PEB there
is PEB_LDR_DATA:

kd> dt nt!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x01c EnvironmentPointer : Ptr32 Void
   +0x020 ClientId         : _CLIENT_ID
   +0x028 ActiveRpcHandle  : Ptr32 Void
   +0x02c ThreadLocalStoragePointer : Ptr32 Void
   +0x030 ProcessEnvironmentBlock : Ptr32 _PEB
   ...
   
kd> dt nt!_PEB
   +0x000 InheritedAddressSpace : UChar
   +0x001 ReadImageFileExecOptions : UChar
   +0x002 BeingDebugged    : UChar
   +0x003 SpareBool        : UChar
   +0x004 Mutant           : Ptr32 Void
   +0x008 ImageBaseAddress : Ptr32 Void
   +0x00c Ldr              : Ptr32 _PEB_LDR_DATA  
   
kd> dt nt!_PEB_LDR_DATA
   +0x000 Length           : Uint4B
   +0x004 Initialized      : UChar
   +0x008 SsHandle         : Ptr32 Void
   +0x00c InLoadOrderModuleList : _LIST_ENTRY
   +0x014 InMemoryOrderModuleList : _LIST_ENTRY
   +0x01c InInitializationOrderModuleList : _LIST_ENTRY
   +0x024 EntryInProgress  : Ptr32 Void
   
There are 3 list entries importatn for us here that describe
state of loaded modules, all of them are pointing to same struct
for one module but depending on how module is being loaded those
lists will be rearanged by loader.

This lists point to one structure that describes stae of each loaded
module:

typedef struct _LDR_MODULE {

  LIST_ENTRY              InLoadOrderModuleList;
  LIST_ENTRY              InMemoryOrderModuleList;
  LIST_ENTRY              InInitializationOrderModuleList;
  PVOID                   BaseAddress;
  PVOID                   EntryPoint;
  ULONG                   SizeOfImage;
  UNICODE_STRING          FullDllName;
  UNICODE_STRING          BaseDllName;
  ULONG                   Flags;
  SHORT                   LoadCount;
  SHORT                   TlsIndex;
  LIST_ENTRY              HashTableEntry;
  ULONG                   TimeDateStamp;

} LDR_MODULE, *PLDR_MODULE;

Whenever GetModuleHandle is called it will scan trough this structs
and try to locate right .dll if it is loaded. If not it will fail,
same goes for LoadLibraryA that will scan if .dll is loaded, if not,
it will load .dll and insert new struct in lists.

My attack consist of faking BaseAddress, EntryPoint and SizeOfImage
wit my loaded .dll which will return my .dll whenever GetModuleHandleA
is used to get base address of, for example, kernel32.dll. 

By faking kernel32.dll in PEB->PEB_LDR_DATA we have to create .dll that
will have all exports as kernel32.dll so protector won't fail. Once
protector starts filling importtable using GetProcAddress or custom
implementation of GetProcAddress it will actually take our exports and
we have full control over program. 

To accomplish this first we will load our .dll using LoadLibrary, and
at entrypoint of our hooking .dll we will take all steps needed to 
hook dll:

                        call    LoadLibraryA, offset szkernel32
                        mov     old_dll_base, eax
                        xchg    eax, ebx
                        
__find_dll:             cmp     [esi.lm_baseaddress], ebx
                        je      __esiedi
                        lodsd
                        xchg    eax, esi
                        jmp     __find_dll                        
                        
__esiedi:               cmp     ebx, imagebase
                        je      __hook
                        mov     edi, esi
                        mov     ebx, imagebase
                        jmp     __find_dll        

__hook:                 mov     eax, ebx
                        xchg    eax, [edi.lm_baseaddress]
                        mov     [esi.lm_baseaddress], eax
                        
                        add     ebx, [ebx+3ch]
                        mov     eax, [ebx.pe_addressofentrypoint]
                        add     eax, imagebase
                        xchg    eax, [edi.lm_entrypoint]
                        mov     [esi.lm_entrypoint], eax

                        mov     eax, [ebx.pe_sizeofimage]
                        xchg    eax, [edi.lm_sizeofimage]
                        mov     [esi.lm_sizeofimage], eax
                        
Now when protector tries to get handle for kernel32.dll it will get handle
for our hooking .dll and we may easily write our hooking routines here.

                                        S verom u Boga, deroko/ARTeam