零、先看看相关函数的原型 ：

    1.模块的加载与卸载
HMODULE WINAPI LoadLibraryA(const char* name);
HMODULE WINAPI LoadLibraryW(const wchar_t* name);
BOOL WINAPI FreeLibrary(HMODULE module);

    2.线程函数占位符
DWORD WINAPI ThreadFunc(LPVOID param); // windows.h
unsigned __stdcall thread_proc(void* param); // process.h

    3.获得线程返回值
BOOL WINAPI GetExitCodeThread(HANDLE thread,LPDWORD result);



一、 利用CreateRemoteThread在远程进程中加载模块应该是没有问题的。

LoadLibraryA(const char* );
LoardLibraryW(const wchar_t* );
ThreadFunc(LPVOID );
thread_proc(void* );
第1个参数均为指针，位长相同。

所以仍然可以
以模块加载函数为线程函数
以被加载模块的文件名为线程参数
启动远程线程
CreateRemoteThread( ... , LoadLibraryA , "injectant.dll" , ...);

当然， 这是伪代码。
该方法能工作还需要取得LoadLibraryA在远程进程中的地址，和在远程进程的地址空间中，写入"injectant.dll"。

二、 利用CreateRemoteThread在远程进程中卸载模块也应该是没有问题的。

FreeLibrary(HMODULE );
ThreadFunc(LPVOID );
thread_proc(void* );

指针为了能指向64位的地址空间， 需要64位长。
HMODULE用来表示模块的基地址， 而地址空间是64位， HMODULE也需要64位。

所以仍然可以
以模块卸载函数为线程函数
以被加载模块句柄为线程参数
启动远程线程
CreateRemoteThread( ... , FreeLibrary , hModule , ... );

三、 问题发生在：

如何取得被远程进程加载的模块句柄？

    三.1、 线程返回值

线程函数的原型从返回值类型可以分为2种： DWORD和unsigned

可以说，返回机器字长， 也就是unsigned是比较合理的。
而依赖于返回DWORD的代码也不会因为返回类型改为unsigned而出问题。
因为前者需求更少， 后者给于更多。
前者还需要作一次截断， 来取得32位的DWORD返回值。

线程函数以DWORD的原因， 可能是在16位机器上， 如果使用机器字长作返回值， 取值范围太少。
所以，线程函数的返回值， 有可能会改为 uint_least32_t
16位机器上， 使用2个机器字长拼装返回值  32位
32位机器上， 使用机器字长作返回值            32位
64位机器上， 使用机器字长作返回值            64位

也就是说， 线程函数是有可能返回64位的模块句柄的。
为什么不呢？  难道要在返回前作没必要的自行截断么？

    三.2、 取得线程返回值

BOOL GetExitCodeThread(HANDLE thread,LPDWORD result);

可以将第2个参数改为指向机器字长数据的指针么？  也许不能。
因为函数要求更多 ： result必须是指向机器字长数据的指针， 即result所指的连续8个字节都是可写的。
但调用者提供更少 ： 调用者很有可能不提供机器字长， 而只提供指向连续4个字节的指针。

想想如下代码是多么普遍（尤其是喜欢使用windows定义的数据类型的同学）
DWORD code = 0;
GetExitCodeThread( thread , &code );
GetExitCodeThread绝对不可以写入8字节内容。

所以， 很有可能无法取得前一步所加载的模块的句柄， 从而无法卸载。



四、 总结

在64位机上， 仍然可以使用该技术远程加载模块。

但是否可以卸载， 还得看：
1. 64位的线程返回值类型
2. 取得线程返回值的函数能够取得多少字节的返回值。
如果2者都是64位， 该技术依然可行。