-
-
[原创]某内核注入型外挂样本原理分析。震惊！火绒惨遭利用，蓝洞或成最大输家。
-
发表于: 2018-7-27 11:14
-
近日，我们发现一款内核注入型的外挂，使用类似火绒dtrampo.dll的早期注入技术（相关源码见https://gitee.com/hzqst/FuckTP/blob/master/FuckTP/inject.c）。
该外挂在游戏还未创建窗口时就已经加载完成，注入时机非常早，并且只需要加载一次驱动后便不需要依赖外部EXE即可完成注入。
该外挂会生成两份驱动（随机名且无后缀名，其中一个驱动带签名，另一个不带签名）到”我的文档”下，并且如果当前系统没有安装火绒的话，还会加载一份火绒的驱动（sysdiag.sys）
该外挂首先以正常的sc start方式加载带签名的驱动
截至发布本文时该样本所用的签名尚未吊销，该公司全名为河南忆之东科技有限公司，搜索其备案域名可以发现如下信息：
根据域名和发帖内容猜测该公司有经营一些提卡售卡（卡盟）和支付相关的业务。
该驱动未加壳，但是使用了O-LLVM（https://github.com/Qrilee/llvm-obfuscator，https://blog.his.cat/a/vs_obfuscation.cat）编译，因此会在源码里插入很多无用分支。
InitAll上来会碰到很多OLLVM插入的无用分支，我们手动忽略
往下继续分析，碰到第一个样本行为是动态禁用PatchGuard
其中win7PG第一段是手动加载ntos内核并使用特征码搜索一些PachGuard的东西
大致就是搜索到PatchGuard的加密context并解密，然后修改其中的关键函数如ExQueueWorkItem为空函数，然后再加密回去。相关的代码如下，这里不细讲。
然后是禁用win10的PatchGuard：
基本就是抄的https://github.com/killvxk/DisableWin10PatchguardPoc，这里也不细讲了。
需要注意的是他只处理了pool内存中的pgcontext，没有处理MmAllocateIndependentPages分配的内存，可能有几率导致蓝屏。
然后接下来该样本以手动map方式加载自身sys：
核心在于调用MmCreateSection和MmMapViewInSystemSpace，将一片可读可写可执行的虚拟内存映射到驱动所在的地址空间附近，效果类似于在ring3使用CreateFileMapping+MapViewOfFile映射一片内存，然后该样本自己完成节表的重定位、修复导入表等工作，最终在常规驱动所在的地址空间中得到一片可读可写可执行的内存，里面是手动加载的新的样本驱动，用PsLoadedModuleList链表无法枚举到，并且没有驱动对象。
手动加载的新驱动会劫持Null设备的fastio接口，让其跟R3程序通信。
特征码为0F B6 D0 48 8B BC 0B 28 04 00 00，在火绒的sysdiag.sys驱动中可以直接搜索到
跳板的模板如下：
跳板2：
FFFFF88003446FC0即是回调地址，可以看到回调确实处于常规驱动所在的空间附近：
回调地址由这里填充：
至此初始化全部完成，可以启动游戏。
游戏启动阶段，系统调用火绒的镜像回调时就会进入该样本的镜像回调。回调行为如下：
注入原理基本类似于火绒早期注入
（https://gitee.com/hzqst/FuckTP/blob/master/FuckTP/inject.c 和 https://www.cnblogs.com/yifi/p/6389251.html）
0、 使用OLLVM编译驱动加入很多混淆代码和无用分支干扰分析。
1、 利用MmCreateSection+MmMapViewInSystemSpace将自己映射到驱动空间，而不用使用pool内存，防止自己被Battleye扫描pool内存扫到。
2、 劫持null设备的fastio派遣函数与R3程序通信。
3、 劫持火绒镜像回调，获得早期注入时机。
4、 禁用PatchGuard，不过似乎在该样本中没有意义（不需要）。
0x02 分析
InitAll上来会碰到很多OLLVM插入的无用分支，我们手动忽略
往下继续分析，碰到第一个样本行为是动态禁用PatchGuard
其中win7PG第一段是手动加载ntos内核并使用特征码搜索一些PachGuard的东西
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
Tennn
无非是姿势不到位
