Dll注入器干什么用的？

怎么样添加进程进去

这个应该是你要的吧 正好在论坛里发现 顺便贴上来 DLL注入 WinNT/Win2000/WinXP中的远线程技术之一－－DLL注入 什么是远线程？我们e68a84e79fa5e9819331333335313865知道用CreateThread可以在当前进程里建立一个线程，远线程与此类似，只不过是在其他进程中建立一个线程，用API函数CreateRemoteThread。这个远线程建立后就与建立它的进程无关了，而是进入了另外一个进程。举例说，进程A可以在进程B中建立一个远线程，这个远线程就是进程B中的线程了，而此时如果进程A结束了，也不会影响到那个远线程的运行，除非进程B也结束了，那个远线程才会结束。怎么样，是不是很神奇啊？现在我们来看看怎么建立远线程。 最简单的远线程技术是DLL注入。好，先从这个讲起。所谓DLL注入就是将一个DLL放进某个进程的地址空间里，让它成为那个进程的一部分。要实现DLL注入，首先需要打开目标进程。 hRemoteProcess = OpenProcess( PROCESS_CREATE_THREAD | //允许远程创建线程 PROCESS_VM_OPERATION | //允许远程VM操作 PROCESS_VM_WRITE, //允许远程VM写 FALSE, dwRemoteProcessId ) 由于我们后面需要写入远程进程的内存地址空间并建立远程线程，所以需要申请足够的权限（PROCESS_CREATE_THREAD、VM_OPERATION、VM_WRITE）。 如果进程打不开，以后的操作就别想了。进程打开后，就可以建立远线程了，不过别急，先想想这个远线程的线程函数是什么？我们的目的是注入一个DLL。而且我们知道用LoadLibrary可以加载一个DLL到本进程的地址空间。于是，自然会想到如果可以在目标进程中调用LoadLibrary，不就可以把DLL加载到目标进程的地址空间了吗？对！就是这样。远线程就在这儿用了一次，建立的远线程的线程函数就是LoadLibrary，而参数就是要注入的DLL的文件名。(这里需要自己想一想，注意到了吗，线程函数ThreadProc和LoadLibrary函数非常相似，返回值，参数个数都一样) 还有一个问题，LoadLibrary这个函数的地址在哪儿？也许你会说，这个简单，GetProcAddress就可以得出。于是代码就出来了。 char *pszLibFileRemote="my.dll"; PTHREAD_START_ROUTINE pfnStartAddr = (PTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle("Kernel32"), "LoadLibraryA"); CreateRemoteThread( hRemoteProcess, NULL, 0, pfnStartAddr, pszLibFileRemote, 0, NULL); 但是不对！不要忘了，这是远线程，不是在你的进程里，而pszLibFileRemote指向的是你的进程里的数据，到了目标进程，这个指针都不知道指向哪儿去了，同样pfnStartAddr这个地址上的代码到了目标进程里也不知道是什么了，不知道是不是你想要的LoadLibraryA了。但是，问题总是可以解决的，Windows有些很强大的API函数，他们可以在目标进程里分配内存，可以将你的进程中的数据拷贝到目标进程中。因此pszLibFileRemote的问题可以解决了。 char *pszLibFileName="my.dll";//注意，这个一定要是全路径文件名，除非它在系统目录里；原因大家自己想想。 //计算DLL路径名需要的内存空间 int cb = (1 + lstrlenA(pszLibFileName)) * sizeof(char); //使用VirtualAllocEx函数在远程进程的内存地址空间分配DLL文件名缓冲区 pszLibFileRemote = (char *) VirtualAllocEx( hRemoteProcess, NULL, cb, MEM_COMMIT, PAGE_READWRITE); //使用WriteProcessMemory函数将DLL的路径名复制到远程进程的内存空间 iReturnCode = WriteProcessMemory(hRemoteProcess, pszLibFileRemote, (PVOID) pszLibFileName, cb, NULL); OK，现在目标进程也认识pszLibFileRemote了，但是pfnStartAddr好像不好办，我怎么可能知道LoadLibraryA在目标进程中的地址呢？其实Windows为我们解决了这个问题，LoadLibraryA这个函数是在Kernel32.dll这个核心DLL里的，而这个DLL很特殊，不管对于哪个进程，Windows总是把它加载到相同的地址上去。因此你的进程中LoadLibraryA的地址和目标进程中LoadLibraryA的地址是相同的(其实，这个DLL里的所有函数都是如此)。至此，DLL注入结束了。

DLL的远程注入技术是目前Win32病毒广泛使用的一种技术。使用这种技术的病毒体通常位于一个DLL中，在系统启动的时候，一个EXE程序会将这个DLL加载至某些系统进程（如Explorer.exe）中运行。这样一来，普通的进程管理e799bee5baa6e78988e69d8331333335313865器就很难发现这种病毒了，而且即使发现了也很难清除，因为只要病毒寄生的进程不终止运行，那么这个DLL就不会在内存中卸载，用户也就无法在资源管理器中删除这个DLL文件，真可谓一箭双雕哉。 病毒主体文件为: kvmxema.dll 卡巴斯基无法检测是何种病毒,只警告有病毒行为,频繁弹出几个宿主EXE的警告,点"添加到信任区域"看了一下,都是在试图调用同一个文件 : 位于system32下的kvmxema.dll 好了,基本确定这个就是病毒文件,由几个常规进程调用触发(包括Explorer.exe,任务管理器taskmgr.exe .. 这意味着你开机看到桌面以后这个病毒就已经在运行了,你打开任务管理器时同样也会调用这个病毒) 尝试删除病毒kvmxema.dll文件,正被使用无法删除 失败 尝试终止这几个调用病毒DLL的进程,然后删除病毒DLL文件.发现DLL由EXPLORER.EXE调用(终止EXPLORER.EXE后也就无法再进入EXPLORER.EXE进行删除文件操作..这是个悖论哦 :-P) 尝试修改注册表取消掉关联,在注册表中搜索 kvmxema.dll 发现删除相关键值后马上被还原 失败. 尝试进入安全模式下删除,进入时病毒已被调用(EXPLORER.EXE嘛) 失败 那么就只能进DOS操作系统删除了,Win5.0以后不再支持DOS了(不是命令行CMD),手边又没有启动盘,上网搜了下,下载了"矮人工具箱",可以从硬盘启动DOS,下载,安装,重启进入DOS模式 一路CD,进入SYSTEM32,执行"DEL kvmxema.dll" 报错"文件未找到" ,忽然想起来那个DLL是隐藏状态的(够狠),于是"cd .."回到上一层,执行"attrib system32\kvmxema.dll -h" 修改文件属性,成功.注意不要在SYSTEM32下执行ATTRIB(目录下有个同名程序不能在当前DOS下运行),再DEL一下,成功 重启进XP,卡巴终于安静了,再进注册表,搜索删除掉垃圾,然后搜索一下最近修改的EXE,找到几个从后门进来的EXE,删除 总结一下: ·注意打好操作系统和浏览器的补丁，像我这样从不打补丁的就要整天忙着删病毒 ·准备一套独立的进程管理器和文件管理器，当Explorer和taskmgr瘫痪时就要指望它们了 ·安装一个GHOST，备份一下系统，要知道其实最好的杀毒办法就是还原系统