TX系列游戏驱动保护研究心得

最近时间有些多,一时对网络游戏的保护机制感兴趣了,来研究了一下,听说QQ系列的TesSafe.sys 有些强,于是拿来看看驱动都做了些什
么.以下是对DNF和QQffo(自由幻想)研究结果(xp sp2)
在网上找了些TesSafe的资料,说TesSafe并不怎么样
现在这个版本保护的结果为:任务管理器中可以看到游戏进程,但OD和CE看不见,更不用说什么调试了,iceword可以 看到EPROCSS,但WSysCheck看
不见,自己写程序,也不能注入受保护的游戏进程.

可见,NtOpenProcess被Hook了,恢复SSDT后,没有任何效果,可见是inline hook ,

用一般的软件检测一下,没有发现inline hook,看来hook得比较深,在网上一找资料才发现,原来的确够隐藏的
以下是上一个TesSafe版本的分析结果

从网上找出来的资料,TesSafe.sys保护原理(DNF的保护,我听说,QQ系列游戏的保护机制都是一样的)

=================================================================

保护得比较没有意思,强度也不高.可能隐藏性稍好一些.

用IDA反汇编TesSafe.sys可以看到：

这个驱动一加载，ExAllocPoolWithTag分配了一块内存，然后将一个函数写进这块内存，接着做好保护，然后 PsCreateSystemThread()创建的
线程调用ZwUnloadDriver将驱动卸载。虽

然驱动被卸载了，但是ExAllocPoolWithTag分配的内存仍然在起作用。

具体来看它如何进行保护：
先是得到了ObOpenObjectByPointer的地址，然后在 NtOpenProcess中搜索0xe8 ，也就是跳转指令，直到遇见RET为止。
一但得到0xe8，比较后面的四个字节，如果转换后为 ObOpenObjectByPointer的地址,就把这个地址用自己代理函数的地址转换后替换掉，达到
保护自己的目的。
用WinDbg看了看，果然在我的机器上:0x80570e41这个在 NtOpenProcess中的区域被TesSafe.sys修改,原来这里是:80570e41 e87c8dffff   
call nt!ObOpenObjectByPointer (80569bc2)
系统通过ObOpenObjectByPointer来通过 EPROCESS得到Handle返回给调用者。TENCENT在这里下了一个跳转：（TesSafe.sys加载后。）80570e41
e826542a78    call f881626c
很明显，系统执行到这里就会调用0x6881626c的函数，也就是 TesSafe.sys的
ObOpenObjectByPointer代理函数。这 样，Client.exe就会在这里被过滤掉，从而让R3程序无法得到QQT的句柄，从而保护进程。
=================================================================================

我手头拿到的版本是2008年8月5号的,把TesSafe逆出来一看,比上个版本有所加强.
在这个新版本中,TesSafe一共InLine Hook了六个函数,我只逆出并恢复了五个
其中:

1.

KeAttachProcess

NtOpenProcess

NtOpenThread

这三个函数的HOOK方式与上一个版本一样,就是上面蓝色字体的方法,把本应该call ObOpenObjectByPointe的代码修改成了call他自己的代码,
然后在他自己的代码中处理保护的进程

上面三个函数,原来正常的代码为

80581ce3 e8a658ffff      call    nt!ObOpenObjectByPointer (8057758e)
被HOOK后的代码变成了

call a8724af4(TesSafe自己搞出来的函数)
lkd> u a8724af4 a8724af4+110

a8724af4 8b450c          mov     eax,dword ptr [ebp+0Ch]

a8724af7 55              push    ebp

a8724af8 8bec            mov     ebp,esp

a8724afa 81ec00010000    sub     esp,100h

...

往下找,

a8724bc6 ff25409372a8    jmp     dword ptr ds:[0A8729340h] ;ObOpenObjectByPointer

可以找到跳到ObOpenObjectByPointer的代码
我先偿试着直接用WinDbg把80581ce3 call a8724af4后面的值给修改回来,可是一修改回来就蓝屏,不知道什么原因,搞不清楚.

于是没办法,我用另一种方法,直接在HOOK函数的入口点a8724af4修改为jmp ObOpenObjectByPointer,这样就成功恢复了,没有蓝屏

用这种方法把以上三个函数全恢复了
2.

NtWriteVirtualMemory

NtReadVirtualMemory

这两个函数被TesSafe把头几个字节HOOK了

lkd> u 805878d0 805878d0+180 ;NtWriteVirtualMemory

805878d0 b89e9707a9      mov     eax,0A907979Eh

805878d5 ffe0            jmp     eax

805878d7 e8a7c5f5ff      call    nt!CIsqrt+0x2d7 (804e3e83)

805878dc 64a124010000    mov     eax,dword ptr fs:[00000124h]

上面这是NtWriteVirtualMemory的代码,头几个字节被修改了,直接恢复之就OK了,
上面inline hook的函数一共六个,我只恢复了五个,另一个函数不知道是什么,没弄出来

