基于行为监控的木马查杀技术设计方案

1、基于行为监控的木马查杀技术设计方案绪论计算机的广泛应用把人类带入了一个全新的信息时代， 不仅大方便了人们的 生活，而且还直接影响着社会的各个方面； 计算机及信息系统在给人们提供高速 计算、海量信息、协同处理等各种服务的同时，其本身的安全性、完整性和可用 性也受到了前所未有的威胁，计算机病毒、计算机犯罪、黑客攻击、系统故障等 事件层出不穷，尤其是近年来计算机病毒的增长速度之快、传播围之广、 造成损 失之大令人痛心疾首。2007 年初，我读到了中国互联网 2006 年度信息安全报告 。该报告中显 示， 2006 年全国的计算机病毒呈现三大特点：一是电脑病毒呈爆炸式增长。全 年共截获新增病毒多达 2

2、40156 种（图 0.1 ）。图 0.1 2003 、2004、2005、2006 连续四年新增病毒数量对比示意图二是木马增长特快，并且变种多、比例高。 2006 年，木马的新增数占总病 毒新增数的 73%，多达 175313种。有的木马程序在一天之增加了 10 余个不同的 变种（图 0.2 ）。而在所有的木马中，盗号木马又是最严重的一类，所占比例高 达 76.04%，成为了名副其实的“ 最毒” 。图 0.2 2006 年新增病毒主要类型所占比例示意图三是破坏力强， 木马所造成的灾难非常严重。 病毒不仅使全国 75,967,19 台 计算机受到感染， 破坏了大量的硬件设施和软件设备， 而且使

3、广大网民的网上财 产受到了空前的损失。特别是盗号木马不仅疯狂盗取网民的网银、虚拟财产， 而 且还盗取个人信息、 企业资料等各种重要数据， 已经形成了强大的无孔不入的产 业链，成为了众多网民面临的第一大威胁。资料证明 6：在过去的两年里， 有 91.35%的计算机遭受过木马的攻击， 有 51% 的恶意程序是专门用于盗取网银、网游等网络财产和 QQ号、密码、 数据的木马， 每年给国家和网民造成 115 亿元以上的经济损失，而且还在以 74%的速度递增。面对如此严峻的形势， 我的心情非常沉重：既然木马这么严重，特别是盗号 木马已经成为网民的第一大威胁， 为什么我们还要由它肆意泛滥而坐视不管呢？ 是我

4、们没有能力解决还是有能力解决但没有找到好的办法呢？作为一名计算机 爱好者，特别是一名有志青年， 为什么不为消除恶意程序尽点自己的努力呢？于 是，我开始留意这方面的成果，收集相关资料，下定决心找一种无需特征码、主 动防御、能为用户提供木马详尽信息的方法，为广大网民、为互联网的安全、也 为我国的计算机事业做出自己的贡献，于是我坚定地开始了该课题的研究。1 系统功能及总体架构1.1 软件功能1.1.1 对键盘记录型木马的监控使用全局钩子监控键盘的用户输入是当前盗号木马常用的一种盗号方式，本软件的行为监控功能可以及时发现木马并阻止该行为。测试软件：键盘记录者 v8.0下载地址： 代表类型：使用全局钩子

5、的键盘记录型盗号木马 首先，不打开本软件或关闭行为监控功能，直接运行键盘记录者程序。 从截图可以看出，键盘记录者已将在记事本中输入的字符截获。图 1.1 未运行本程序时的情形然后，我们先开启本程序或开启行为监控功能，再运行键盘记录者。从以下截图中可以看出， 在键盘记录者运行时， 本程序给出了提示以及键盘 记录者程序的路径。同时， 由于默认的行为规则为阻止全局钩子设置， 键盘记录 者已无法发挥作用。图 1.2 本程序检测到全局钩子的设置并给出提示图 1.3 由于设置钩子被阻止，键盘记录功能已无法发挥作用1.1.2 对消息发送型木马的监控通过向文本框发送 WM_GETTEX消T息获取其中的文本也是

6、常见的一种盗号方 法，本软件对此行为也进行了监控。测试软件：窗体属性修改专家 2007下载地址： .skycn./soft/9342.html代表类型：通过发送 WM_GETTEX消T息获取文本框文本的木马 首先，不打开本软件或关闭行为监控功能，直接运行窗体属性修改专家 2007，打开记事本，随意键入一些文本，再按窗体属性修改专家的方法，将头像 图标拖至记事本的文本框。从截图可以看出， 记事本的文本已出现在 “获得窗口的文本或 *号密码” 中图 1.4 窗体属性修改专家已将记事本中的文本显示出来然后，我们先开启本程序或开启行为监控功能，再运行窗体属性修改专家。 从以下截图中可以看出， 在尝试获

