DLL Injection and function interception tutorial

DLL Injection and function interception tutorial

By CrankHank
Introduction
The source files depend a lot on function pointers. Overview is recommended.

DLL Injection is similar to 'Injecting' code into an already running process. Many things have been taken from Matt Pietrek's book 'Secrets of Windows 95'.

Function interception means 'intercepting' an API function that was loaded by a statically linked DLL by modifying the address of the beginning of the function's code, resulting in the application to call your 'intercepting' function instead of the original 'intercepted' function. This is similar to the idea in "APIHijack - A Library for easy DLL function hooking" article posted by Wade Brainerd.

DLL Injection

"DLL Injection" is not an accurate name for what my content will actually be. My code will 'inject' a series of assembled assembly language instructions [code] into some available space in the running process and alters the registers to point at the offset of the 'injected' [code]. The process will of course execute the instructions which will load a certain DLL, which is the DLL that is being injected. Note that this code 'Injects' [code]. The code can be anything, it doesn't necessarily have to load a DLL. Hence, the inaccurate title.

There are two ways to 'Inject' a series of bytes into an already running process. VirtualAllocEx() - which isn't supported in Win9x/ME - will allow a process to reserve or commit a region of memory within the virtual address space of a separate specified process. Use WriteProcessMemory() to write the data in the reserved/committed area of the target process' memory. The other way is to directly use ReadProcessMemory() and WriteProcessMemory() - which is supported in all versions of Windows - to search for some accessible area of the target process' memory and replace the bytes within the area size equal to the size of the code. Of course, you will be saving a backup of the replaced bytes in order to put them all back later on.

(Of course, you can use CreateRemoteThread() instead of all this, but it's not supported in all versions of Windows.)

One good yet slow method of injecting the code is using Windows' debugging functions. Suspend the threads of the running process (using the debugging functions) and use GetThreadContext() and SetThreadContext() to save a backup of all the registers and then modify the EIP register, which is the register that contains the offset of the current to-be-executed code, to point it to the 'Injected' code. The injected code block will have a breakpoint set at the end of it (Interrupt 3h -int 3h-). Again, use the debugging functions to resume the threads, which will then continue executing till the first breakpoint is reached. Once your application receives the notification, all you have to do is restore the modified bytes and/or un-allocate any allocated space in memory, and finally restore the registers (SetThreadContext()). That's all there is to it. The application has no idea of what has happened! The code was executed, and probably loaded a DLL. As you know, loaded DLLs are in an application's address space, therefore, the DLLs can access all memory and control the whole application. Very interesting.

Lookup the MSDN library for more information (MSDN).
Useful points to lookup:

1. Memory management...you need to know how Windows manages its memory.
2. How DLLs tick - MSDN - I suggest you read it. Might help in inspirations. Revising isn't bad.
3. PE/COFF Headers specifications... The most important thing if you're doing this in Win9x/ME - MSDN.
4. Basic debugging APIs...those are some APIs that allow you to debug certain applications. Lookup the section "Debugging and Error Handling" in MSDN.
5. Enough knowledge of ASM is required of course...and OPCODES of instructions.

Have a look at the accompanied files: Injector_src.zip.
Function Interception
Notice the DLL project in the zip file. This function is in HookApi.h.
Código:

// Macro for adding pointers/DWORDs together without C arithmetic interfering
// -- Taken from Matt Pietrek's book
// Thought it'd be great to use..
#define MakePtr( cast, ptr, addValue ) (cast)( (DWORD)(ptr)+(DWORD)(addValue))

Código:

//This code is very similar to Matt Pietrek's, except that it is written
//ccording to my understanding...
//And Matt Pietrek's also handles Win32s
//--(Because they it has some sort of a problem)

Código:

PROC WINAPI HookImportedFunction(HMODULE hModule,
//Module to intercept calls from
PSTR FunctionModule, //The dll file that contains the function you want to
//hook(ex: "USER32.dll")
PSTR FunctionName, //The function that you want to hook
//(ex: "MessageBoxA")
PROC pfnNewProc) //New function, this gets called instead{
PROC pfnOriginalProc; //The intercepted function's original location
IMAGE_DOS_HEADER *pDosHeader;
IMAGE_NT_HEADERS *pNTHeader;
IMAGE_IMPORT_DESCRIPTOR *pImportDesc;
IMAGE_THUNK_DATA *pThunk;

Código:

// Verify that a valid pfn was passed
if ( IsBadCodePtr(pfnNewProc) ) return 0;
pfnOriginalProc = GetProcAddress(GetModuleHandle(FunctionModule),
FunctionName);
if(!pfnOriginalProc) return 0;

Código:

pDosHeader = (PIMAGE_DOS_HEADER)hModule;
//kindly read the ImgHelp function reference
//in the Image Help Library section in MSDN
//hModule is the Process's Base address (GetModuleHandle(0))
//even if called in the dll, it still gets the hModule of the calling process
//---That's you should save the hInstance of the DLL as a global variable,
//in DllMain(), because it's the only way to get it(I think)

Código:

// Tests to make sure we're looking at a module image (the 'MZ' header)
if ( IsBadReadPtr(pDosHeader, sizeof(IMAGE_DOS_HEADER)) )
return 0;
if ( pDosHeader->e_magic != IMAGE_DOS_SIGNATURE )
//Image_DOS_SIGNATURE is a WORD (2bytes, 'M', 'Z' 's values)
return 0;

Código:

// The MZ header has a pointer to the PE header
pNTHeader = MakePtr(PIMAGE_NT_HEADERS, pDosHeader, pDosHeader->e_lfanew);
//it's like doing pDosHeader + pDosHeader->e_lfanew
// e_lfanew contains a RVA to the 'PE\0\0' Header...An rva means, offset,
// relative to the BaseAddress of module
// -pDosHeader is the base address..and e_lfanew is the RVA,
// so summing them, will give you the Virtual Address..

Código:

// More tests to make sure we're looking at a "PE" image
if ( IsBadReadPtr(pNTHeader, sizeof(IMAGE_NT_HEADERS)) )
return 0;
if ( pNTHeader->Signature != IMAGE_NT_SIGNATURE )
//IMAGE_NT_SIGNATURE is a DWORD (4bytes, 'P', 'E', '\0', '\0' 's values)
return 0;

Código:

// We now have a valid pointer to the module's PE header.
// Now get a pointer to its imports section
pImportDesc = MakePtr(PIMAGE_IMPORT_DESCRIPTOR,
pDosHeader, //IMAGE_IMPORT_DESCRIPTOR *pImportDesc;
pNTHeader->OptionalHeader.DataDirectory
[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
//What i just did was get the imports section by getting the RVA of it
//(like i did above), then adding the base addr to it.
//// pNTHeader->OptionalHeader.DataDirectory
/// [IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress
//// IMAGE_DIRECTORY_ENTRY_IMPORT==1 -- Look at that PE documentation.
//// Pietrek's articles in MSJ and MSDN Magazine will be real helpful!

Código:

//Go out if imports table doesn't exist
if ( pImportDesc == (PIMAGE_IMPORT_DESCRIPTOR)pNTHeader )
return 0; //pImportDesc will ==pNTHeader.
//if the RVA==0, cause pNTHeader+0==pNTHeader -> stored in pImportDesc
//Therefore, pImportDesc==pNTHeader


I think you got the idea. I hope this is useful.
Regards,
CrankHank
Nasser R. Rowhani
manuelnet@hack.com -