目 录

Transcription

1 第 1 页 摘 要 随着计算机的发展, 越来越多人用上了个人计算机, 而主流的操作系统是 Microsoft 的 Windows 这种操作系统占据着 PC 操作系统市场的 90% 以上 但问题也随之而来, 越来越多的针对该平台的病毒 木马 黑客程序 恶意程序 流氓软件以及间谍程序盗窃和破坏用户数据 研究发现, 大多数上述非法程序是通过注册表来达到自启动的 那么只要我们拦截上述程序对注册表的访问, 便可禁止他们启动, 达到了保护用户数据的目的 在本次设计中, 使用了 SSDT Hook 这中技术对注册表的访问进行拦截 这种拦截技术通用, 功能强大 首先, 探讨了 SSDT Hook 这种技术的实现的机理 其次介绍了各个模块的实现 关键词 : 注册表 SSDT Hook 系统服务拦截

2 ABSTRACT 第 2 页 With the development of computers, more and more people use a personal computer, and the mainstream operating system is Microsoft Windows. This operating system to occupy the PC operating system market more than 90%. But the attendant problems, more and more against the platform of the virus, Trojan horse, hackers procedures, malicious procedures, rogue software, as well as theft and espionage procedures damage user data. The study found that while most of these illegal procedures adopted to achieve since the registry started. So long as we intercept these procedures on the visit to the registry can be initiated against them, to the protection of user data purposes. In this design, the use of the SSDT Hook this technical visit to the registry to intercept. Such generic interception technology, powerful functions. First, to explore the technology SSDT Hook the realization of the mechanism. Second of all modules in the system. Keywords:Registry,SSDT Hook, Interceptor system services

3 第 3 页 目录 摘要... 1 ABSTRACT 绪论 研究背景 论文内容概述 系统服务拦截技术 系统调用的定义 WINDOWS 下系统调用的流程 WINDOWS 平台下系统调用拦截技术 用户态下的系统调用拦截 [9] 内核态修改系统调用的拦截 各种拦截系统调用方案对比 注册表拦截系统的采用的技术方案 SSDT (SYSTEM SERVICE DISPATH TABLE) 概述 [7] SSDT HOOK 技术 系统结构及模块划分 本软件的系统结构 内核拦截模块 驱动程序的结构 对系统函数的挂接 工作流程 与上层程序的通信 驱动程序的调试 后台监控模块 控制中心模块 托盘模块 系统使用与系统测试 系统使用 系统测试 设计中遇到的问题 可改进之处 参考文献 HOOKING THE NATIVE API AND CONTROLLING PROCESS CREATION ON A SYSTEM-WIDE BASIS INTRODUCTION DEFINING OUR STRATEGY CONTROLLING PROCESS CREATION... 38

4 CONCLUSION 第 4 页 系统范围内挂钩本地 API 控制进程的创建 致谢 附加信息 : 凑页数的话 :... 50

5 1 绪论 第 5 页 1.1 研究背景 随着经济的发展, 越来越多的人用上了个人计算机, 并且连接了因特网 但也安全的问题随之而来 越来越多的病毒, 木马, 恶意软件, 流氓程序以及间谍程序进入个人电脑, 对用户造成巨大的损失 研究表明, 上述程序多数运行在 windows 平台, 并且通过修改注册表达到随机启动的目的 例如著名的冰河,BO2K 等木马 因此, 可以通过拦截对注册表的访问, 从根本上阻止上述程序的运行, 以此达到保护用户文件数据的目的 调查同时发现, 市场上已经出现了同类功能的产品, 如 : 瑞星 可见发展注册表保护技术是有很好的前景的 1.2 论文内容概述 本论文主要阐述了 Windows 下拦截注册表访问的方法

6 2 系统服务拦截技术 第 6 页 2.1 系统调用的定义 用户在程序中调用操作系统中的功能子模块 或操作系统核心中设置了一组用于实现各种系统功能的子程序, 提供用户程序调用 在 Windows 中, 系统调用有多套 最重要的是两套系统调用分别是内核例程 ( 提供给驱动程序 ) Win32 API( 提供给 Win32 应用程序 ). [1][3] 2.2 Windows 下系统调用的流程 下图是 Windows NT 系列操作系统的体系结构 : [4] 图 Windows 体系结构

7 第 7 页 处在 User mode 的是普通应用程序, 它们通过 Ntdll.dll 进入到 Kernel mode, 再由 System service dispatcher 调度完成所需的功能, 例如申请内存, 访问文件, 网络, 注册表, 以及硬件等等 下列以 explorer.exe(windows 外壳程序 ) 访问设置注册表键值为例来说明系统调用的流程 Windows 下访问注册表的 API 是 RegSetValueEx, 这个 API 是 Kernel32.dll 导出的函数, 但 Kernel32.dll 内部的 RegSetValueEx, 并不做什么, 它交给了 ntdll.dll 去实现, 反汇编 ntdll!zwregsetvalueex 可获得如下代码 (Win2K sp4): Mov eax,0d7h Lea edx,[esp+4] Int 2eH Ret 10H 可见, 它把 0d7H 送进 Eax 后通过 int 指令交给了 windows 内核 ntoskrnl 去完成对注册表的设置, 这是实现对应功能的是 ntoskrnl!ntregsetvalueex 图 系统调用流程 2.3 Windows 平台下系统调用拦截技术 [9] 用户态下的系统调用拦截 用户态拦截系统调用主要有两种技术 :IAT Hook 和 JMP Hook(inline Hook) IAT 即导入地址表, 包含了导入的相关信息和导入函数的地址 我们在调用 API 时, 通常是这部分起作用, 编译器并不直接把调用连接到模块, 而是用 jmp 指令连接调用到 IAT, IAT 在系统把进程调入内存时时会由进程载入器填满 这就是我们可以在两个不同版本的 Windows 里使用相同的二进制代码的原因, 虽然模块可能会加载到不同的地址 进程载入器会在程序代码里调用所使用的 IAT 里填入直接跳转的 jmp 指令 很明显, 只要我们修改模块的 IAT, 那么系统调用就会跳转到我们自定义的模块执行 这就达到了拦截系统调用的目的 下面是 IAT 钩子的工作流程 : [8]

8 第 8 页 图 IAT 钩子流程 JMP 钩子是在目标函数开始放置一条 JMP 指令来修改原系统调用执行流程的方法 下面是 JMP 钩子执行流程以及修改后的代码 ( 摘自 detours 帮助文档 ) 图 JMP 钩子执行流程

9 第 9 页 图 函数修改后 内核态修改系统调用的拦截 内核态主要有三种方法去拦截系统调用 :Hook SSDT( 挂钩系统服务调用表 ) Hook PE ( 即使用 IAT Hook 或 Jmp Hook 修改 ntoskrnl 等内核模块 ) 和挂接中断 各种拦截系统调用方案对比 在用户层拦截系统调用容易, 而且稳定, 但由于进程隔离, 不容易捕获到所有的进程活动 在内核层拦截系统调用强大, 但开发难度较大 而且可能会对系统造成一定的不良影响 在内核系统调用拦截方法中,SSDT Hook 实现起来就方便, 而且具有跨平台的特性 故在本设计中选用了该方法