7、取文本时， 本程序给出了提示以及窗体属 性修改专家的程序路径。同时，由于默认的行为规则为阻止了文本获取， “获得 窗口的文本或 * 号密码”中已无任何文本出现。图 1.5 窗体属性修改专家已无法获取文本1.1.3 系统状况分析：全局钩子检测众所周知，全局钩子是一种能截获系统围的消息并进行处理的一种机制， 键 盘记录型木马使用此技术监视用户键盘、鼠标等活动，盗取密码。本软件的全局钩子检测功能可以检测出系统中当前活动的所有全局钩子， 并 获取全局钩子的设置者、钩子类型等信息。不论全局钩子何时设置， 本功能都能检测出来。 因此， 也可以检测出行为监 控关闭时以及本软件启动前侥幸逃脱监控的钩子。例如，

8、我们可以按以下步骤验证此功能： 首先，关闭行为监控或关闭本软件，打开键盘记录者。 然后，再运行本软件并打开主窗口及系统状况分析 - 全局钩子检测功能。 从截图中可以看出， 键盘记录者所设置的钩子已显示在列表中。 这两个钩子 的类型为 WH_GETMESSA和GEWH_CB，T钩子的设置者为键盘记录者程序 “ C:Program Fileskdemo80demo80.exe ”。图 1.6 全局钩子列表选中键盘记录者设置的这两个钩子， 点击删除钩子。 删除成功后， 再向记事 本中输入文本，可见键盘记录者中已无相应文本出现。1.1.4 行为日志记录在 1.1.1 对键盘记录型木马的监控中，运行键盘

9、记录者时，本软件给出了 提示，同时，在行为日志中， 也对键盘记录者的各种操作做了详细记录。 如图 1.7 中所示的时间、所进行的操作（设置钩子） 、操作来源、钩子类型及根据行为规 则对此的处理等信息。图 1.7 行为日志记录1.1.5 自定义行为规则对于某些系统进程（如 Explorer.exe ）常常成为木马进行线程注入后的藏 身之处，此时可使用自定义行为规则功能，将其列入“受保护的进程”中，对其 进行重点保护。图 1.8 自定义行为规则1.1.6 重点进程保护远程线程注入是木马常用的一种自我隐藏技术，而系统进程 Explorer.exe 等常常成为线程注入的对象。本软件的重点进程保护功能可

10、为列入“行为规则 受保护的进程”的进程提 供单独的保护。下面以“ Windows应用程序捆绑核心编程配套光盘”中的创建远程线程示例 程序作为演示。首先，关闭本软件或关闭行为监控，打开计算器，再运行演示程序，该演示 程序会在计算器进程中注入 HideProcess.dll 并显示出消息框如下图所示图 1.9 线程注入成功然后，运行本软件，在行为规则设置中，在“受保护的进程”中加入计算器进程，再运行演示程序，本软件便可以捕获线程注入操作。图 1.10 本软件捕获线程注入操作1.1.7 清除自我保护进程随着技术的发展， 部分木马目前也具有了自我保护能力， 对此，本软件使用 驱动程序攻破了木马的保护。

11、下面用外挂进程隐藏 -窗口隐藏 -进程防杀器 V1.0 进行演示测试软件：外挂进程隐藏 -窗口隐藏 -进程防杀器 V1.0下载地址： 代表类型：修改可执行文件导入表自我保护的木马 原理： 先关闭本程序或关闭行为监控，打开“进程防杀器” ，随意选择一个进程， 设置为防杀（如将记事本设置为防杀） 。图 1.11 记事本进程保护成功自我保护成功后， 再尝试用任务管理器结束记事本进程， 可见任务管理器已 无法完成此工作。打开本软件的主窗口，选择系统状况分析 - 进程列表，再选择记事本进程， 单击结束进程，可见本软件依然可以清理保护后的记事本进程。图 1.12 任务管理器无法结束自我保护进程1.2 系统

12、架构本软件的总体架构如图 1.13 所示：图 1.13 本程序的框架GlobalHookUI.exe 提供用户界面GlobalHookUIExt.dll 提供扩展功能ActionRule.xml 储存事件日志与行为规则GlobalHook.sys 完成修改核，接管 API 函数，收集行为信息，帮助GlobalHookUI.exe 实现 Ring3 下无法完成的功能。在以下部分对各模块进行详细介绍：1.2.1 用户界面模块 (GlobalHookUI.exe)用户界面模块是用户与本程序进行交互的主要界面，如图 1.14 所示。 “设置行为规则” 功能可以让用户对行为规则进行自定义， 如默认对某一

