阻击方案二
    还有一种更简单的方法，可以直接使用超级巡警专业版（AST）直接在Windows里进行简单快捷的查杀，只需要启动AST，切换到高级界面，然后点击“SSDT”列表，在里面点击鼠标右键，在出现的菜单里选中“仅显示被Hook的函数”，AST就会自动过滤正常的系统函数，用户可以方便快捷的查阅具体什么函数被驱动木马给拦截了，通常驱动木马最喜欢拦截以下函数：
    NtDeleteKey
    NtEnumerateKey
    NtQueryKey
    NtSetValueKey（注册表API）
    NtQueryDirectoryFile
    NtDeleteFile（文件操作API）
    NtOpenProcess
    NtTerminateProcess（进程操作API）
    拦截了这些函数，它们就可以达到无法查看、无法删除、无法终止的目的，这样也正是我们取消不了启动项的原因，因为相关的函数已经被拦截了，我们的操作实际上根本就没有影响到这些木马的一切。

    但是如果用户遇到的是改良型的高优先级木马或者感染了不止一个驱动木马时，问题就会变得棘手起来，这也是为什么一开始我并没有直接介绍使用AST查杀的原因，早些时候的AST在遇到这种状态的情况下，会无法正常搜集到被Hook的SSDT，而显示“正常”信息，但是用IceSword却能发现异常的Hook数据，在这种情况下由于AST存在bug，用户无法通过它来发现驱动木马的踪迹，如果用户不幸遇到这种驱动木马，他的查杀过程将会变得复杂起来……

    三、高手过招：
    在上述的步骤里我们可以查杀一般的在安全模式里无法启动的驱动木马，然而如果用户在安全模式里执行dir操作也无法列出记录下来的驱动文件名时，问题就棘手了，此时就用户遇到了高优先级驱动木马，它们在安全模式里也能被正常加载并实施保护！遇到这种情况，大部分人只能选择彻底格式化重装系统，就没有其他的方法解决吗？
通常在这种情况下，许多查杀手段都已失效，但是天无绝人之路，利用系统的特性，我们依然可以找到一线生机。

    和前面的步骤一样，首先把检测出来的驱动文件做个记录，然后进入“基于命令提示符的安全模式”里，直到dir的那一步，系统返回“找不到文件”的提示宣布了安全模式下照样运行的驱动木马的存在！此时需要冷静思考，熟悉DOS的朋友也许还记得，并不是只有dir这个命令可以查看文件。输入下面这个命令：
    Type文件名                    //在SSDT中被标记为红色的文件

    此时您会发现，如果这个驱动木马没有猖狂到封锁了某个涉及打开文件的API，用户会发现系统列出了一堆乱码，这个实际上就是驱动木马是否存在的依据！但是如果这时候用户继续执行更改文件属性和删除操作，将会发现一切都是前功尽弃，因为即使你执行了del命令，再次使用type或dir时，它又出现了。这是因为它已经hook了NtDeleteFile这个删除文件的API操作！