10 3 注册表拦截系统的采用的技术方案 第 10 页 [7] 3.1 SSDT (System Service Dispath Table) 概述 Windows 系统服务调用是存在于 Windows 系统中的一个关键接口, 常常称作 System Call,Sysem Service Call 或 System Service Dispatching 等, 在此我们就权且称之为 Windows 系统服务调用, 它提供了操作系统环境由用户态切换到内核态的功能 并且完成应用程序的功能请求 这点可以达到保护系统资源的目的 Windows 2000 本机系统服务又称为 Windows 本机应用程序编程接口, 它是由执行体 (Executive) 为用户模式和内核模式的程序提供的系统服务集 它包含两种类型的函数 : Windows 执行系统服务的系统服务调度占位程序 ; 子系统, 子系统 DLL 和其他本机映像使用的内部支持函数 从用户模式调用本机系统服务是通过 NTDLL.dll 来实现的 表面上,Win32 函数为编程人员提供了很多接口来实现我们想要的功能, 但是这些 Win32 函数只不过是本机应用程序编程接口的一个包装器而已, 它们将本机 API 包装起来, 调用本机系统服务来实现用户期望的功能 也就是说 NTDLL.dll 只是系统服务调用接口在用户模式下的一个外壳 Windows 2000 的陷阱调度 (Trap Dispatching) 机制包括了 : 中断 (Interrupt), 延迟过程调用 (Deferred Procedure Call), 异步过程调用 (Asynchronous Procedure Call), 异常调度 (Exception Dispatching) 和系统服务调用 在 Intel x86 的 Windows 2000 系统中, 处理器执行 int 0x2e 指令来激活 Windows 系统服务调用 ; 在 Intel x86 的 Windows XP 系统中处理器却是通过执行 sysenter 指令使系统陷入系统服务调用程序中 ; 而在 AMD 的 Windows XP 中使用了指令 syscall 来实现同样的功能 我们暂时使用 x86 的 Windows 2000 为例来演示 我们先给出一个系统服务调用的模型 : mov eax, ServiceId lea edx, ParameterTable int 2eh ret ParamTableBytes 其中,ServiceId 清楚的说明了传递给系统服务调用的系统服务号, 内核使用这个标识符来查找系统服务调度表 (System Service Dispath Table) 中的对应系统服务信息 在系统服务调度表中的每一项包含了一个指向系统服务程序的指针, 我们 Hook 时就是修改这个指针使其指向我们自定义的系统服务的地址 ParameterTable 是传递的参数, 系统服务调用程序 KiSystemService 必须严格校验传递的每一个参数, 并将其参数从线程的用户堆栈中复制到系统的核心堆栈以备使用 由于执行 int 指令会导致陷阱发生, 所以在 Windows 2000 内的中断描述表 (IDT = Interrupt Descriptor Table) 中的 0x2e 项指向了系统服务调用程序 最后返回的 ParamTableBytes 是关于参数个数的信息 现在我们已经看得出来了, 系统服务调用只是一个接口, 它提供了将用户模式下的请求转发到 Windows 2000 内核的功能, 并引发处理器模式的切换 在用户看来, 系统服务调用接口就是 Windows 内核组件功能实现对外的一个界面 系统服务调用接口定义了 Windows 内核提供的大量服务 在 Windows 2000 中默认存在两个系统服务调度表, 它们对应了两类不同的系统服务 这两个系统服务调度表分别是 :KeServiceDescriptorTable 和 KeServiceDescriptorTableShadow

11 第 11 页 Windows 2000 执行程序服务对应于 NTDLL.dll 为我们提供的系统服务调用 子系统通过调用 NTDLL.dll 中的函数接口来实现它们需要的功能 系统服务调度表 KeServiceDescriptorTable 定义了在 ntoskrln.exe 中实现的系统服务, 通常在 kernel32.dll/advapi32.dll 中提供的函数接口均是调用的这个系统服务调度表中 同时存在于 Windows 2000 操作系统中还有在 Win32k.sys 中实现的相关 Win32USER 和 GDI 函数, 它们是属于另一类系统服务调用 与之对应的系统服务调度表为 KeServiceDescriptorTableShadow, 它提供了内核模式实现的 USER 和 GDI 服务 函数 KeAddSystemServiceTable 允许 Win32.sys 和其他设备驱动程序添加系统服务表 除了 Win32k.sys 服务表外, 使用 KeAddSystemServiceTable 添加的服务表会被同时复制到 KeServiceDescriptorTable 和 KeServiceDescriptorTableShadow 中去 我们可以看出这两类函数实现在服务调度上的区别 :Win32 内核 API 经过 Kernel32.dll/advapi32.dll 进入 NTDLL.dll 后使用 int 0x2e 中断进入内核, 最后在 Ntoskrnl.exe 中实现了真正的函数调用 ;Win32 USER/GDI API 直接通过 User32.dll/Gdi32.dll 进入了内核, 最后却是在 Win32k.sys 中实现了真正的函数调用 在此我们只讨论与 NTDLL.dll 相关的函数, 也就是我们例子中处理的函数 图 3-1 KeServiceDescriptorTable 的结构图

12 第 12 页 3.2 SSDT Hook 技术 图 3-2 KeServiceDescriptorTableShadow 的结构图 在此我们讨论 Hook 的对象仅限于由 Windows 2000 的 ntoskrnl.exe 提供的系统服务调用 Windows 2000 系统服务调用为内核模式的代码, 所以我们必须书写设备驱动程序来访问系统服务调度表 如果你对 Windows 2000 下基本设备驱动程序的书写不太清楚, 请查阅相关的书籍, 此处不做介绍 我们先回顾一下 Win32 内核 API 的实现流程 [1][15][16] Windows 2000 系统服务调用向用户提供了经过包装的用户模式的函数接口 ( 由 NTDLL.dll 提供 ) 当 Kernel32.dll/Advapi32.dll 中的函数执行时, 先调用 NTDLL.dll 中对应的相关接口, 经过参数检查后使用 int 0x2e 指令进入内核模式, 传递相关的服务号和参数列表 在 ntoskrnl.exe 中维护着两个表系统服务调度表 (System Service Dispath Table) 和系统服务参数表 (System Service Parameter Table), 其中 int 0x2e 指令就是通过服务号在 SSDT 中查询相关系统服务程序指针的 现在我们已经清楚了每个系统服务调用都对应一个服务号, 同时也对应一个服务程序的地址! 如果我们修改 SSDT 中的某个系统服务程序的入口地址为指向我们自定义的函数地址, 在执行完我们的代码后再执行原始系统服务地址处的代码, 这不就实现了对系统服务调用的了 Hook 吗? 对我们来说, 定位系统服务调度表是实现 Hook 的关键 在 Windows 2000 中有一个未公开的由 ntoskrnl.exe 导出的单元 :KeServiceDescriptorTable, 我们可以通过它来完成对 SSDT 的访问与修改 KeServiceDescriptorTable 对应于一个数据结构, 定义如下 : typedef struct SystemServiceDescriptorTable UINT *ServiceTableBase; UINT *ServiceCounterTableBase;

13 UINT NumberOfService; UCHAR *ParameterTableBase; SystemServiceDescriptorTable,*PSystemServiceDescriptorTable; 第 13 页 其中 ServiceTableBase 指向系统服务程序的地址,ParameterTableBase 则指向 SSPT 中的参数地址, 它们都包含了 NumberOfService 这么多个单元 我们只要由 KeServiceDescriptorTable 找到了我们关注的系统服务调用程序, 就可以修改它的 ServiceTableBase 参数来实现对相关系统服务调用的 Hook 了! 但是存在着一个问题, 对于同一个系统调用, 不同版本的 Windows 系统调用号都不同, 因此要解决此问题就要深入研究 一个方法就是进行操作系统版本的判断, 但 Windows 版本过多, 工作量太大 反汇编 Windows2000 和 WindowsXP 的 ZwSetValueKey 可以看到下面的代码 图 3-3 Windows2000(sp4)ZwSetValueKey 的反汇编代码 图 3-4 WindowsXP(sp2) ZwSetValueKey 的反汇编代码从上图我们可以知道 ZwSetValueKey 在开头的第二字节 ( 偏移一字节 ) 便是系统调用号 因此我们可以根据 ZwSetValueKey 的地址偏移一字节处取得系统调用号进行挂钩 为了编程的方便, 我们写成一个宏 :SYSCALL #define SYSCALL(_function) KeServiceDescriptorTable-> ServiceTableBase[*(PULONG)((PUCHAR)_function+1)] 另外一个问题是, 内核页面是只读的, 但可以通过修改 CR3 寄存器来达到可写的目的 下面的代码便可使内核页面可写 CLI MOV EAX, CR0 AND EAX, NOT 10000H MOV CR0, EAX

14 4 系统结构及模块划分 第 14 页 4.1 本软件的系统结构 本系统采用 SSDT Hook 技术, 所以使用驱动程序 另外, 考虑到无人登陆状态下也要进行注册表的拦截, 因此程序应该做成服务进行后台监控 但本系统应该有个人机界面, 就是监控中心来跟用户打交道 采用金山的所个进程协作模式, 本系统也分成多个模块 分别是 : 内核拦截模块 (KeHookReg.sys) 监控程序 (KeXRegSprX.exe) 控制中心 (KeXCenter.exe) 托盘程序 (KeXTray.exe) 和崩溃处理程序 (BugReport.dll) 结构示意如下图 : 颜色示意 : 浅蓝代表本程序模块黑色代表操作系统 (Windows) 淡紫代表其他程序 系统流程如下图所示 : 图 4-1 系统结构图