13、操 作是允许、禁止或提示；也可以设置特例，如对系统进程赋予更高的权限，允许 所有操作； 也可以对某些重点进程设置保护，禁止其他进程对其的访问等。 具体 讨论可参见 1.1.5 自定义行为规则。“系统状况分析” 功能可以让用户了解系统的运行状况。 首创的全局钩子检 测功能(参见对一种通用于 Windows 2000XP2003 的枚举全局钩子及获取其 关键信息的方法 的查新报告) 可以让用户了解到哪些程序正在使用全局钩子监 视键盘、鼠标或是系统消息。同时，本软件提供了清除钩子的功能，以消除木马 的监视。具体讨论可参见 1.1.3 系统状况分析：全局钩子检测。“行为日志” 功能记录了系统中受监控行

14、为的发出者、 操作对象、用户的处 理等，为清除木马提供了依据。具体讨论可参见 1.1.4 行为日志记录。图 1.14 本程序的主窗口1.2.2 驱动模块 (GlobalHook.sys)驱动模块完成了截获各种行为、收集行为信息、读取与修改核数据等需要 Ring0 权限的工作。1.2.3 行为日志 / 行为规则 (ActionRule.xml)ActionRule.xml 存储了用户自定义的行为规则及行为日志1.2.4 功能扩展模块 (GlobalHookUIExt.dll)本软件的用户界面模块使用 C#编写，由于 .NET程序使用 Win32 API/Native API要频繁的使用 PInv

15、oke ，这样带来了诸多不便。 功能扩展模块实现了与 Win32 API/Native API 关系紧密的部分，如承担跨权限级别通讯功能的 LPC端口的部 分功能。1.3 系统关键技术与创新点1.3.1 行为监控技术行为监控技术为本系统实现对木马的监控、 行为日志记录、 重点进程保护提 供了技术基础。木马程序的各种功能，必须借助系统提供的各种函数来实现，通常情况下， API 函数调用的路径为：用户程序子系统 DLL系统核，在行为监控启用时， API 函数调用的路径被修改，变为用户程序子系统 DLL行为验证 系统核， 在子系统 DLL与系统核的过程间加入了行为验证步骤。 具体说来， 其路径为用户

16、 程 序 子 系 统 DLL 驱 动 模 块 (GlobalHook.sys) 用 户 界 面 模 块 (GlobalHookUI.exe)- 行为规则比较根据规则阻止操作 / 到达系统核。 API 调用 路径如下图所示用户程序子系统 DLL驱动模块用户界面模块行为规则用户态 (Ring3)核心态 (Ring0)系统内核阻止操作图 1.15 API 函数调用路径本程序修改了以下函数的执行路径，在路径中插入了行为验证步骤：Win32 APINative API函数的作用针对的木马行为XTSetWindowsHookExNtUserSetWindowsHookEx设置钩子键盘记录型木马SendMe

17、ssageNtUserMessageCall发送消息通过 WM GETTE 消息获取文本框 文本TerminateProces sNtTerminateProcess结束进程结束杀毒软件进 程以进行自我保 护CreateRemoteThr eadNtCreateThread创建远程线程向系统进程注入 线程以进行隐藏RegSetValueExNtSetValueKey修改注册表向注册表添加自启动项表 1.1 本程序监控的函数调用木马进行的各种操作必然是跨进程的， 此特点被作为区分正常行为与异常行 为的依据。因此， 本程序可以允许进程的钩子设置而阻止全局钩子设置， 允许在 进程创建线程而阻止远程注

18、入线程。上述某些操作系统进程也可能进行， 因此需要有一个行为规则库对一些特例 进行特例处理。若暂时无法判断操作源的是否可信，则给用户提示， 让用户决定 是否执行此操作。通过以上方法，已经可以将误伤降到一个比较低的水平。关于行为监控的具体讨论可参见 2.1 行为监控技术。 采用行为监控作为技术基础， 克服了传统特征码检测的滞后性、 局限性、 效 率低等问题，具有能准确定位攻击源、 发现未知木马、 具备强大的自我保护能力 等特点。同时， 行为监控通过修改系统核完成，有别于传统设置回调函数的方法， 具 有更广的监控围，能获取更精准的行为信息。普 通 方 法 通 过 调 用 Windows 提 供 的

