HONJAY

破解常用断点

2008-02-16 00:24

常用断点(OD中)

拦截窗口：
bp CreateWindow 创建窗口
bp CreateWindowEx(A) 创建窗口
bp ShowWindow 显示窗口
bp UpdateWindow 更新窗口
bp GetWindowText(A) 获取窗口文本

拦截消息框：
bp MessageBox(A) 创建消息框
bp MessageBoxExA 创建消息框
bp MessageBoxIndirect(A) 创建定制消息框
bp IsDialogMessageW

拦截警告声：
bp MessageBeep 发出系统警告声(如果没有声卡就直接驱动系统喇叭发声)

拦截对话框：
bp DialogBox 创建模态对话框
bp DialogBoxParam(A) 创建模态对话框
bp DialogBoxIndirect 创建模态对话框
bp DialogBoxIndirectParam(A) 创建模态对话框
bp CreateDialog 创建非模态对话框
bp CreateDialogParam(A) 创建非模态对话框
bp CreateDialogIndirect 创建非模态对话框
bp CreateDialogIndirectParam(A) 创建非模态对话框
bp GetDlgItemText(A) 获取对话框文本
bp GetDlgItemInt 获取对话框整数值

拦截剪贴板：
bp GetClipboardData 获取剪贴板数据

拦截注册表：
bp RegOpenKey(A) 打开子健
bp RegOpenKeyEx 打开子健
bp RegQueryValue(A) 查找子健
bp RegQueryValueEx 查找子健
bp RegSetValue(A) 设置子健
bp RegSetValueEx(A) 设置子健

功能限制拦截断点：
bp EnableMenuItem 禁止或允许菜单项
bp EnableWindow 禁止或允许窗口

拦截时间：
bp GetLocalTime 获取本地时间
bp GetSystemTime 获取系统时间
bp GetFileTime 获取文件时间
bp GetTickCount 获得自系统成功启动以来所经历的毫秒数
bp GetCurrentTime 获取当前时间（16位）
bp SetTimer 创建定时器
bp TimerProc 定时器超时回调函数
GetDlgItemInt 得指定输入框整数值
GetDlgItemText 得指定输入框输入字符串
GetDlgItemTextA 得指定输入框输入字符串

拦截文件：
bp CreateFileA 创建或打开文件 (32位)
bp OpenFile 打开文件 (32位)
bp ReadFile 读文件 (32位)
bp WriteFile 写文件 (32位)
GetModuleFileNameA
GetFileSize
Setfilepointer
fileopen
FindFirstFileA
ReadFile

拦截驱动器：
bp GetDriveTypeA 获取磁盘驱动器类型
bp GetLogicalDrives 获取逻辑驱动器符号
bp GetLogicalDriveStringsA 获取当前所有逻辑驱动器的根驱动器路径

★★VB程序专用断点★★

文件长度：RtcFileLen
bp __vbaFreeStr 对付VB程序重启验证
bp __vbaStrCmp 比较字符串是否相等
bp __vbaStrComp 比较字符串是否相等
bp __vbaVarTstNe 比较变量是否不相等
bp __vbaVarTstEq 比较变量是否相等
bp __vbaStrCopy 复制字符串
bp __vbaStrMove 移动字符串
bp MultiByteToWideChar ANSI字符串转换成Unicode字符串
bp WideCharToMultiByte Unicode字符串转换成ANSI字符串

=============== ================

密码常用中断
Hmemcpy (win9x专用)
GetDlgItemTextA
GetDlgItemInt
vb:
getvolumeinformationa

vbastrcomp (trw)
Bpx __vbaStrComp (记得是两个 ‘_’)
MSVBVM60!_vbastrcomp|sofice
MSVBVM50! |

VBAI4STR

Ctrl+D
bpx msvbvm60!__vbastrcomp do “d *(esp+0c)”(softice)
按几次F5出册码出来了。
bpx regqueryvalueexa do “d esp－>8″(trw)

vbaVarTstEq 判断是否注册的函数
(0042932F 66898580FEFFFF mov word ptr [ebp+FFFFFE80], ax
改为0042932F 66898580FEFFFF mov word ptr [ebp+FFFFFE80], bx)

时间常用中断
GetSystemTime
GetLocalTime
GetTickCount
vb:
rtcGetPresentDate //取得当前日期

