作者：小金

一. 无法驱逐的“助手”
网管小张正在手忙脚乱的寻找他的手工杀毒工具包，因为他在安装一个网管工具的时候无意中走了神，点击了“下一步”按钮后才惊觉安装程序的界面里一个不引人注目的角落里写着“安装CNNIC网络实名”这一行小字，而且最开头部分有一个小小的勾。于是著名的 “中国网民的得力助手”便理所当然的在他的机器里安了家。
心里把厂商骂了十八遍的小张终于翻出了他外出修机时最得意的工具IceSword和超级巡警，果然在进程列表和SSDT列表里发现了红色警报，小张笑了笑，对付这些一般用户无法卸载的恶意流氓，自己可谓经验丰富了，当下便三下五除二的把 CNNIC的进程给终结了，SSDT也给恢复了初始状态，然后小张去删除注册表启动项——突然发出的一个错误提示声音把小张吓了一跳，再定睛一看，他的笑容凝固了：“删除项时出错”。不会吧？小张急忙去删除CNNIC目录，结果彻底愣在了那里，系统弹出的错误提示很明确的告诉他，“无法删除文件，文件可能正在被使用”。怎么回事？小张一下子没了头绪……
达尔文的进化论告诉我们，“物竞天择，适者生存”，同样，在这安全与入侵的网络世界里，也在进行着这样一场选择的过程……

二. 被AIDS纠缠的互联网
Rootkit 是什么？如果您在几年前就是本刊的读者，那您一定已经看过小金写的涉及Rootkit的相关文章，一种在当时可以被称为“艾滋病毒AIDS”的技术产物，只是，在这场“适者生存”的残酷游戏里，最终存活的，只剩下Rootkit了，于是，今天的Rootkit地位已经等同于当年的感冒病毒——因为它实在是太普遍了，在用户上网的同时，瘟神时刻都紧随着其后，以求伺机而入。
小知识：什么是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”，多用于高人之间的交流称谓。
而普通上网民众，对这些东西的存在完全是概不知情的，或者，仅限于一个模糊的概念……
//文章出处:网络技术论坛(http://bbs.nettf.net) 作者:小金
当其他类型的木马后门技术已可以轻而易举被歼灭以后，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的势头迅速被压了下去，短暂的世界太平，短暂的，恩。