19、 通 知 函 数 （ 函 数 名 通 常 为 xxxNotifyChangeyyy ）设置回调函数对某些操作进行监控。 但这种方法有很大的 局限，若 Windows没有提供相应的通知函数，就无法监控。本软件直接修改系统 核，可以不受 Windows通知函数的限制，对任意行为进行监控， 提供了更广的行 为监控围。Windows提供的通知函数也很少给出行为实施者的相关信息，知道什么行为 发生了， 但却不知道行为由谁发出。 本软件利用驱动程序的优势， 可以明确的知 道行为由谁发出、行为的作用对象是谁，信息更精准。1.3.2 系统消息过滤系统消息过滤技术是实现对消息发送型木马的监控的技术基础。Wind

20、ows中消息的发送大都通过 SendMessage函数完成， SendMessage函数 对应的核函数为 NtUserMessageCall 。在驱动模块接管 NtUserMessageCall 函数 时，也可以接收用户程序传递的各种参数。在我们自定义的 NtUserMessageCall 函数中，我们可以对用户程序传递过来的 Msg参数进行验证， 是否为受监视的消 息，同时，通过 NtUserQueryWindow函数可以获取目标窗口所在进程的信息， 再 根据行为规则，我们可以决定是否将此消息发送到目标窗口。1.3.3 自我保护功能部分木马为了逃避杀毒软件的监视， 在运行时尝试结束杀毒软件的

21、进程， 而 本软件可以监视系统中结束进程的操作，保护自身不被木马破坏。如下图中尝试使用进程管理工具结束记事本进程时， 本软件能给出相应的提 示。图 1.16 使用进程管理工具结束进程时本软件能给出相应提示1.3.4 自我保护进程清理 修改可执行文件的导入表是木马常用的一种自我保护技术， 通过在 API 函数 调用路径上的导入表处设置障碍， 阻止了进程管理工具对其进程的结束操作。 本 软件在执行此类操作时， 可以直接绕过被修改的导入表，利用驱动模块，直接到 达系统核进行执行。下图展示了清理自我保护进程的过程。进程管理程序代码区导入表（被木马 修改）无法到达 系统内核 系统内核本软件用户界面模块代

22、码区导入表驱动模块系统内核绕过被修改的导入表用户态 (Ring3)核心态 (Ring0)图 1.17 本软件为执行操作而开辟的专门通道1.3.5 全局钩子检测使用全局钩子对用户的键盘输入进行监视是木马常见的一种盗号方式，因 此，检测与清除全局钩子也是防御木马的重要一环。Windows中的全局钩子以钩子链的形式存在于核中， 但由于其有权限级别的 保护，因此对其数据结构的读取也需要驱动模块的帮助，其关键的数据结构为 DesktopInfo 、 Hook、 ETHREAD等。有关其有详细讨论可参见 2.3 枚举全局钩子。2 对关键技术的深入讨论2.1 行为监控技术在 1.3.1 中提到，行为监控的基

23、础是在应用程序调用 API 函数的路径上插入 行为验证步骤。进行行为监控前后， API 函数调用的路径如图 2.1 所示。用户程序子系统 DLL系统内核用户程序用户界面模块行为规则子系统 DLL用户态 (Ring3)核心态 (Ring0)驱动模块阻止操作系统内核图 2.1 进行行为监控前后 API 函数调用路径图相比正常情况，我们需要完成以下任务： 注入驱动模块2.1.1 获取 Ring0 权限将详细讨论此问题。 将 API 函数调用引入驱动模块，而非直接到达系统核2.1.2 接管 API 函数将详细讨论此问题。 将行为发出者及行为作用对象的信息发送到用户态2.1.3 与用户态程序间的通讯将讨

24、论此问题 将中的信息通过 PInvoke 封送到 .NET应用程序2.1.4 .NET 应用程序与非托管代码间的互操作将讨论此问题2.1.1 获取 Ring0 权限 背景：权限级别带来的局限保护模式下， CPU提供了 4个权限级别： Ring0-Ring3 。该机制使低权限级别 的程序无法访问高权限级别程序的代码与数据， 但同时也给杀毒软件等程序设置 了一个障碍。CPU的分页机制提供了精确到页的保护，当某程序尝试访问某地址时，CPU会检查其页目录项 ( Page-Directory Entry ，PDE)或页表项(Page-Table Entry ， PTE)中的 U/S 位，若

