Invisible.c是该rootkit的主体结构，其中包括入口函数DriverEntry和卸载函数OnUnload。操作系统加载该驱动程序时将调用入口函数。我们看到，在传递给入口函数的参数中有一个是DRIVER_OBJECT，它的作用是给出跟该驱动程序通信时所调用的函数的映射表。就本例而言，我们仅仅映射了一个函数pDriverObject-〉DriverUnload，这样以来，当卸载驱动程序时，操作系统调用onunload函数就可行了。需要特别说明的是，这一点在rootkit开发过程中特别实用，不用重启系统就可以卸载驱动程序，但是它却带来了一个大问题：容易被发现，所以在隐蔽性要求较高时不能使用，我们已经在源代码的相应部分给出了注释。

　　下面我们看一下该rootkit如何实现隐形。我们将隐藏设备驱动程序的代码摘录如下：　　

// 隐藏该驱动程序 　　driverData = *((DRIVER_DATA**)((DWORD)pDriverObject + 20)); 　　if( driverData != NULL ) 　　{ 　　// 将本驱动程序的相应目录项从项驱动程序目录中拆下来 　　*((PDWORD)driverData->listEntry.Blink) = (DWORD)driverData->listEntry.Flink; 　　driverData->listEntry.Flink->Blink = driverData->listEntry.Blink; 　　}

　　为了达到不让操作系统找到我们的rootkit设备驱动程序的目的，这段代码修改了系统内核中的一个内部数据结构。系统中有一个双向链表，专门记录当前运行着的驱动程序，也就是说每个运行的驱动程序在该链表中都有一个对应的表项。像drivers.exe之类的应用程序，正是通过该链表来获取设备驱动程序信息的，换句话说，如果从该链表中摘除本rootkit对应的表项，就能隐藏该rootkit的存在，从而躲过大多数的检测。具体如下图所示：

　　

　　                                        图1 修改前的驱动程序链表

　　

　　                                         图2 修改后的驱动程序链表

　　细心的读者也许会问：能藏起来固然是好，不过系统若仅通过该链表来感知驱动程序的存在的话，我们的这样做岂不是自己把rootkit给干掉了?!的幸运的是，Windows操作系统的内核使用另一个表来给各运行中的驱动程序分配时间，所以，即使从设备驱动程序列表清除rootkit相应的表项，我们的rootkit也照样活得很自在。

　　利用该技术隐匿rootkit时，必须注意一点：如果已在我们的rootkit之前安装了anti-rootkit软件，“清除一个设备驱动程序表项”这一行为本身有可能被发觉，从而引起人们的注意。读者会问：这该怎么办呢?答案是，先记下本rootkit所对应的设备驱动程序表项的地址，然后钩住钩住检查设备驱动程序链表的内核函数，当这个函数要检查该链表时，我们就有机会提前把保存的表项放回到设备驱动程序链表。当检查过后，再将该表项摘除。这样，在rootkit检测程序看来，没有人在设备驱动程序链表做手脚：反Rootkit软件被我们忽悠了。不过该技术较为复杂，超出了本文的讨论范围，有机会我们会专文讲解。

　　您可能已经注意到，在Invisible.c中很多地方都使用了调试语句。事实上，DbgPrint语句基本上可以在rootkit中随意放置。在本例中，我们使用DbgPrint语句用来监视驱动程序的装卸和错误状态。不过该语句的输出不会直接显示到标准输出设备即显示器上，只有在DebugView程序的帮助下，我们才可以查看这些语句的输出。除DebugView程序外，内核程序调试工具也可以达此目的。另外，我们的调试语句还有一个特点，它们都以comint 32开头，这样做一方面是用以区别其他程序的调试语句的输出。 另一方面利用comint 32这个词是为了掩人耳目，因为这个词很难让人跟rootkit联系到一块。