↓然后用ZwQuerySystemInformation功能号11 SystemModuleInformation枚举驱动找到Fs_Rec.sys驱动,并返回他的ImageBase
再取到Fs_Rec的驱动对象,将其IRP_MJ_CREATE、IRP_MJ_CLOSE和IRP_MJ_DEVICE_CONTROL三个IRP派遣函数保存进g_Context并替换为自己往fs_rec.sys驱动Image空间中写入的代码MyCode,这个MyCode怎么来的下面会讲。
在
RegisterProcessObCallback(1, routine);
中将其安装为进程Ob回调
同理mov rax, CreateProcessNotifyRoutine和
mov rax, LoadImageNotifyRoutine
也被安装
这两个回调的功能分别是:
根据游戏进程名 保存游戏进程的EPROCESS,进程名由某个IOCTL指定。
根据游戏进程名
备份游戏进程的页表(为后面读写CF内存做准备)
同理,DispatchIrp派遣函数的模板也被复制到pool并用mov rax的形式设置为Fs_Rec驱动对象的真实派遣函数
此时fs_rec.sys的.text段起始地址的代码如下:
mov rax, pool内存中的进程OB回调
jmp rax
jmp rax, pool内存中的进程创建回调
jmp rax
jmp rax, pool内存中的线程创建回调
jmp rax
jmp rax, pool内存中的DispatchIrp派遣函数
jmp rax
至此该驱动样本初始化完成,固定返回错误码0xC0000001强行加载失败,以让其被系统自动卸载。
下面简要分析该样本DispatchIrp派遣函数中的内容:
首先判断访问该派遣函数的设备对象是否是我们刚才创建的\Device\iubesks设备对象,如果不是,根据MajorFunction调用g_pContext->中对应的原始函数,如FsRecDisptchCreate 、
FsRecDisptchClose、
FsRecDisptchIOCTL
并且如果MajorFunction不是IRP_MJ_DEVICE_CONTROL则直接返回成功并完成该IRP
再根据不同的Parameters.DeviceIoControl.IoControlCode执行不同的操作
如:
IoControlCode=0x223BD8,执行g_pContext->MouseServiceCallback模拟鼠标操作
如:IoControlCode= 0x223BE4 ,保存用户传来的进程名到自己分配的pool内存中并存到g_pContext->process_name中
如:
IoControlCode=
0x223BE0 0x223BF4,则遍历进程的Wow64Peb->Ldr查找指定模块的ImageBase和ImageSize,具体代码如下
IoControlCode=
0x223BE8,使用KeStackAttachProcess+MDL方式跨进程读写内存(这里其实不用MDL也可以,直接memcpy就行了)
IoControlCode=
0x223BFC 绕过CF/DNF PageFault内存保护使用自己备份的页表读写内存
这里和上面正常读写方法唯一的区别就是使用了自己在LoadImage回调中备份的页表
IoControlCode=
0x223BF8,设置保护进程,打开被保护的进程时在我们刚才安装的进程OB回调中会被摘掉VM_READ VM_WRITE等权限,使其无法被(两年前的)CF游戏进程读取内存,以避开内存特征扫描
样本总结:
1、利用DriverEntry返回失败的STATUS码来让系统自动卸载,免去了sc stop / ZwUnloadDriver的麻烦。
2、把代码放在pool内存中以达到(游戏运行期间)无驱动(也就是内存加载)的效果
3、把各个回调入口放到了fs_rec.sys的.text可执行段中,使其在ARK工具中不易被发现,还可以躲过ntos的guardcall检查
4、自建设备对象让其可以被应用层的程序正常打开其符号链接并进行交互
5、备份了CF游戏进程的页表使其可以正常读写CF的游戏内存
6、进程OB回调保护自己的wg程序不被内存特征扫描
至此样本全部分析完毕,具体的样本利用代码这里就不放了,样本我已经放出来了,有兴趣的读者可以自己逆一下。