25、 U/S 位被设置为 1，则此页可被任意权限级别的程序访问， 若 U/S 位被设置为 0 ，表示此页由系统维护，只有具有 Ring0 权限的程序才能访 问，若较低权限级别的程序尝试访问该页，将引起一般性保护异常。图 2.2 PDE 与 PTE的结构Windows的核数据处于虚拟地址空间中高 2GB的部分，被分页机制保护起来， 因此本程序必须通过某种方式获取 Ring0 的权限才能对其进行修改。 方案比较.1 方案一：中断门 /调用门/ 陷阱门中断门/调用门/ 陷阱门是 CPU提供的一种在不同权限级别间进行切换的方 法，因此，只要在全局描述符表 （GDT）或局部描述符

26、表 （ LDT）中找到一个空位， 添加一个指向 Ring0 代码的门描述符即可。此种方法网上流传的代码很多，如： 但遗憾的是，此方法仅对 Win9x有效。 WindowsN T已将 GDT/LDT映射到虚拟 地址空间中高 2GB的部分， 同时 NtSetLdtEntries 函数的漏洞也早已修复， 这让 获取 Ring0 权限与添加门描述符成为先有鸡还是先有蛋的问题。之后，有人提出了此方法的改进版：将所有的物理存通过 DevicePhysicalMemory 对象映射到进程的地址空间中，再对物理存进行修改。 此方法的代码可以参考： 再次让人遗憾的是， 此方法仅对 Windows XP及更早版本

27、有效，Windows Server 2003 SP1及之后的版本已修复该问题。.2 方案二：核心态驱动程序核心态驱动程序作为 Windows核执行体的一部分运行， 可由服务管理器加载， 同样具有 Ring0 的权限。此方法仅有的不足为较难移植到 64 位 Windows。由于部分恶意程序已向系统 核心态转移，因此，在 64 位 Windows上，仅有通过数字签名的驱动程序才能被 加载。.3 优劣比较及本程序的选择方案一：优点：不需要驱动程序，方法简单缺点：兼容性不佳优点：兼容性较好，几乎对所有 32 位 Windows均适用 缺点：较难移植到 64 位 Window

28、s上对于不通过驱动程序获得 Ring0 权限的方式， 微软偏向于把此当作安全漏洞 处理，例如上文中关于 DevicePhysicalMemory 对象与 NtSetLdtEntries 函数 的例子。因此，为了保证程序对各个 Windows版本的兼容性，本程序采用了方案二。具体实现本软件将所有有关系统核的操作放入了核心态驱动模块 GlobalHook.sys 中 并通过 Windows服务管理器加载驱动模块。2.1.2 接管 API 函数背景.1Windows NT 的系统架构WindowsN T采用了微核架构，核只提供对操作系统绝对必要的功能，而把其

29、 它属于传统操作系统核的部分的功能留给用户态进程实现。 用户程序与系统进程 间是一种客户端 / 服务器的关系，用户程序将请求的操作发送给服务器进程，服 务器进程完成操作后再将结果发送回用户程序。用户程序子系统 DLLEnvironment subsystems POSIX 子系统OS/2 子系统(posix.exe)(os2ss.exe)Win32 子系统 (csrss.exe)Integral subsystems 本地安全认 证 (lsass.exe)ntdll.dll用户态 (Ring3)核心态 (Ring0)Kernel32.dll对象IO电源缓存进程/内存LPC执安全引用监管理管理管

30、理管理线程管管理机制行视器器器器器理器器体ntoskrnl.exe内核Hal.dll 硬件抽象层硬件图 2.3 Windows NT 的系统架构 （Windows NT 4.0 之前的版本 ）Windows NT中的服务器进程被称作子系统。 Windows NT 中有两种子系统：Integral subsystems 和 Environment subsystems 。Integral subsystems 用于完成基本的操作系统任务，如本地安全认证进程 lsass.exe 。 Environment subsystems 则相当于模拟程序，使得在 Windows NT 能兼容不同的 API。

31、POSIX子系统提供符合 POSIX 1003.1 标准的 API 。OS/2子系统能运行 OS/2 应用程序。Win32子系统实现了 GDI、窗口管理器（ User）、控制台（ Console ）API、错 误报告机制等功能。由于系统核并不完成实际的操作，而仅将操作发送给服务器进程进行处理， 因此需要在用户程序与服务器进程间建立起一种强大的消息传递机制。在 Windows NT上承担这一任务的是 LPC（本地过程调用） /RPC（远程过程调用）机 制。将操作交给服务器进程处理也带来了一些问题，如频繁的消息复制与进程空间切换会占用大量的 CPU时间。因此在 Windows NT 4.0 中，