3.

在驱动中TesSafe还用了以下三个函数

PsSetCreateProcessNotifyRoutine

PsSetCreateThreadNotifyRoutine

PsSetLoadImageNotifyRoutine
可见,他设置了进程,线程创建和加载模块的回调函数,这几个函数设置的回调函数,不容易去除,我只能把
PspCreateProcessNotifyRoutine,PspCreateThreadNotifyRoutine,PspLoadImageNotifyRoutine 表全部清空,


分析结果:

经过我以上的处理,ce可以对进程进程读写操作,但不能附加调试,会失败,

OD可以附加上去,可以读写内存,可以暂停程序,但还是不能调试,表现为暂停后,游戏程序就会出错

看来TesSafe这次吸收了以前的教训了,下了狠工夫,太烂了,HOOK这么多函数
至于为什么不能调试,有可能是还有一个函数我没有恢复的原因吧,我也没那么 多时间去研究了

总体来说,他次的保护做得还可以,但就不知道他的ring3保护做得如何了,我只分析了一下驱动,没有分析他的游戏进程,

如果游戏进程中没有做好保护,驱动保护就等同于摆设,


PspCreateProcessNotifyRoutine,PspCreateThreadNotifyRoutine,PspLoadImageNotifyRoutine 表全部清空代码如下:

其它的恢复代码都很简单,就不放出来了

RtlInitUnicodeString(&name,L"PsSetCreateProcessNotifyRoutine");

RemoveNotifyRoutine((PVOID)MmGetSystemRoutineAddress(&name));
RtlInitUnicodeString(&name,L"PsRemoveCreateThreadNotifyRoutine");

RemoveNotifyRoutine((PVOID)MmGetSystemRoutineAddress(&name));
RtlInitUnicodeString(&name,L"PsRemoveLoadImageNotifyRoutine");

RemoveNotifyRoutine((PVOID)MmGetSystemRoutineAddress(&name));
__declspec(naked) void DisableWPBitAndCli()

{

__asm

{

cli

mov     eax, cr0

and     eax, 0xFFFEFFFF

mov     cr0, eax

retn

}

}
__declspec(naked) void EnableWPBitAndSti()

{

__asm

{

mov eax, cr0

or eax, 0x10000

mov cr0, eax

sti

retn

}

}

NTSTATUS

MydrvDispatch (

IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp

)

{

Irp->IoStatus.Status = STATUS_SUCCESS;

Irp->IoStatus.Information = 0L;

IoCompleteRequest( Irp, 0 );

return Irp->IoStatus.Status;

}
/*

NTSTATUS RemoveNotifyRoutine(PVOID RemoveFunPointer)
can remove all of the Routine of CreateThread and CreateProcess and LoadImage

注意传入参数为下面三者之一

PsSetCreateProcessNotifyRoutine

PsRemoveCreateThreadNotifyRoutine

PsRemoveLoadImageNotifyRoutine

===========

by xp sp2

*/

NTSTATUS RemoveNotifyRoutine(PVOID RemoveFunPointer)

{

ULONG AddrFun;

ULONG* pRoutineList;

ULONG i;
pRoutineList = 0;

AddrFun = (ULONG)RemoveFunPointer;

DbgPrint("RemoveNotifyRoutine = %08X\n",RemoveFunPointer);

//

//the RemoveFunPointer could

//only be PsRemoveLoadImageNotifyRoutine

//or PsSetCreateProcessNotifyRoutine

//or PsRemoveCreateThreadNotifyRoutine

//find code bf 00975680      mov     edi,offset nt!PsThreadType+0x44 (80569700)

//

for(i = AddrFun;i<AddrFun + 0x20;i++)

{

if( 0xbf == *(PBYTE)i )

{

i++;

pRoutineList = (ULONG*)( *(ULONG*)i );

break;
   }

}
if( 0 == pRoutineList)

{

DbgPrint("Can not find the RoutineList\n");

return STATUS_UNSUCCESSFUL;

}



if( TRUE != MmIsAddressValid((PVOID)pRoutineList) )// memory is valid

{

DbgPrint("Access Memory is not Valid %08X\n",pRoutineList);

return STATUS_UNSUCCESSFUL;

}



//

//Zero the PspCreateThreadNotifyRoutine;

//

DisableWPBitAndCli();

for(i=0;i<8;i++) //这里写成0x40也没有问题,我看他这个表应该长度为0x40,但网上说PspCreateProcessNotifyRoutine表长
度在win2K下为8,xp下为多少,我没有找到资料,懒得去分析代码找出他的长度

{

//if( 0 == pRoutineList )break;

pRoutineList = 0;//清空

}

EnableWPBitAndSti();
DbgPrint("RemoveNotifyRoutine STATUS_SUCCESS %08X\n",RemoveFunPointer);

return STATUS_SUCCESS;

}

很不错