<ReversingEngineering> experience on DLL injection technology in WINDOWS32 bit system

Last semester bored himself in the library has been looking at the reverse engineering technology, from the beginning to the beginner, now also dare to say that his leg has entered the door of this knowledge, because the blog just opened first will be some experience recorded, but also left to make a reference to their own on the one hand. "Reverse Engineering Core principle" ((han) Li Chengyuan) "Reversing: Reverse engineering revealed (electronic industry Press)" "Hacker Disassembly Revealed" ((Russian) Kaspersky)

DLL injection technology is a very basic technology in reverse engineering, it is also the key to open the door, the precondition of reverse cracking. API check, rootkit process shadowing requires DLL injection as a prerequisite. The basic method is as follows (each method has been tested by myself and has different opinions welcome comments):

(1) The DLL is injected into the process through the Windows hook function

The first is the definition of the HOOK function API:

HOOK SetWindowsHookEx (

int Idhook;

HOOKPROC LPFN;

HINSTANCE Hmod;

DWORD dwThreadID;

)/////////definition in header file #include〈windows.h〉

SetWindowsHookEx Proto:d Word,dword,dword,dword

;;;;;; Definitions in MASM32

(Take global keyboard hooks for example) The hook process is subordinate to the operating system, not a separate process or thread, as long as the hook is installed, regardless of which process, it will be WM_CHAR or wm_ The SYSCHAR message forces the DLL that invokes the hook function to be loaded into the appropriate process (so the hook callback function must be written into a DLL). The hook can either intercept the keyboard message through the DLL in the OS's message loop queue or "process" the message to the next hook callback function or application (depending on whether the CallNextHookEx function is called).

The DLL can be injected by adding some functions that you really want to use in the DLL that writes the hook callback function.

///////////////////////////////////////////////////////////////////

(2) Injecting a DLL into a process by creating a remote thread

The core idea of this approach is: # #不同的应用程序所装载的系统关键dll的虚拟地址一致 # #

////////////////////////////////////////////////////////////////////////////////////

"The new ASLR feature was applied in VISTA/7 and the address loaded by the system DLL changed every time, but he was mapped (Mapping) to the same address for each process during the system run"

("Reverse Engineering Core principle" ((han) Li Chengyuan) May 2014 1th edition P207)

/////////////////////////////////////////////////////////////////////////////////////

So we can get the function entry by invoking the LoadLibraryA or Loadlibraryw function in our own program, and the address of this function can be used to load the DLL you want to load by passing it to a remote thread created in another process. (So the premise is that the DLL already exists in the host where the injected process resides)

The concrete steps are summarized as follows://///switch Input method too annoying, this paragraph or write in English

1) openprocess (param ... )////to get the handle of process as the parameter of Createromotethread

2) VirtualAllocEx (param ...)/////to alloc a block of memory to store the path/name of DLLs (WCHAR or CHAR depends)

WriteProcessMemory (param ...)//////Fill in the block alloced

3) GetModuleHandle ("kernel32.dll")/////Get the virtual address/handle of Kernel32.dll which stores the entry of Loadli BRARYA/W API

GetProcAddress (Hkernelmod, "Loadlibray")///////////as stated above to get entry

4) createremotethread (param ...)////as call this API the DLL would be injected in remote thread ' s LoadLibrary function

5) Memory Cleaning freeing Deleting,handles shutting down

This is done by creating a remote thread to complete the DLL injection.

/////////////////////////////////////////////////////////////////////////////

(3) Complete the static injection of the DLL by statically modifying the disk image of the PE format file

After we are familiar with the loading process of the entire PE format file, we can complete the DLL's security injection process by using some very simple hex modifiers.

1) Locate the PE header through the DOS header and add a new struct in the IMPORT Directory table in the PE header (named Image_import_ in Windows.h Descriptor) to load the DLL through Windows application loader.

Here's a question of whether IDT (Import Directory Table) in the original PE header has enough space to allow us to add a struct (the loader is to determine if IDT is over by a fully null struct), where the problem arises from the branch, If there is enough space, we have no problem with the direct violence to modify IDT, but if the space is not enough for us to join a new structural unit, our choice is only to transfer the entire IDT location to (i. The free space in the other section two. Create a new section statically to hold IDT)

Method One: After emptying the IDT in the original image, we add the structure that we need to add, and then modify the RVA that points to IDT to complete the DLL injection.

Method Two: Create a new section area we need to enlarge the image size of the entire static file, and to calculate the initial rva of the new section accurately after the modification, the process of repeating method one completes the DLL static injection. (This part is a lot of content, no longer repeat here.) ）

<ReversingEngineering> about DLL injection technology in WINDOWS32 bit system