32、Win32 子系统做了 大幅修改。用户程序Environment subsystemsIntegral subsyste 本 地 安 m全s 认证 lsass.exePOSIX 子系统(posix.exe)OS/2 子系统(os2ss.exe)子系统 DLLWin32 子系统User32.dll Kernel32.dll(csrss.exe)ntdll.dll用户态核心态win32k.sys(Ring0)ntoskrnl.exe (与较早版本相同)窗口管理器（ User ）GDI图 2.4 Windows NT 系统架构（ Windows NT 4.0 及后续的版本）Win32子系统中的 GD

33、I和窗口管理器被移入了核心态（控制台 API 等其余部 分保持不变），形成了一个新的核组件 Win32k.sys 。这些被频繁调用的组件 的移入， 使调用时不必进行进程空间切换和消息复制，提高了系统性能， 但核也 因此变得相对庞大， Windows NT不再被称作微核，而叫“混合核” 。另一个重要的变化是在 Windows XP及后续版本中，移除了 POSIX子系统与 OS/2子系统，其功能被 Windows Service for Unix 取代， Windows 2000成为最 后一个支持 POSIX与 OS/2 子系统的版本。.2 API 函数的调用路径根据 Windows

34、 NT的系统架构， API 函数的调用路径大致分以下三种（参见图 2.2 ）：(1) 用户程序子系统 DLL ntdll.dll ntoskrnl.exe(2) 用户程序 User32.dll/Gdi32.dllWin32k.sys(3) 用户程序子系统 DLL LPC机制服务器进程大部分 API 调用为第一种路径， ntdll.dll 中的函数完成了用户态到核心态 的权限切换，进入核。一部分 API调用(主要是 User和 GDI)为第二种路径， User32.dll 和 Gdi32.dll 中的函数完成权限切换， ntdll.dll 没有参与其中。 少 数 API 调用(如 Win32 子

35、系统实现的控制台 API)为第三种路径，其中有关 LPC 机制的函数位于 ntdll.dll 中。 方案比较.1 方案一：改变用户程序子系统 DLL的路径Windows动态的实现，依赖于可执行文件中的导入表与导出表。导入表中存 储了应用程序引用函数的 DLL文件名、 函数名与函数序号， 导出表存储了 DLL公 开函数的函数名、序号及函数地址。应用程序加载时系统执行的以下操作：(1) 将应用程序及相关 DLL载入存(2) 将应用程序导入表中的相关条目，根据 DLL 导出表中给出的函数地址， 替换为一条跳转指令，该跳转指令指向 DLL中对应的函数。应用程序进行调用操作时

36、，步骤如下(以 ExitProcess 函数为例)：(1)XXX.exe 中的 Main 过程通过 call ExitProcess 转到了 XXX.exe 中的同 名函数(该函数一身由编译器自动生成) 。(2)XXX.exe 中的 ExitProcess 函数简单的跳转到导入表中的 ExitProcess 条目。(3) 导入表中的 ExitProcess 条目已被 Windows替换为一条跳转指令，因此 会跳转到 Kernel32.dll 中的 ExitProcess 函数。(4) ExitProcess 函数执行完后，通过 ret 指令返回上一条 call 指令的位置， 即 XXX.exe

37、中 Main过程， API 调用完成。在上述的步骤中， 一共用到了 3 次跳转，改变任何一条跳转指令都可以达到 改变 API 调用路径的目的。 其中，因导入表位置较为固定，改变此处的跳转指令 最为容易。有关导入表的位置可以参考可执行文件格式的文档。目前， Windows中的“热补丁”使用了此技术，该项技术需要 Windows XP SP2/Windows Server 2003 或更高版本。磁盘XXX.exe导入表DLL 文件名 Kernel32.dll 函数名ExitProcess序号#N代码区导出表函数名ExitProcess序号 函数地址#NXXXXXXXXhKernel32.dll代码

38、区加载加载导出表函数名 ExitProcess序号 #N函数地址XXXXXXXhKernel32.dll代码区ExitProcess procExitProcess endpXXX.exe 的地址空间 （内存 ）XXX.exe导入表jmp XXXXXXXXh代码区Main proccall ExitProcessMain endpExitProcess procjmp ds:ZZZZZZZhExitProcess endp图 2.5 Windows 中动态的实现.2 方案二：直接修改目标函数上述两种方案都依靠了系统中已有的跳转指令并对其进行修改， 但如果一些 函数没有跳转指令怎么

