A new way to inject DLL files into other processes

Http://www.45it.com/windowszh/201212/33946.htm

Http://www.hx95.cn/Article/OS/201212/65095.html

We know that there are many ways to inject dynamic connection libraries into other processes. The most common approach is to use the hook function (hook), but this approach has two drawbacks: first, if a process does not load User32.dll, the hook DLL will never be loaded. Second hook DLL loading timing problem, only when the process issued a User32 call, the Hook DLL can be loaded. This means that the Hook DLL is not loaded when the process is undergoing complex numerical calculations without time for message invocation. Theoretically, there is no precise way to determine whether our hook DLLs have been injected into the process we want. Another most common approach is to use function CreateRemoteThread to open a thread in other processes to load a DLL. It should be said that this is a relatively perfect solution to the case, this method avoids all the drawbacks of using the hook function, but unfortunately this function can only be used under winnt/2000.

This article discusses a new way to inject a dynamic connection library into other processes. The idea is similar to the method of using function CreateRemoteThread, except that it can be used under WIN9X,WIN2K,WINXP and other operating systems. Here we will show the reader how we injected the DLL (InjectDll.dll) into the Explorer.exe process!

The idea of the program is as follows

1: Get the ID of any thread in the Explorer.exe process.

2: According to the ID of this thread, get the handle of this thread handle

3: Suspend this thread and save the current "context" of the thread

4: Change the EIP pointer on this thread so that it points to the function that we loaded the DLL (Injectcodefun), and then restore the thread.

5: After the function of our load DLL is finished, suspend this thread again, use our previously saved "context", restore the thread to its state before it was changed, and continue to run.

After the above steps, the Explorer.exe process will load our DLL (InjectDll.dll), it is interesting that Explorer.exe is unaware of any anomalies!

Below we will explain in detail how to implement the above procedure.

The implementation of Step 1 is very easy, we just need to call toolhelp function can get what we want, here we do not elaborate, please refer to the source code GETPROCESSID, GetThreadId two functions.

Step 2 is more troublesome, there is no function in Win9x that can get thread Handle by thread ID (fortunately Win2K provides this functionality). Fortunately, we can find this function in some foreign BBS, it uses some non-public structure, the purpose of this article is not to discuss this question, if the reader is interested, can refer to our source code OpenThread2 function. The function is to pass in a thread ID parameter and return the corresponding thread Handle.

The implementation of Step 3 is also very easy and normative, we can use Suspendthread,getthreadcontext and other SDK functions easy to complete.

Step 4 This step is the most important step. To illustrate the convenience, we will refer to the statements in our source code, please refer to the source code in the Injectcodeintothread function.

First change the EIP pointer of the thread, we can do it with the following code

Threadcontext.eip = (DWORD) m_lpcodebase;

SetThreadContext (M_hinjectthread,&threadcontext);

The variable m_lpcodebase the first address of the function (Injectcodefun) that points to our load DLL.

The most critical part here is how we generate our load DLL's function (Injectcodefun). Note that we cannot simply write a function in our program and then assign its first address to the EIP. This is because the function that loads the DLL is to run in the Explorer.exe address space, and if we use the function in our own address space, it will inevitably cause the system to crash. The solution is to put our written load DLL function (INJECTCODEFUN) in all program shared address space, in Win9x 0x80000000 ~ 0xFFFFFFFF is the address we want to share the address space, So how do we put the load DLL function we wrote in this address space? There are many ways to solve this problem by using a canonical method called "Memory image File". We use the function createfilemapping to allocate a shared address space, and then copy the load DLL function we wrote to this address space. Please refer to the Initinject function in the source code for the specific code.

There are two more questions in our Load DLL function (INJECTCODEFUN) We need to explain that first in this function we cannot use any of the variables defined in our own program, as it is said, because the address space is different. And we can't call functions directly, such as using Loadlibray directly in Injectcodefun. This is because if you use Loadlibray directly then you need to go through the import table of the program and jump to get to the real Windows Loadlibray function. However, different processes have different import, so we can't call the function directly. We can use a technique called "dynamic constructors" to create our functions. First use GetProcAddress to get the direct address of the function Loadlibray, and then in the call Loadlibray place, use a special number instead of it such as 0x11111111, and finally after our function is copied to the shared address space, Search shared memory Find this special number and replace it with the correct address we got earlier. The second interesting phenomenon is that the load DLL function (Injectcodefun) we wrote should not be returned. This is because the function is running in the explorer thread, we don't know the correct contents of the stack, we don't know what the ESP point is, and if the function returns, we lose control of the program. Our approach is to send a custom message to our main program after the Loadlibray is called, to advertise that our program has completed the load task and then put the thread into a dead loop state.

Step 5 When our program accepts a custom message, it suspends the thread again, restores the "context" of our previously saved thread with the function SetThreadContext and resumes running the thread. As a result, Explorer.exe never felt that he had been interrupted.

The above is the method we introduced, the reader can refer to our source code to understand the above methods. The function of the source code is to inject our DLL (InjectDll.dll) into the Explorer.exe, in InjectDll.dll we create a new thread and then display the current time in the upper-left corner of the screen. The source code is divided into the Win9x version and the Win2K version, the main difference between the two versions is that the method of allocating shared memory is different. The source code is already under PWN98,PWINME,WIN2K,WINXP and other operating systems, using VC6 to compile through

The source code can be found on the downloads page of the following URL: http://webaide.myetang.com/or http://netaide.top263.net/.



Author: Robinhao ([email protected])
Please obtain the consent of the author for reprint.

A new way to inject DLL files into other processes