15 第 15 页 图 4-2 系统流程图 4.2 内核拦截模块 该模块完成对系统服务的拦截, 以及注册表键的过滤 是最核心的模块 驱动程序的结构 驱动程序 (Device Driver) 全称为 设备驱动程序, 是一种可以使计算机和设备通信的特殊程序, 可以说相当于硬件的接口, 操作系统只能通过这个接口, 才能控制硬件设备的工作, 假如某设备的驱动程序未能正确安装, 便不能正常工作 正因为这个原因, 驱动程序在系统中的所占的地位十分重要, 一般当操作系统安装完毕后, 首要的便是安装硬件设备的驱动程序 [2][5][6] 驱动程序从代码结构上讲应该包含三个例程 :DriverEntry DispatchIoctl 和 DriverUnload 一个驱动程序可以被多个类似的硬件使用, 但驱动程序的某些全局初始化操作只能在第一次被装入时执行一次 而 DriverEntry 例程就是用于这个目的 DriverEntry 是内核模式驱动程序主入口点常用的名字 I/O 管理器按下面方式调用该例程 : extern "C" NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath)

16 第 16 页... 当驱动程序被操作系统从内存中卸载时,IO 管理器便会调用 DriverUnload, 给驱动程序清理的机会 下面是该例程的原形 : VOID DriverUnload(IN PDRIVER_OBJECT pdrvobj); Windows 内部是使用包驱动的, 当驱动程序与其他用户程序交互时也使用 IRP( 输入 / 输出请求数据包 ) 下面是 IRP 的数据结构 : 图 4-3 IRP 的数据结构阴影部分代表不透明域,MdlAddress(PMDL) 域指向一个内存描述符表 (MDL), 该表描述了一个与该请求关联的用户模式缓冲区 Flags(ULONG) 域包含一些对驱动程序只读的标志 AssociatedIrp.SystemBuffer SystemBuffer 指针指向一个数据缓冲区, 该缓冲区位于内核模式的非分页内存中 对于 IRP_MJ_READ 和 IRP_MJ_WRITE 操作, 如果顶级设备指定 DO_BUFFERED_IO 标志, 则 I/O 管理器就创建这个数据缓冲区 对于 IRP_MJ_DEVICE_CONTROL 操作, 如果 I/O 控制功能代码指出需要缓冲区 ( 见第九章 ), 则 I/O 管理器就创建这个数据缓冲区 I/O 管理器把用户模式程序发送给驱动程序的数据复制到这个缓冲区, 这也是创建 IRP 过程的一部分 这些数据可以是与 WriteFile 调用有关的数据, 或者是 DeviceIoControl 调用中所谓的输入数据 对于读请求, 设备驱动程序把读出的数据填到这个缓冲区, 然后 I/O 管理器再把缓冲区的内容复制到用户模式缓冲区 对于指定了 METHOD_BUFFERED 的 I/O 控制操作, 驱动程序把所谓的输出数据放到这个缓冲区, 然后 I/O 管理器再把数据复制到用户模式的输出缓冲区 驱动程序通过 DispatchIoctl 来处理 IRP, 来达到交互的功能, 下面是该例程的原形 : NTSTATUS DispatchIoctl(PDEVICE_OBJECT pdevobj, PIRP pirp); 下图说明了驱动程序的代码结构 :

17 第 17 页 图 4-4 驱动程序的代码结构 Windows 驱动程序是分层的, 下面示意图说明了分层的驱动程序 图 4-5 WDM 分层驱动程序 IRP 从最顶层的 FiDO 传到最底层的 PDO, 处理完毕后再往上回传

18 4.2.2 对系统函数的挂接 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 18 页 首先要修改当前页属性, 使页 ( 内存 ) 可写, 然后再修改 SSDT, 最后恢复页属性 这个变完成了对系统函数的挂接, 为了方便使用, 写成了两个函数 AllHookOn( 挂接所有的要挂接的系统服务 ) 和 AllHookOff( 取消挂接 ) VOID AllHookOn() OldZwSetValueKey = (ZWSETVALUEKEY)SYSCALL(ZwSetValueKey); _asm CLI // 关中断, 这部很重要, 为了防止在修改 SSDT 被中断而产生错误 MOV EAX, CR0 AND EAX, NOT 10000H MOV CR0, EAX (ZWSETVALUEKEY)(SYSCALL(ZwSetValueKey)) = HookZwSetValueKey; _asm MOV EAX, CR0 OR EAX, 10000H MOV CR0, EAX STI bhookon = TRUE; AllHookOff() _asm CLI MOV EAX, CR0 AND EAX, NOT 10000H MOV CR0, EAX (ZWSETVALUEKEY)(SYSCALL(ZwSetValueKey))= (ZWSETVALUEKEY)OldZwSetValueKey; _asm MOV EAX, CR0 OR EAX, 10000H MOV CR0, EAX STI

19 bhookon = FALSE; 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 19 页 工作流程 图 4-6 工作流程 挂接函数的内部工作代码 :( 该代码便是上述工作流程的实例 ) NTSTATUS HookZwSetValueKey ( IN HANDLE KeyHandle, IN PUNICODE_STRING ValueName, IN ULONG TitleIndex OPTIONAL, IN ULONG Type,

20 IN PVOID Data, IN ULONG DataSize ) 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 20 页 char pch[1024]; ANSI_STRING astr; KeyList * pkey =NULL; GetFullName(KeyHandle,pch);// 获得键名 pkey = FindKey(pch);// 比较键名 if(pkey!=null) // 如果找到该键 if (pkey->cops==2)// 是否提示? return STATUS_ACCESS_DENIED; KeWaitForMutexObject(g_setValueKeyMutext,Executive,KernelMode,FALSE,0); // 在多个进程间同步, 因为会有多个进程访问注册表 RtlZeroMemory(g_visitData,sizeof(VisitData));// 设置好获得的信息 g_visitdata->upid = (ULONG)PsGetCurrentProcessId(); g_visitdata->utid = (ULONG)PsGetCurrentThreadId(); RtlUnicodeStringToAnsiString(&astr,ValueName,TRUE); strcpy(g_visitdata->subkey,astr.buffer); RtlFreeAnsiString(&astr); strcpy(g_visitdata->chkey,pch); g_visitdata->utype = Type; if (DataSize<1024) memcpy(g_visitdata->chdata,data,datasize); strcpy(g_visitdata->szdes,pkey->szdes); strcpy(g_visitdata->szop,pkey->szop); g_visitdata->idan=pkey->idan; KeSetEvent(NotifyEvent, 0, FALSE);// 通知上层应用程序 KeClearEvent(NotifyEvent); KeWaitForSingleObject(pDeteEvent,Executive,KernelMode,FALSE,0); // 等待上层应用程序的处理 KeClearEvent(pDeteEvent); if (g_detearray->crel==1) KeReleaseMutex(g_setValueKeyMutext,FALSE); return OldZwSetValueKey(KeyHandle,ValueName,TitleIndex, Type,Data,DataSize); DbgPrint("Find"); KeReleaseMutex(g_setValueKeyMutext,FALSE); return STATUS_ACCESS_DENIED;

21 else DbgPrint("not find"); 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 21 页 return OldZwSetValueKey(KeyHandle,ValueName,TitleIndex, Type,Data,DataSize); 所有的查找算法 :( 贴出该代码的原因是该代码体现出如何在多个进程和 CPU 之间同步, 怎么对比键值 ) 因为系统可能存在多个 CPU, 同步是必须的, 可以通过获得旋转锁来同步多个 CPU, 当然这时进程间的同步也就解决了 另外, 因为是通过请求旋转锁来进程同步的, 当前的 IRQL 会被提升到 DISPATCH_LEVEL 级, 这时如果使用 C 库函数 strcmp 之类的函数去进行键的对比就很可能会导致缺页错误, 从而导致系统蓝屏, 所以在程序中自己实现了键的对比, 是通过一个字节一个字节对比的, 没什么巧妙, 需要注意就是内存的使用, 必须在非分页内存中进行 KeyList * pretkey = NULL; ULONG uone,utwo,utwo2; char tmpkey[1024]; PLIST_ENTRY pentry; PLIST_ENTRY phead; KeyList * kl = NULL; BOOLEAN bfind; KIRQL oldirql; if (pch==null) return NULL; memset(tmpkey,0,1024); strcpy(tmpkey,pch); _strupr(tmpkey); utwo = strlen(tmpkey); KeAcquireSpinLock(&g_KeyLock,&oldirql);// 请求旋转锁 if (!IsListEmpty(&g_KeyListHead))// 如果链表不为空 pentry = NULL; phead = &g_keylisthead; for (pentry=phead->flink;pentry!=phead;pentry=pentry->flink) // 检查每个结点 kl = CONTAINING_RECORD(pEntry,KeyList,next);

