使用CreateRemoteThread进行DLL注入 [英] DLL Injection with CreateRemoteThread

问题描述

如果您查看以下简单的DLL注入的工作代码:

If you take a look at the following working code of a simple DLL injection:

  //Open the target process with read , write and execute priviledges
   Process = OpenProcess(PROCESS_CREATE_THREAD|PROCESS_QUERY_INFORMATION|PROCESS_VM_READ|PROCESS_VM_WRITE|PROCESS_VM_OPERATION, FALSE, ID); 

   //Get the address of LoadLibraryA
   LoadLibrary = (LPVOID)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA"); 

   // Allocate space in the process for our DLL 
   Memory = (LPVOID)VirtualAllocEx(Process, NULL, strlen(dll)+1, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); 

   // Write the string name of our DLL in the memory allocated 
   WriteProcessMemory(Process, (LPVOID)Memory, dll, strlen(dll)+1, NULL); 

   // Load our DLL 
   CreateRemoteThread(Process, NULL, NULL, (LPTHREAD_START_ROUTINE)LoadLibrary, (LPVOID)Memory, NULL, NULL); 

   //Let the program regain control of itself
   CloseHandle(Process); 

让我感到困惑的是，GetProcAddress返回当前进程的LoadLibraryA功能地址，如何将其作为参数传递给CreateRemoteThread并期望目标程序运行吗?

The thing confuses me is that GetProcAddress returns the LoadLibraryA fucntion address of the current process, how can you pass it as a parameter to CreateRemoteThread and expect the target process to run it?

推荐答案

它偶然起作用.这是非常的常见事故，Microsoft付出了很多努力来确保操作系统DLL(例如kernel32.dll)的基址不与任何其他DLL冲突. kernel32.dll在进程初始化时就很早就加载了，从而进一步增强了这种可能性，以至于它不得不为获得其首选的基址而奋斗.

It works by accident. It is a very common accident, Microsoft makes a great deal of effort to ensure that the operating system DLLs, like kernel32.dll, have a base address that doesn't conflict with any other DLLs. Further enhanced by kernel32.dll getting loaded very early at process initialization so low odds that it has to fight to get its preferred base address.

您将轻松摆脱困境.值得注意的是，此以前曾经出错，XP的安全更新引起了gdi32.dll的重新定位，并导致许多计算机在启动时崩溃.正确的方法是很痛苦的，CreateToolhelp32Snapshot()+ Module32First/Next()查找重定位偏移并不是一件很愉快的事情.坦白说，如果操作系统像这样怪异"，您可能根本不应该这样做.

You'll get away with easily. It is notable that this has gone wrong in the past, there was an XP security update oops that caused gdi32.dll to get relocated and made lots of machines fall over at boot. The correct way is fairly painful, CreateToolhelp32Snapshot() + Module32First/Next() to find the relocation offset isn't great joy. Frankly, you probably ought to not do this at all if the operating system is "weird" like that.

这篇关于使用CreateRemoteThread进行DLL注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！