最近，在论坛看帖子时发现：中毒后，杀而不净的现象比较普遍。更有甚者，毒没杀净，杀软反而被干掉了。其实，这也不是什么新鲜事，针对各有名杀软的病毒早就有。卡巴斯基这样的名杀软被病毒干掉也不是什么新鲜事。
不废话了。言归正传。
中毒后，杀不净，常见的原因之一是病毒插入了系统/应用程序进程。
不将被插进程中的病毒模块处理掉，毒是杀不净的。
如何发现进程被插？常见的方法是：在中招的电脑上扫SRENG日志。SRENG日志的“正在运行的进程”部分可找到进程被插信息（阅读这部分日志判断进程中的病毒木块————需要经验）。当然，你也可以用IceSword一一检视进程列表中各进程的“模块信息”（比较累）。
按照手工杀毒时的不同处理方式，被插进程大致可分为以下几类：
1、系统核心进程。系统核心进程不能结束。否则，系统崩溃。
下面是阅读论坛中求助帖时，在SRENG日志见到的一个具体例子：
正在运行的进程
[PID: 668][\??\C:\WINDOWS\system32\csrss.exe] [Microsoft Corporation, 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)]
[C:\WINDOWS\system32\E5CEBDF.DLL] [Microsoft Corporation, ]
正在运行的进程
[PID: 668][\??\C:\WINDOWS\system32\csrss.exe] [Microsoft Corporation, 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)]
[C:\WINDOWS\system32\E5CEBDF.DLL] [Microsoft Corporation, ]
这段日志提示：系统核心进程C:\WINDOWS\system32\csrss.exe被病毒模块插入了。插入此进程的病毒模块是C:\WINDOWS\system32\E5CEBDF.DLL。
如果不采取相应措施卸掉csrss.exe进程中的E5CEBDF.DLL，病毒文件C:\WINDOWS\system32\E5CEBDF.DLL无法删除。
除了csrss.exe以外，属于系统核心进程的还有：
SystemRoot\System32\smss.exe
SystemRoot\System32\winlogon.exe
SystemRoot\System32\lsass.exe
SystemRoot\System32\services.exe
SystemRoot\System32\svchost.exe
处理这些进程中的病毒模块，我尝试过：
（1）用IceSword禁止进程创建，然后，强制卸除之。有时可以成功卸除，有时卸除失败（系统崩溃，重启）。
（2）如果（1）失败。可以尝试“禁止进程创建”后，强制删除病毒模块文件，有时也可达到目的（如木马Keygen.exe的处理）。
（3）如果（1）、（2）均失败，可以尝试用SSM解决问题：将病毒模块录入SSM的规则中，禁止病毒模块加载。将SSM设置为“启动加载”。然后，重启系统。
（4）将病毒模块录入Tiny的黑名单。重启系统。
（5）在安全模式下尝试删除病毒模块（成功率并非100%）。需要注意的是：有些病毒感染后，用户根本无法进入安全模式。这时，就别想这招了。没用。
如果不采取相应措施卸掉csrss.exe进程中的E5CEBDF.DLL，病毒文件C:\WINDOWS\system32\E5CEBDF.DLL无法删除。
除了csrss.exe以外，属于系统核心进程的还有：
SystemRoot\System32\smss.exe
SystemRoot\System32\winlogon.exe
SystemRoot\System32\lsass.exe
SystemRoot\System32\services.exe
SystemRoot\System32\svchost.exe
处理这些进程中的病毒模块，我尝试过：
（1）用IceSword禁止进程创建，然后，强制卸除之。有时可以成功卸除，有时卸除失败（系统崩溃，重启）。
（2）如果（1）失败。可以尝试“禁止进程创建”后，强制删除病毒模块文件，有时也可达到目的（如木马Keygen.exe的处理）。
（3）如果（1）、（2）均失败，可以尝试用SSM解决问题：将病毒模块录入SSM的规则中，禁止病毒模块加载。将SSM设置为“启动加载”。然后，重启系统。
（4）将病毒模块录入Tiny的黑名单。重启系统。
（5）在安全模式下尝试删除病毒模块（成功率并非100%）。需要注意的是：有些病毒感染后，用户根本无法进入安全模式。这时，就别想这招了。没用。
总之，中招者必须想办法将这些系统核心进程处理干净。否则，病毒杀不净。
2、explorer.exe（资源管理器）进程。这种进程插入比较常见。
explorer.exe进程可以结束（不会导致系统崩溃）。但是，用户若结束了explorer.exe进程，那他就只能对着一个空荡荡的桌面发呆了。
插入了explorer.exe进程的病毒模块，用IceSword禁止进程创建后，一般可以顺利卸除。
explorer.exe进程可以结束（不会导致系统崩溃）。但是，用户若结束了explorer.exe进程，那他就只能对着一个空荡荡的桌面发呆了。
插入了explorer.exe进程的病毒模块，用IceSword禁止进程创建后，一般可以顺利卸除。
3、一般应用程序进程。
这种情形最容易处理。用IceSword禁止进程创建，然后，找到相应进程，结束之。
这种情形最容易处理。用IceSword禁止进程创建，然后，找到相应进程，结束之。
4、比较“掉轨”的情形：
用IceSword，预先设置了禁止进程创。然后，根据SRENG日志提供的信息，所有被插进程都处理干净了，但病毒文件依然无法删除！
导致这种情形的原因常被忽视： 您遇到了“动态插入”（即：中毒后，用户运行哪个程序，病毒模块随即插入其进程中）。很可能是————您运行IceSword时，病毒插入了IceSword进程。这时，应检查IceSword进程的“模块信息”，找到其中的病毒模块，强制卸除之。
用IceSword，预先设置了禁止进程创。然后，根据SRENG日志提供的信息，所有被插进程都处理干净了，但病毒文件依然无法删除！
导致这种情形的原因常被忽视： 您遇到了“动态插入”（即：中毒后，用户运行哪个程序，病毒模块随即插入其进程中）。很可能是————您运行IceSword时，病毒插入了IceSword进程。这时，应检查IceSword进程的“模块信息”，找到其中的病毒模块，强制卸除之。
将所有被插进程处理干净后，即可开始删除病毒文件。
注意：如果前面用IceSword处理进程时一切顺利，删除病毒文件时，请不要更换工具，继续用IceSword操作。
删净病毒文件后，还要删除病毒添加的注册表项（根据SRENG日志）。
当然，您愿意先删除病毒添加的注册表项，然后再删除病毒文件，也是可以的。这只是个操作顺序问题。用IceSword禁止进程创建并处理干净所有进程后，这种不同的操作顺序————没有什么本质区别。
注意：如果前面用IceSword处理进程时一切顺利，删除病毒文件时，请不要更换工具，继续用IceSword操作。
删净病毒文件后，还要删除病毒添加的注册表项（根据SRENG日志）。
当然，您愿意先删除病毒添加的注册表项，然后再删除病毒文件，也是可以的。这只是个操作顺序问题。用IceSword禁止进程创建并处理干净所有进程后，这种不同的操作顺序————没有什么本质区别。
总之，进程插入问题，是导致病毒屡杀不净的常见原因。手工杀毒时，需重视这个问题，并根据实际情况，灵活采取相应的措施。
此贴于2007-4-3 10:16:23被baohe修改
发贴时间:2007-4-3 10:25:12
发贴时间:2007-4-3 10:25:12
部分回复：
1、辨认系统进程中病毒模块问题：凭经验。正常系统中C:\WINDOWS\system32\文件夹中没有E5CEBDF.DLL这个文件（这个回答可能让你失望）。
2、用IceSword强制邪除系统进程中的病毒模块，实质是“结束病毒模块的运行状态”（运行的文件是无法删除的）。
3、不结束病毒模块的运行状态而强制删除病毒模块文件的例子较少（这样做，要辅以特殊措施），据我的经验，也只有IceSword可以实现这种操作（尽管成功率不是100％）。那个Keygen.exe木马的处理就是个例子。强制删除病毒文件后，待硬盘无读写动作时，立即断开系统电源，即可奏效。这算个特例吧。
尽管是特例，但也是实践证明成功的例子，必要时可以考虑这样的方法。总之，手工杀毒讲究的是“灵活”，不必拘泥于什么“成规”。有时，就是要打破成规。
1、辨认系统进程中病毒模块问题：凭经验。正常系统中C:\WINDOWS\system32\文件夹中没有E5CEBDF.DLL这个文件（这个回答可能让你失望）。
2、用IceSword强制邪除系统进程中的病毒模块，实质是“结束病毒模块的运行状态”（运行的文件是无法删除的）。
3、不结束病毒模块的运行状态而强制删除病毒模块文件的例子较少（这样做，要辅以特殊措施），据我的经验，也只有IceSword可以实现这种操作（尽管成功率不是100％）。那个Keygen.exe木马的处理就是个例子。强制删除病毒文件后，待硬盘无读写动作时，立即断开系统电源，即可奏效。这算个特例吧。
尽管是特例，但也是实践证明成功的例子，必要时可以考虑这样的方法。总之，手工杀毒讲究的是“灵活”，不必拘泥于什么“成规”。有时，就是要打破成规。
转载自卡卡论坛病毒版baohe大虾的大作
本文转自starger51CTO博客，原文链接： http://blog.51cto.com/starger/22559，如需转载请自行联系原作者