22 // 求串长度 uone = 0; utwo2=utwo; bfind = TRUE;// 假设找到 while (kl->chkey[uone]!='\0') uone++; 第 22 页 if (utwo2<uone)//pch 较短 continue; while(uone>0) // 遍历对比整个字符串 if (kl->chkey[uone]!=tmpkey[utwo2]) // 发现不同 bfind = FALSE; break; uone--; utwo2--; if (bfind==true) KeReleaseSpinLock(&g_KeyLock,oldirql); return kl; KeReleaseSpinLock(&g_KeyLock,oldirql); return NULL; 上面还解决了一个问题, 那就是注册表键名的获取 在 Win32 API 中, 管理内核对象是通过 HANDLE, 而在内核内部是通过 Object 来管理内核对象的 下面是 Object 属性结构 : [10][11][12][18] typedef struct _OBJECT_ATTRIBUTES ULONG Length;// 结构长度 HANDLE RootDirectory;// 根目录 UNICODE_STRING *ObjectName;//Object 的名称 ULONG Attributes;// 属性 PSECURITY_DESCRIPTOR SecurityDescriptor;// 安全描述符 PSECURITY_QUALITY_OF_SERVICE SecurityQualityOfService; OBJECT_ATTRIBUTES,*POBJECT_ATTRIBUTES 我们感兴趣的是 ObjectName 成员, 因为它包含了注册表名 回到问题上, 我们拦截

23 第 23 页 ZwSetValueKey 后, 获得的是操作的注册表键的 Handle, 我们使用内核例程 ObReferenceObjectByHandle 便可以获得对应的 Object 的内存地址, 原则上可以直接取得 ObjectName, 但 OBJECT_ATTRIBUTES 是不公开的结构, 为了跨越不同的版本, 我们使用一个未公开的内核例程 ObQueryNameString 变可以获得 ObjectName 了 与上层程序的通信 本模块与上层程序通信是通过 IOCTL 完成的, 下面列出所有的 IOCTL: #define IOCTL_SETVALUEKEY \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x830, METHOD_BUFFERED, FILE_ANY_ACCESS) 读取访问信息 #define IOCTL_MGRVISIT \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x831, METHOD_BUFFERED, FILE_ANY_ACCESS) 裁决一个进程的访问 #define IOCTL_HOOKON \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x832, METHOD_BUFFERED, FILE_ANY_ACCESS) 开始拦截 #define IOCTL_HOOKOFF \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x833, METHOD_BUFFERED, FILE_ANY_ACCESS) 暂停拦截 #define IOCTL_ADDARUL \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x834, METHOD_BUFFERED, FILE_ANY_ACCESS) 添加一条规则 #define IOCTL_REMOVEARUL \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x835, METHOD_BUFFERED, FILE_ANY_ACCESS) 移除一条规则 #define IOCTL_DELALLRULS \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x836, METHOD_BUFFERED, FILE_ANY_ACCESS) 移除所有的规则

24 4.2.5 驱动程序的调试 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 24 页 调试驱动程序有多种方式, 包括日志输出调试, 使用内核调试器 因为 SoftICE 不再开发, 在本次开发中选用了 WinDBG 作为调试工具 使用 WinDBG 需要先安装符号文件, 并且必须使用两台机器进行调试 把驱动程序拷贝到目标机器, 重新启动, 然后使用 WinDBG 连接到目标机器即可 常用的命令如下 : bp/bu/bm 下断点, 例如 bp nt!zwsetvaluekey, 在 ntoskrnl 的 ZwSetValueKey 上下断点 t 单步执行 u 显示反汇编 dt 显示结构提 d 显示内存 r 显示或者修改寄存器 s 搜索内存 4.3 后台监控模块 后台监控模块主要完成拦截模块的载入, 处理拦截模块返回的信息 该模块是作为 Windows 后台服务工作的, 因为要在无人登陆的环境下工作 ( 为了方便在答辩上演示, 该版本只是一个普通的后台程序 ) 该模块的流程非常简单 下图说明 : 图 4-7 监控流程

25 系统使用类列表 : CIni CKeXHelper CRulHelper CDriver CKeXDriver KeXShareMEM 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) ini 文件操作类系统辅助类规则文件操作类驱动程序操作类核心驱动操作类共享内存操作类 第 25 页 图 4-8 监控模块顶级类图 规则数据 typedef struct _RulData char chkey[1024];// 键名 char szdes[256];// 规则描述 char szops[256];// 提示操作 unsigned int idan;// 风险度 #define KE_ASK 1// 询问 #define KE_HOLDUP 2// 拦截 char cops;// 当出发规则后的操作 RulData; 存储的规则数据 typedef struct _StoreRulData RulData rd; char szrulname[25];// 规则名称

26 #define RUL_USEING #define RUL_DISABLE char cstatus;// 规则状态 StoreRulData; 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 1// 规则启用 2// 规则禁用 第 26 页 拦截后的操作数据 typedef struct _VisitData ULONG upid;// 进程 ID ULONG utid;// 线程 ID char chkey[1024];// 主键 char subkey[256];// 子键 ULONG utype;// 键值类型 char chdata[1024];// 健值数据 char szdes[256];// 描述 char szop[256];// 提示操作 unsigned int idan;// 风险度 VisitData; // 操作 typedef struct _DeteData ULONG utid;// 线程 ID char crel;// 操作 DeteData; 进程相关信息 typedef struct _ProcInfo VisitData vd; char chpath[256];// 进程路径 // 状态 0: 正在处理 1: 通过 2: 拒绝 ULONG ustatus;// 状态 ProcInfo; 消息结构 typedef struct _KeXMsg #define KEX_NULL 0// 空消息 // 以下消息针对 KeXRegSprX 监控进程 #define KEX_QUIT 1// 退出程序 #define KEX_STARTUP 2// 程序启动 #define KEX_SUCC 3// 操作成功

27 #define KEX_FAIL 5// 操作失败 #define KEX_START_CTL 11// 开始监控 #define KEX_STOP_CTL 12// 停止监控 #define KEX_GET_CTLSTATUS 13// 获得当前状态 #define KEX_ADDARUL 21// 添加一条规则 #define KEX_REMOVEARUL 22// 移除一条规则 #define KEX_GETRULNUM 23// 获得规则总数 #define KEX_GETARUL 24// 获得一条规则 #define KEX_DISABLEARUL 25// 禁用一条规则 #define KEX_ENABLEARUL 26// 启用一条规则 #define KEX_RELOADRUL 27// 重新加载规则 #define KEX_LOAD 第 27 页 // 以下消息针对 KeXCenter #define KEX_STATUS_STARTCTL #define KEX_STATUS_STOPCTL #define KEX_CTRL_PASS #define KEX_CTRL_REF 101// 监控开启 102// 监控关闭 150// 进程通过裁决 151// 进程被拦截 DWORD dwmsg;// 消息类型 DWORD dwcookie;// 消息跟踪 char chdata[4* ];// 消息数据 KeXMsg; 日志结构 typedef struct _LogEntry #define KEX_LOG_WARN 1 #define KEX_LOG_COM 2 char clogtype;// 日志类型 SYSTEMTIME st;// 日志日期 char chdata[1024];// 日志内容 LogEntry; // 异常钩子函数 typedef LONG (WINAPI *KEXERRORFUN)(struct _EXCEPTION_POINTERS *); 规则存储结构图 :

28 第 28 页 图 4-9 规则存储结构图 4.4 控制中心模块 控制中心是与用户打交道的接口, 它主要提供的功能是日志查看, 规则的操作以及系统的配置 图 4-10 控制中心层次图