39、办呢？没有跳转， 就要创造跳转。 此种方案首先通过导出表或系统服务分配表获取函数地址， 再将目标函数的前几条指令进行了替换。 因 此，修改后 API 函数的调用路径如下：ntoskrnl.exeKiSystemService/KiFastCallEntryMyDriver.sysTargetFunction proc;此处被覆盖为跳转指令jmp MyFunctionXXXXXXXXXh: instructionTargetFunction endpMyFunction proc;希望执行的操作;执行被覆盖的指令 ;跳回原函数， 继续执行jmp XXXXXXXXh MyFunction endp

40、图 2.6 修改后函数的执行路径目前， IceSword 使用了此种方法接管了系统中的部分函数，通过 Windows Debugger 可以观察到 IceSword 所做的修改。图 2.7 IceSword 运行前对 NtTerminateProcess 的反汇编结果图 2.8 IceSword 运行时对 NtTerminateProcess 的反汇编结果IceSword 通过修改 NtTerminateProcess 函数对自身进程进行了保护.3 方案三：改变用户态核心态权限切换处的路径用户程序调用子系统 DLL后，接下来就要让 ntdll.dll 或其它部件完成权限 的切换。

41、 Windows核导出了数几百个函数，若为每一个函数设置一个中断，显示 是不现实的。DOS中断通过向 AH寄存器中放入不同的值调用不同的功能。 Windows 采用了类似的方法，系统服务中断只有一个 (int 2Eh) ，但向 EAX寄存器中放入 不同的值，可以转到不同的核函数。以 Windows 2000 ntdll.dll中的 NtQuerySystemInformation 函数为例，反汇编的代码如下：ZwQuerySystemInformation proc neararg_0= dword ptr 4mov eax, 97h ; lea edx, esp+arg_0 int 2Eh

42、;将系统服务 ID 放入 EAX ; 将参数指针放入 EDX 调用系统服务中断retn 10hZwQuerySystemInformation endp随着 SSE指令集的加入， Windows XP及后续版本提供了除中断外第二种进 行权限切换的方式快速系统调用。该功能由 ntdll.dll 中的 KiFastSystemCall 函数通过 sysenter 指令实现，其反汇编代码如下 (Windows Server 2003 版本) ：KiFastSystemCall proc nearmov edx, espsysenterKiFastSystemCall endpint2EhKiSyst

43、emServicesys ent erKiFastCallEntry内核函数用户态核心态ntoskrnl.exe服务 ID函数地址XXXhXXXXXXXXh系统服务分配表服务 ID参数大小XXXhX(字节)系统服务参数表图 2.9 系统服务的分派ID 进行由于只提供了一个系统服务中断，在核的入口就必须通过系统服务 分派。系统中保存了两有关的表：系统服务分派表和系统服务参数表。系统服务分派表保存了服务 ID 与相应的函数地址。 系统服务参数表保存了服务 ID 与相应函数所需参数的大小。int 2Eh 中断的处理程序 KiSystemService 与快速系统调用的入口KiFastCallEntr

44、y 完成了以下操作：(1) 将函数的参从用户程序堆栈复制到核堆栈(2) 根据 EAX中的服务 ID 跳转到相应的核函数图 2.10 使用 Windows Debugger 可以观察到 API 函数调用的路径图 3.10 显示了 DeviceIoControl 函数的执行过程：Kernel32!DeviceIoControl ntdll!ZwDeviceIoControlFilentdll!KiFastSystemCallRet nt!KiFastCallEntry nt!NtDeviceIoControlFile不难发现，此处 API 函数调用又发生了一次跳转， 因此，只要修改系统服务 分配表

45、中的函数地址，就可以改变函数执行的路径。.4 各种方案的优劣比较及本程序采用的方法优点：可完全在用户态下实现，调试简单缺点：(1)Windows 进程的地址空间中高 2GB映射到同一存区域，为所有进程共享，保 存了核心态程序及关键的数据结构， 只有具有 Ring0的权限才能访问， 低 2GB为 每个进程所独有，没有权限限制(若系统启动时启用了 /3GB 选项，则共享空间 为 1GB，进程的专有地址空间为 3GB)。因为此方法在用户态下进行，所以所有的 修改只对某一进程有效。 如修改了 B.exe 中 Kernel32.dll 的 ExitProcess 函数， 则修改的函数只对

46、B.exe 有效，而 A.exe 及其它进程均无效。 对每一个进程都进 行一次修改，效率不高，也会影响系统的运行速度。(2)Windows 中调用 DLL 中的函数不仅可以直接使用导入表，也可以在程序运行 时使用 GetModuleHandle 与 GetProcAddress 函数动态获取函数地址。若木马程 序采用了 VB等默认采用此种方式调用 API 函数的语言，则可能出现漏报的情况。B.exe 专有A.exe 专有共享地物理地址空间地址空间址空间内存图 2.11 Windows 进程的地址空间部局优点：(1) 不依赖系统中已有的跳转指令，对任何函数，任何程序均适用(2) 此步骤为 API

