DLL Injection and API

Hooking
Presented by
Japneet Singh
 Agenda
• DLL/code Injection
– Injecting a DLL using registry
– Injecting a DLL using Windows Hooks
– Injecting a DLL using Remote Threads
– Injecting a DLL using Trojan DLL
– Injecting a DLL as a Debugger
– Injecting Code with CreateProcess
• Different ways of API Hooking
– API hooking by Overwriting code
– API hooking by manipulating a Module’s Import
section
DLL Injection
 Injecting a DLL using registry
• Applicable to GUI apps only (User32.dll)
• Put your dll name in AppInit_Dlls value in HKLM \
Software \ Microsoft \ Windows NT \ CurrentVersion \
Windows \
• Create a DWORD value named LoadAppInit_Dlls with
1 as the value.
• Launch a process which loads user32.dll
• Problems with this approach:
– DLL is mapped only into processes that use User32.dll.
– DLL is injected into all the processes which load User32.dll.
– DLL injected into process for its entire lifetime
 Injecting a DLL using Windows
Hooks
• Applicable to GUI apps only
• Install hook by calling
SetWindowsHookEx
• Provide the type of hook to install, the
address of a hook function in your address
space, the dll that contains the function.
• Uninstall hook by calling
UnhookWindowsHookEx(HHOOK hHook)
 Injecting a DLL using Remote
Threads
To inject:
• Allocate memory in the remote process’ address space using VirtualAllocEx
• Copy the DLL’s pathname to the allocated memory using WriteProcessMemory
• Get the real address of the LoadLibrary function using GetProcAddress
• Create a thread in the remote process that calls the LoadLibrary function using
CreateRemoteThread, passing it the address of the memory allocated in step 1
• At this point, the DLL has been injected into the remote process’ address space, and
the DLL’s DllMain function receives DLL_PROCESS_ATTACH notification and can
execute the desired code. When DllMain returns the remote thread returns from its
call to LoadLibrary causing remote thread to die.
• Free the memory allocated in Step 1 using the VirtualFreeEx

To eject
• Allocate memory in the remote process’ address space using VirtualAllocEx
• Copy the DLL’s pathname to the memory allocated in step 1 using
WriteProcessMemory
• Get real address of the FreeLibrary function using GetProcAddress
• Create a thread in remote process that calls the FreeLibrary function using
CreateRemoteThread, passing the remote DLL’s HMODULE.
• Free the memory allocated in Step 1 using the VirtualFreeEx
 Injecting a DLL using Trojan DLL
• Create a dll with same name and
exporting same symbols as a DLL loaded
by target process
• Replace the original DLL with new DLL
and rename original DLL.
• Problems with this approach:
– Not version resilient
– DLL injected into process for its entire lifetime
 Injecting a DLL as a Debugger
• Debugger can perform special actions on a debuggee process.
• When a debuggee loads, system automatically notifies the
debugger when the debuggee’s address space is ready but before
the debuggee’s primary thread executes any code.
• At this point, debugger can force some code into the debuggee’s
address space using WriteProcessMemory and then cause
debuggee’s primary thread to execute that code.
• Problems:
– This technique requires that you manipulate debuggee’s thread
CONTEXT which means writing CPU specific code.
– if debugger terminates, windows automatically kills the debuggee.
 Injecting Code with CreateProcess
• If your process is spawning the process into which you want to inject code,
create the new process in suspended mode.
• Using primary thread’s handle, you can alter what code the thread executes.
• Retrieve the primary thread’s starting memory address from the exe
module’s file header.
• Save the machine instructions at this memory address
• Force some hand code d machine instructions at this address. These
instructions call LoadLibrary
• Resume the child process’ primary thread so that this code executes
• Restore the original instructions back into the starting address
• Let the process continue execution from the starting address as if nothing
had happened.
• Problems with this approach
– Requires writing CPU dependant code
– It requires that your process is parent process
API Hooking
 API Hooking by Overwriting code
1. Locate the function you want to hook in memory
2. Save the first few bytes of the function
3. Overwrite the first few bytes of the function with JUMP instruction
which jumps to memory address of your own function.
Replacement function should have same signature and calling
convention as the original function
4. Now when the hooked function is invoked, the instruction pointer
jumps to replacement function leading to API hooking
5. You unhook the function by taking the saved bytes and placing
them back at the original function
6. Now invoke the original function which performs its normal
processing
7. When the original function returns, repeat steps 2 and 3 so that
replacement function is invoked the next time.
 API hooking by manipulating a
module’s Import section
• A module’s import section contains a set of DLLs and the symbols
imported from each of these DLLs that module requires in order to
run.
• When a module calls an imported function, it actually takes the
address of imported function from import section.
• To hook an imported function, change the address of imported
function in import section
• To trap calls to an API from all the modules in a process, we need to
modify the address of imported function in import section of all the
modules in process
• For hooking API calls in modules loaded after hooking, trap the
LoadLibrary and LoadLibraryEx functions so that we can replace
import section of newly loaded module and implicitly loaded
modules
DEMO
Thanks