杀窗常用中断
Lockmytask (win9x专用)
bp ExitProcess 退出进程
DestroyWindow
mouse_event (鼠标中断)
postquitmessage (Cracking足彩xp,很有用^_^)
vb:
_rtcMsgBox

ini文件内容常用中断
GetPrivateProfileStringA
GetPrivateProfileProfileInt

key文件:
getprivateprofileint
ReadFile
CreateFileA

注册表常用中断
RegQueryvalueA
RegQueryvalueExA

狗加密中断
BPIO -h 278 R
BPIO -h 378 R

其它常用函数断点
CreateFileA (读狗驱动程序),
DeviceIOControl,
FreeEnvironmentStringsA (对付HASP非常有效).
Prestochangoselector (16-bit HASP’s), ’7242′ 查找字符串 (对付圣天诺).具体含义参考下面的范例。

光盘破解中断
16:
getvolumeinformation
getdrivetype
int 2fh (dos)
32:
GetDriveTypeA
GetFullPathNameA
GetWindowsDirectoryA

读磁盘中断
GETLASTERROR 返回扩充出错代码

限制中断
EnableMenuItem 允许、禁止或变灰指定的菜单条目
EnableWindow 允许或禁止鼠标和键盘控制指定窗口和条目（禁止时菜单变灰）

不知道软盘中断是什么了？还有其它特殊中断，不知道其他朋友可否说一下了？
如ockmytask and mouse_event，这些就不是api32函数？
win9x 与 win2k进行破解，以上中断有部分已经不能用了？
不知道在win2k上，以上常用中断函数是什么了？
也就是问密码、时间、窗口、ini、key、注册表、加密狗、光盘、软盘、限制等！
了解常用的中断，对破解分析可以做到事半功倍！
请大家说一下！还有如何破解了某个软件时，一重启就打回原形？
不知道下什么中断了？可以分为三种情况：
1.比较可能在注册表中
2.比较在特殊文件(*.key *.ini *.dat等)
3.比较在程序中，没有任何错误提示或者反译也找不到明显字符(这个就是我想问的)

还有一个是最难的，就是去掉水印！
也可以三种情况：
A.水印是位图文件(bitblt,creatBITMAP等位图函数)
B.水印是明显字符(反译分析)
C.水印不是明显字符(如：This a demo!它只是显示在另一个制作文件上,可是*.htm *.exe等)
C.才是最难搞，也是很多人想知道的！包括我在内。不知道高手们有何提示了？

广告条：
可以分两种情况:
A.从创建窗口进手,可以用到movewindow或者其它窗口函数!
B.从位图进手,也可以用到bitblt或者其它位图函数!
最后可以借助一些现有工具(如:api27,vwindset,freespy之类的工具)

葡萄虽无树，藤生棚中秧。
人处凡尘中，岂不惹尘埃?

小球[CCG]
那要看是在哪作的标记，通常是在注册表中留下信息！
在softice中就要用bpx regqueryvalueexa do “d esp->8″来中断看看，
在trw中要用bpx regqueryvalueexa do “d*(esp+8)”来中断看看。
还有的是在本目录下留下注册信息，常见的有.dat .ini .dll等等，
我是用bpx readfile来中断的，还有的是在windows目录下留下注册信息。
你可以借助专用的工具帮助你查看，入filemon等！

vb:

1、__vbaVarTstNe //比较两个变量是否不相等
2、rtcR8ValFromBstr //把字符串转换成浮点数
3、rtcMsgBox 显示一信息对话框
4、rtcBeep //让扬声器叫唤
5、rtcGetPresentDate //取得当前日期

针对字串:
__vbaStrComp
__vbaStrCmp
__vbaStrCompVar
__vbaStrLike
__vbaStrTextComp
__vbaStrTextLike
针对变量:
__vbaVarCompEq
__vbaVarCompLe
__vbaVarCompLt
__vbaVarCompGe
__vbaVarCompGt
__vbaVarCompNe

VB的指针:
THROW

VB DLL还调用了oleauto32.dll中的部分函数。oleauto32.dll是个通用的proxy/stub DLL，其每个函数的原型在<oleauto.h>中定义，并在MSDN中有详细描述。这也有助于理解VB DLL中的函数的作用。

举例：

LEA EAX, [EBP-58]
PUSH EAX
CALL [MSVBVM60!__vbaI4Var]