29 第 29 页 4.5 托盘模块 托盘程序主要是启动监控中心 图 4-11 托盘程序执行流程 5 系统使用与系统测试 5.1 系统使用 1: 程序的启动 : 双击目录中的 KeXTray.exe 便可启动程序, 并在系统托盘区显示一个控制图标, 如 : 图 5-1 2: 设置保护的注册表键 : 在控制图标上点右键, 然后选择显示监控中心便出现如下窗口 :

30 第 30 页 图 5-2 选择规则设置, 便切换到规则设置页, 如下图 : 图 5-3 通过选择列表中的规则便可以对规则进行相应的操作 该页上的功能包括 : 添加 : 添加一条规则

31 修改 : 修改一条规则 删除 : 删除一条规则 启用 : 起用一条规则 禁用 : 禁用一条规则 导入 : 从外部规则库文件导入规则 导出 : 把规则保存到另外一个文件中 添加规则操作 : 先点击添加规则, 出现如图所示的窗口 : 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 31 页 图 5-4 其中 : 规则名称 : 为方便区分规则而填写的资料 规则描述 : 对该规则的一个详细描述 注册表键 : 要保护的注册表键, 不应该包括根键 例子请见系统附带的三条规则 建议操作 : 当规则被触发时建议的采取的操作 起用规则 : 当规则被添加后是否立刻启用规则, 建议勾选此选项 询问 / 拦截 : 当规则被触发时采取的操作, 当选择询问时, 会出现一个对话框询问用户采取的措施 填写完上述资料便点确定保存规则 3: 监控开启和关闭 : 要开启或者关闭监控, 请使用监控中心的菜单或者控制图标的菜单 4: 拦截后的操作 : 当有应用程序修改被保护的键并且规则设置为询问时, 就会出现下面对话框 :

32 第 32 页 图 5-5 详细按钮包含详细信息, 同意修改表示同意程序修改, 拒绝修改表示拒绝应用程序修改注册表键 5: 系统的退出 : 使用控制图标的菜单便可退出系统 5.2 系统测试 下面提供两个黑盒测试用例 : 测试用例一 : 内容 : 单个进程访问受限注册表键 运行 msconfig, 切换到启动页, 随便钩选一个, 点应用按钮 结果 : 弹出询问对话框, 询问用户是否拒绝, 点击拒绝, 再运行 regedit, 查看相应的注册表键, 结果正确 测试用例二 : 内容 : 多个进程同时访问受限注册表键 运行 msconfig 切换到启动页, 随便钩选个, 再运行 regedit, 点开 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 键, 然后新建字符串值, 弹出询问对话框, 这是点击 msconfig 里的应用按钮, 并没有新的询问对话框, 在询问对话框里点拒绝,regedit 显示写入错误, 这时弹出新的询问对话框, 提示 msconfig 访问受限注册表键, 点同意, 写入成功, 结果正确

33 5.3 设计中遇到的问题 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 33 页 1 编写驱动程序中遇到的语法错误 驱动程序是使用纯 C 语言编写的, 但我学习的是 C++ 语言, 语法上很接近所以一开始编写驱动程序出现了这个低级的错误 C 语言的所有变量声明必须放在函数的开头, 而 C++ 则没这个规定 否则将产生编译错误 2 驱动程序中 IRQL 和内存问题导致系统崩溃 开始编写时, 并未注意到这个问题, 主要是第一次编写, 没有经验 在对比键值函数 FindKey 里使用 KeAcquireSpinLock 进行同步, 第一次完成时, 在运行一段时间后 ( 大概 10S) 系统蓝屏 后来在一本书看到了问题, 当使用 KeAcquireSpinLock 进行同步时, 当前 IRQL 会提升到 DISPATCH_LEVEL, 但链表却生存在分页内存中, 但这部分内存被换入硬盘后 ( 即不在物理内存 ) 而访问这部分内存, 将会产生一个缺页中断, 但页调度程序是运行在 APC_LEVEL, 这是因为无法执行页调度程序, 系统便执行 BugCheck(), 也就是蓝屏报错 将链表分配到非分页内存即可解决 图 5-5 系统蓝屏修正该错误的方法是把所有的内存分配方式改为 NonPagedPool, 即可 3 PSAPI.H 无法打开编译出现下面错误提示 :fatal error C1083: Cannot open include file: 'PSAPI.H': No such file or directory Error executing cl.exe. 因为 vc6 默认不包含该头文件, 安装 windows 2003 r2 sdk 即可 然后在 vc6 的 options 的 Directories 里填如 SDK 的安装路径 再编译即可 4 驱动程序驻留内存, 导致其它程序无限等待当监控程序意外退出时, 驱动程序会驻留内存继续工作, 这时当有其它程序访问受限制的注册表键时将会导致无限等待, 即使使用任务管理器也无法结束 解决方法是当监控程序意外退出时卸载掉驱动 而系统中独立出一个模块 BugReport 主要是调用 SetUnhandledExceptionFilter 设置未处理异常钩子回调函数

34 第 34 页 5 驱动程序移位再编译后加载失败把驱动工程移动到别的地方, 在编译后加载失败 运行 regedit, 搜索 KeHookReg, 把找到的键全部删除 5.4 可改进之处 1 该系统拦截的用户层的程序, 若在在驱动内部访问注册表则无法拦截, 可以使用 Hook PE 技术来拦截驱动访问注册表 2 附带更多的规则, 这样软件安装完毕不需要更多的设置便可使用 3 提供注册表优化 清理 备份和还原功能 4 兼容最新的 Windows 操作系统 Vista

35 第 35 页 参考文献 [1] Sven B.Schreiber Undocumented Windows 2000 Secrets. 美国,1999 [2] 沃尔特.oney Microsoft Windows 驱动程序模型设计. 美国, 微软出版社,1999 [3] Prasad Dabak,Milind Borate Sandeep Phadke.Undocumented_Windows_NT. 美国,1999 [4] David A. Solomon, Mark Russinovich.Inside Microsoft Windows 美国 Microsoft Press,2000 [5] Unknow.Windows2000 驱动程序设计指南. 美国,1998 [6] Chris Cant.Windows WMD 设备驱动程序开发指南. 美国,1999 [7] Brief. 剖析 Windows 系统服务调用机制.Internet, [8] SoBeIt. 挂钩 Windows API.Internet, [9] sinister. 内核级 HOOK 的几种实现与应用.Internet, [10] tombkeeper. 获取 Windows 系统的内核变量.Internet, [11] tombkeeper. 对 Native API NtSystemDebugControl 的分析.Internet, [12] MustBE. 获得进程的 EPROCESS.Internet, Internet, [13] Greg Hoglund. 一个修改 NT 内核的真实 RootKit.Internet, [14] crazylord.playing with Windows /dev/(k)mem.internet, [15] Refdom. 谈谈 WIN2K 的服务.Internet, [16] tombkeeper.the NT Insider:Stop Interrupting Me - Of PICs and APICs.Internet, [17] sunwear. 浅析本机 API.Internet, [18] WebCrazy. 剖析 Windows NT/2000 内核对象组织.Internet, [19] tomh.win2k 下的 Api 函数的拦截.Internet, [20] SoBeIt.Windows 异常处理流程.Internet,

