最近因为上论坛时间不多了，比较少上救援区看帖，所以对最近比较流行的病毒，在论坛上回帖帮助求助者的经历比较少。反而是因为几次被同学叫去帮忙杀毒，有了好几次实机查杀的经验，让我比较容易脱出论坛上回帖者的思维定势来看待问题。下面说说两点体会。
先说conficker。对付conficker，SREng日志不是太好使，主要原因有：
1. conficker修改自身注册表服务项的注册表权限属性，去除管理员用户的读取权限，使得SREng无法显示其服务项。
2. conficker的dll加载后，对自身代码进行解码，解码到新申请的内存中，实质动作在解码后的代码中执行，而原来的dll模块就卸除了，这样SREng在进程模块中也看不到dll模块。
所以有人说狙剑啊什么的这些Ring0的一起上，就可以避免服务项注册表权限问题。这有一定道理，但是现在中毒电脑的系统环境越来越复杂，杀毒软件与病毒驱动并存的情况下，Ring0工具上阵，有时候容易蓝屏。而且我一向不喜欢Ring0工具一拥而上的这种人海战术。
其实conficker的服务名看似任意，但只要它的加载方式不变，要找到它有更加简单和直接的办法。
这个办法，微软已经总结了：
http://support.microsoft.com/kb/962007（不知道回帖处理conficker的会员们有多少看过微软的conficker专题页面。）
在这个页面的“删除conficker.b变量的手动步骤”中，阐述了查找conficker服务名的方法：
只要注意一下注册表
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost]
的netsvcs键的内容，就可以发现conficker的踪迹，然后就按照微软的警报中提供的方法手动修改注册表权限后禁用服务项（如果有盘符autorun.inf或远程计划任务，相应做处理），重启后conficker不再启动，可轻松处理。
前两天我就是这样单纯用注册表编辑器搞定了室友电脑里的conficker。
比起大把工具一拥而上的做法，我认为微软警报中提到的手动处理方法，才是真正抓住了conficker注册表项中不变的东西。微软告诉我们，我们不需要盲目地去遍历服务项来查找conficker，这个netsvcs键值中的异常条目，才是conficker最为醒目的标志，也是最容易被抓住的脉门。
因此大家以后碰到conficker的时候注意这一点，可以事半功倍。
第二个要说的是被替换的系统文件comres.dll
比如
http://bbs.ikaka.com/showtopic-8620921.aspx就提到了这个。
对于这个被替换的系统文件的修复问题，我们习惯于提出“到其他电脑拷贝正常的comres.dll来替换”，但是实机操作时我发现，正常的comres.dll就“近在咫尺”。
如果中毒电脑的dllcache文件夹中有comres.dll，那么它并没有被这个病毒修改掉，因此它可以用来替换。
接着是怎么替换的问题。
首先comres.dll在加载着，资源管理器直接删除是不行了。
我们习惯性的思维仍然想到的是“使用IceSword等工具强制删除或替换”。
OK，这也行，但是还是那个问题，中毒电脑情况复杂。特别是这次，有pcidump.sys这样的病毒驱动在内。
我在实机查杀过程中，IceSword一打开就蓝屏。
然而最后，我没有利用任何非系统的东西，轻而易举搞定这个comres.dll的替换问题。
方法是：资源管理器里将system32的comres.dll改名，随便改，比如把.dll去掉。实机操作证明这个操作成功。
改名了之后，系统文件保护自动将dllcache中的正常的comres.dll拷贝到system32。
重启电脑，正常的comres.dll被加载，病毒comres.dll以及依赖于它启动的一大串font文件夹中的.ttf全部哑火，直接收尸。
看了这个方法大家会不会跳起来，就这么简单，一次所有用户都会做的重命名就解决了问题。关键是系统文件保护帮助我们绕过了“被修改的comres.dll正在被加载不能正常替换和删除”的问题。
所以我觉得有时候思路最重要，我们不要死守着习惯思维，不要总想着走“更Ring0，更底层，更猥琐”的对抗之路。有时候，其实解决问题可以更简单的。
用户系统信息：Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 2.0.50727; aff-kingsoft-ciba; MAXTHON 2.0)