执行call之前敲dd eax+8，得到的值为3；
执行完call之后，eax = 3
从而可知__vbaI4Var的作用是将一个VARIANT转换为I4（即一个长整数）。

__vbaVarTstNe似乎是用来进行自校验的，正常情况下返回值为0。
已知适用的软件有：网络三国智能机器人、音乐贺卡厂。当这两个软件被脱壳后都回出错，网络三国智能机器人会产生非法*作，而音乐贺卡厂会告诉你是非法拷 贝，通过修改__vbaVarTstNe的返回值都可让它们正常运行。
所以当您遇到一个VB软件，脱壳后无法正常运行，而又找不出其它问题时，可试试拦截这个函数，说不定会有用哦。8-）

API不太知道,也许可以通过BIOS在98平台上读写扇区,不过在2000/NT下可以通过内黑ATAPI,HAL写扇区
machoman[CCG]
bpx WRITE_PORT_BUFFER_USHORT
NT/2000下这个断点,当edx=1f0h,时,可以看见EDI地址内数据为扇区位置数据,必须先 在winice.dat 中装入hal.sys 详细内容看ATAPI手册

补充篇:
关于对VB程序和时间限制程序的断点
CrackerABC
先给出修改能正确反编译VB程序的W32DASM的地址：
======================
offsets 0x16B6C-0x16B6D

修改机器码为： 98 F4
======================

VB程序的跟踪断点：

============
MultiByteToWideChar,
rtcR8ValFromBstr,
WideCharToMultiByte,
__vbaStrCmp
__vbaStrComp
__vbaStrCopy
__vbaStrMove
__vbaVarTstNe
rtcBeep
rtcGetPresentDate (时间API)
rtcMsgBox
=========

时间限制断点：

================
CompareFileTime
GetLocalTime
GetSystemTime
GetTimeZoneInformation
msvcrt.diffTime()
msvcrt.Time()
================

一般处理

bpx hmemcpy
bpx MessageBox
bpx MessageBoxExA
bpx MessageBeep
bpx SendMessage

bpx GetDlgItemText
bpx GetDlgItemInt
bpx GetWindowText
bpx GetWindowWord
bpx GetWindowInt
bpx DialogBoxParamA
bpx CreateWindow
bpx CreateWindowEx
bpx ShowWindow
bpx UpdateWindow

bmsg xxxx wm_move
bmsg xxxx wm_gettext
bmsg xxxx wm_command
bmsg xxxx wm_activate

时间相关
bpint 21 if ah==2A (DOS)
bpx GetLocalTime
bpx GetFileTime
bpx GetSystemtime

CD-ROM 或 磁盘相关
bpint 13 if ah==2 (DOS)
bpint 13 if ah==3 (DOS)
bpint 13 if ah==4 (DOS)
bpx GetFileAttributesA
bpx GetFileSize
bpx GetDriveType
bpx GetLastError
bpx ReadFile
bpio -h (Your CD-ROM Port Address) R

软件狗相关
bpio -h 278 R
bpio -h 378 R

键盘输入相关
bpint 16 if ah==0 (DOS)
bpint 21 if ah==0xA (DOS)

文件访问相关
bpint 21 if ah==3dh (DOS)
bpint 31 if ah==3fh (DOS)
bpint 21 if ah==3dh (DOS)
bpx ReadFile
bpx WriteFile
bpx CreateFile
bpx SetFilePointer
bpx GetSystemDirectory

INI 初始化文件相关
bpx GetPrivateProfileString
bpx GetPrivateProfileInt
bpx WritePrivateProfileString
bpx WritePrivateProfileInt

注册表相关
bpx RegCreateKey
bpx RegDeleteKey
bpx RegQueryvalue
bpx RegCloseKey
bpx RegOpenKey

注册标志相关
bpx cs:eip if EAX==0

内存标准相关
bpmb cs:eip rw if 0×30:0x45AA==0

显示相关
bpx 0×30:0x45AA do “d 0×30:0x44BB”
bpx CS:0x66CC do “? EAX”

查找窗口
FindWindowA

BP SetFilePointer

bpx hmemcpy ;破解万能断点，拦截内存拷贝动作(注意：Win9x专用断点)
bpx Lockmytask ;当你用其它断点都无效时可以试一下，这个断点拦截按键的动作(Win9x专用)

实在找不到断点可以试下面的方法：

