关于CreateRemoteThread引起对象进程崩溃的处理

蓝色的忧郁

要做卸载某个进程中的某个已加载模块,baidu网上做法,用CreateRemoteThread,WriteProcessMemory,Of Course(此Of Course确实是Of Course,CodeProject确实very nice,打广告了啊o.O)在codeproject上搜到相关的文章,其中一篇"Three Ways to Inject Your Code into Another Process"(- -b,后面有后续联系),对英文不感冒,下了source code和demo code see了2 see,发现跟网上代码差不多,so忽略
用网上的代码实验,并排除其中几个显眼的错误,但是...
bk~~~bk~~~持续的bk,宿主进程持续的crash,Module Handle?~~~OK,WriteProcessMemory?~~~OK,ThreadFunc?~~~OK
郁闷的持续排错中......
大致确定在CreateRemoteThread时,在宿主进程出错
baidu"CreateRemoteThread 崩溃"发现同病相怜的xd,~~~以及一篇"向其他进程注入代码的三种方法(上)_远程控制技术",阅读中发现似曾相识,目示标题数秒,省悟,翻出前面的"Three Ways to Inject Your Code into Another Process",依相关章节查阅,找到问题所在,排除问题
依旧感叹ing~~~

以下为翻译加经验,经验是网上代码中几处比较奇怪的错误,奇怪的是传播如此之广,转载如此之多,怎么还有这种错误呢?
1.传递到Remote Thread的参数存的应为MODULEENTRY32.hModule,而非MODULEENTRY32.modBaseAddr
2.扫尾工作:Free内存,CloseHandle,WaitForSingleObject
造成宿主进程崩溃的可能原因,大致由于ThreadFunc中的错误引起:
1.不应该在ThreadFunc中调除在kernel32.dll
and user32.dll以外的函数,而user32.dll有时候也不会被程序加载
2.不能引用任何的static strings.编译时此string已放入本进程的.data段,只用pointer引用,典型例子:记得传入MessageBox的函数指针,调用时却直接用MessageBox(NULL,"Hello","Hello",MB_OK);此测试方法人数应该不少吧
3.去掉/GZ编译选项
4.定义ThreadFunc时要不用static,要不就将链接选项Enable Incremental Link设为NO.Incremental Link与Normal Link的区别是in incrementally linked ones each function call goes through an extra JMP instruction emitted by the linker (an exception to this rule are functions declared as static!). 即增量链接时,对函数的引用都转化为由一个jmp指令跳转到真实的代码.这样链接时链接器只需要更新jmp后面的地址,而不需要call指令后面的地址.个人认为这条非常重要