如果以上的答案无法解决你的问题，你可以把源文件上传一份来，帮你修改。
希望我的回答对你有所帮助！Kiss灬小猪
如果你的dll也是C#生成的dll，你可以把程序和你的dll合并在一起，用工具 ILMerge （微软出的小工具），c/c++ dll藏不了，不过也有变态方法，把它们添加为项目的Resources，用时保存到本地。进程隐藏技术用得最多的地方就是在病毒和木马中，因为这些不适合出现在阳光下的程序，越隐蔽生存率就越高。在当今Windows环境下，病毒和木马流传得越来越广泛，让读者适当了解这方面的技术可以在防治方面起到积极的作用，技术这种东西就是这样，大家都知道的“秘技”也就不再是“秘技”了，所以，大家都知道了进程隐藏是怎么一回事，进程隐藏起来也就不那么隐蔽了。13.4.1 在Windows 9x中隐藏进程
在Windows 9x系列 *** 作系统中，可以通过Kernel32.dll中的一个未公开函数来完成隐藏功能，这个函数就是RegisterServiceProcess，该函数的功能是将一个进程注册为系统服务进程，由于Windows的任务管理器并不列出系统服务进程，所以可以用它来隐藏进程，不过该函数在Windows NT系列中并不存在。
RegisterServiceProcess函数的使用方法是：
invoke RegisterServiceProcess,dwProcessID,dwFlag
dwProcessID指明目标进程的进程ID，参数dwFlag指定是注册还是撤销，指定TRUE的话，进程被注册为系统服务进程，如果指定为FALSE，则进程的属性恢复为普通进程属性。
Kernel32.lib导入库中并没有这个函数的导入信息，如果要使用这个函数，程序需要自己装入库文件并使用GetProcAddress函数获取入口地址后使用（方法请复习第11章）。所附光盘的Chapter13\HideProcess9x目录中的例子程序演示了该函数的使用方法。
13.4.2 Windows NT中的远程线程
在Windows 9x中将进程注册为系统服务进程就能够从任务管理器中隐形，但在NT下就不同了。首先，NT下不存在RegisterServiceProcess函数；其次，NT的任务管理器会列出所有的进程（包括系统进程），即使一个进程将自己的可执行文件放在很隐蔽的目录中，文件名还是会被任务管理器列出来，所以想让别人看不见进程是不可能的。
当然，如果不用进程也能运行程序的话，那是最好不过的办法了，但是不用进程是无法执行文件的。
再从另一个角度考虑，如果进程显示的不是正确的名称呢，这也可以起到掩护作用，如果在DLL中执行我们的代码，系统报告的进程名称是装入DLL的进程的名称，而不是DLL本身的名称。
在Windows NT中还有另一种办法，那就是使用远程线程，使用它可以在其他进程中创建一个线程，由于线程是被所属进程拥有的，所以任务管理器中列出来的还是所属进程的名称。
1. Windows NT的远程 *** 作函数
有两个函数可以用来实现上述功能：VirtualAllocEx和CreateRemoteThread。这两个函数都只能在Windows NT下使用。
VirtualAllocEx函数可以用来在其他进程的地址空间内申请内存，当然申请到的内存也是位于目标进程的地址空间内的，将这个函数和WriteProcessMemory函数配合就可以在目标进程的地址空间中“造”出任何东西来。
在10.1.5节中已经介绍过虚拟内存管理函数VirtualAlloc，VirtualAllocEx函数就是这个函数的扩充，相比之下，VirtualAllocEx函数多了一个参数hProcess，其他参数定义和使用的方法都和VirtualAlloc函数相同，读者可以回过头去查看这些参数的用法。新增的hProcess参数用来指定要申请内存的进程句柄，如果需要在目标进程中使用VirtualAllocEx函数，那么必须对进程拥有PROCESS_VM_OPERATION权限。
如果内存申请成功，函数返回一个指针，指向申请到的内存块，当然这个指针是针对目标进程的地址空间的。如果内存申请失败，函数返回NULL。
CreateRemoteThread函数用来在其他进程内创建一个线程，当然创建的线程是运行于目标进程的地址空间内的，它和目标进程自己创建的线程并没有什么区别。函数的用法是：
该函数是CreateThread函数的扩充，与CreateThread相比，CreateRemoteThread函数多了一个hProcess参数，其他所有参数的定义和用法都与CreateThread的参数相同。hProcess用来指定要创建线程的目标进程句柄。注意：lpStartAddress指向的线程函数的地址是位于目标进程的地址空间内的。如果需要在目标进程中使用CreateRemoteThread函数，那么必须对进程拥有PROCESS_CREATE_THREAD权限。
使用VirtualAllocEx和CreateRemoteThread函数，再配合WriteProcessMemory函数，就能够让一段代码在其他进程中运行，由于远程线程是属于目标进程的，所以在任务管理器中不会产生新的进程，事实上，谁也不会发现列出的某个进程中会多了一个不属于它自己控制的线程。整个实现的过程归纳如下：
（1）使用VirtualAllocEx函数在目标进程中申请一块内存，内存块的长度必须能够容纳线程使用的代码和数据，内存块的属性应该是PAGE_EXECUTE_READWRITE，这样拷贝到内存块中的代码就可以被执行。
（2）使用WriteProcessMemory函数将需要在远程线程中执行的代码（包括它使用的数据）拷贝到第（1）步申请到的内存块中。
（3）使用CreateRemoteThread函数创建远程线程。
2. 远程线程存在的技术问题
实现远程线程的框架结构已经搭好了，但是在具体的实现中还有一些技术问题需要解决，归纳起来主要有两点：代码的重定位问题和函数的导入问题。
这时候，A1FC0F4000机器码还是被解释为存取00400FFCh地址，而实际的变量地址已经被搬到00800FFCh处了，这就是说，指令存取的是错误的地址，所以这段指令要想正常执行，就必须放在00401000h地址开始的地方，如果想搬到别的地方去执行，就必须对访问全局变量的指令进行修正，这就是重定位的问题
由此可见，如果想把这段指令放到远程线程中去执行，由于无法保证将代码放到00401000h处，所以几乎可以肯定它是不能正常工作的，但是根据代码最后执行的实际位置来修正某些指令的话，在远程线程中执行它还是可行的。
对于高级语言来说，重定位问题是个致命的问题，是根本不可能解决的，因为高级语言无法在机器码级别上进行细微的 *** 作，所以，即使在相对比较低级的C语言中也无法将一段代码拷贝到远程线程中去执行，大部分的教科书和资料在介绍远程线程的时候，都采用了变通的方法，就是将DLL嵌入到目标进程中去执行。
如Jeffrey Richer的《Windows高级编程指南》中就介绍了使用远程线程将DLL注入目标进程的方法，其实实现步骤是将需要远程执行的代码写到一个DLL中，然后在目标进程中申请一块内存并将DLL文件名写入，最后将目标进程地址空间中的LoadLibrary函数当做线程函数来执行，输入的参数就是前面的DLL文件名，这样LoadLibrary函数执行到ret的时候，远程线程结束，但是DLL也被装入了目标进程中，只要在DLL的入口函数中创建一个新的线程，就可以执行我们的代码了，在所附光盘的Chapter13\RemoteThreadDll中的例子演示了这种方法的汇编版本，程序将一个DLL文件插入到文件管理器Explorer.exe中运行，有兴趣的读者可以自己查看一下。
虽然DLL文件在目标进程中运行的时候，任务管理器中不会列出DLL文件名，看到的只是目标进程的文件名，但是有一些工具可以查看一个进程究竟装入了哪些DLL文件，通过这些工具还是可以发现进程中的可疑DLL。
要彻底解决这个问题，就必须脱离DLL文件，让远程运行的代码只存在于内存中，这样就不会有任何的蛛丝马迹显示有某个文件被非法装入，这个问题的关键也就是这个重定位问题。但现在Win32汇编程序员可以很骄傲地说“我可以实现它”，因为自定位的代码正是汇编语言的拿手好戏，在快成为历史的DOS病毒中，十个病毒中就有九个用到了自定位技术，这些技术完全可以用在这个地方。
自定位技术其实很简单，观察下面这段代码：
在程序开始，首先获取LoadLibrary，GetProcAddress和GetModuleHandle函数的入口地址，这些地址将在远程线程中被用来获取其他API的入口地址。
接下来就是打开Explorer.exe进程的 *** 作，程序通过GetWindowThreadProcessId和OpenProcess函数来完成，函数中使用的窗口句柄是桌面的窗口句柄，因为桌面就是由文件管理器进程创建的，桌面的窗口类是“Progman”，窗口名称是“Program Manager”，使用FindWindow函数就可以很方便地找到它。在打开进程的时候必须包括对应的权限，PROCESS_CREATE_THREAD权限将允许创建远程线程，PROCESS_VM_OPERATION权限将允许在目标进程中分配内存并将远程代码写到里面。
程序使用VirtualAllocEx函数在目标进程中分配内存，在分配内存的时候，内存属性必须指定为PAGE_EXECUTE_READWRITE，这样分配到的内存可以有执行和读写的权限，分配方式必须指定为MEM_COMMIT，这样内存才会被提交到物理内存中去。
在分配到内存以后，程序使用WriteProcessMemory将远程代码写入，然后再一次将LoadLibrary，GetProcAddress和GetModuleHandle函数的地址写入到远程代码的数据段中。并不将这3个函数的地址存放到远程代码中一次性写入的原因在于：远程代码（包括远程代码使用的数据）是定义在本地的代码段中的，而本地的代码段是只读的，我们无法在本地对它们进行写入初始化数据的 *** 作，所以只好采用远程写入的方式。
最后，用CreateRemoteThread函数创建远程线程后就万事大吉了。编译链接以后运行可执行文件可看到，窗口正常出现了，一眼看上去，这个窗口和别的窗口没有任何不同！但是在任务管理器中却没有多出任何新的进程。
假如远程线程不是这样“招摇过市”地创建了一个窗口，而是在后台偷偷地运行的话，大家能不能从各种蛛丝马迹来发现它的存在呢？反正笔者是找不到它的，因为它仅存在于目标进程的内存中，并不对应任何磁盘文件，当远程线程被执行的时候，惟一可以发现的就是Explorer.exe进程中的活动线程多了一个，使用的内存多了一点而已，但是活动线程用工具软件查看也只能看到一个线程ID，又怎么知道这个线程不是Explorer.exe进程自己的呢？
以上代码用在不合适的地方可能产生危害，笔者第一次公开这段代码，其目的就是希望能对有害代码的防治起到积极的作用，请读者负责任地使用这段代码。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）