bmsg handle wm_gettext ;拦截注册码（handle为对应窗口的句柄）
bmsg handle wm_command ;拦截OK按钮（handle为对应窗口的句柄）

拦截窗口：

bpx CreateWindow ;创建窗口
bpx CreateWindowEx(A/W) ;创建窗口
bpx ShowWindow ;显示窗口
bpx UpdateWindow ;更新窗口
bpx GetWindowText(A/W) ;获取窗口文本

拦截消息框：

bpx MessageBox(A/W) ;创建消息框
bpx MessageBoxExA(W) ;创建消息框
bpx MessageBoxIndirect(A/W) ;创建定制消息框

拦截警告声：

bpx MessageBeep ;发出系统警告声(如果没有声卡就直接驱动系统喇叭发声)

拦截对话框：

bpx DialogBox ;创建模态对话框
bpx DialogBoxParam(A/W) ;创建模态对话框
bpx DialogBoxIndirect ;创建模态对话框
bpx DialogBoxIndirectParam(A/W) ;创建模态对话框
bpx CreateDialog ;创建非模态对话框
bpx CreateDialogParam(A/W) ;创建非模态对话框
bpx CreateDialogIndirect ;创建非模态对话框
bpx CreateDialogIndirectParam(A/W) ;创建非模态对话框
bpx GetDlgItemText(A/W) ;获取对话框文本
bpx GetDlgItemInt ;获取对话框整数值

拦截剪贴板：

bpx GetClipboardData ;获取剪贴板数据

拦截注册表：

bpx RegOpenKey(A/W) ;打开子健 ( 例：bpx RegOpenKey(A) if *(esp->8)==’****’ )
bpx RegOpenKeyExA(W) ;打开子健 ( 例：bpx RegOpenKeyEx if *(esp->8)==’****’ )
bpx RegQueryValue(A/W) ;查找子健 ( 例：bpx RegQueryValue(A) if *(esp->8)==’****’ )
bpx RegQueryValueEx(A/W) ;查找子健 ( 例：bpx RegQueryValueEx if *(esp->8)==’****’ )
bpx RegSetValue(A/W) ;设置子健 ( 例：bpx RegSetValue(A) if *(esp->8)==’****’ )
bpx RegSetValueEx(A/W) ;设置子健 ( 例：bpx RegSetValueEx(A) if *(esp->8)==’****’ )

注意:’****’为指定子键名的前4个字符，如子键为’Regcode’，则’****’= ‘Regc’

功能限制拦截断点：

bpx EnableMenuItem ;禁止或允许菜单项
bpx EnableWindow ;禁止或允许窗口
bmsg hMenu wm_command ;拦截菜单按键事件，其中hMenu为菜单句柄
bpx K32Thk1632Prolog ;配合bmsg hMenu wm_command使用，可以通过这个断点进入菜单处理程序
应用示例：
CALL [KERNEL32!K32Thk1632Prolog]
CALL [......] <– 由此跟踪进入菜单处理程序
CALL [KERNEL32!K32Thk1632Epilog]

拦截时间：

bpx GetLocalTime ;获取本地时间
bpx GetSystemTime ;获取系统时间
bpx GetFileTime ;获取文件时间
bpx GetTickCount ;获得自系统成功启动以来所经历的毫秒数
bpx GetCurrentTime ;获取当前时间（16位）
bpx SetTimer ;创建定时器
bpx TimerProc ;定时器超时回调函数

拦截文件：

bpx CreateFileA(W) ;创建或打开文件 (32位)
bpx OpenFile ;打开文件 (32位)
bpx ReadFile ;读文件 (32位)
bpx WriteFile ;写文件 (32位)
bpx _lcreat ;创建或打开文件 (16位)
bpx _lopen ;打开文件 (16位)
bpx _lread ;读文件 (16位)
bpx _lwrite ;写文件 (16位)
bpx _hread ;读文件 (16位)
bpx _hwrite ;写文件 (16位)

拦截驱动器：

bpx GetDrivetype(A/W) ;获取磁盘驱动器类型
bpx GetLogicalDrives ;获取逻辑驱动器符号
bpx GetLogicalDriveStringsA(W) ;获取当前所有逻辑驱动器的根驱动器路径

拦截狗：

bpio -h 378(或278、3BC) R ;378、278、3BC是并行打印端口
bpio -h 3F8(或2F8、3E8、2E8) R ;3F8、2F8、3E8、2E8是串行端口