47、 函数调用的最后一步，最为底层。缺点：(1) 同一函数的前几条指令可能会随着程序版本的更新发生变化，对“执行被覆 盖的指令”这一步提出了较高的要求。(2) 因 x86 指令是变长指令，在返回原函数时，一旦跳转的地址不正确，将引起 后续指令解释错误， 进而引起程序崩溃。 对被覆盖的指令相对于跳转指令多余的 部分，一般使用 nop 指令进行填充，但这样仍不能消除跳转失败的危险。“花指令”是 x86 指令的此项特性正面利用，通过在程序中加入跳转指令和 无用字节来防止程序被反汇编。优点：(1) 系统服务分派表在共享存区，对所有进程均有效(2) 仅服务 ID 对应的函数地址，不覆盖任何指令，不存在跳转失

48、败的危险缺点：每一次 Windows版本的更新，核都会增加新的函数， 服务 ID 也会相应发生变化， 因此需要对不同的 Windows版本进行不同的处理。综上所述，本程序采用了方案三实现行为监控。 具体实现.1 修改系统服务分派表修改系统服务分派表的目的在于将 API 函数调用引至驱动模块中自定义的函 数而非默认情况下系统核的函数。系统服务分派表的地址可以通过 ntoskrnl.exe 导出的变量 KeServiceDescriptiorTable 或线程 ETHREAD结构的 ServiceTable 获得。但两 处获取的结果却有所不同，因为 Win32k.sys

49、 仅为 GUI线程加载，所以所有有关 Win32k.sys 的操作都必须在 GUI 线程的地址空间中进行，否则将会因无效地址 引起蓝屏。本程序接管了部分 Win32k.sys 中的函数，需要通过 GUI线程 ETHREAD 结构的 ServiceTable 获取指针。与系统服务分派表有关的数据结构如下图所示：ETHREAD-ServiceTableKiArgumentTableNtAcceptConnectPortNtAccessCheckNtAccessCheckAndAuditAlarmNtAccessCheckByTypeNtOpenChannelNtReplyWaitSendChann

50、elNtSendWaitReplyChannelNtSetContextChannelNtYieldExecutionKiServiceTableSYSTEM_SERVIC E_TABLE ntoskrnl.exe ServiceTable CounterTable ServiceLimit ArgumentTable Win32k.sys ServiceTable CounterTable ServiceLimit ArgumentTable NULL ServiceTable CounterTable ServiceLimit ArgumentTable NULL ServiceTable

51、 CounterTable ServiceLimit ArgumentTable图 2.12 系统服务分派表有关的数据结构系统中共有 4 分派表，第一表负责 ntoskrnl.exe 中函数的分派，其服务 ID 围为 0h FFFh，第二表负责 Win32k.sys 函数的分派，服务 ID 的围为 1000h 1FFFh。SYSTEM_SERVICE_TAB结L构E的 ServiceTable 和ArgumentTable 分别指向一 个数组，以服务 ID 为索引，对应处即为相应函数的地址或参数大小。本程序接管的 API 函数可参考表 1.1 。.2 构建自己的 API 函数驱动

52、模块修改系统服务分派表成功后， 若某一程序再对已接管的 API 函数进 行调用， 将直接转到驱动模块指定的函数。 在指定的函数中， 驱动模块完成了以 下过程（如图 2.13 ）：用户程序调用收集信息是否是跨进程操作否是将信息发送给用户态程序允许操作阻止操作图 2.13 指定函数的工作流程(1) 收集发起操作的进程和目标进程的信息(2) 将收集的信息发送到用户态的程序(3) 阻塞当前线程，等待用户态程序规则匹配的结果(4) 根据结果决定执行此操作或阻止此操作下面以 NtUserMessageCall 函数为例进行说明。我们自己的 API 函数的定义最好与原 API函数相同，以便与系统服务参数表 中的参数大小一致。 NtUserMessageCall 函数的定义如下(其定义与用户态的 SendMessage稍有不同)：NtUserMessageCall proc hWnd:HANDLE,lngMessage:DWORD,wParam:DWORD,lParam:DWORD,xParam:DWORD,p Proc:PVOID,blnAnsi:BOOLhWnd：接收消息的窗口 ln