【梅哥的Ring0湿润插入教程】
Email:mlkui@163.com 转载请注明出处，谢绝喷子记者等，如引起各类不适请自觉滚J8蛋！
番外篇四：抓取盛大GPK驱动保护文件及简略逆向
【湿润前言】
随着驱动保护技术的逐步成熟，诸如网络游戏公司等越来越多的商业软件公司开始使用Ring0级保护技术保护自己的产品，以起到反用户级调试、反RootKit、反各类钩子、反各类远程注入等作用。目前，使用驱动保护技术的代表产品主要有上海盛大网络发展有限公司开发的GPK（Game Protect Kit）、深圳市腾讯计算机系统有限公司开发的TenSafe及韩国neople棒子公司开发的nProtect等。显然，进入到Ring0级进行某些操作是应对这些驱动保护技术的较好办法之一，而运行于核心态即Ring0级的Windows设备驱动程序则可以说是进入到Ring0的唯一方法。
微软在其WDK，即所谓Windows Driver Kit的官方文档《Getting Started with the Windows Driver Development Environment》一文中开篇指出：“Even for experienced developers, getting started with Windows® device drivers can be difficult. You have a new programming model to learn and a new set of tools for building and debugging”。
正如上文所述，Windows内核编程与Win32编程区别较大，其调试方法也与Win32下的调试方法有极大不同；同时，Ring0级的反汇编与Ring3反汇编环境也有不小的差异；而大量计算机专业从业人员在没有点拨的情况下也难以意识到内核编程化御姐为萝莉、化少年为怪蜀黍的威力（以下省略一万字）。正是出于以上及其他的各种原因，梅哥将在学习Windows内核编程的同时写下本系列的Ring0湿润插入大法，旨在分享Windows内核编程经验、并说明Windows内核编程在绕过/破解商业驱动保护软件中的重要地位和神奇作用！
好了，下面就抛开用户级的桎梏，跟梅哥一起开始深入Ring0的湿润之旅吧~
============================我是湿润的昏割线=============================
【为什么获得驱动文件】
目前，几乎所有的商业驱动保护全部采取了释放.sys文件、加载驱动、然后立即删除.sys文件的方法，例如盛大公司GPK就在其驱动加载后删除了名为1394hub.sys的驱动文件，而提示“文件不存在”，如图所示：
显然，为了得知其驱动保护机制而对1394hub.sys进行逆向分析是必须的，因而我们首先必须获得该文件。
【获得驱动的错误做法】
首先，试图使用工具从内存中dump出.sys文件的做法是不可取甚至是错误的，如图所示：
我们注意到所dump出的1394hub.sys文件大小为560KB：
众所周知，出于内存资源利用率的考虑，所有Windows驱动程序的入口函数DriverEntry均被链接在PE文件的INIT区段中。所谓INIT区段即该区段的代码在加载之后立即执行，然后即将本区段从进程虚拟地址空间中删除。这样，我们也就知道直接利用工具从内存中dump出的驱动文件是不完整的，至少缺少了关键的DriverEntry函数。例如，在对560KB大小的1394hub.sys进行静态反汇编即可发现如图所示的现象：
【如何获得驱动文件】
思路：利用Ring3调试器加载被保护游戏进程，在其释放1394hub.sys后断下，进而得到该文件。
前戏脱衣：毫无悬念，被保护的游戏客户端主程序被加壳，其原始大小为，如图所示：
使用PEID查壳为著名的ASProtect：
进一步使用ASProtect专用查壳插件可知为：
为调试代码，首先脱去该程序的壳（对于如何脱壳已经超过了本文的范围，飘过），被扒光后的程序大小为：
PEID可见为VC2005开发：
尝试一：单步调试，使用FileMon等文件监视工具监视文件创建（失败）
事实证明，GPK在启动前通过某种手段对系统中存在进程等进行了扫描，一旦检测到打开了FileMon文件监视工具，则立即对机器进行了粗暴的重启动作（WinXP、Win2003直接重启，Win7直接卡死）。
当然，这也就从侧面提示我们，可在GPK驱动加载前慢慢调试，逐渐跟到GPK的“黑名单”所在！
尝试二：对CreateFile下断点，在创建1394hub.sys时断下（小成功）
显然，无论采用了何种压缩/加密/释放手段，总是必须通过CreateFile的Win32 API创建文件，则对其下断点即可跟踪到1394hub.sys的创建；在这个过程中，还可以看到GPK释放其他关键文件的信息，如下图所示：
当然，之所以称下CreateFile断点是小成功是由于创建后的1394hub.sys为大小为零的空文件，后续还需要继续跟踪才能找到写入内容后的1394hub.sys。
尝试三：对OpenSCManager、CreateService下断点，在驱动加载时断下（中成功）
显然，在加载驱动前，驱动文件必然已经完全解压完成并存储在硬盘上。因而，如果能在驱动加载前将其断下，即可得到完整的驱动文件。一开始，我以为GPK使用了诸如Kernel PE Load等高级驱动加载手段，然而在尝试性地对OpenSCManager及CreateService下断后竟然发现GPK使用了传统的加载手段，如图所示：
当此时程序被断下后，我们可以在相应目录下找到加载前的驱动程序1394hub.sys，其大小为565KB，大于直接内存dump得到的560KB文件，其反汇编代码不再粘贴。
尝试四：对DeleteFile下断点（G点）
既然在驱动加载后文件被删除，那么在文件被删除前将其断下即可，如图所示：
（囧，加载了一次就不再加载了，懒得重启了，图略了）
）【GPK启动过程简略逆向】
客户端首先加载动态链接库GPKitCtl.dll，之后调用GPKitCtl.#1进行了某些处理，而后由GPK接管了进程执行。GPK联网检查更新，释放出名为itt.dll的模块，由其完成GPK驱动的更新及加载动作。在更新动作中，GPK对其自身9个关键文件进行了更新及验证，具体是AutoUpdate.dll、fuc.A、GOL.S、GPE.E、GPU.dll、gt.dll、it.dll、Sddyn01.dll、Splash.jpg。其中，GPK对几乎所有dll采取了加壳处理，对各种莫名其妙的.A、.S、.E采取了未知的加密 --！
暂留以后继续被深入，你懂的。
============================我是湿润的昏割线=============================
XXXX界的同学总是把脱壳放在首位看来并不无道理；
也许商业保护软件为了追求稳定性，而仍然选择了较为稳妥的驱动加载方法等——虽然其保护软件也越来越向Rootkit乃至流氓软件演变。