Rootkit
Rootkit自身也是木马后门或恶意程序的一类，只是，它很特殊，为什么呢？因为，你无法找到它。
正如自然界的规则一样，最流行的病毒，对生物的伤害却是最小的，例如一般的感冒，但是最不流行的病毒，却是最夺命的。Rootkit木马就是信息世界里的 AIDS，一旦感染，就难以用一般手段消灭了，因为它和自然界里的同类做的事情一样，破坏了系统自身检测的完整性——抛开术语的描述也许难以理解，但是可以配合AIDS的图片想象一下，由于AIDS破坏了人体免疫系统，导致白细胞对它无能为力，只能眼睁睁看着人体机能被慢慢破坏。计算机系统没有免疫功能，但是它提供了对自身环境的相关检测功能——枚举进程、文件列表、级别权限保护等，大部分杀毒软件和进程工具都依赖于系统自带的检测功能才得以运作，而 Rootkit木马要破坏的，正是这些功能。
要了解Rootkit木马的原理，就必须从系统原理说起，我们知道，操作系统是由内核（Kernel）和外壳（Shell）两部分组成的，内核负责一切实际的工作，包括CPU任务调度、内存分配管理、设备管理、文件操作等，外壳是基于内核提供的交互功能而存在的界面，它负责指令传递和解释。由于内核和外壳负责的任务不同，它们的处理环境也不同，因此处理器提供了多个不同的处理环境，把它们称为运行级别（Ring），Ring让程序指令能访问的计算机资源依次逐级递减，目的在于保护计算机遭受意外损害——内核运行于Ring 0级别，拥有最完全最底层的管理功能，而到了外壳部分，它只能拥有Ring 3级别，这个级别能操作的功能极少，几乎所有指令都需要传递给内核来决定能否执行，一旦发现有可能对系统造成破坏的指令传递（例如超越指定范围的内存读写），内核便返回一个“非法越权”标志，发送这个指令的程序就有可能被终止运行，这就是大部分常见的“非法操作”的由来，这样做的目的是为了保护计算机免遭破坏，如果外壳和内核的运行级别一样，用户一个不经意的点击都有可能破坏整个系统。
由于Ring的存在，除了由系统内核加载的程序以外，由外壳调用执行的一般程序都只能运行在Ring 3级别，也就是说，它们的操作指令全部依赖于内核授权的功能，一般的进程查看工具和杀毒软件也不例外，由于这层机制的存在，我们能看到的进程其实是内核 “看到”并通过相关接口指令（还记得API吗？）反馈到应用程序的，这样就不可避免的存在一条数据通道，虽然在一般情况下它是难以被篡改的，但是不能避免意外的发生，Rootkit正是“制造”这种意外的程序。简单的说，Rootkit实质是一种“越权执行”的应用程序，它设法让自己达到和内核一样的运行级别，甚至进入内核空间，这样它就拥有了和内核一样的访问权限，因而可以对内核指令进行修改，最常见的是修改内核枚举进程的API，让它们返回的数据始终 “遗漏”Rootkit自身进程的信息，一般的进程工具自然就“看”不到Rootkit了。更高级的Rootkit还篡改更多API，这样，用户就看不到进程（进程API被拦截），看不到文件（文件读写API被拦截），看不到被打开的端口（网络组件Sock API被拦截），更拦截不到相关的网络数据包（网络组件NDIS API被拦截）了，幸好网络设备的数据指示不受内核控制，否则恐怕Rootkit要让它也不会亮了才好！我们使用的系统是在内核功能支持下运作的，如果内核变得不可信任了，依赖它运行的程序还能信任吗？
这段概念是三年前写下的，而如今的网络世界，越来越多的木马后门在反病毒产品的围剿下消灭殆尽，就如同在一个密封的箱子里投入五大毒虫，让它们自相残杀，无论结局怎么样，总会有一方顽强的存活下来，而幸存的这只毒虫，就是最强最可怕的，只不过，反病毒产品并非每次都能成为存活下来的一方，而能够存活下来的非反病毒产品，必然是Rootkit。
这唯一幸存的毒虫所采用的技术迅速成了众人研究学习的重点，于是，Rootkit在短短几年内就走下了神秘的舞台，越来越“平民化”了，网络终于成为一个新的“艾滋病村”，在如此“平民化”的氛围里，Rootkit终于有了它“平民化”的名称：驱动木马、驱动马、带驱动的木马，诸如此类，而它的本名，也被缩写为“RK”，多用于高人之间的交流称谓。
而普通上网民众，对这些东西的存在完全是概不知情的，或者，仅限于一个模糊的概念……
当其他类型的木马后门技术已可以轻而易举被歼灭以后，Rootkit技术就成了这场对抗赛的主力军，于是，为了存活，“驱动马”也开始出现不同的发展分支，在普通网民尚未察觉的时候，它们早已经“变异”出不同派系了……
一切的开端：SSDT Hook
在很早很早以前，一些用户突然觉得自己的机器存在异常，并经常有被人监控的感觉，于是使用杀毒软件进行全盘扫描，答案却是否定的，于是用户就信任杀毒软件，放心的去用了，直到有一天，“灰鸽子”木马在网上闹得轰轰烈烈，用户慌忙去下载了最新专杀工具，这一下，用户被吓坏了：我是什么时候被感染的灰鸽子？
普通网民第一次与“会隐形的木马”打交道，莫过于灰鸽子事件了，但是为什么“灰鸽子”无法被任务管理器和那时候的杀毒软件找到，甚至用户自己手动去查找，也是无功而返呢？这是因为，灰鸽子使用了最初的Rootkit技术：SSDT钩子。
而后，又有一些尚在雏形阶段的恶意流氓软件，也开始大玩“隐身”了，用户们是丝毫没有察觉的，除非一些恶意程序太过于张扬，但是，即使如此，他们也始终找不到异常情况发生的依据，任务管理器里没有、搜索文件没有、就连注册表监视软件，也没了回应……
造成这些现象的原因是什么呢？因为灰鸽子，以及后来出现的恶意程序，它们使用的交互接口，并非Ring 3用户层上的标准Win32 API，而是通过各种手段，例如驱动程序，进入到Ring 0内核层的Native API。
“Native API”（原生API）是Windows NT架构系统中真正工作的API，众所周知，Windows是一个通过大量API函数来实现程序功能的系统，然而，由于Windows是支持POSIX标准（可移植操作系统接口，Portable Operating System Interface）的系统，这就意味着，它除了能运行标准Windows平台程序（即Win32程序）以外，还支持少量其他平台上的程序运行，如 OS/2。由于不同平台的程序功能实现方法差异，系统就必须分别为它支持的各个符合POSIX标准的程序提供相应的接口函数，如果根据这个思路去开发一套庞大而完整的接口函数调用，那就太不切实际了，于是，在NT架构系统上，开发者设计了两种不同性质的API接口层，一种被称为“用户态API”，它包括常见的Win32 API和POSIX接口API等，这些API运行在Ring3用户层上，构成了今天的Windows世界；而另一种是被称为“Native”性质的 API，它们才是真正的系统API，通常运行在内核态上，实现真正的系统核心功能调用。同时为了实现POSIX，开发者还设计了被称为“子系统”（Sub System）的技术来将不同的系统环境区别开来，正常情况下，从系统引导到桌面时，我们就处于“Win32”子系统下，这时候起到作用的自然就是 Win32 API。普通程序员平时接触到的几千个Win32 API，实际上都是通过几百个Native API的不同封装形式来实现的。系统厂商极少提供这些API的公开文档，是因为它们要比一般的函数难以应用而且可能发生变化，当程序员使用Win32 API时，最终的执行过程是在系统经过兼容性检查、错误处理、参数选项分离等一系列复杂转换后，才送入Native API进行处理的，Native API才是真正执行并反馈运行结果的主体，用户层的API调用只是一种封装形式罢了，例如fopen和CreateFile这两个Win32函数，它们的真正执行函数是Native性质的NtCreateFile，这就是rootkit可以让一般的进程工具不能发现自己的原因，因为它直接干涉了 Native API的执行结果。
因为API还有这样复杂的故事，所以现在的恶意程序纷纷为了能最大限度提升自己的权限而变身rootkit性质程序，去“钩”这些原生API，而达到同等层次的安全检测工具和反病毒产品，也为了达到同样的效果而做了同样的事情，到了这个地步，安全产品和恶意软件在执行过程中已经没有区别了，唯一的区别是对用户和系统环境造成的后果差异而已。
既然大家都要控制到原生API层，那么他们的做法有没有共同点呢？答案是一定的，Windows作为一个规范的系统，就必须在原生API和用户层API之间存在一个标准的接口来实现数据传递，并限制用户使用其他不知名的操作来达到目的，这个接口由一个名为“ntdll.dll”的动态链接库文件负责，所有用户层API的处理都是调用这个DLL文件中的相关API入口实现的，但它只是一个提供从用户层跳转到内核层的接口，它并不是最终执行体。当API调用被转换为ntdll内的相关API函数后，系统就会在一个被称为 “SSDT”（System Service Descriptor Table，系统服务描述符表）的数据表里查找这个API的位置，然后真正的调用它，这时候执行的API就是真正的原生API了，它们是位于NT系统真正内核程序ntoskrnl.exe里的函数。这一过程，就是系统服务的调用，例如外壳程序需要运行一个新的进程，那么它就会调用kernel32.dll 导出的API函数CreateProcess，接下来就是kernel32.dll内的执行过程，实际上它只是把这个请求又包装了一下，变形为自己发出的参数，去调用ntdll.dll里导出的NtCreateProcess函数，然后ntdll.dll通过一个中断请求int 2Eh（Sysenter）进入内核态，并把我们最初的新建进程请求转换为“服务号”一起传递过去，到了内核的世界里，在正常手段下对API的调用都需要先通过一个函数地址描述表的转变来实现，SSDT就是这个表，它记录了一个庞大的地址索引，内容为几百个原生API在内核中导出的地址位置，除此之外还有一些有用的其他信息，在这个例子里，系统根据SSDT里记录的服务号与函数对应关系来确认我们要使用什么函数，以及这个函数在内核中的位置信息，最终实现功能调用，函数执行完毕后再把结果通过ntdll接口一层层传递回去，直到发出请求的程序收到一个表示处理结果的状态代码，这一次系统服务的调用过程就结束了。
由于上述原理，无论是恶意程序还是反病毒产品都会优先考虑把SSDT的内容给篡改以达到效果，简单的说，例如一个恶意程序把SSDT里对于获取进程标识的服务号对应的原生API地址修改为指向自己位于Ring0层的驱动入口，那么每次系统执行到这个函数时，都会由于SSDT的错误引导而进入了作者指定的服务模块中，就会导致相关的操作请求和参数被这个第三方模块记录和篡改，于是各种奇怪的现象就会发生了，就拿隐藏自身进程的rootkit技术来说，其原理就在于通过篡改SSDT里枚举进程的原生API服务号先指向自己的模块，再由自己的模块另行传递到真正的系统服务上（如果没有这一步操作或者操作错误，那么这个对应的系统服务就会作废甚至引发系统崩溃），并对真正的系统服务返回的数据进行加工处理，如删除带有自己进程名的数据，那么最终返回的数据里自然就 “看不到”这个进程了。
通过操纵SSDT，以这个技术维生的Rootkit嚣张跋扈过一段时间，无论是木马后门还是流氓插件和恶意软件。在幕后挣钱的作者们也结结实实的过了个肥得流油的好年，然而好景不长，Anti-Rootki t（反Rootkit，即“ARK”）的概念被提出了，ARK工具也诞生了，如国产的IceSword、超级巡警等。此类ARK工具的运作原理和 Rootkit大相径庭，它们也是通过驱动模块将自身投入系统内核中，从而达到了与Rootkit们平起平坐的公平竞争地位，然后，位于用户层的程序主体和进入内核态的驱动模块同时产生一个相同的查询API，例如枚举当前系统进程列表等，由于Rootkit的存在，用户层的程序主体最终得到的数据会比驱动模块返回的数据少那么几个——很明显，Rootkit驱动拼命要隐藏起来的用户层程序就此暴露，不打自招了；而同时，ARK还能将当前SSDT服务号指向的函数幕后的执行主体找出来，如果某个服务号指向的函数对应的执行主体不是NTOSKRNL.EXE（XP及以上系统中，某些机器是 ntkrnlpa.exe），则可以断定该服务号有问题了。超级巡警以及后来的ARK更是直接提供了“一键恢复”功能，只需用户鼠标轻轻一点，所有第三方程序在SSDT挂住的钩子纷纷“脱钩”，短时间内就把RK布下的层层障碍给解除了，在一段时间内RK的势头迅速被压了下去，短暂的世界太平，短暂的，恩。
对于SSDT Hook，现在的所有Anti-Rootkit工具都能轻易找出并解除它的钩子（脱钩，Unhook），如IceSword、RKU、超级巡警等。
运行IceSword，首先点击“进程”，观察这里是否存在红色标记的进程，如果有，说明你的系统里绝对存在SSDT Hook，那红色的进程正是被底层驱动隐藏起来的文件，将它的具体位置记下来，并将其终止。
现在点击进入SSDT列表，会发现一些被红色标注出来的行列，记住它的“当前服务函数所在模块”，这个就是实施SSDT Hook的底层驱动文件。
然后，使用超级巡警切换至高级模式，将SSDT恢复为初始状态，它的所有防御就被解除了，现在直接查找刚才记录的文件去删除吧。
进一步试探：Shadow SSDT Hook
RK 作者不甘心，无论是出于技术上的抗争还是利益上的损失，反正，ARK既然让我丢了面子或瘪了钱包，那么，“有朝一日龙得水，定叫长江水倒流！”，一些人开始尝试研究破解Anti-Rootkit工具，誓与之抗争到底，另一些人，则开始了新的探索，最终，双方都有了成效：首先，pjf的大作 IceSword被成功反汇编了，虽然得到的并不是最初的C语言代码而是汇编语句，但是对于研究Rootkit的人来说，汇编在他们眼里，就如同看网络小说一样轻而易举，很快，就有人识破了作者的检测逻辑，可以绕过IceSword以及其他采用类似检测方法的工具的Rootkit就此诞生，甚至一部分RK 已经开始反过来监控ARK，一旦相应ARK的驱动被加载，立即开始玉石俱焚——将用户机器弄成经典的蓝屏死机，不明就里的用户在几次与蓝色屏幕对望后，通常都会无奈的放弃；而另一种蓝屏则是更深层次的问题导致的，下面会提到。
而探索另一个方向的研究者们，也传来了捷报：Windows系统里，除了那个大家都在玩的SSDT（KeServiceDescriptorTable）以外，还有一个隐藏得非常深入的类似SSDT结构的数据段在同时工作着，它被称为“Shadow SSDT”（SSDT映射），这个“KeServiceDescriptorTableShadow”功能并未从系统内核中导出，但是通过外联的系统级别调试器，却看到了它的踪影。Shadow SSDT的作用和SSDT本身差不多，只不过它主要是提供一些基于图形用户界面（GUI）下的系统服务函数，并保存了一份与SSDT相同的服务列表，当然，这也是提供给基于GUI下的程序调用的。Shadow SSDT被安排在win32k.sys中，非常少文献提及它，因此这几乎是个被人遗忘的角落，Rootkit作者们很快就发现，控制这里也能达到一定的效果，因为Shadow SSDT同样具备了SSDT的所有功能，只不过是要利用的时候多了一些步骤而已，于是RK又有了新的玩法，这一次，轮到ARK傻眼了，那时候ARK根本没有做到Shadow SSDT这一步，于是，只钩住Shadow SSDT的Rootkit们得以无法无天的生存下去，任由用户怎么发现恶意程序怎么恢复SSDT都好，始终都是影响不到此类Rootkit！
这个情形，一直到具备了Shadow SSDT检测功能的ARK工具出现才结束，例如大名鼎鼎的RootKit Unhooker（RKU），它那强大的SSDT以及其Shadow检测脱钩功能，帮助许多人解决了这些新生的捣蛋鬼，于是，Rootkit作者们又开始寻求新的生存之道。
此类Hook由于出现得比较晚，很多当初流行的ARK都没有涉及这块，所以，我们只能使用RKU、狙剑等工具对其进行操作。
运行RKU（Rootkit Unhooker），它是英文软件，但是操作十分简便。点击“Shadow SSDT”，如果系统中存在Shadow SSDT Hook，你会发现软件底部状态栏里“Services/Hooked”不再是“xxx/0”的状态，同时相应被Hook的函数显示行里， “Hooked”一栏为“Yes”，现在记下这个文件的位置和地址，然后直接点“UnHooked ALL”，接下来，去找文件删除吧。
逼近顶峰：Inline Hook
世界上最荒谬的事情是什么？是顺着被人故意弄乱方向的路牌，往错误的方向走了好远都没察觉到有问题？还是被朋友恶作剧的将男女洗手间的标识换了位置？如果有天去造访寺院，却发现里面居然是清一色的道士在念经，你一定会惊呼，这简直太荒谬了！
在狂热的Rootkit领域里，类似的荒谬正在散布开来，那就是高级的Hook形式——Inline Hook。
在最初的运作流程里，所有被设置了挂钩的函数操作，最终还是要回到原始功能模块内处理的，毕竟第三方程序作者不是Windows系统编写者，为了保证系统的正常运行，最明智的做法当然是让被拦截的相关函数请求在经过自己编写的模块的层层检测并发现无害以后，立即将这个即将进行正常工作的请求原封不动的送到它该干活的地方去，以便系统完成整个工作流程，所以大家都在打SSDT等地方的主意，就是为了在这条必经之路上插上一脚，力求能绊倒那些看着不顺眼的路人。而现在，路上出现会砍脚的保安了，怎么办，难道玩不下去了吗？然而，迎接挑战正是每个研究者的兴趣所在，于是，荒谬的念头带出了可怕的技术，这就是 Inline Hook。
其实，Inline Hook早就作为一种高级的Hook技术存在了，在用户层上的一些特殊程序如游戏外挂等，为了获得最完整可靠的数据，它们都不再采用错误指路牌的方法来将数据转移了，因为这样很可能会因为触发程序编写者针对此问题而设置的处理程序，最终功亏一篑。那么，怎么样才能让这个处理程序不能达到触发条件呢？那就是千万别去钩这个程序，但是如果不钩住程序，又该如何取得相关数据呢？在这样的思考模式下，一种新的钩子技术诞生了：它虽然也在玩钩子，但是它却不是来钩目标程序的，而是将系统里相应的API函数给虏了去，由于任何普通程序作者对系统API都是绝对信任的，于是，当他们的程序请求调用相关API并将参数一同发送过去时，由于提供这个API的相应模块被钩住了，它的“先知”——布施钩子者就抢先一步得到了数据内容，接下来就得看作者的编程功底来决定程序的生死了，因为作者并不能自己写出相应的系统函数，他就必须得设法将数据送回原函数执行模块里去，这一步稍有差错，就会导致调用这个API的程序崩溃退出。
正因如此，Inline Hook是一种相对一般Hook而言更复杂的技术，除非作者有较深的编程功底和对系统的了解，否则冒冒失失就大量使用这个技术是很容易出问题的，不仅受害者不好过，攻击者也无法取得他所需数据，得不偿失。
既然在用户层（Ring 3）上使用Inline Hook都要如此注意，那么在Rootkit的世界里有没有人吃螃蟹呢？答案是一定的，当钩住SSDT和Shadow SSDT的途径都被堵死以后，Rootkit技术终于向Inline Hook迈出了一步。
设想一下，当所有检测工具都在虎视眈眈SSDT这个关口时，某个Rootkit早已用自己的函数把系统内核里的敏感函数给替换了，当用户层的函数操作请求通过正常的SSDT找到相应内核态函数的执行主体时，却不知道这个执行主体早已被Rootkit冒名顶替了，那么情形会是怎么样的呢？虽然所有检测工具都报告情况正常，但是机器内其实早已被Rootkit安家，如果这个Rootkit预置了在某个时刻进行破坏行为的逻辑，那么用户直到系统出问题的那一刻，都还不知道究竟发生了什么事情！
位于Ring 0的Inline Hook是十分隐蔽的，除非研究者对系统了解较深，否则他想破了头也不能找出原因所在，更别提连杀个进程的概念都很迷茫的普通用户了。但是使用 Inline Hook是必须付出代价的，由于内核的复杂性，尤其因为位于这一层的函数是所有程序都必须频繁调用的，很多时候如果设钩者没考虑周全，导致某个已经 Inline Hook的函数被意外的直接调用，就会导致严重后果。所以，使用Inline Hook的Rootkit能否正常稳定的工作，是与作者的水平连接得十分紧密的，一个不成熟的用户层Inline Hook程序大不了就是跟着它要监控的程序一起引发内存错误导致非法操作异常退出，仅此而已，但是到了系统核心层，这里可没有任何错误检测模块来保证你的程序在做出会导致内核崩溃的事情之前就赶紧将它终止——这已经是最底层了，一个错误的内存读写都会直接引发内核级别的崩溃，即我们俗称的“蓝屏死机” （BSoD，Blue Screen of Dealth）。于是，不成熟的Inline Hook Rootkit的代价就是系统变得及其不稳定，在用户看来，电脑表现出来的症状就是莫名其妙的非常容易蓝屏，这就是技术不成熟的Rootkit导致的后果，只不过，这个代价是由受害的用户来承担的。
不过，目前能流行开来的Inline Hook Rootkit，基本上都是已经在开发者的机器上经历了无数次蓝屏考验后才出场的，所以通常情况下，用户并不会因为这些Rootkit的存在而频频蓝屏，并且，它已经成为当前Rootkit的主流技术。
对付Inline Hook，无论是狙剑、RKU还是Wsyscheck都可以做到，以狙剑为例，点击程序主界面的“扩展功能”，然后点击“SSDT检查”，你会突然有眼花缭乱的感觉，所以请点击右键——“筛选可疑项”，让它仅仅把异常部分显示出来（注意那个SnipeSword.sys，它是狙剑自身的驱动，不要弄错了），如果系统存在异常，“HOOK类型”里会列出相关说明，如HOOK、Inline-Hook等，首先可以尝试右键选择“恢复所有HOOK”，然后刷新一次，如果仍然列出异常项目，就得在相应的项目列上点击右键选择“恢复选定的Inline-HOOK”了。
紧紧缠绕的寄生藤：FSD Hook
随着RK与ARK的斗争进展，SSDT Hook（包括Shadow Hook）的道路被清理了，Inline Hook也被揪出来清理了，但是一些用户惊讶的发现，他们仍然无法删除这些已经暴露在眼皮底下的文件，这是为什么？
在解说这个问题之前，我们先来了解一些概念。为了让用户敲打键盘、点击鼠标、插入U盘等就能直接进入计算机的世界，操作系统在幕后是做了相当多的工作的，这些在底层运作的功能层层汇聚，最终建立出一个可用的操作平台，其中，负责管理磁盘数据和文件读写的部分被称为“文件系统”（File System，FS），其中，Windows系列操作系统是采用IOS（Input/Output Supervisor，输入输出管理程序）技术进行文件系统管理的。它接管所有的存储设备，如硬盘、可移动式磁盘、光驱等。
IOS是一种层次结构的管理方案，展现在用户层上的是各种应用程序的读写操作，其下一层紧接着的是被称为“可安装文件系统”（Installable File System，IFS）的接口层，这一层是以下各层的最终汇聚，通俗点说，也就是我们在屏幕上看到磁盘盘符、光驱盘符、U盘盘符、网络磁盘映射盘符等图标并对它们进行操作的由来。继IFS以后，就是各种文件系统驱动所在的层，即“FSD”（File System Driver，文件系统驱动），这一层直接与IOS连接，用于接受并处理属于自己任务分派内的数据；FSD下一层直达IOS，而到了IOS的下一层，数据就开始往硬件化发展了。
而这次Rootkit的目标，就是到达IOS之前的最后一层：FSD。
FSD在Windows系统中属于开放给编程人员可接触到的最深入的一块区域（再往下就是操作系统自身提供的驱动和硬件厂商的事情了），所以，这一层的权限是很高的，控制了这个层次，开发者就能掌握到最多最全面的文件读写操作控制，于是，当所有的道路都被Anti-Rootkit工具阻挠后， Rootkit作者开始反抗，方法是阻止他们的工具将揪出来的Rootkit直接歼灭。
FSD并非绝对禁地，在这之前，反病毒厂商和磁盘数据加密厂商早就在这一层里专研了，一部分人致力于编写自己的FSD，而更多的人，是通过编写FSD Filter Driver（文件系统驱动过滤器）来达到目的，以便从中析出它们敏感的数据来进行其他工作，而Filter驱动的一个要点就是钩住FSD，即“FSD Hook”。当FSD被你掌握后，你就可以通过操纵它的数据来控制别人的文件读写请求，对于Rootkit来说，它们可以将一些敏感文件如自身驱动程序文件、用户层相关文件等设置为除了它们自己以外的程序都无法对其进行读写的效果，到了用户层，直接反映出来的就是无法对其进行编辑、改名和删除。
用了这个技术，Rootkit作者们又可以偷笑了，因为即使用户用各种手段找到了它并将其进程终止，他也无法操作那些被保护起来的文件。
只是，钩子始终是钩子，总会有人去脱钩的，在克制FSD Hook技术的ARK工具出现后，一部分人面对着十分难以操作的FSD而放弃了，因为到了这一层已经非常容易导致系统不稳定了。
而一些人，仍然走了下去。
如何清理这个类型的Rootkit呢？以最容易操作的Wsyscheck为例，首先运行Wsyscheck（你会发现一个有趣现象：IceSword无法检测到Wsyscheck的Hook，因为它用的技术是Inline Hook和FSD Hook），点击进入“内核检查”，选中“FSD检查”，留意“代码异常”项里是否有标注为“Yes”的项，如果有，请在界面里右键点击，并选择“恢复所有函数”。Wsyscheck的进程列表并非使用IceSword一类的逻辑，所以如果你看到存在红色的列表也不要太过于紧张，它只是表示这个程序是没有系统签名验证、且类型特殊（如服务、加载驱动等）的应用程序而已，并非是IceSword这样的“坏人标识”。
产于极端的终极技术：FSD Inline Hook
Rootkit到了FSD Hook这一层，对系统造成的影响已经相当危险了，然而，由于出现了对抗的工具触动了某些人的利益，终于，一个著名的流氓软件吃了这只大家都会因为良心不安而不去触碰的螃蟹——FSD Inline Hook。
在及其重要敏感的FSD环境下放钩子本身就是一件要求很高的事情，而用自己的函数去替代这个雷区的系统函数，更是被很多人认为是严禁操作的事情，而现在，真的有人带头违反了，以后的局势又将如何呢？
所以，将CNNIC列为当前流氓软件作者的所有研究目标都不过分，因为CNNIC身上，就具备了多种高级技术，只可惜，全都没有用于正道。
Inline Hook的概念我们在前面已经说过了，现在主要说说这个Rootkit的行为以及后果。
也许是CNNIC的开发者对于自家产品频频被删除而恼怒了吧，这次最新发布的程序中，FSD Inline Hook终于出现了，它直接将操作系统厂商编写的相关功能使用自己的函数去取代了，而搞过FSD开发的人都知道，这一层的功能函数对硬件平台、系统版本是具有高度依赖性的，每个操作系统采用的函数都会有些许差异，但是操作系统厂商并不是制作通用的FSD方案，更何况，这个标准就是他们自己提出来的，所以这些变动对他们而言都是无伤大雅的，但是对于第三方厂商来说，他们缺少必要的开发文档（微软并未公布任何涉及FSD Inline Hook技术文档，也不鼓励开发者这样做）和齐全的硬件测试平台，所以，在不齐全的操作系统环境和硬件配置下实现的技术，必然很容易就导致受害用户直接欣赏到赏心悦目的蓝屏。
CNNIC必然清楚这点，但是，他们什么也不顾了。而且，CNNIC的技术水平果然也没达到稳定的水平，在被CNNIC安家的系统里，用户只要运行 IceSword检测，就会直接导致蓝屏，这是因为它们都同时钩住了一个底层函数，但是下钩的位置存在些许偏差，例如，一个钩住了头部，一个钩住了屁股，于是内核受不了这很黄很暴力的行为，而直接崩溃了。
但是，毕竟已经有人起了头。以后的Rootkit世界将会变成什么样子，谁也不知道。
要消灭CNNIC以及采用FSD Inline Hook技术的Rootkit，首选应该是360安全卫士，但是如果出现了360安全卫士也未加入识别的Rootkit，用户就得使用“狙剑”了，解决方法与前面提及的大同小异，只需要对其“脱钩”就可以了，关键在于，用户还得留意Rootkit的用户层程序是否也使用Hook，如线程注入等。
正如自然界的规则一样，最流行的病毒，对生物的伤害却是最小的，例如一般的感冒，但是最不流行的病毒，却是最夺命的。Rootkit木马就是信息世界里的 AIDS，一旦感染，就难以用一般手段消灭了，因为它和自然界里的同类做的事情一样，破坏了系统自身检测的完整性——抛开术语的描述也许难以理解，但是可以配合AIDS的图片想象一下，由于AIDS破坏了人体免疫系统，导致白细胞对它无能为力，只能眼睁睁看着人体机能被慢慢破坏。计算机系统没有免疫功能，但是它提供了对自身环境的相关检测功能——枚举进程、文件列表、级别权限保护等，大部分杀毒软件和进程工具都依赖于系统自带的检测功能才得以运作，而 Rootkit木马要破坏的，正是这些功能。
要了解Rootkit木马的原理，就必须从系统原理说起，我们知道，操作系统是由内核（Kernel）和外壳（Shell）两部分组成的，内核负责一切实际的工作，包括CPU任务调度、内存分配管理、设备管理、文件操作等，外壳是基于内核提供的交互功能而存在的界面，它负责指令传递和解释。由于内核和外壳负责的任务不同，它们的处理环境也不同，因此处理器提供了多个不同的处理环境，把它们称为运行级别（Ring），Ring让程序指令能访问的计算机资源依次逐级递减，目的在于保护计算机遭受意外损害——内核运行于Ring 0级别，拥有最完全最底层的管理功能，而到了外壳部分，它只能拥有Ring 3级别，这个级别能操作的功能极少，几乎所有指令都需要传递给内核来决定能否执行，一旦发现有可能对系统造成破坏的指令传递（例如超越指定范围的内存读写），内核便返回一个“非法越权”标志，发送这个指令的程序就有可能被终止运行，这就是大部分常见的“非法操作”的由来，这样做的目的是为了保护计算机免遭破坏，如果外壳和内核的运行级别一样，用户一个不经意的点击都有可能破坏整个系统。
由于Ring的存在，除了由系统内核加载的程序以外，由外壳调用执行的一般程序都只能运行在Ring 3级别，也就是说，它们的操作指令全部依赖于内核授权的功能，一般的进程查看工具和杀毒软件也不例外，由于这层机制的存在，我们能看到的进程其实是内核 “看到”并通过相关接口指令（还记得API吗？）反馈到应用程序的，这样就不可避免的存在一条数据通道，虽然在一般情况下它是难以被篡改的，但是不能避免意外的发生，Rootkit正是“制造”这种意外的程序。简单的说，Rootkit实质是一种“越权执行”的应用程序，它设法让自己达到和内核一样的运行级别，甚至进入内核空间，这样它就拥有了和内核一样的访问权限，因而可以对内核指令进行修改，最常见的是修改内核枚举进程的API，让它们返回的数据始终 “遗漏”Rootkit自身进程的信息，一般的进程工具自然就“看”不到Rootkit了。更高级的Rootkit还篡改更多API，这样，用户就看不到进程（进程API被拦截），看不到文件（文件读写API被拦截），看不到被打开的端口（网络组件Sock API被拦截），更拦截不到相关的网络数据包（网络组件NDIS API被拦截）了，幸好网络设备的数据指示不受内核控制，否则恐怕Rootkit要让它也不会亮了才好！我们使用的系统是在内核功能支持下运作的，如果内核变得不可信任了，依赖它运行的程序还能信任吗？
这段概念是三年前写下的，而如今的网络世界，越来越多的木马后门在反病毒产品的围剿下消灭殆尽，就如同在一个密封的箱子里投入五大毒虫，让它们自相残杀，无论结局怎么样，总会有一方顽强的存活下来，而幸存的这只毒虫，就是最强最可怕的，只不过，反病毒产品并非每次都能成为存活下来的一方，而能够存活下来的非反病毒产品，必然是Rootkit。
这唯一幸存的毒虫所采用的技术迅速成了众人研究学习的重点，于是，Rootkit在短短几年内就走下了神秘的舞台，越来越“平民化”了，网络终于成为一个新的“艾滋病村”，在如此“平民化”的氛围里，Rootkit终于有了它“平民化”的名称：驱动木马、驱动马、带驱动的木马，诸如此类，而它的本名，也被缩写为“RK”，多用于高人之间的交流称谓。
而普通上网民众，对这些东西的存在完全是概不知情的，或者，仅限于一个模糊的概念……
当其他类型的木马后门技术已可以轻而易举被歼灭以后，Rootkit技术就成了这场对抗赛的主力军，于是，为了存活，“驱动马”也开始出现不同的发展分支，在普通网民尚未察觉的时候，它们早已经“变异”出不同派系了……
一切的开端：SSDT Hook
在很早很早以前，一些用户突然觉得自己的机器存在异常，并经常有被人监控的感觉，于是使用杀毒软件进行全盘扫描，答案却是否定的，于是用户就信任杀毒软件，放心的去用了，直到有一天，“灰鸽子”木马在网上闹得轰轰烈烈，用户慌忙去下载了最新专杀工具，这一下，用户被吓坏了：我是什么时候被感染的灰鸽子？
普通网民第一次与“会隐形的木马”打交道，莫过于灰鸽子事件了，但是为什么“灰鸽子”无法被任务管理器和那时候的杀毒软件找到，甚至用户自己手动去查找，也是无功而返呢？这是因为，灰鸽子使用了最初的Rootkit技术：SSDT钩子。
而后，又有一些尚在雏形阶段的恶意流氓软件，也开始大玩“隐身”了，用户们是丝毫没有察觉的，除非一些恶意程序太过于张扬，但是，即使如此，他们也始终找不到异常情况发生的依据，任务管理器里没有、搜索文件没有、就连注册表监视软件，也没了回应……
造成这些现象的原因是什么呢？因为灰鸽子，以及后来出现的恶意程序，它们使用的交互接口，并非Ring 3用户层上的标准Win32 API，而是通过各种手段，例如驱动程序，进入到Ring 0内核层的Native API。
“Native API”（原生API）是Windows NT架构系统中真正工作的API，众所周知，Windows是一个通过大量API函数来实现程序功能的系统，然而，由于Windows是支持POSIX标准（可移植操作系统接口，Portable Operating System Interface）的系统，这就意味着，它除了能运行标准Windows平台程序（即Win32程序）以外，还支持少量其他平台上的程序运行，如 OS/2。由于不同平台的程序功能实现方法差异，系统就必须分别为它支持的各个符合POSIX标准的程序提供相应的接口函数，如果根据这个思路去开发一套庞大而完整的接口函数调用，那就太不切实际了，于是，在NT架构系统上，开发者设计了两种不同性质的API接口层，一种被称为“用户态API”，它包括常见的Win32 API和POSIX接口API等，这些API运行在Ring3用户层上，构成了今天的Windows世界；而另一种是被称为“Native”性质的 API，它们才是真正的系统API，通常运行在内核态上，实现真正的系统核心功能调用。同时为了实现POSIX，开发者还设计了被称为“子系统”（Sub System）的技术来将不同的系统环境区别开来，正常情况下，从系统引导到桌面时，我们就处于“Win32”子系统下，这时候起到作用的自然就是 Win32 API。普通程序员平时接触到的几千个Win32 API，实际上都是通过几百个Native API的不同封装形式来实现的。系统厂商极少提供这些API的公开文档，是因为它们要比一般的函数难以应用而且可能发生变化，当程序员使用Win32 API时，最终的执行过程是在系统经过兼容性检查、错误处理、参数选项分离等一系列复杂转换后，才送入Native API进行处理的，Native API才是真正执行并反馈运行结果的主体，用户层的API调用只是一种封装形式罢了，例如fopen和CreateFile这两个Win32函数，它们的真正执行函数是Native性质的NtCreateFile，这就是rootkit可以让一般的进程工具不能发现自己的原因，因为它直接干涉了 Native API的执行结果。
因为API还有这样复杂的故事，所以现在的恶意程序纷纷为了能最大限度提升自己的权限而变身rootkit性质程序，去“钩”这些原生API，而达到同等层次的安全检测工具和反病毒产品，也为了达到同样的效果而做了同样的事情，到了这个地步，安全产品和恶意软件在执行过程中已经没有区别了，唯一的区别是对用户和系统环境造成的后果差异而已。
既然大家都要控制到原生API层，那么他们的做法有没有共同点呢？答案是一定的，Windows作为一个规范的系统，就必须在原生API和用户层API之间存在一个标准的接口来实现数据传递，并限制用户使用其他不知名的操作来达到目的，这个接口由一个名为“ntdll.dll”的动态链接库文件负责，所有用户层API的处理都是调用这个DLL文件中的相关API入口实现的，但它只是一个提供从用户层跳转到内核层的接口，它并不是最终执行体。当API调用被转换为ntdll内的相关API函数后，系统就会在一个被称为 “SSDT”（System Service Descriptor Table，系统服务描述符表）的数据表里查找这个API的位置，然后真正的调用它，这时候执行的API就是真正的原生API了，它们是位于NT系统真正内核程序ntoskrnl.exe里的函数。这一过程，就是系统服务的调用，例如外壳程序需要运行一个新的进程，那么它就会调用kernel32.dll 导出的API函数CreateProcess，接下来就是kernel32.dll内的执行过程，实际上它只是把这个请求又包装了一下，变形为自己发出的参数，去调用ntdll.dll里导出的NtCreateProcess函数，然后ntdll.dll通过一个中断请求int 2Eh（Sysenter）进入内核态，并把我们最初的新建进程请求转换为“服务号”一起传递过去，到了内核的世界里，在正常手段下对API的调用都需要先通过一个函数地址描述表的转变来实现，SSDT就是这个表，它记录了一个庞大的地址索引，内容为几百个原生API在内核中导出的地址位置，除此之外还有一些有用的其他信息，在这个例子里，系统根据SSDT里记录的服务号与函数对应关系来确认我们要使用什么函数，以及这个函数在内核中的位置信息，最终实现功能调用，函数执行完毕后再把结果通过ntdll接口一层层传递回去，直到发出请求的程序收到一个表示处理结果的状态代码，这一次系统服务的调用过程就结束了。
由于上述原理，无论是恶意程序还是反病毒产品都会优先考虑把SSDT的内容给篡改以达到效果，简单的说，例如一个恶意程序把SSDT里对于获取进程标识的服务号对应的原生API地址修改为指向自己位于Ring0层的驱动入口，那么每次系统执行到这个函数时，都会由于SSDT的错误引导而进入了作者指定的服务模块中，就会导致相关的操作请求和参数被这个第三方模块记录和篡改，于是各种奇怪的现象就会发生了，就拿隐藏自身进程的rootkit技术来说，其原理就在于通过篡改SSDT里枚举进程的原生API服务号先指向自己的模块，再由自己的模块另行传递到真正的系统服务上（如果没有这一步操作或者操作错误，那么这个对应的系统服务就会作废甚至引发系统崩溃），并对真正的系统服务返回的数据进行加工处理，如删除带有自己进程名的数据，那么最终返回的数据里自然就 “看不到”这个进程了。
通过操纵SSDT，以这个技术维生的Rootkit嚣张跋扈过一段时间，无论是木马后门还是流氓插件和恶意软件。在幕后挣钱的作者们也结结实实的过了个肥得流油的好年，然而好景不长，Anti-Rootki t（反Rootkit，即“ARK”）的概念被提出了，ARK工具也诞生了，如国产的IceSword、超级巡警等。此类ARK工具的运作原理和 Rootkit大相径庭，它们也是通过驱动模块将自身投入系统内核中，从而达到了与Rootkit们平起平坐的公平竞争地位，然后，位于用户层的程序主体和进入内核态的驱动模块同时产生一个相同的查询API，例如枚举当前系统进程列表等，由于Rootkit的存在，用户层的程序主体最终得到的数据会比驱动模块返回的数据少那么几个——很明显，Rootkit驱动拼命要隐藏起来的用户层程序就此暴露，不打自招了；而同时，ARK还能将当前SSDT服务号指向的函数幕后的执行主体找出来，如果某个服务号指向的函数对应的执行主体不是NTOSKRNL.EXE（XP及以上系统中，某些机器是 ntkrnlpa.exe），则可以断定该服务号有问题了。超级巡警以及后来的ARK更是直接提供了“一键恢复”功能，只需用户鼠标轻轻一点，所有第三方程序在SSDT挂住的钩子纷纷“脱钩”，短时间内就把RK布下的层层障碍给解除了，在一段时间内RK的势头迅速被压了下去，短暂的世界太平，短暂的，恩。
对于SSDT Hook，现在的所有Anti-Rootkit工具都能轻易找出并解除它的钩子（脱钩，Unhook），如IceSword、RKU、超级巡警等。
运行IceSword，首先点击“进程”，观察这里是否存在红色标记的进程，如果有，说明你的系统里绝对存在SSDT Hook，那红色的进程正是被底层驱动隐藏起来的文件，将它的具体位置记下来，并将其终止。
现在点击进入SSDT列表，会发现一些被红色标注出来的行列，记住它的“当前服务函数所在模块”，这个就是实施SSDT Hook的底层驱动文件。
然后，使用超级巡警切换至高级模式，将SSDT恢复为初始状态，它的所有防御就被解除了，现在直接查找刚才记录的文件去删除吧。
进一步试探：Shadow SSDT Hook
RK 作者不甘心，无论是出于技术上的抗争还是利益上的损失，反正，ARK既然让我丢了面子或瘪了钱包，那么，“有朝一日龙得水，定叫长江水倒流！”，一些人开始尝试研究破解Anti-Rootkit工具，誓与之抗争到底，另一些人，则开始了新的探索，最终，双方都有了成效：首先，pjf的大作 IceSword被成功反汇编了，虽然得到的并不是最初的C语言代码而是汇编语句，但是对于研究Rootkit的人来说，汇编在他们眼里，就如同看网络小说一样轻而易举，很快，就有人识破了作者的检测逻辑，可以绕过IceSword以及其他采用类似检测方法的工具的Rootkit就此诞生，甚至一部分RK 已经开始反过来监控ARK，一旦相应ARK的驱动被加载，立即开始玉石俱焚——将用户机器弄成经典的蓝屏死机，不明就里的用户在几次与蓝色屏幕对望后，通常都会无奈的放弃；而另一种蓝屏则是更深层次的问题导致的，下面会提到。
而探索另一个方向的研究者们，也传来了捷报：Windows系统里，除了那个大家都在玩的SSDT（KeServiceDescriptorTable）以外，还有一个隐藏得非常深入的类似SSDT结构的数据段在同时工作着，它被称为“Shadow SSDT”（SSDT映射），这个“KeServiceDescriptorTableShadow”功能并未从系统内核中导出，但是通过外联的系统级别调试器，却看到了它的踪影。Shadow SSDT的作用和SSDT本身差不多，只不过它主要是提供一些基于图形用户界面（GUI）下的系统服务函数，并保存了一份与SSDT相同的服务列表，当然，这也是提供给基于GUI下的程序调用的。Shadow SSDT被安排在win32k.sys中，非常少文献提及它，因此这几乎是个被人遗忘的角落，Rootkit作者们很快就发现，控制这里也能达到一定的效果，因为Shadow SSDT同样具备了SSDT的所有功能，只不过是要利用的时候多了一些步骤而已，于是RK又有了新的玩法，这一次，轮到ARK傻眼了，那时候ARK根本没有做到Shadow SSDT这一步，于是，只钩住Shadow SSDT的Rootkit们得以无法无天的生存下去，任由用户怎么发现恶意程序怎么恢复SSDT都好，始终都是影响不到此类Rootkit！
这个情形，一直到具备了Shadow SSDT检测功能的ARK工具出现才结束，例如大名鼎鼎的RootKit Unhooker（RKU），它那强大的SSDT以及其Shadow检测脱钩功能，帮助许多人解决了这些新生的捣蛋鬼，于是，Rootkit作者们又开始寻求新的生存之道。
此类Hook由于出现得比较晚，很多当初流行的ARK都没有涉及这块，所以，我们只能使用RKU、狙剑等工具对其进行操作。
运行RKU（Rootkit Unhooker），它是英文软件，但是操作十分简便。点击“Shadow SSDT”，如果系统中存在Shadow SSDT Hook，你会发现软件底部状态栏里“Services/Hooked”不再是“xxx/0”的状态，同时相应被Hook的函数显示行里， “Hooked”一栏为“Yes”，现在记下这个文件的位置和地址，然后直接点“UnHooked ALL”，接下来，去找文件删除吧。
逼近顶峰：Inline Hook
世界上最荒谬的事情是什么？是顺着被人故意弄乱方向的路牌，往错误的方向走了好远都没察觉到有问题？还是被朋友恶作剧的将男女洗手间的标识换了位置？如果有天去造访寺院，却发现里面居然是清一色的道士在念经，你一定会惊呼，这简直太荒谬了！
在狂热的Rootkit领域里，类似的荒谬正在散布开来，那就是高级的Hook形式——Inline Hook。
在最初的运作流程里，所有被设置了挂钩的函数操作，最终还是要回到原始功能模块内处理的，毕竟第三方程序作者不是Windows系统编写者，为了保证系统的正常运行，最明智的做法当然是让被拦截的相关函数请求在经过自己编写的模块的层层检测并发现无害以后，立即将这个即将进行正常工作的请求原封不动的送到它该干活的地方去，以便系统完成整个工作流程，所以大家都在打SSDT等地方的主意，就是为了在这条必经之路上插上一脚，力求能绊倒那些看着不顺眼的路人。而现在，路上出现会砍脚的保安了，怎么办，难道玩不下去了吗？然而，迎接挑战正是每个研究者的兴趣所在，于是，荒谬的念头带出了可怕的技术，这就是 Inline Hook。
其实，Inline Hook早就作为一种高级的Hook技术存在了，在用户层上的一些特殊程序如游戏外挂等，为了获得最完整可靠的数据，它们都不再采用错误指路牌的方法来将数据转移了，因为这样很可能会因为触发程序编写者针对此问题而设置的处理程序，最终功亏一篑。那么，怎么样才能让这个处理程序不能达到触发条件呢？那就是千万别去钩这个程序，但是如果不钩住程序，又该如何取得相关数据呢？在这样的思考模式下，一种新的钩子技术诞生了：它虽然也在玩钩子，但是它却不是来钩目标程序的，而是将系统里相应的API函数给虏了去，由于任何普通程序作者对系统API都是绝对信任的，于是，当他们的程序请求调用相关API并将参数一同发送过去时，由于提供这个API的相应模块被钩住了，它的“先知”——布施钩子者就抢先一步得到了数据内容，接下来就得看作者的编程功底来决定程序的生死了，因为作者并不能自己写出相应的系统函数，他就必须得设法将数据送回原函数执行模块里去，这一步稍有差错，就会导致调用这个API的程序崩溃退出。
正因如此，Inline Hook是一种相对一般Hook而言更复杂的技术，除非作者有较深的编程功底和对系统的了解，否则冒冒失失就大量使用这个技术是很容易出问题的，不仅受害者不好过，攻击者也无法取得他所需数据，得不偿失。
既然在用户层（Ring 3）上使用Inline Hook都要如此注意，那么在Rootkit的世界里有没有人吃螃蟹呢？答案是一定的，当钩住SSDT和Shadow SSDT的途径都被堵死以后，Rootkit技术终于向Inline Hook迈出了一步。
设想一下，当所有检测工具都在虎视眈眈SSDT这个关口时，某个Rootkit早已用自己的函数把系统内核里的敏感函数给替换了，当用户层的函数操作请求通过正常的SSDT找到相应内核态函数的执行主体时，却不知道这个执行主体早已被Rootkit冒名顶替了，那么情形会是怎么样的呢？虽然所有检测工具都报告情况正常，但是机器内其实早已被Rootkit安家，如果这个Rootkit预置了在某个时刻进行破坏行为的逻辑，那么用户直到系统出问题的那一刻，都还不知道究竟发生了什么事情！
位于Ring 0的Inline Hook是十分隐蔽的，除非研究者对系统了解较深，否则他想破了头也不能找出原因所在，更别提连杀个进程的概念都很迷茫的普通用户了。但是使用 Inline Hook是必须付出代价的，由于内核的复杂性，尤其因为位于这一层的函数是所有程序都必须频繁调用的，很多时候如果设钩者没考虑周全，导致某个已经 Inline Hook的函数被意外的直接调用，就会导致严重后果。所以，使用Inline Hook的Rootkit能否正常稳定的工作，是与作者的水平连接得十分紧密的，一个不成熟的用户层Inline Hook程序大不了就是跟着它要监控的程序一起引发内存错误导致非法操作异常退出，仅此而已，但是到了系统核心层，这里可没有任何错误检测模块来保证你的程序在做出会导致内核崩溃的事情之前就赶紧将它终止——这已经是最底层了，一个错误的内存读写都会直接引发内核级别的崩溃，即我们俗称的“蓝屏死机” （BSoD，Blue Screen of Dealth）。于是，不成熟的Inline Hook Rootkit的代价就是系统变得及其不稳定，在用户看来，电脑表现出来的症状就是莫名其妙的非常容易蓝屏，这就是技术不成熟的Rootkit导致的后果，只不过，这个代价是由受害的用户来承担的。
不过，目前能流行开来的Inline Hook Rootkit，基本上都是已经在开发者的机器上经历了无数次蓝屏考验后才出场的，所以通常情况下，用户并不会因为这些Rootkit的存在而频频蓝屏，并且，它已经成为当前Rootkit的主流技术。
对付Inline Hook，无论是狙剑、RKU还是Wsyscheck都可以做到，以狙剑为例，点击程序主界面的“扩展功能”，然后点击“SSDT检查”，你会突然有眼花缭乱的感觉，所以请点击右键——“筛选可疑项”，让它仅仅把异常部分显示出来（注意那个SnipeSword.sys，它是狙剑自身的驱动，不要弄错了），如果系统存在异常，“HOOK类型”里会列出相关说明，如HOOK、Inline-Hook等，首先可以尝试右键选择“恢复所有HOOK”，然后刷新一次，如果仍然列出异常项目，就得在相应的项目列上点击右键选择“恢复选定的Inline-HOOK”了。
紧紧缠绕的寄生藤：FSD Hook
随着RK与ARK的斗争进展，SSDT Hook（包括Shadow Hook）的道路被清理了，Inline Hook也被揪出来清理了，但是一些用户惊讶的发现，他们仍然无法删除这些已经暴露在眼皮底下的文件，这是为什么？
在解说这个问题之前，我们先来了解一些概念。为了让用户敲打键盘、点击鼠标、插入U盘等就能直接进入计算机的世界，操作系统在幕后是做了相当多的工作的，这些在底层运作的功能层层汇聚，最终建立出一个可用的操作平台，其中，负责管理磁盘数据和文件读写的部分被称为“文件系统”（File System，FS），其中，Windows系列操作系统是采用IOS（Input/Output Supervisor，输入输出管理程序）技术进行文件系统管理的。它接管所有的存储设备，如硬盘、可移动式磁盘、光驱等。
IOS是一种层次结构的管理方案，展现在用户层上的是各种应用程序的读写操作，其下一层紧接着的是被称为“可安装文件系统”（Installable File System，IFS）的接口层，这一层是以下各层的最终汇聚，通俗点说，也就是我们在屏幕上看到磁盘盘符、光驱盘符、U盘盘符、网络磁盘映射盘符等图标并对它们进行操作的由来。继IFS以后，就是各种文件系统驱动所在的层，即“FSD”（File System Driver，文件系统驱动），这一层直接与IOS连接，用于接受并处理属于自己任务分派内的数据；FSD下一层直达IOS，而到了IOS的下一层，数据就开始往硬件化发展了。
而这次Rootkit的目标，就是到达IOS之前的最后一层：FSD。
FSD在Windows系统中属于开放给编程人员可接触到的最深入的一块区域（再往下就是操作系统自身提供的驱动和硬件厂商的事情了），所以，这一层的权限是很高的，控制了这个层次，开发者就能掌握到最多最全面的文件读写操作控制，于是，当所有的道路都被Anti-Rootkit工具阻挠后， Rootkit作者开始反抗，方法是阻止他们的工具将揪出来的Rootkit直接歼灭。
FSD并非绝对禁地，在这之前，反病毒厂商和磁盘数据加密厂商早就在这一层里专研了，一部分人致力于编写自己的FSD，而更多的人，是通过编写FSD Filter Driver（文件系统驱动过滤器）来达到目的，以便从中析出它们敏感的数据来进行其他工作，而Filter驱动的一个要点就是钩住FSD，即“FSD Hook”。当FSD被你掌握后，你就可以通过操纵它的数据来控制别人的文件读写请求，对于Rootkit来说，它们可以将一些敏感文件如自身驱动程序文件、用户层相关文件等设置为除了它们自己以外的程序都无法对其进行读写的效果，到了用户层，直接反映出来的就是无法对其进行编辑、改名和删除。
用了这个技术，Rootkit作者们又可以偷笑了，因为即使用户用各种手段找到了它并将其进程终止，他也无法操作那些被保护起来的文件。
只是，钩子始终是钩子，总会有人去脱钩的，在克制FSD Hook技术的ARK工具出现后，一部分人面对着十分难以操作的FSD而放弃了，因为到了这一层已经非常容易导致系统不稳定了。
而一些人，仍然走了下去。
如何清理这个类型的Rootkit呢？以最容易操作的Wsyscheck为例，首先运行Wsyscheck（你会发现一个有趣现象：IceSword无法检测到Wsyscheck的Hook，因为它用的技术是Inline Hook和FSD Hook），点击进入“内核检查”，选中“FSD检查”，留意“代码异常”项里是否有标注为“Yes”的项，如果有，请在界面里右键点击，并选择“恢复所有函数”。Wsyscheck的进程列表并非使用IceSword一类的逻辑，所以如果你看到存在红色的列表也不要太过于紧张，它只是表示这个程序是没有系统签名验证、且类型特殊（如服务、加载驱动等）的应用程序而已，并非是IceSword这样的“坏人标识”。
产于极端的终极技术：FSD Inline Hook
Rootkit到了FSD Hook这一层，对系统造成的影响已经相当危险了，然而，由于出现了对抗的工具触动了某些人的利益，终于，一个著名的流氓软件吃了这只大家都会因为良心不安而不去触碰的螃蟹——FSD Inline Hook。
在及其重要敏感的FSD环境下放钩子本身就是一件要求很高的事情，而用自己的函数去替代这个雷区的系统函数，更是被很多人认为是严禁操作的事情，而现在，真的有人带头违反了，以后的局势又将如何呢？
所以，将CNNIC列为当前流氓软件作者的所有研究目标都不过分，因为CNNIC身上，就具备了多种高级技术，只可惜，全都没有用于正道。
Inline Hook的概念我们在前面已经说过了，现在主要说说这个Rootkit的行为以及后果。
也许是CNNIC的开发者对于自家产品频频被删除而恼怒了吧，这次最新发布的程序中，FSD Inline Hook终于出现了，它直接将操作系统厂商编写的相关功能使用自己的函数去取代了，而搞过FSD开发的人都知道，这一层的功能函数对硬件平台、系统版本是具有高度依赖性的，每个操作系统采用的函数都会有些许差异，但是操作系统厂商并不是制作通用的FSD方案，更何况，这个标准就是他们自己提出来的，所以这些变动对他们而言都是无伤大雅的，但是对于第三方厂商来说，他们缺少必要的开发文档（微软并未公布任何涉及FSD Inline Hook技术文档，也不鼓励开发者这样做）和齐全的硬件测试平台，所以，在不齐全的操作系统环境和硬件配置下实现的技术，必然很容易就导致受害用户直接欣赏到赏心悦目的蓝屏。
CNNIC必然清楚这点，但是，他们什么也不顾了。而且，CNNIC的技术水平果然也没达到稳定的水平，在被CNNIC安家的系统里，用户只要运行 IceSword检测，就会直接导致蓝屏，这是因为它们都同时钩住了一个底层函数，但是下钩的位置存在些许偏差，例如，一个钩住了头部，一个钩住了屁股，于是内核受不了这很黄很暴力的行为，而直接崩溃了。
但是，毕竟已经有人起了头。以后的Rootkit世界将会变成什么样子，谁也不知道。
要消灭CNNIC以及采用FSD Inline Hook技术的Rootkit，首选应该是360安全卫士，但是如果出现了360安全卫士也未加入识别的Rootkit，用户就得使用“狙剑”了，解决方法与前面提及的大同小异，只需要对其“脱钩”就可以了，关键在于，用户还得留意Rootkit的用户层程序是否也使用Hook，如线程注入等。