第42章 内核6中的会话
本文最后更新于：2022年5月27日 下午
第42章内核6中的会话
Windows OS Kernel 6（Vista、7、8等）开始采用一种新的“会话”（Session）管理机制，本
章将学习这方面的内容。
如果你是一个Windows应用程序开发者，那么有可能遇到过以下问题：一个在XP中运行良好的服务程序在Vista或7中无法正常运行^这些服务程序主要是与用户存在交互行为的程序。也就是说，一个以服务形式运行的应用程序中，显示用户对话框或尝试在用户程序与服务程序之间通信时，无法像在XP中一样正常运行。这些问题实际上都是由Kernel6中使用的会话管理机制引起的。从程序的开发角度看，了解Kernel6中这种会话管理机制的改变是十分必要的；从代码逆向分析角度看，会话机制的改变是也个相当重要的事件。因为这意味着原先使用的通过CreateRemoteThread()API进行DLL注入的方法不再适用于Kernel 6中的服务进程（对一般进程仍然适用）。
42.1会话
简单地说，会话指的是登录后的用户环境。大部分OS允许多个用户同时登录，并为每个登录的用户提供独立的用户环境。以Windows操作系统为例，“切换用户”可以创建本地用户会话， “远程桌面连接”可以创建远程用户会话。在Process Explorer的View菜单中选择“ Select-Columns-Session”后，即可显示当前运行进程所属的会话（参考图42-1）。
为了查看当前会话，使用“切换用户”功能同时登录2个用户。会话的ID（0、1、2、…）是根据登录顺序确定的。图42-2显示岀Windows 7中正在运行的进程及其所属会话。接下来查看Windows XP中正在运行的进程及其所属会话。
用户登录系统后，系统默认为相应会话创建csrss.exe、winlogon.exe、explorer.exe进程。
Windows 7（图42-2）与Windows XP（图42-3）有1个非常大的不同。两个操作系统中都登录了2个用户，但Windows 7中共有3个会话（0、1、2），而Windows XP中只有2个会话（0、1）。无 论Windows XP还是Windows 7,系统进程与服务进程都在ID为0的会话（系统会话）中运行。二 者差别在于，第一个登录的用户的会话ID是不同的。Windows XP中，第一个登录系统的用户的会话ID为0;而Windows 7中，第一个登录系统的用户的会话ID为1，非系统会话。这种细微的差别使在XP系统中可以使用的技术在Windows 7中无法正常使用。请注意，上述测试中我计算机的UAC（用户账户控制）处于关闭状态，如图42-3所示。
42.2会话隔离机制
从Windows内核版本6开始，为进一步增强系统安全性，第一个登录系统的用户会话ID被设为1，使之与系统会话（ID: 0）区分。分离系统会话与用户会话就取消了它们之间的相互作用，采用这种机制虽然可能引起向下兼容的问题，但能够大大增强系统安全性。微软把这种机制称为会话0隔离机制（Session 0 Isolation）。
关于会话0隔离机制在Windows Team Blog中有非常详细的说明，感兴趣的读者可以进入下面地址学习。
http://windowsteamblog.com/blogs/developers/archive/2009/10/01/session-0-isolation.aspx
42.3 增强安全性
前面介绍的会话0隔离机制以及上一章中讲解的ASLR技术都是为增强系统安全性而增加的功能。虽然用心良苦，但它们能否有效增强系统安全性仍有待商榷。由于会话0中的进程并未完全实现分离，所以会话1中的进程（如：Process Explorer）可以强行终止会话0中的进程，并且ReadProcessMemory()、WriteProcessMemory()、VirtualAllocEx()等调试API也能正常运行（可以轻松绕开ASLR技术）。无论如何，借助微软的这些新增技术，目前尚能拦截过去常见的一些黑客攻击行为。然而随着逆向技术的不断发展，相信会有更高级、更新的针对它们的攻击技术出现。这是一场无休止的“矛”与“盾”的战争。
这场无休止的“矛”与“盾”的战争中，“盾”方（微软）始终处于不利地位，因为他们要考虑到方方面面，既要提供良好的支持，保证各种应用程序正常运行；又要考虑向下兼容性，为用户提供便利。此外还要考虑对大量硬件提供支持，保证系统能够在大量PC上正常运行。由于系统的用户数量非常多，“矛”方（黑客）只要从中选取微软Windows的部分用户（如：MS XP SP3 IE 8用户）进行攻击就能获得好的攻击效果。以战争来比喻，攻击方只要选取一个地方集中力量攻击就能获得较为有利的局面，防守方却会因战线太长、需要守卫的地方过多而筋疲力竭、力不从心。
为了应对这种会话管理机制的变化，我们将在下一章学习新的DLL注入方法，借助新方法可以很好地克服会话管理机制变化对DLL注入造成的不利影响。