36 第 36 页 英文原文 Hooking the native API and controlling process creation on a system-wide basis Introduction Recently I came across the description of a quite interesting security product, called Sanctuary. This product prevents execution of any program that does not appear on the list of software that is allowed to run on a particular machine. As a result, the PC user is protected against various add-on spyware, worms and trojans - even if some piece of malware finds its way to his/her computer, it has no chance of being executed, and, hence, has no chance of causing any damage to the machine. Certainly, I found this feature interesting, and, after a bit of thinking, came up with my own implementation of it. Therefore, this article describes how process creation can be programmatically monitored and controlled on a system-wide basis by means of hooking the native API. This article makes a "bold" assumption that the target process is being created by user-mode code (shell functions, CreateProcess(), manual process creation as a sequence of native API calls, etc). Although, theoretically, a process may be launched by kernel-mode code, such possibility is, for practical purposes, negligible, so we don't have to worry about it. Why??? Try to think logically - in order to launch a process from the kernel mode, one has to load a driver, which, in turn, implies execution of some user-mode code, in the first place. Therefore, in order to prevent execution of unauthorized programs, we can safely limit ourselves to controlling process creation by user-mode code on a system-wide basis. Defining our strategy First of all, let's decide what we have to do in order to monitor and control process creation on a system-wide basis. Process creation is a fairly complex thing, which involves quite a lot of work (if you don't believe me, you can disassemble CreateProcess(), so you will see it with your own eyes). In order to launch a process, the following steps have to be taken: 1. Executable file has to be opened for FILE_EXECUTE access. 2. Executable image has to be loaded into RAM. 3. Process Executive Object (EPROCESS, KPROCESS and PEB structures) has to be set up. 4. Address space for the newly created process has to be allocated.

37 第 37 页 5. Thread Executive Object for the primary thread of the process (ETHREAD, KTHREAD and TEB structures) has to be set up. 6. Stack for the primary thread has to be allocated. 7. Execution context for the primary thread of the process has to be set up. 8. Win32 subsystem has to be informed about the new process. In order for any of these steps to be successful, all previous steps have to be accomplished successfully (you cannot set up an Executive Process Object without a handle to the executable section; you cannot map an executable section without file handle, etc). Therefore, if we decide to abort any of these steps, all subsequent ones will fail as well, so that process creation will get aborted. It is understandable that all the above steps are taken by means of calling certain native API functions. Therefore, in order to monitor and control process creation, all we have to do is to hook those API functions that cannot be bypassed by the code that is about to launch a new process. Which native API functions should we hook? Although NtCreateProcess() seems to be the most obvious answer to the question, this answer is wrong - it is possible to create a process without calling this function. For example, CreateProcess() sets up process-related kernel-mode structures without calling NtCreateProcess(). Therefore, hooking NtCreateProcess() is of no help to us. In order to monitor process creation, we have to hook either NtCreateFile() and NtOpenFile(), or NtCreateSection() - there is absolutely no way to run any executable file without making these API calls. If we decide to monitor calls to NtCreateFile() and NtOpenFile(), we have to make a distinction between process creation and regular file IO operations. This task is not always easy. For example, what should we do if some executable file is being opened for FILE_ALL_ACCESS??? Is it just an IO operation or is it a part of a process creation??? It is hard to make any judgment at this point - we need to see what the calling thread is about to do next. Therefore, hooking NtCreateFile() and NtOpenFile() is not the best possible option. Hooking NtCreateSection() is a much more reasonable thing to do - if we intercept a call to NtCreateSection() with the request of mapping the executable file as an image (SEC_IMAGE attribute), combined with the request of page protection that allows execution, we can be sure that the process is about to be launched. At this point we are able to take a decision, and, in case if we don't want the process to be created, make NtCreateSection() return STATUS_ACCESS_DENIED. Therefore, in order to gain full control over process creation on the target machine, all we have to do is to hook NtCreateSection() on a system-wide basis. Like any other stub from ntdll.dll, NtCreateSection() loads EAX with the service index, makes EDX point to function parameters, and transfers execution to KiDispatchService() kernel-mode routine (this is done by the INT 0x2E instruction under Windows NT/2000 and SYSENTER instruction under Windows XP). After validating function parameters, KiDispatchService() transfers execution to the actual implementation of the service, the address of which is available from the Service Descriptor Table (pointer to this table is

38 第 38 页 exported by ntoskrnl.exe as the KeServiceDescriptorTable variable, so it is available to kernel-mode drivers). The Service Descriptor Table is described by the following structure: struct SYS_SERVICE_TABLE void **ServiceTable; unsigned long CounterTable; unsigned long ServiceLimit; void **ArgumentsTable; ; The ServiceTable field of this structure points to the array that holds addresses of all the functions that implement system services. Therefore, all we have to do in order to hook any native API function on a system-wide basis is to write the address of our proxy function to the i-th entry (i is the service index) of the array, pointed to by the ServiceTable field of KeServiceDescriptorTable. Looks like now we know everything we need to know in order to monitor and control process creation on a system-wide basis. Let's proceed to the actual work. Controlling process creation Our solution consists of a kernel-mode driver and a user-mode application. In order to start monitoring process creation, our application passes the service index, corresponding to NtCreateSection(), plus the address of the exchange buffer, to our driver. This is done by the following code: //open device device=createfile("\\\\.\\protector",generic_read GENERIC_WRITE, 0,0,OPEN_EXISTING, FILE_ATTRIBUTE_SYSTEM,0); // get index of NtCreateSection, and pass it to the driver, along with the //address of output buffer DWORD * addr=(dword *) (1+(DWORD)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtCreateSection")); ZeroMemory(outputbuff,256); controlbuff[0]=addr[0]; controlbuff[1]=(dword)&outputbuff[0]; DeviceIoControl(device,1000,controlbuff,256,controlbuff,256,&dw,0); The code is almost self-explanatory - the only thing that deserves a bit of attention is the way we get the service index. All stubs from ntdll.dll start with the line MOV EAX, ServiceIndex, which applies to any version and flavour of Windows NT. This is a 5-byte instruction, with MOV EAX opcode as the first byte and the service index as remaining 4 bytes. Therefore, in order to get the service index that corresponds to some particular native API

39 第 39 页 function, all you have to do is to read 4 bytes from the address, located 1 byte away from the beginning of the stub. Now let's look at what our driver does when it receives IOCTL from our application: NTSTATUS DrvDispatch(IN PDEVICE_OBJECT device,in PIRP Irp) UCHAR*buff=0; ULONG a,base; PIO_STACK_LOCATION loc=iogetcurrentirpstacklocation(irp); if(loc->parameters.deviceiocontrol.iocontrolcode==1000) buff=(uchar*)irp->associatedirp.systembuffer; // hook service dispatch table memmove(&index,buff,4); a=4*index+(ulong)keservicedescriptortable->servicetable; base=(ulong)mmmapiospace(mmgetphysicaladdress((void*)a),4,0); a=(ulong)&proxy; _asm mov eax,base mov ebx,dword ptr[eax] mov RealCallee,ebx mov ebx,a mov dword ptr[eax],ebx MmUnmapIoSpace(base,4); memmove(&a,&buff[4],4); output=(char*)mmmapiospace(mmgetphysicaladdress((void*)a),256,0); Irp->IoStatus.Status=0; IoCompleteRequest(Irp,IO_NO_INCREMENT); return 0; As you can see, there is nothing special here either - we just map the exchange buffer into the kernel address space by MmMapIoSpace(), plus write the address of our proxy function to the Service Table (certainly, we do it after having saved the address of the actual service

40 第 40 页 implementation in the RealCallee global variable). In order to overwrite the appropriate entry of the Service Table, we map the target address with MmMapIoSpace(). Why do we do it? After all, we already have an access to the Service Table, don't we? The problem is that the Service Table may reside in read-only memory. Therefore, we have to check whether we have write access to the target page, and if we don't, we have to change page protection before overwriting the Service Table. Too much work, don't you think? Therefore, we just map our target address with MmMapIoSpace(), so we don't have to worry about page protection any more - from now on we can take write access to the target page for granted. Now let's look at our proxy function: //this function decides whether we should //allow NtCreateSection() call to be successfull ULONG stdcall check(pulong arg) HANDLE hand=0;pfile_object file=0; POBJECT_HANDLE_INFORMATION info;ulong a;char*buff; ANSI_STRING str; LARGE_INTEGER li;li.quadpart=-10000; //check the flags. If PAGE_EXECUTE access to the section is not requested, //it does not make sense to be bothered about it if((arg[4]&0xf0)==0)return 1; if((arg[5]&0x )==0)return 1; //get the file name via the file handle hand=(handle)arg[6]; ObReferenceObjectByHandle(hand,0,0,KernelMode,&file,&info); if(!file)return 1; RtlUnicodeStringToAnsiString(&str,&file->FileName,1); a=str.length;buff=str.buffer; while(1) if(buff[a]=='.')a++;break; a--; ObDereferenceObject(file); //if it is not executable, it does not make sense to be bothered about it //return 1 if(_stricmp(&buff[a],"exe"))rtlfreeansistring(&str);return 1; //now we are going to ask user's opinion.

41 //Write file name to the buffer, and wait until //the user indicates the response //(1 as a first DWORD means we can proceed) 第 41 页 //synchronize access to the buffer KeWaitForSingleObject(&event,Executive,KernelMode,0,0); // set first 2 DWORD of a buffer to zero, // copy the string into the buffer, and loop // until the user sets first DWORD to 1. // The value of the second DWORD indicates user's //response strcpy(&output[8],buff); RtlFreeAnsiString(&str); a=1; memmove(&output[0],&a,4); while(1) KeDelayExecutionThread(KernelMode,0,&li); memmove(&a,&output[0],4); if(!a)break; memmove(&a,&output[4],4); KeSetEvent(&event,0,0); return a; //just saves execution contect and calls check() _declspec(naked) Proxy() _asm //save execution contect and calls check() //-the rest depends upon the value check() returns // if it is 1, proceed to the actual callee. //Otherwise,return STATUS_ACCESS_DENIED pushfd pushad mov ebx,esp add ebx,40 push ebx

