CreateRemoteThread 和 LoadLibrary 技术：
通常，任何进程都可以通过LoadLibrary动态地加载DLL，但是我们如何强制一个外部进程调用该函数呢？答案是CreateRemoteThread。
让我们先来看看LoadLibrary和FreeLibrary的函数声明：
HINSTANCE LoadLibrary(
LPCTSTR lpLibFileName // address of filename of library module
);
BOOL FreeLibrary(
HMODULE hLibModule // handle to loaded library module
);
再和CreateRemoteThread的线程过程（thread procedure）ThreadProc比较一下：
DWORD WINAPI ThreadProc(
LPVOID lpParameter // thread data
);
你会发现所有的函数都有同样的调用约定（calling convention）、都接受一个32位的参数并且返回值类型的大小也一样。也就是说，我们可以把LoadLibrary/FreeLibrary的指针作为参数传递给CrateRemoteThread。
然而，还有两个问题（参考下面对CreateRemoteThread的说明）
1． 传递给ThreadProc的lpStartAddress 参数必须为远程进程中的线程过程的起始地址。
2． 如果把ThreadProc的lpParameter参数当做一个普通的32位整数（FreeLibrary把它当做HMODULE）那么没有如何问题，但是如果把它当做一个指针（LoadLibrary把它当做一个char*），它就必须指向远程进程中的内存数据。
第一个问题其实已经迎刃而解了，因为LoadLibrary和FreeLibrary都是存在于kernel32.dll中的函数，而kernel32可以保证任何“正常”进程中都存在，且其加载地址都是一样的。（参看附录A）于是LoadLibrary/FreeLibrary在任何进程中的地址都是一样的，这就保证了传递给远程进程的指针是个有效的指针。
第二个问题也很简单：把DLL的文件名（LodLibrary的参数）用WriteProcessMemory复制到远程进程。
所以，使用CreateRemoteThread和LoadLibrary技术的步骤如下：
1． 得到远程进程的HANDLE（使用OpenProcess）。
2． 在远程进程中为DLL文件名分配内存（VirtualAllocEx）。
3． 把DLL的文件名（全路径）写到分配的内存中（WriteProcessMemory）
4． 使用CreateRemoteThread和LoadLibrary把你的DLL映射近远程进程。
5． 等待远程线程结束（WaitForSingleObject），即等待LoadLibrary返回。也就是说当我们的DllMain（是以DLL_PROCESS_ATTACH为参数调用的）返回时远程线程也就立即结束了。
6． 取回远程线程的结束码（GetExitCodeThtread），即LoadLibrary的返回值――我们DLL加载后的基地址（HMODULE）。
7． 释放第2步分配的内存（VirtualFreeEx）。
8． 用CreateRemoteThread和FreeLibrary把DLL从远程进程中卸载。调用时传递第6步取得的HMODULE给FreeLibrary（通过CreateRemoteThread的lpParameter参数）。
9． 等待线程的结束（WaitSingleObject）。
同时，别忘了在最后关闭所有的句柄：第4、8步得到的线程句柄，第1步得到的远程进程句柄。
现在我们看看LibSpy的部分代码，分析一下以上的步骤是任何实现的。为了简单起见，没有包含错误处理和支持Unicode的代码。
HANDLE hThread;
char szLibPath[_MAX_PATH]; // "LibSpy.dll"的文件名 (包含全路径!);
void* pLibRemote; // szLibPath 将要复制到地址
DWORD hLibModule; //已加载的DLL的基地址（HMODULE）;
HMODULE hKernel32 = ::GetModuleHandle("Kernel32");
//初始化 szLibPath
//...
// 1. 在远程进程中为szLibPath 分配内存
// 2. 写szLibPath到分配的内存
pLibRemote = ::VirtualAllocEx( hProcess, NULL, sizeof(szLibPath),MEM_COMMIT, PAGE_READWRITE );
::WriteProcessMemory( hProcess, pLibRemote, (void*)szLibPath,sizeof(szLibPath), NULL );
// 加载 "LibSpy.dll" 到远程进程
// (通过 CreateRemoteThread & LoadLibrary)
hThread = ::CreateRemoteThread( hProcess, NULL, 0,(LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,"LoadLibraryA" ),pLibRemote, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );
//取得DLL的基地址
::GetExitCodeThread( hThread, &hLibModule );
//扫尾工作
::CloseHandle( hThread );
::VirtualFreeEx( hProcess, pLibRemote, sizeof(szLibPath), MEM_RELEASE );
我们放在DllMain中的真正要注入的代码（比如为SendMessage）现在已经被执行了（由于DLL_PROCESS_ATTACH），所以现在可以把DLL从目的进程中卸载了。
// 从目标进程卸载LibSpu.dll
// (通过 CreateRemoteThread & FreeLibrary)
hThread = ::CreateRemoteThread( hProcess, NULL, 0,(LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,"FreeLibrary" ),(void*)hLibModule, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );
// 扫尾工作
::CloseHandle( hThread );
进程间通讯
到目前为止，我们仅仅讨论了任何向远程进程注入DLL，然而，在多数情况下被注入的DLL需要和你的程序以某种方式通讯（记住，那个DLL是被映射到远程进程中的，而不是在你的本地程序中！）。以密码间谍为例：那个DLL需要知道包含了密码的的控件的句柄。很明显，这个句柄是不能在编译期间硬编码（hardcoded）进去的。同样，当DLL得到密码后，它也需要把密码发回我们的程序。
幸运的是，这个问题有很多种解决方案：文件映射（Mapping），WM_COPYDATA，剪贴板等。还有一种非常便利的方法#pragma data_seg。这里我不想深入讨论因为它们在MSDN（看一下Interprocess Communications部分）或其他资料中都有很好的说明。我在LibSpy中使用的是#pragma data_seg。
附录
A) 为什么kernel32.dll和user32.dll中是被映射到相同的内存地址？
我的假定：以为微软的程序员认为这么做可以优化速度。让我们来解释一下这是为什么。
一般来说，一个可执行文件包含几个段，其中一个为“.reloc”段。
当链接器生成EXE或DLL时，它假定这个文件会被加载到一个特定的地址，也就是所谓的假定/首选加载/基地址（assumed/preferred load/base address）。内存映像（image）中的所有绝对地址都时基于该“链接器假定加载地址”的。如果由于某些原因，映像没有加载到这个地址，那么PE加载器（PE loader）就不得不修正该映像中的所有绝对地址。这就是“.reloc”段存在的原因：它包含了一个该映像中所有的“链接器假定地址”与真正加载到的地址之间的差异的列表（注意：编译器产生的大部分指令都使用一种相对寻址模式，所以，真正需要重定位[relocation]的地方并没有你想像的那么多）。如果，从另一方面说，加载器可以把映像加载到链接器首选地址，那么“.reloc”段就会被彻底忽略。
但是，因为每一个Win32程序都需要kernel32.dll，大部分需要user32.dll，所以如果总是把它们两个映射到其首选地址，那么加载器就不用修正kernel32.dll和user32.dll中的任何（绝对）地址，加载时间就可以缩短。
让我们用下面的例子来结束这个讨论：
把一个APP.exe的加载地址改为kernel32的（/base:"0x77e80000"）或user32的（/base:"0x77e10000"）首选地址。如果App.exe没有引入UESE32，就强制LoadLibrary。然后编译App.exe，并运行它。你会得到一个错误框（“非法的系统DLL重定位”），App.exe无法被加载。
为什么？当一个进程被创建时，Win2000和WinXP的加载器会检查kernel32.dll和user32.dll是否被映射到它们的首选地址（它们的名称是被硬编码进加载器的），如果没有，就会报错。在WinNT4 中ole32.dll也会被检查。在WinNT3.51或更低版本中，则不会有任何检查，kernel32.dll和user32.dll可以被加载到任何地方。唯一一个总是被加载到首选地址的模块是ntdll.dll，加载器并不检查它，但是如果它不在它的首选地址，进程根本无法创建。
总结一下：在WinNT4或更高版本的操作系统中：
●总被加载到它们的首选地址的DLL有：kernel32.dll，user32.dll和ntdll.dll。
●Win32程序（连同csrss.exe）中一定存在的DLL：kernel32.dll和ntdll.dll。
●所有进程中都存在的dll：ntdll.dll。
B) /GZ编译开关
在Debug时，/GZ开关默认是打开的。它可以帮你捕捉一些错误（详细内容参考文档）。但是它对我们的可执行文件有什么影响呢？
当/GZ被使用时，编译器会在每个函数，包含函数调用中添加额外的代码（添加到每个函数的最后面）来检查ESP栈指针是否被我们的函数更改过。但是，等等，ThreadFunc中被添加了一个函数调用？这就是通往灾难的道路。因为，被复制到远程进程中的ThreadFunc将调用一个在远程进程中不存在的函数。
C) static函数和增量连接（Incremental linking）
增量连接可以缩短连接的时间，在增量编译时，每个函数调用都是通过一个额外的JMP指令来实现的（一个例外就是被声明为static的函数！）这些JMP允许连接器移动函数在内存中的位置而不用更新调用该函数的CALL。但是就是这个JMP给我们带来了麻烦：现在ThreadFunc和AfterThreadFunc将指向JMP指令而不是它们的真实代码。所以，当计算ThreadFunc的大小时:
const int cbCodeSize = ((LPBYTE) AfterThreadFunc - (LPBYTE) ThreadFunc);
实际得到的将是指向ThreadFunc和AfterThreadFunc的JMP指令之间的“距离”。现在假设我们的ThreadFunc在004014C0，和其对应的JMP指令在00401020
:00401020 jmp 004014C0
...
:004014C0 push EBP ; ThreadFunc的真实地址
:004014C1 mov EBP, ESP
...
然后，
WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);
将把“JMP 004014C0”和其后的cbCodeSize范围内的代码而不是ThreadFunc复制到远程进程。远程线程首先会执行“JMP 004010C0”，然后一直执行到这个进程代码的最后一条指令（译者注：这当然不是我们想要的结果）。
然而，如果一个函数被声明为static，就算使用增量连接，也不会被替换为JMP指令。这就是为什么我在规则#4中说把ThreadFunc和AfterThreadFunc声明为static或禁止增量连接的原因了。（关于增量连接的其他方面请参看Matt Pietrek写的“Remove Fatty Deposits from Your Applications Using Our 32-bit Liposuction Tools”）
D) 为什么ThreadFunc只能有4K的局部变量？
局部变量总是保存在栈上的。假设一个函数有256字节的局部变量，当进入该函数时（更确切地说是在functions prologue中），栈指针会被减去256。像下面的函数：
void Dummy(void) {
BYTE var[256];
var[0] = 0;
var[1] = 1;
var[255] = 255;
}
会被编译为类似下面的指令：
:00401000 push ebp
:00401001 mov ebp, esp
:00401003 sub esp, 00000100 ; change ESP as storage for
; local variables is needed
:00401006 mov byte ptr [esp], 00 ; var[0] = 0;
:0040100A mov byte ptr [esp+01], 01 ; var[1] = 1;
:0040100F mov byte ptr [esp+FF], FF ; var[255] = 255;
:00401017 mov esp, ebp ; restore stack pointer
:00401019 pop ebp
:0040101A ret
请注意在上面的例子中ESP（栈指针）是如何被改变的。但是如果一个函数有多于4K的局部变量该怎么办？这种情况下，栈指针不会被直接改变，而是通过一个函数调用来正确实现ESP的改变。但是就是这个“函数调用”导致了ThreadFunc的崩溃，因为它在远程进程中的拷贝将会调用一个不存在的函数。
让我们来看看文档关于栈探针（stack probes）和/Gs编译选项的说明：
“/Gssize选项是一个允许你控制栈探针的高级特性。栈探针是编译器插入到每个函数调用中的一系列代码。当被激活时，栈探针将温和地按照存储函数局部变量所需要的空间大小来移动。
如果一个函数需要大于size指定的局部变量空间，它的栈探针将被激活。默认的size为一个页的大小（在80x86上为4k）。这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互，在运行期间向程序栈增加已提交的内存总数。
我能确定你们对上面的叙述（“栈探针将温和地按照存储函数局部变量所需要的空间大小来移动”）感到奇怪。这些编译选项（他们的描述！）有时候真的让人很恼火，特别是当你想真的了解它们是怎么工作的时候。打个比方，如果一个函数需要12kb的空间来存放局部变量，栈上的内存是这样“分配”的
sub esp, 0x1000 ; 先“分配”4 Kb
test [esp], eax ; touches memory in order to commit a
; new page (if not already committed)
sub esp, 0x1000 ; “分配”第二个 4 Kb
test [esp], eax ; ...
sub esp, 0x1000
test [esp], eax
注意栈指针是如何以4Kb为单位移动的，更重要的是每移动一步后使用test对栈底的处理（more importantly, how the bottom of the stack is "touched" after each step）。这可以确保了在“分配”下一个页之前，包含栈底的页已经被提交。
继续阅读文档的说明：
“每一个新的线程会拥有（receives）自己的栈空间，这包括已经提交的内存和保留的内存。默认情况下每个线程使用1MB的保留内存和一个页大小的以提交内存。如果有必要，系统将从保留内存中提交一个页。”（看MSDN中GreateThread > dwStackSize > “Thread Stack Size”）
..现在为什么文档中说“这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互”也很清楚了。
E) 为什么我要把多于3个case分支的swith分割开来呢？
同样，用例子来说明会简单些：
int Dummy( int arg1 )
{
int ret =0;
switch( arg1 ) {
case 1: ret = 1; break;
case 2: ret = 2; break;
case 3: ret = 3; break;
case 4: ret = 0xA0B0; break;
}
return ret;
}
将会被编译为类似下面的代码：
Address OpCode/Params Decoded instruction
--------------------------------------------------
; arg1 -> ECX
:00401000 8B4C2404 mov ecx, dword ptr [esp+04]
:00401004 33C0 xor eax, eax ; EAX = 0
:00401006 49 dec ecx ; ECX --
:00401007 83F903 cmp ecx, 00000003
:0040100A 771E ja 0040102A
; JMP to one of the addresses in table <B>***</B>
; note that ECX contains the offset
:0040100C FF248D2C104000 jmp dword ptr [4*ecx+0040102C]
:00401013 B801000000 mov eax, 00000001 ; case 1: eax = 1;
:00401018 C3 ret
:00401019 B802000000 mov eax, 00000002 ; case 2: eax = 2;
:0040101E C3 ret
:0040101F B803000000 mov eax, 00000003 ; case 3: eax = 3;
:00401024 C3 ret
:00401025 B8B0A00000 mov eax, 0000A0B0 ; case 4: eax = 0xA0B0;
:0040102A C3 ret
:0040102B 90 nop
; 地址表 ***
:0040102C 13104000 DWORD 00401013 ; jump to case 1
:00401030 19104000 DWORD 00401019 ; jump to case 2
:00401034 1F104000 DWORD 0040101F ; jump to case 3
:00401038 25104000 DWORD 00401025 ; jump to case 4
看到switch-case是如何实现的了吗？
它没有去测试每个case分支，而是创建了一个地址表（address table）。我们简单地计算出在地址表中偏移就可以跳到正确的case分支。想想吧，这真是一个进步，假设你有一个50个分支的switch语句，假如没有这个技巧，你不的不执行50次CMP和JMP才能到达最后一个case，而使用地址表，你可以通过一次查表即跳到正确的case。使用算法的时间复杂度来衡量：我们把O（2n）的算法替换成了O(5)的算法，其中：
1． O代表最坏情况下的时间复杂度。
2． 我们假设计算偏移（即查表）并跳到正确的地址需要5个指令。
现在，你可能认为上面的情况仅仅是因为case常量选择得比较好，（1，2，3，4，5）。幸运的是，现实生活中的大多数例子都可以应用这个方案，只是偏移的计算复杂了一点而已。但是，有两个例外：
●如果少于3个case分支，或
●如果case常量是完全相互无关的。（比如 1， 13， 50， 1000）。
最终的结果和你使用普通的if-else if是一样的。
有趣的地方：如果你曾经为case后面只能跟常量而迷惑的话，现在你应该知道为什么了吧。这个值必须在编译期间就确定下来，这样才能创建地址表。
回到我们的问题！
注意到0040100C处的JMP指令了吗？我们来看看Intel的文档对十六进制操作码FF的说明：
Opcode Instruction Description
FF /4 JMP r/m32 Jump near, absolute indirect,
address given in r/m32
JMP使用了绝对地址！也就是说，它的其中一个操作数（在这里是0040102C）代表一个绝对地址。还用多说吗？现在远程的ThreadFunc会盲目第在地址表中004101C然后跳到这个错误的地方，马上使远程进程挂掉了。
F) 到底是什么原因使远程进程崩溃了？
如果你的远程进程崩溃了，原因可能为下列之一：
1． 你引用了ThreadFunc中一个不存在的字符串。
2． ThreadFunc中一个或多个指令使用了绝对寻址（看附录E中的例子）
3． ThreadFunc调用了一个不存在的函数（这个函数调用可能是编译器或连接器添加的）。这时候你需要在反汇编器中寻找类似下面的代码：
:004014C0 push EBP ; entry point of ThreadFunc
:004014C1 mov EBP, ESP
...
:004014C5 call 0041550 ; 在这里崩溃了
; remote process
...
:00401502 ret
如果这个有争议的CALL是编译器添加的（因为一些不该打开的编译开关比如/GZ打开了），它要么在ThreadFunc的开头要么在ThreadFunc接近结尾的地方
不管在什么情况下，你使用CreateRemoteThread & WriteProcessMemory技术时必须万分的小心，特别是编译器/连接器的设置，它们很可能会给你的ThreadFunc添加一些带来麻烦的东西。
远程线程来进行DLL注入 实例：
１）、取得远程进程的进程ID；
２）、在远程进程空间中分配一段内存用来存放要注入的DLL完整路径；
３）、将要注入的DLL的路径写到刚才分配的远程进程空间；
４）、从Kernel32.dll中取得LoadLibray的地址；
５）、调用CreateRemoteThread函数以从Kernel32.dll中取得的LoadLibrary函数的地址为线程函数的地址，以我们要注入的DLL文件名为参数，创建远程线程；
在第二三步中，为什么要把我们要注入的DLL的文件名写到远程进程的地址空间进行操作，《WINDOWS核心编程》中是这样描述的：“（要注入的DLL文件名）字符串是在调用进程的地址空间中。该字符串的地址已经被赋予新创建的远程线程，该线程将它传递给LoadLibraryA。但是，当LoadLibraryA取消对内存地址的引用时， DLL路径名字符串将不再存在，远程进程的线程就可能引发访问违规”；
至于第四步中为什么不直接对LoadLibrary进行调用，《WINDOWS核心编程》中是这样描述的：“如果在对CreateRemoteThread的调用中使用一个对LoadLibraryA的直接引用，这将在你的模块的输入节中转换成LoadLibraryA的形实替换程序的地址。将形实替换程序的地址作为远程线程的起始地址来传递，会导致远程线程开始执行一些令人莫名其妙的东西。其结果很可能造成访问违规。”
下面开始我们的例子。
１、先创建一个DLL工程，代码如下：
extern "C" __declspec(dllexport) __stdcall void About();
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{
return 1;
}
//---------------------------------------------------------------------------
void __declspec(dllexport) __stdcall About()
{
MessageBox(NULL,"这个DLL模块演示了DLL的注入技术。/n"
"通过程序的调用LoadLibrary将本模块注入到指定的"
"进程的地址空间中。", "DLL注入技术",
MB_ICONINFORMATION + MB_OK);
}
编译它，就得到我们用来注入的DLL文件了。
２、编写测试工程。用BCB建立一个应用程序工程，在窗体中放入两个按钮，一个用来注入，一个用来撤消，另外还有一个文本框控件，用来等待用户输入进程ID号。代码如下：
DLL注入函数
BOOL WINAPI LoadLib(DWORD dwProcessId, LPWSTR lpszLibName)
{
HANDLE hProcess = NULL;
hThread = NULL;
LPWSTR lpszRemoteFile = NULL;
// 打开远程进程
hProcess = OpenProcess(PROCESS_CREATE_THREAD| PROCESS_VM_OPERATION | PROCESS_VM_WRITE, FALSE, dwProcessId);
if (hProcess == NULL)
{
MessageBox(NULL, ("OpenProcess failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE
}
// 在远程进程中分配存贮DLL文件名的空间
lpszRemoteFile = (LPWSTR)VirtualAllocEx(hProcess, NULL, sizeof(WCHAR) * lstrlenW(lpszLibName) + 1, MEM_COMMIT, PAGE_READWRITE);
if (lpszRemoteFile == NULL)
{
MessageBox(NULL, ("VirtualAllocEx failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 复制DLL文件名到远程刚分配的进程空间
if (!WriteProcessMemory(hProcess, lpszRemoteFile, (PVOID)lpszLibName, sizeof(WCHAR) * lstrlenW(lpszLibName) + 1, NULL))
{
MessageBox(NULL, ("WriteProcessMemory failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 取得LoadLibrary函数在Kennel32.dll中的地址
PTHREAD_START_ROUTINE pfnThreadRtn = (PTHREAD_START_ROUTINE)GetProcAddress( GetModuleHandle("Kernel32.dll"),"LoadLibraryW");
if (pfnThreadRtn == NULL)
{
MessageBox(NULL, ("GetProcAddress failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 创建远程线程
hThread = CreateRemoteThread(hProcess, NULL, 0, pfnThreadRtn, lpszRemoteFile, // 要加载的DLL名 0, NULL); //pfnThreadRtn为 LoadLibrary地址，lpszRemoteFile, 要加载的DLL名
if (hThread == NULL)
{
MessageBox(NULL, ("CreateRemoteThread failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 等待线程返回
WaitForSingleObject(hThread, INFINITE);
// 释放进程空间中的内存
VirtualFreeEx(hProcess, lpszRemoteFile, 0, MEM_RELEASE);
// 关闭句柄
CloseHandle(hThread);
CloseHandle(hProcess);
return TRUE;
}
在进程空间释放注入的DLL
BOOL WINAPI FreeLib(DWORD dwProcessId, LPTSTR lpszLibName)
{
HANDLE hProcess = NULL;
hThread = NULL;
hthSnapshot = NULL;
MODULEENTRY32 hMod = {sizeof(hMod)};
BOOL bFound;
// 取得指定进程的所有模块映象
hthSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, dwProcessId);
if (hthSnapshot == NULL)
{
MessageBox(NULL, ("CreateRemoteThread failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 取得所有模块列表中的指定的模块
BOOL bMoreMods = Module32First(hthSnapshot, &hMod);
if (bMoreMods == FALSE)
{
MessageBox(NULL, ("Module32First failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 循环取得想要的模块
for (;bMoreMods; bMoreMods = Module32Next(hthSnapshot, &hMod))
{
//ShowMessage(String(hMod.szExePath) + " | " + String(lpszLibName));
if ((strcmp(hMod.szExePath, lpszLibName) == 0) || (strcmp(hMod.szModule, lpszLibName) == 0))
break;
}
// 打开进程
hProcess = OpenProcess(PROCESS_CREATE_THREAD | PROCESS_VM_OPERATION, FALSE, dwProcessId);
if (hProcess == NULL)
{
MessageBox(NULL, ("OpenProcess failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 取得FreeLibrary函数在Kernel32.dll中的地址
PTHREAD_START_ROUTINE pfnThreadRtn = (PTHREAD_START_ROUTINE)GetProcAddress( GetModuleHandle("Kernel32.dll"), "FreeLibrary");
if (pfnThreadRtn == NULL)
{
MessageBox(NULL, ("GetProcAddress failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 创建远程线程来执行FreeLibrary函数
hThread = CreateRemoteThread(hProcess, NULL, 0, pfnThreadRtn, hMod.modBaseAddr, 0, NULL);
if (hThread == NULL)
{
MessageBox(NULL, ("CreateRemoteThread failed with error " + IntToStr(GetLastError())).c_str(), "Error", MB_ICONINFORMATION + MB_OK);
return FALSE;
}
// 等待线程返回
WaitForSingleObject(hThread, INFINITE);
// 关闭句柄
CloseHandle(hThread);
CloseHandle(hthSnapshot);
CloseHandle(hProcess);
return TRUE;
}
//---------------------------------------------------------------------------
void __fastcall TfrmMain::btLoadClick(TObject *Sender)
{
m_szDllFile = Application->ExeName;
m_szDllFile = m_szDllFile.SubString(0, m_szDllFile.Length()- String(StrRScan(m_szDllFile.c_str(),'//')).Length());
m_szDllFile = m_szDllFile + "//DllLib.dll"; m_dwProcessId = StrToInt(Edit->Text);
LoadLib(m_dwProcessId, WideString(m_szDllFile).c_bstr());
}
//---------------------------------------------------------------------------
void __fastcall TfrmMain::btUnloadClick(TObject *Sender)
{
FreeLib(m_dwProcessId, m_szDllFile.c_str());
}
//---------------------------------------------------------------------------
把上面的工程编译成生EXE文件，接下来我们就可以进行DLL的注入测试了。先打开记事本（当然你也可以打开其它的进程，或直接在已经加载的进程测试），通过WINDOWS的任务管理器，找到它的进程ID。然后运行我们的测试工程，在文本框中输入进程ID，点击注入。这时我们就可以通过我们最先写的小工具来查看它的进程空间中所包含的模块了，你会发现，我们的DLL已经成功加载到了它的进程空间中。点击卸载，取消DLL的注入。
164
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
