PowerTool是一款免费的系统分析，手动杀毒工具。这款内核级的手动杀毒辅助工具，能帮助你找出病毒
木马在你的电脑中动过的手脚，并去除病毒设下的机关。目前具备以下功能：系统修复、进程管理、内
核模块、内核相关、钩子、应用层、文件、注册表、离线分析、启动项、系统服务、网络链接、漏洞修
复等。
PowerTool 的特色在于它能够获取较高权限，从而执行一些底层的系统维护操作，如常用的强制结束进
程、强制删除文件、强制编辑注册表、强制删除系统服务等等。作为内核级手动杀毒辅助工具，
PowerTool 与 PCHunter不相上下，PowerTool 在某些方面提供的功能还要多些，处理速度蛮快。
适用系统环境：Windows PE / 安全模式 / Windows XP / Windows 2003 Server / Vista / Windows
2008 Server / Windows 7 / Windows 8 / Windows 8.1 / Windows 10 RTM / Windows 10 build 10586
如何使用PowerTool 20秒手动清除鬼影3病毒
“鬼影”系列病毒的共同特点是感染电脑硬盘的主引导记录（MBR），无论重装系统或是格式化硬盘都无
法清除病毒。
“鬼影”系列病毒的共同特点是感染电脑硬盘的主引导记录（MBR），无论重装系统或是格式化硬盘都无
法清除病毒。在查杀前两代“鬼影”时，不同厂商推出的专杀工具都会首先修复MBR，然后再全面扫描清
除病毒残骸，然而这个方法在查杀“鬼影3”时却遇到了难题。据分析，“鬼影3”病毒之所以非常顽固
，原因在于它释放了一个恶意驱动作为“保镖”，用来禁止任何修复MBR的操作。对杀毒软件来说，不清
除“保镖”驱动就无法修复MBR，不修复MBR又无法清除“保镖”驱动，从而陷入“鬼影3”怎么都杀不干
净的死循环中。
年初的时候我写过一篇20秒手杀鬼影的教程，斗转星移，病毒的作者精益求精，前段时间，已更新到鬼
影3代了。
不过正所谓魔高一尺，道高一丈，邪还是不能胜正的，现在也有一些鬼影3的专杀工具了，不过为了知其
所以然，我写一下如何用PowerTool的3.8版来手刃鬼影3病毒~~~
PowerTool 顽固文件清除文件下载地址为：www.jb51.net/softs/25378.html
第一步
看一下鬼影3都干了那些坏事，我们才能够做到有的放矢
1. 鬼影3的进程
2. 鬼影3的文件
3. 鬼影3的流氓快捷方式
4. 鬼影3的网络连接
5. 鬼影3在内核里面的钩子
6. 鬼影3在的其他勾当
7. 最后也是最重要的也就是鬼影3的MBR
差不多就这些了，知道了它干得勾当，自然就可以清除它了。
清除步骤：
1.结束鬼影3的进程
2.恢复隐藏的扩展名
3.删除鬼影3的文件
4.删除鬼影3的流氓快捷方式
5.恢复它在内核的钩子(这一步很重要，否则无法恢复MBR)
6.恢复成正确的MBR
========
PowerTool手动清除IE自动捆绑hao123一例
http://bbs.kafan.cn/thread-1772662-1-1.html
话说本人很少使用IE浏览器，但最近由于工作中某个ZF网站只支持IE才能正常显示(奇葩的设计），不得
不又使用了一下久违的IE软件。
打开IE后，发现自动打开了hao123页面，确切的说是指向了：http://www.hao123.com/?
tn=91055648_hao_pg页面。
第一反应，进入IE设置，首页清空，重启浏览器，还是这样，继续搜索注册表，果然找到几个“hao123"
的键值，删除之，哈哈，简单，重启~
回来嗯？怎么还是没用？再次搜索注册表，并未发现流氓的踪迹，MUMM~，
第二反应，右键IE快捷方式，啊哈，果然，快捷方式直接添加了流氓软件的地址。删除之~，重运行，还
是不行，删除它，嗯？显示不具备管理员权限？啥意思？这有些木马的感觉啊~~~，重启，F8，安全模式
删除，哈哈，成功，小样~~~~~
再回来~~~，嗯？？？还在？看来有模块监视，自动创建，咋办？上网，度了一圈，也没办法，卡饭一顿
，都是求助，要不就是重装系统！这么烦？！！
咱是干啥的？折腾呗~~~
杀毒~~~~，没用
查看启动项~~~~，没啥
查看进程~~~~，正常
Mummm~~~~~
突然想起了好久没用的PowerTool,Win7下还没用过呢，试试，先吹吹灰先~~~
打开，流氓快捷方式——无，（识别不出？），进程管理，有红色的一个个看........，在
Explorer.exe中，发现了线程:路径:/bangdun/product.dll,这是啥？摘除之，explorer重启，还在！还
有钩子？
继续找，钩子，内核入口，啊又发现了这个玩意，摘除钩子
再次删除一下快捷方式看看，成功啦，看来就是这东西:Bangdun!啥玩意？找到该文件目录删除，系统注
册表里寻找bangdun并清理。
重启~~~~~~哈！快捷方式不再生成了，小样，就是一流氓软件。
（该过程有几天时间了，所以本文中的细节可能记得不是很完整了，今天上网看看，很多人都在问怎么
清理hao123，我这也算是一个思路吧，大家看看，杀毒记得举一反三。 ）
使用PowerTool快速清除鬼影病毒
http://www.cr173.com/html/11038_1.html
鬼影病毒让人很恼火，重做系统都没有用，当然现在已经有很多鬼影专杀工具了，不过MBR病毒不只限于
鬼影，以后遇到了类似的也可以用PowerTool清除
第一步，先查看MBR是否有异常，如果有红色的项目，就说明MBR已经被病毒篡改了
（PT会自动确认是否有恶意代码和MBR代码是否被隐藏，然后显示红色）
第二步就是点击自动修复来修复了：
到此为止，确认加上恢复大概是10秒钟吧
接下来清除鬼影留下的流氓广告和快捷方式
（普通的删除方法很烦琐，PT只需一步就可删除）
点击修复即可，大概耗时5秒
最后，删除鬼影遗留下来的驱动文件
也差不多5秒，
最后系统重启即可，就可以恢复成干净的系统了
鬼影其实还只是一个入门级别的Bootkit，以后变种可能会强一些吧
PowerTool还可以对抗隐藏MBR代码的MBR Rootkit，
如果还无法对抗，
在dos底下修复MBR最彻底了
重置：
fdisk /mbr
fixmbr(windows恢复控制台)
gdisk disk /mbr。
使用PowerTool轻松检测魔影病毒（TDSS.TDL-4）
http://www.cr173.com/html/12812_1.html
就不过多重复了，为了保护自己的篡改的MBR，可谓是用尽可手段，
PowerTool可以在不恢复和修改TDL-4任何钩子的情况下，
直接穿透它的防护，检测到TDL-4 rootkit
首先，有两个地方，大家可能以前就知道了，
一个是工作列线程
一个是StartIO的钩子
这个以前版本的PowerTool就可以检测到
这次加强了内核模块的检测，可以看到TDL-4的隐藏驱动
TDL-4还劫持了ATAPI的设备
如果以上，大家还不能确认是否是真的中了TDL-4病毒的话
最后一个，可以彻底让它露出真面目，
在MBR里面点击强力检测按钮(目前不支持AHCI/RAID/SCSI模式)
可以完全穿透TDL-4的防护，检测到MBR
清除的话，建议大家可以用卡巴或者BitDefender的专杀工具
也可以到PE系统里面，修复MBR来清除
以后PT会进一步加强清楚的工作，呵呵
找下PowerTool 0.40最新版的茬 (1)
http://bbs.kafan.cn/thread-1052303-1-1.html
刚看到PowerTool 0.40出正式版了，随便找了一个测试环境看了下它的一些功能。
下面是0.40新增或改进项目的一点问题。
1、PT新版新增了调试寄存器的检测，但是由于对调试寄存器了解不够深入，有一些错误。
本来准备拿一些比较特殊的改写调试寄存器来测试，但是一看显示界面，大囧。
最新版误将几个DRX调试寄存器的名字写作CRX（正确的名字应该是DR0---DR7），作者对调试寄存器的了
解还得加深。
PT遇到某个调试寄存器的值非零就提示该处可能被hook，实际上某些还原软件也可能对它做手脚，但并
不是hook。
另外，只检测几个DRX的值，而没有检测相应的一些重要标志位，更不说一些组合方式利用调试寄存器了
。
2、PT新版加入了内核入口点的检测，但是由于对syscall（系统调用）机制的不熟悉，会导致正常系统
出现一些误报或者漏报。
PT不支持2000系统，就似乎默认了syscall只是某一种，只显示KiFastCallEntry的地址。
而事实上，即使在Win 7环境下，三种syscall入口都是可能的。
这里由于PT直接将KiFastCallEntry固定为内核入口点，导致检测不了hook。
另外，由此也导致PT的内核入口点检测读取错误的、不起作用的“入口”地址，通过交叉分析，可能得
出存在hook的结论。
3、PT新版修正了之前版本将MBR启动代码的16位汇编解析为32位汇编的问题。
不考虑重定位，显示时，PT将启动地址标为00000002，而不是00000000，总感觉怪怪的。
4、PT新版加入了woodmann论坛Kayaker的代码，实现在Win7快速遍历指定内核区域。
http://www.woodmann.com/forum/en ... s-space-in-Windows7
不过Kayaker的代码只是demo性质的，存在一些问题，比如最基本的校验，可能导致崩溃。
5、PT新版改进了网络连接的显示，本想测试解析IP库是否存在问题，结果测试中出现了蓝屏，所以顺便
看了下网络连接的枚举。
Win7下的枚举，PT使用了debugman的《WIN7下向NSI取TCP UDP信息》提供的代码。
http://www.debugman.com/discussi ... 4%BF%A1%E6%81%AF/p1
可惜原帖给出的代码本身存在一些问题，比如分配释放pool的逻辑存在问题，可能导致蓝屏。
一个典型的下PT在Win7枚举网络连接导致蓝屏时的栈回溯如下：
945a7464 81c57b92 00000003 1a501172 00000000 nt!RtlpBreakWithStatusInstruction
945a74b4 81c58673 00000003 945a7940 000001ff nt!KiBugCheckDebugBreak+0x1c
945a7878 81dc91d9 000000c2 00000006 0000108e nt!KeBugCheck2+0x6a1
945a78ec 88c1bc15 945a7948 00000000 8cb300b8 nt!ExFreePoolWithTag+0x129
WARNING: Stack unwind information not available. Following frames may be wrong.
945a79a8 88c2d635 945a7a5c 945a7a50 878b3030 kEvP+0x3c15
945a7a6c 88c37dbd 878b3030 8cb300b8 0000f428 kEvP+0x15635
945a7bec 81c4311a 878b3030 8cb300b8 00000000 kEvP+0x1fdbd
945a7c0c 82118a40 8cb300b8 8cb30128 923aff38 nt!IofCallDriver+0x7e
945a7c2c 82119bd6 878b3030 923aff38 00000000 nt!IopSynchronousServiceTail+0x258
945a7cc8 82120332 00000178 8cb300b8 00000000 nt!IopXxxControlFile+0x740
945a7d04 81da8173 00000178 00000000 00000000 nt!NtDeviceIoControlFile+0x4c
945a7d04 7702a364 00000178 00000000 00000000 nt!KiFastCallEntry+0x163
001f8878 77000844 74f8e074 00000178 00000000 ntdll!KiFastSystemCallRet
001f887c 74f8e074 00000178 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
001f88dc 75c01830 00000178 002221c4 00000000 KERNELBASE!DeviceIoControl+0xee
001f8908 013e6762 00000178 002221c4 00000000 kernel32!DeviceIoControlImplementation+0x80
001ff260 00000000 00000000 00000000 00000000 PowerTool+0xa6762
404 Not Found
今天写到这里，明天开放。
Anti-rootkit如某些大牛说的，现在越来越多人在写了，门槛也越来越低了。但是要写出一个优秀的ark
，不仅仅靠得是模仿和不仔细分析就增加功能，需要对系统机制的深入理解，需要作者的思考。
有感于一直以来很多人对ark的误解（当然，不是后面PT作者所想的）和前段时间PowerTool交流群某些
人对XueTr作者的人身攻击，主要给出了PT这次5处更新对应项目的一些问题，作为一点回应。
一点说明：
1、调试寄存器，顾名思义，这里指P3 x86下用于扩展CPU调试机制的Drx寄存器。
调试器可直接利用它实现硬件断点（这里是内核调试器），rootkit等可以通过设置调试寄存器，可以对
指定地址的读取、写入、执行进行控制，达到隐藏目的。
这里PT检测的是全局的Drx寄存器，并不是用户态的per thread context下的drx。
举几个实例：
1、一些反外{过}{滤}挂驱动会修改调试寄存器，达到阻止hook被恢复等目的。
2、360还原保护器会对IO端口下硬件断点，拦截直接IO方式的穿还原。
3、一些反外{过}{滤}挂驱动及微点主防驱动恢复hook前会清零调试寄存器，减少受干扰可能。
2、内核入口点。
这里内核入口点不够明确，就PT检测项目而言指的是系统调用的内核入口点。
wiki:系统调用指程序向操作系统内核请求需要更高权限运行的服务，它提供了用户程序与操作系统之间
的接口。
Windows NT下系统调用对应的服务函数一般指的是SSDT和Shadow SSDT两张表内的函数，很多驱动会通过
替换这些表内的函数或者改写函数内部代码等方法实现hook，做一些拦截、隐藏等动作。
而由用户态发起请求到分发服务函数有一个过程，由于SSDT和Shadow SSDT相对明显，可以通过对从用户
态发起请求到分发服务函数中间过程的代码进行改写，来实现相对隐蔽的hook。
PT准备检测的是便是这部分hook。
简单来说，PT作者对系统机制的理解不全面，很多地方没有考虑周全，导致漏检测(比如内核入口点只检
测了一个）
不过将调试寄存器名称写错有点囧了
Anti-rootkit如某些大牛说的，现在越来越多人在写了，门槛也越来越低了。但是要 ...
CRX的名字确实写错了。。。不过没什么大碍
重要标志位可以自己分析DR7，
不过打算在下个版本，详细列出来
入口点监测，可能没检测全，以后的版本继续加强了。。。
后面几个问题，我也再检查一下，
PT确实还算不上优秀，只能继续改进，
如果只是进程线程文件，确实很多人都可以做，
不过dl牛好像把PT归于这一类了。。。
而且ARK也不可能全部都考虑到，
即使是XT也有考虑不到的地方，枚举不到的模块吧？
PT已经加了很多自己的东西，也不能单纯的说是模仿了吧
群里面有人攻击XT吗？会不会是dl牛过于敏感了
有人习惯用PT，有人习惯用XT，不可能让大家都统一的标准啊。。。
更多的人应该是两个都在用吧。。。
不管怎么说XT在linxer牛和dl牛的努力下，
的确是第一流和最优秀的ARK，但是对用户的要求也很高
而我则努力结合用户的反馈加上自己的想法。
做一个简单易懂的工具，即使不把PT算作ARK，
能在大多数情况下解决病毒就可以了，呵呵
========
找下PowerTool的茬 (2)——使用PT 20秒检测并清除ZeroAccess的不可行性
http://bbs.kafan.cn/thread-1061080-1-1.html
ZeroAccess rootkit是最近讨论得比较多的一种恶意软件。它又名max++，ZAccess，得名于rootkit
文件内调试信息中的作者命名。它最早于大半年前在国外一些反病毒论坛和技术博客被讨论，近半年前
在剑盟的一个关于清理InstallAntiVirus2010的讨论帖里，ZeroAccess首次在国内被关注，那时它已加
入了针对检测工具的反制措施。几个月后，卡巴、Prex、安博士、SurfRight等厂商对该rootkit进行了
公开报道。
ZeroAccess rootkit使用了许多技术实现隐藏和反检测，包括驱动reload and run、虚拟盘、NTFS
文件压缩、存储栈设备扩展劫持、文件缓存欺骗、直接操作FCB、引诱检测、高级自我保护等。
看到PowerTool作者在博客发布了名为《20秒检测并清除ZeroAccess/ADS流病毒By PowerTool》的博
文，提出了清理该rootkit的简便方便。不过由于作者并未仔细分析该rootkit，导致该教程和PowerTool
清理过程中出现很多问题，甚至是安全隐患。结合自己对清理ZeroAccess的体会，对其中的不少细节提
出一些质疑。
这里对清理教程发现的问题做一些探讨。
1、对ZeroAccess自我保护规避的不彻底。
PowerTool最新版驱动会在每次分发时恢复ZeroAccess新版对IoIsOperationSynchronous函数的
hook，以此来防止访问ZeroAccess的ADS流文件时由于未通过rootkit验证被结束进程并清除文件权限。
可惜的是，PowerTool这样做并不能完全规避ZeroAccess的自我保护，最新版在很多情况下仍然会
出现触发ZeroAccess导致无法正常使用。
试举一例：
PowerTool在启动时会检测硬盘，可能会发送SMART_RCV_DRIVE_DATA的I/O控制码获取硬盘信息。
这一动作会被ZeroAccess在Ata/Scsi/Storport等设备栈最底层微端口设备驱动的hook截获，然后
PowerTool会被无情的结束进程并且文件被清除权限。
如下所示，PowerTool的访问被ZeroAccess的hook截获，PowerTool.exe文件被清除了权限。
1:kd> p
8154fa2e ff156c945581 call dword ptr ds:[8155946Ch] ds:0023:8155946c={nt!
ZwSetSecurityObject (80501fb0)}
1: kd> !handle @ecx
Image: PowerTool.exe
Object: 8137ba48 Type: (819edad0) File
Directory Object: 00000000 Name: \Documents and Settings\Administrator\桌面
\PowerToolV4.0.2\PowerTool.exe {HarddiskVolume1}
1: kd> lmvm PowerTool
Image path: C:\Documents and Settings\Administrator\桌面\PowerToolV4.0.2\PowerTool.exe
Image name: PowerTool.exe
Timestamp: Thu Sep 01 23:22:51 2011 (4E5FA34B)
ImageSize: 0065F000
2、教程针对ZeroAccess版本的局限导致清除无效的可能性
教程提出20秒修复ZeroAccess，最后提出的3步，即恢复hook、清除关机回调和修复感染文件在很
多情况下是无法清除ZeroAccess感染文件的。
教程对应的ZeroAccess版本，是一个多星期前的，并没有考虑再这之前以及最新的版本。最近的
版本，ZeroAccess自建的微型文件系统的存储文件也已转移。
更重要的是，教程中并没有提到删除ADS流文件以及该文件对应的服务（实际上0.40版删除ADS流
文件存在问题），也没有去尝试清除ZeroAccess自建的微型文件系统的存储文件。特别是前者的文件和
服务配置信息，不删除可能导致重启重新感染，这点之前的一些教程帖中已有讨论。
3、教程给出的清理步骤的多余性
教程提出的三步清理ZeroAccess,除了修复感染文件，其它步骤，单就ZeroAccess系列而言是没有
意义的。即使不处理，也不会导致本身清理局限性外的修复的问题。由于该教程本身针对的是
ZeroAccess的某一版，且有着前面所述的局限性，把删除回调、恢复hook这样常见的杀毒手段放在这是
没有必要的。
另外，由于PowerTool对ZeroAccess的hook检测并不全面，包括前面所述的存储栈设备扩展劫持（如下
XueTr提示）默认都没有检测，不能作为PowerTool通用清理方法。
4、对进程的枚举和显示。
由截图看，PowerTool将进程2571670320:3480008550.exe本身模块显示为隐藏。实际上该模块并
不存在隐藏，使用其它Ring3工具都能正常枚举出模块，除了读取文件本身可能存在困难。
5、对进程文件的删除。
教程中并没有提到3480008550.exe对应进程的结束以及该文件的删除。
实际使用PowerTool删除3480008550.exe这一文件后，再次刷新进程管理，会将该进程路径名显
示为C:。
此时使用结束进程并删除文件功能，PowerTool会将该路径传入，删除整个C盘时自然导致系统死
锁或者蓝屏崩溃，影响系统安全性。
一个典型的崩溃dump如下，这里PowerTool附加到explorer.exe关闭了不该关的句柄：
*Bugcheck Analysis **
INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code (server, redirector, other driver, etc.)
attempts to close a handle that is not a valid handle.
Arguments:
Arg1: 00000208, The handle that NtClose was called with.
Arg2: 00000001, means an invalid handle was closed.
Arg3: 00000000
Arg4: 00000000
PROCESS_NAME: explorer.exe
STACK_TEXT:
f088900c 804f9df9 00000003 f0889368 00000000 nt!RtlpBreakWithStatusInstruction
f0889058 804fa9e4 00000003 e186e008 81529af0 nt!KiBugCheckDebugBreak+0x19
f0889438 804faf33 00000093 00000208 00000001 nt!KeBugCheck2+0x574
f0889458 805bd4bd 00000093 00000208 00000001 nt!KeBugCheckEx+0x1b
f088949c 805bd509 00000208 00000000 00000000 nt!ObpCloseHandle+0x173
f08894b0 8054261c 00000208 f088957c 80500f31 nt!NtClose+0x1d
f08894b0 80500f31 00000208 f088957c 80500f31 nt!KiFastCallEntry+0xfc
f088952c f069f208 00000208 0100001e 813978f0 nt!ZwClose+0x11
WARNING: Stack unwind information not available. Following frames may be wrong.
f088957c f06b0a09 8158a378 f0889a80 00e37b61 kEvP+0x5208
f0889abc f06ba16f 8148e778 81677378 00e37d9d kEvP+0x16a09
f0889c40 804f018f 8148e778 81677378 806e7410 kEvP+0x2016f
f0889c50 80580982 816773e8 8162c7a0 81677378 nt!IopfCallDriver+0x31
f0889c64 805817f7 8148e778 81677378 8162c7a0 nt!IopSynchronousServiceTail+0x70
f0889d00 8057a274 000000d4 00000000 00000000 nt!IopXxxControlFile+0x5c5
f0889d34 8054261c 000000d4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f0889d34 7c92e4f4 000000d4 00000000 00000000 nt!KiFastCallEntry+0xfc
00129360 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
FOLLOWUP_IP:
kEvP+5208
f069f208 8b4508 mov eax,dword ptr [ebp+8]
6、“跟踪硬盘读写过程”的不全面
ZeroAccess会对DR0设备的设备扩展进行修改，这种方式绕过了常规的hook检测。PowerTool最
新版的检测MBR功能会受此影响，导致显示“无法读取MBR信息（内核）”。
教程分析中提到了通过“跟踪硬盘读写过程”检测可能更改。“跟踪硬盘读写过程”类似avast
出品aswMBR工具的Disk IO Trace功能。PowerTool另可以通过这一功能恢复上面的劫持。不过这一功能
仍然存在问题，无法突出高亮显示ZeroAccess的另一处hook，正是该处hook导致了之前PowerTool最新仍
然可能触发ZeroAccess自保。
7、总结
《20秒检测并清除ZeroAccess/ADS流病毒By PowerTool》一文，其中的分析、给出的方法和实
际配合PowerTool清理ZeroAccess的效果都存在不少问题，甚至是安全隐患。这里提出其中一些问题，供
网友评论