42 call check cmp eax,1 jne block 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 42 页 //proceed to the actual callee popad popfd jmp RealCallee //return STATUS_ACCESS_DENIED block:popad mov ebx, dword ptr[esp+8] mov dword ptr[ebx],0 mov eax,0xc l popfd ret 32 Proxy() saves registers and flags, pushes a pointer to the service parameters on the stack, and calls check(). The rest depends on the value check() returns. If check() returns TRUE (i.e. we want to proceed with the request), Proxy() restores registers and flags, and transfers control to the service implementation. Otherwise, Proxy() writes STATUS_ACCESS_DENIED to EAX, restores ESP and returns - from the caller's perspective it looks like NtCreateSection() call had failed with STATUS_ACCESS_DENIED error status. How does check() make its decision? Once it receives a pointer to the service parameters as an argument, it can examine these parameters. First of all, it checks flags and attributes - if a section is not requested to be mapped as an executable image, or if the requested page protection does not allow execution, we can be sure that NtCreateSection() call has nothing to do with process creation. In such a case check() returns TRUE straight away. Otherwise, it checks the extension of the underlying file - after all, the SEC_IMAGE attribute and the page protection that allows execution may be requested for mapping some DLL file. If the underlying file is not a.exe file, check() returns TRUE. Otherwise, it gives the user-mode code a chance to take its decision. Therefore, it just writes the file name and the path to the exchange buffer, and polls it until it gets the response. Before opening our driver, our application creates a thread that runs the following function: void thread() DWORD a,x; char msgbuff[512]; while(1)

43 memmove(&a,&outputbuff[0],4); 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 43 页 //if nothing is there, Sleep() 10 ms and check again if(!a)sleep(10);continue; // looks like our permission is asked. If the file // in question is already in the white list, // give a positive response char*name=(char*)&outputbuff[8]; for(x=0;x<stringcount;x++) if(!stricmp(name,strings[x]))a=1;goto skip; // ask user's permission to run the program strcpy(msgbuff, "Do you want to run "); strcat(msgbuff,&outputbuff[8]); // if user's reply is positive, add the program to the white list if(idyes==messagebox(0, msgbuff,"warning", MB_YESNO MB_ICONQUESTION 0x L)) a=1; strings[stringcount]=_strdup(name);stringcount++; else a=0; // write response to the buffer, and driver will get it skip:memmove(&outputbuff[4],&a,4); //tell the driver to go ahead a=0; memmove(&outputbuff[0],&a,4); This code is self-explanatory - our thread polls the exchange buffer every 10 ms. If it discovers that our driver has posted its request to the buffer, it checks the file name and path against the list of programs that are allowed to run on the machine. If the match is found, it gives an OK response straight away. Otherwise, it displays a message box, asking the user whether he allows the program in question to be executed. If the response is positive, we add the program in question to the list of software that is allowed to run on the machine. Finally, we write the user response to the buffer, i.e., pass it to our driver. Therefore, the user gets the full control of processes creation on his PC - as long as our program runs, there is absolutely no way to launch any process on the PC without asking user permission.

44 第 44 页 As you can see, we make the kernel-mode code wait for the user response. Is it really a wise thing to do??? In order to answer this question, you have to ask yourself whether you are blocking any critical system resources -everything depends on the situation. In our case everything happens at IRQL PASSIVE_LEVEL, dealing with IRPs is not involved, and the thread that has to wait for the user response is not of critical importance. Therefore, in our case everything works fine. However, this sample is written for demonstration purposes only. In order to make any practical use of it, it makes sense to rewrite our application as an auto-start service. In such a case, I suggest we should make an exemption for the LocalSystem account, and, in case if NtCreateSection() is called in the context of a thread with LocalSystem account privileges, proceed to the actual service implementation without performing any checks -after all, LocalSystem account runs only those executables that are specified in the Registry. Therefore, such an exemption is not going to compromise our security. Conclusion In conclusion I must say that hooking the native API is definitely one the most powerful programming techniques that ever existed. This article gives you just one example of what can be achieved by hooking the native API - as you can see, we managed to prevent execution of unauthorized programs by hooking a single(!!!) native API function. You can extend this approach further, and gain full control over hardware devices, file IO operation, network traffic, etc. However, our current solution is not going to work for kernel-mode API callers - once kernel-mode code is allowed to call ntoskrnl.exe's exports directly, these calls don't need to go via the the system service dispatcher. Therefore, in my next article we are going to hook ntoskrnl.exe itself. This sample has been successfully tested on several machines that run Windows XP SP2. Although I haven't yet tested it under any other environment, I believe that it should work fine everywhere - after all, it does not use any structure that may be system-specific. In order to run the sample, all you have to do is to place protector.exe and protector.sys to the same directory, and run protector.exe. Until protector.exe's application window is closed, you will be prompted every time you attempt running any executable. I would highly appreciate if you send me an with your comments and suggestions.

45 第 45 页 中文译文 系统范围内挂钩本地 API 控制进程的创建 最近我碰到的描述相当有趣的安全产品, 叫避难所. 这个产品不允许执行任何程式, 并没有出现在名单上的软件, 即允许运行在一个特定的程序. 这样电脑用户就可以免受各种间谍蠕虫和木马的侵袭 - 即使有一块恶意的认定方式, 以他 / 她的电脑, 它已没有机会再被执行, 因此, 没有机会造成任何破坏. 当然, 我发现这个有趣的特点, 并且经过一点思考, 提出了自己的实施方案. 因此, 这篇文章描述如何实现过程, 可以以编程的方式监测与控制系统的基础上, 挂钩本地 API. 这篇文章提出了 " 大胆 " 假设目标进程正在创建用户模式代码 ( 外壳函数, CreateProcess(), 最终结果还是调用本地 API 等 ). 虽然, 从理论上说, 一个进程可能调用内核模式代码, 这种可能性是出于实际目的, 微不足道的, 所以, 我们不用担心. 为什么??? 想想实际情况, 为启动程序, 由内核模式, 必须装载了驱动程序, 这反过来意味着, 应该先执行用户模式代码. 因此, 为了防止执行未经许可的程序, 我们可以安全地把自己局限在控制进程创建的用户模式代码一个系统范围内. 确定我们的策略 首先, 让我们决定我们要做的, 建立一个监测和控制过程, 在系统范围内. 创建进程是一个相当复杂的事, 其中涉及相当多的工作 ( 如果你不相信我, 你可以反汇编 CreateProcess( ) ). 为了启动一个进程, 之后必须采取步骤 : 可执行文件必须以 FILE_EXECUTE 方式打开 2 执行影象必须加载进 RAM 3 进程对象 (EPROCESS,KPROCESS 和 PEB 结构体 ) 被创建 4 分配进程的地址空间 5 主线程对象 (ETHREAD,KTHREAD 和 TEB 结构体 ) 被创建 6 分配主线程栈 7 进程的主线程的上下文被创建 8 win32 子系统记录新进程信息 为了使这些步骤, 要取得成功, 之前所有的步骤都必须成功地完成了 ( 你不能设立一个进程过程对象无效句柄可执行科 ; 你不能映射一个没有句柄的执行对象等 ). 因此, 如果我们决定退出任何这些步骤, 随后所有的失败一样, 使创建过程会胎死腹中. 这是可以理解的, 所有上述步骤, 采取的手段是修改某些本地 API 函数. 因此, 为了监测和控制进程创建, 我们所要做的是挂钩那些 API 函数, 不能绕开的代码, 即将创建一项新的进程. 那个本地 API 要挂钩? 虽然 NtCreateProcess ( ) 似乎是最明显的答案, 这个答案是错的, 创建一