VB程序专用断点：

bpx msvbvm60!rtcMsgBox
bpx msvbvm60!__vbaStrCmp
bpx msvbvm60!__vbaStrComp
bpx msvbvm60!__vbaStrCompVar
bpx msvbvm60!__vbaStrTextCmp
bpx msvbvm60!__vbaFileOpen
bpx msvbvm60!__vbaInputFile
bpx msvbvm60!__vbaFileSeek
bpx msvbvm60!__vbaWriteFile
bpx msvbvm60!__vbaFileClose
bpx msvbvm60!rtcFileAttributes
bpx msvbvm60!rtcFileDateTime
bpx msvbvm60!rtcFileLen
bpx msvbvm60!rtcFileLength
bpx msvbvm60!__vbaVarInt
bpx msvbvm60!__vbaVarCmpGe
bpx msvbvm60!__vbaVarCmpGt
bpx msvbvm60!__vbaVarCmpLe
bpx msvbvm60!__vbaVarCmpLt
bpx msvbvm60!__vbaVarCmpNe
bpx msvbvm60!__vbaVarTextCmpEq
bpx msvbvm60!__vbaVarTextCmpGe
bpx msvbvm60!__vbaVarTextCmpGt
bpx msvbvm60!__vbaVarTextCmpLe
bpx msvbvm60!__vbaVarTextCmpLt
bpx msvbvm60!__vbaVarTextCmpNe
bpx msvbvm60!__vbaVarTextTstEq
bpx msvbvm60!__vbaVarTextTstGe
bpx msvbvm60!__vbaVarTextTstGt
bpx msvbvm60!__vbaVarTextTstLe
bpx msvbvm60!__vbaVarTextTstLt
bpx msvbvm60!__vbaVarTextTstNe
bpx msvbvm60!__vbaVarTstEq
bpx msvbvm60!__vbaVarTstGe
bpx msvbvm60!__vbaVarTstGt
bpx msvbvm60!__vbaVarTstLe
bpx msvbvm60!__vbaVarTstLt
bpx msvbvm60!__vbaVarTstNe

注意：VB程序仍然可以使用普通API函数，只要函数“最终”CALL了这个函数
上面的断点对应VB6程序，如果是VB5程序则将msvbvm60改成msvbvm50即可

Rootkit技术发展史

2008-02-01 10:46

一切的开端：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的驱动被加载，立即开始玉石俱焚——将用户机器弄成经典的蓝屏死机，不明就里的用户在几次与蓝色屏幕对望后，通 常都会无奈的放弃；而另一种蓝屏则是更深层次的问题导致的，下面会提到。
//文章出处:网络技术论坛(http://bbs.nettf.net) 作者:小金
而探索另一个方向的研究者们，也传来了捷报：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
//文章出处:网络技术论坛(http://bbs.nettf.net) 作者:小金
随着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世界将会变成什么样子，谁也不知道。
//文章出处:网络技术论坛(http://bbs.nettf.net) 作者:小金

要消灭CNNIC以及采用FSD Inline Hook技术的Rootkit，首选应该是360安全卫士，但是如果出现了360安全卫士也未加入识别的Rootkit，用户就得使用“狙剑”了，解决方 法与前面提及的大同小异，只需要对其“脱钩”就可以了，关键在于，用户还得留意Rootkit的用户层程序是否也使用Hook，如线程注入等。
RK 多了，ARK也多了，这是好事还是坏事呢？答案自然是后者，无论是RK还是ARK，它们都必须进行同一个行为，就是进入系统内核层次并达到目的，于是不兼 容现象往往会发生在几个ARK之间，例如，在运行了狙剑后，Wsyscheck经常会直接报错退出，而如果用户在开启了Wsyscheck的情况下运行 IceSword，他将会有很大几率看到那蓝底白字的屏幕。

三. 结语
虽然到处都在提倡和谐网络的普及，但是，“健康上网”仅仅是指代那些黄赌毒而已吗？在利益面前，开发者的正义感越发渺小起来，我们的网络世界，是被瘟神紧 紧跟随着的。技术的斗争越发激烈，但是用户的电脑知识是不会跟着时代发展而自动填充的，最终，大众上网的人民成了这一切技术较量的受害者。
这个荒谬的发展方向，何时才能休止呢？

转自:http://hi.baidu.com/zrxc/blog/item/14231d3e124a54fe838b131b.html