用CreateRemoteThread注入动态链接库

Question

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

  //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，并期望目标进程运行它？

Answer 1

它是偶然工作的。这是一个非常常见的事故，微软做了大量的努力，以确保操作系统DLL，像内核32.dll，有一个基本地址，不与任何其他DLL冲突。内核进一步增强了内核32.dll在进程初始化时很早就被加载，所以很低的几率，以至于它必须战斗才能获得它的首选基址。

你会轻易逃脱的。值得注意的是，这个在过去出现了错误，有一个XP安全更新oops导致gdi32.dll被重新定位，导致许多机器在引导时崩溃。正确的方法是相当痛苦的，CreateToolhelp32Snapshot() + Module32First/Next()查找重定位偏移量不是很大的joy。坦率地说，如果操作系统是这样的“奇怪”，那么您可能根本不应该这么做。

Answer 2

地址空间布局随机化(ASLR)是Windows处理的一种防利用漏洞缓解功能，它允许地址重定位，以帮助攻击者确定用于利用内存中某物的地址(停止地址/偏移的硬编码)。但是，Windows模块只更改每个会话的地址。

如果您有一个使用kernel32.dll的进程(不是所有进程都使用kernel32.dll，我将在几分钟后进一步解释)，例程的地址可能是55AA1122作为示例(这是一个无效的示例地址)。现在，使用kernel32.dll的下一个进程将具有与前一个程序相同的55AA1122的地址。只有当进程都是相同的体系结构时。

32位进程的内核32 will导出地址与其他USER32模块导出的地址相同(例如NTDLL、NTDLL等)。64位进程将有不同的地址与32位进程，但64位进程都将有相同的地址的Windows模块，也！

远程线程的创建不是一个“意外”，微软有意实现它。为什么？Microsoft在Windows期间经常使用它，也用于异步过程调用。微软也经常为自己的日常程序热补东西，作为反逆转的伎俩，或者如果他们把源代码丢给自己的项目，哈哈。

现在，对于将内核32.dll加载到进程中，它只加载到使用Win32 API的进程中。这包括世界上99%的程序，但是可以编译一个不使用它的本地进程。然而，这将迫使您完全使用本机API而不使用Win32 API，而名为smss.exe的smss.exe进程正是这样做的。您还可以编译本机DLL，这些DLL甚至没有普通的Win32 API DLL条目例程。

简而言之，Windows模块例程的地址每次引导都会更改一次。它将保持不变，直到下一次重新启动，依此类推。32位进程和64位进程一样，对每个进程都有自己的Windows模块共享地址.因此，除非使用32位Kernel32.dll LoadLibraryA地址，否则在将DLL注入作为32位进程的目标时，不能使用64位进程的LoadLibraryA地址。一个更好的想法是无论如何使用LdrLoadDll，或者仅仅是一个反射DLL加载程序存根的shell代码注入。

Answer 3

LoadLibraryA驻留在kernel32.dll中，该模块总是加载到每个进程中，并且碰巧在每个进程中被加载到相同的地址。