46 第 46 页 个进程可能不会调用此函数. 例如, CreateProcess( ) 设置与进程相关的内核模式结构, 而不需要 NtCreateProcess ( ). 因此, 挂钩 NtCreateProcess ( ) 对我们没有帮助. 为了监视进程的创建, 我们要么挂钩 NtCreateFile ( ) 和 NtOpenFile ( ), 或者 NtCreateSection ( ), 创建进程是绝对要调用上述 API 的. 如果我们决定要挂钩 NtCreateFile ( ) 和 NtOpenFile ( ), 那我们要区分, 创建进程和普通的文件 IO 的行动. 这项任务并不容易. 举例来说, 我们应该怎样做, 如果一些可执行文件正以 file_all_access 打开呢??? 只是一个 IO 的操作还是一个进程创建??? 很难作出判断, 在这一点我们必须清楚地看到哪些调用线程即将做什么. 因此, 挂钩 NtCreateFile ( ) 和 NtOpenFile ( ) 不是最佳的选择. 挂钩 NtCreateSection ( ) 是一个更为合理的事情, 如果我们拦截 NtCreateSection( ) 掉用请求映射可执行文件作为图像 ( sec_image 属性 ), 结合请求页面保护, 使执行我们可以肯定, 这一进程即将执行. 在这点上我们是能够作出判断的, 并如果, 如果我们不希望这一进程创造, 使 NtCreateSection( ) 返回 status_access_denied. 因此, 为了充分控制进程在目标机器上创建, 我们所要做的是在全局范围内钩钩 NtCreateSection( ). 象 ntdll.dll 其它调用代理那样 NtCreateSection ( ) 使用 EAX 加载系统服务索引号,EDX 指向函数参数, 然后转换到内核模式执行 KiDiSpatchService ( ) 内核模式例程 ( 在 windows2000 中由 int 2eH 实现, 在 WindowsXP 则由 sysenter 实现 ). 经过验证功能参数后, KiDiSpatchService ( ) 的执行转移到实际执行的服务, 地势可从服务描述表 ( 指向这个表是作为 ntoskrnl.exe keservicedescriptortable 的导出变量, 因此它是提供给内核模式驱动 ). 服务描述表的结构如下 : servicetable 这个结构体的地址数组完成的全部功能, 系统服务的实现. 因此, 我们要做的, 任何在全局范围内挂钩本地 API 函数基础是改写 KeServiceDescriptorTable 的 servicetable 地址使之转向我们的代理函数 像现在, 我们知道我们需要知道的一切, 在全局范围内监控进程的创建. 让我们开始实际工作. 我们的解决方案包含了内核模式驱动程序和用户模式程序. 为了开始监测过程中创造, 我们的程序过滤掉 ntcreatesection ( ) 相应的服务索引, 再加上地址的交换缓冲区, 我们的驱动. 这是由以下代码 : 代码不需要太多的注释, 唯一值得有点注意的是, 我们得到服务索引的方式.ntdll.dll 里面的所有服务代理的开头都是 mov eax, serviceindex, 它适用于任何版本 Windows NT. 这是一个 5 字节的指令, 其中 MOV EAX opcode 作为第一字节和服务索引作为剩余的 4 个字节. 因此, 为了得到服务索引号, 定位与本地 API, 取得后四个字节. 现在让我们看看, 我们的驱动程序处理我们的应用程序发出的 ioctl: 如你所见, 没有什么特别到这里, 我们只映射交换缓冲到内核地址空间通过调用 MmMapIoSpace ( ), 再加上写的地址是我们的代理函数的服务表 ( 当然, 我们这样做是经过储存地址中的实际执行的服务, 在全局 RealCallee 变量 ). 为了改写服务表, 我们的映射目标地址通过 MmMapIoSpace ( ). 我们为什么要这样做? 毕竟, 我们已访问一个以服务表, 不就? 目前的问题是, 服务表可能放在只读存储器. 因此, 我们要检查是否有写权限在目标页面上, 如果我们不这样做, 我们要改变页保护之前, 改写的服务表. 太多的工作, 你难道不好吗? 因此, 我们只是映射目标地址通过 MmMapIoSpace ( ), 所以不用担心更多的页保护, 从现在开始我

47 们理所当然的可以采取写的方式对目标页面. 现在让我们看看我们代理函数的功能 : 第 47 页 Proxy( ) 保存寄存器和标志, 把一个指向服务参数的指针入栈, 并调用 check( ). 剩余的工作由 check( ) 返回. 如果 check( ) 返回 TRUE ( 即要着手处理请求 ),Proxy( ) 恢复寄存器和标志并将控制权转让给系统服务完成. 否则,Proxy( ) 向 EAX 写入 STATUS_ACCESS_DENIED, 恢复 ESP 并返回, 从调用者的角度看来 NtCreateSection ( ) 调用失败返回 STATUS_ACCESS_DENIED 错误状态. check( ) 如何作出决定? 一旦它收到一个指向服务参数, 可以检查这些参数. 首先, 它检查标志位和参数, 如果区域对象不要求将其映射为一个可执行的形象, 或者如果被请求页面保护不允许执行, 我们可以肯定地说 ntcreatesection ( ) 调用与创建进程无关. 在这种情况下检查 ( ) 返回 TRUE. 否则, 它会检查扩展名, sec_image 的属性和页面保护, 使运行的时间可能会要求载入一些映射的 DLL 文件. 如果扩展名不是. exe 文件, 检查 ( ) 返回 TRUE. 否则, 它给用户模式代码一个机会做出决定. 因此, 它只是写到档案名称和路径交换缓冲区由用户决定, 直到得到回应. 在打开我们的驱动之前, 我们的应用开启了一个线程完成下列功能 : 这个代码不需要太多的说明 -- 我们的线程每 10ms 便检查一次缓冲. 如果发现我们的驱动已将其请求的缓冲区, 它检查扩展名称和路径, 如果匹配, 它立刻返回一个 OK. 否则, 它显示一个对话框, 询问用户是否允程序执行. 如果运行程序, 我们把程序添加到安全程序列表. 最后, 我们写用户回应缓冲, 通知我们的驱动程序. 现在, 我们已经完全控制了进程的创建, 如果没有用户的许可, 进程是不可能被创建的. 如你所见, 我们让内核方式代码等待用户响应. 这是一件好事呢??? 为了回答这个问题, 你要问自己到底是什么阻塞关键系统资源 - 一切视情况而定. 在我们的情况一切都发生 irql passive_level 上, 等待用户的反应并非至关重要的. 因此, 在我们的情况一切都运行良好. 然而, 这样写示范仅供参考. 为了使任何实际使用它, 是有道理的, 改写了我们的程序, 作为自启动服务. 在这种情况下, 我认为我们应该让程序运行在 localsystem 下, 但 ntcreatesection ( ) 调用环境中的 localsystem 帐户特权从实际执行服务不进行任何检查毕竟, localsystem 帐户挤提只有那些可执行文件. 因此, 这种做法是不太安全的. 结论 最后, 我不得不说挂钩本地 API 绝对是一个最强大的编程技术. 这篇文章给你, 只是一个例子, 我们能够做到的挂钩本地 API, 你可以看到, 我们设法阻止并决定本地 API 的执行结果. 你领会一做法的同时, 充分控制硬件设备, 文件 IO 的操作, 网络流量, 等等 但是, 我们目前的解决方法是行不通的内核模式下可以直接调用 ntoskrnl.exe 的到处函数, 这些调用没有必要去通过系统调度服务. 因此, 在接下来的文章里我们将挂钩 ntoskrnl.exe 本身. 这个样品已经成功地测试了几个运行在 windows xp sp2 的机器. 虽然我还未测试, 它应该可以在任何环境下, 我相信能运行在任何环境下 为了能够正常运行, 请把 protector.exe 和 protector.sys 放在同一目录下 我也非常欣赏, 如果你送我一个电子邮件与你的意见和建议.

48 第 48 页 致 谢 在本次毕业设计中学到很多新知识, 例如驱动程序的编写,Windows 的内部机制, 驱动程序的调试等等 更累积了不少开发经验, 例如驱动编写中常见容易犯的错误 多层软件的开发 这些都是在课本上学习不到的 非常感谢我的毕业设计指导老师, 以及在设计中帮助过我的各位朋友

49 附加信息 : 中国矿业大学 2007 届本科生毕业设计 ( 论文 ) 第 49 页 CSDN ID:KeSummer BLOG( 不喜欢写 ):

50 第 50 页 凑页数的话 : 喜欢一个人旅行, 喜欢天文观测, 喜欢新奇的东西等等