最近讨论游戏保护的帖子又见增多, 正好我以前逆过HS, 抠出点东西来跟大家分享下
今天也是我接触驱动, 逆向这一块整整一周年, 写个帖子聊表纪念
论坛上这方面帖子大多都是写的如何跳过驱动层的hook点来达到过保护的目的
再聊这些东西也没什么意思, 我就爆料一些HS内部的处理的细节吧
这里面有很多很好的安全编程方法值得我们借鉴和学习, 大家有时间的话可以拖到IDA中看一下,
比起写个驱动在内核跳来跳去, 学习到一些实用的编程技巧对自身的成长是大有益处的
写这篇帖子的时候我的电脑中并没有装带有HS保护的游戏,
所以下面讨论的内容全部根据以前逆向时留下的笔记和回忆来总结的,
所以具体的细节上可能与实际有所出入
这里的讨论的HS版本全部都是去年11月份左右的版本, 应该是5.5.xxx
而我最后一次玩某游戏好像版本有了小幅度的更新
HS也是通过一系列的内核HOOK来达到保护游戏目的的, 主要有以下这些<部分函数只是存在于驱动中, 实际并没有被使用>:
SSDT hook:
1.NtReadVirtualMemory
2.NtWriteVirtualMemory
3.NtOpenProcess
4.NtSuspendProcess
5.NtTerminateThread
引用到的结构如下:
// SSDT hook 函数相关结构
typedef struct _SSDTHookInfo{
ULONG SSDTNAME; // 函数名称, 对应一个加密后的字串地址
ULONG SSDTINDEX; // 函数索引
ULONG ProxyAddress; // 代理函数地址
ULONG PreValue; // hook前地址
ULONG PrevBeenHooked; // 该函数是否被别人hook
ULONG someflag; // 标志
}SSDTHookInfo; //+0x18大小
SSDT Inline hook:
1 KeAttachProcess //4
2 KiAttachProcess //4
3 NtDeviceIoControlFile //4
4 NtClose //4
5 IopXxxControlFile //4
6 NtOpenProcess //4
7 NtReadProcessMemory //4
8 NtWriteProcessMemory //4
9 PsSuspendThread //4
10 NtTerminateThread //4
11 unknow
12 NtSetContextThread //4
13 NtGetContextThread //4
14 NtQueryPerformanceCounter //2
15 NtGetContextThread_End //4
引用到的结构如下:
// inline hook 函数相关的结构
typedef struct _SSDTInlineHookInfo{
ULONG FunctionName; //函数名字串指针
ULONG FunctionRVA; //+0X04 函数距离模块基址RVA
ULONG HookOffsetFromFunction; //+0X08 HOOK处距离函数头偏移
ULONG HookAddress; //+0X0C HOOK线性地址
ULONG JmpCodeAddress; //+0X10 JmpCodeBuffer [0x18大小], 要跳转到的中间跳缓冲地址
BOOLEAN ProxySwitchOn; //+0X14 过滤是否启用
BOOLEAN unknow;
LARGE_INTEGER OriginalData; //+0X18 原始值
ULONG Flag; //+0X20 一些标志
ULONG unknow; //+0X24
}SSDTInlineHookInfo; //size = 0x28
Shadow SSDT Hook:
0 NtUserQueryWindow 0x0
1 NtUserBuildHwndList 0x0
2 NtUserFindWindowEx 0x0
3 NtUserGetForegroundWindow 0x0
4 NtUserWindowFromPoint 0x0
5 NtGdiBitBlt 0x20000
6 NtGdiStretchBlt 0x20000
7 NtGdiMaskBlt 0x20000
8 NtGdiPlgBlt 0x20000
9 NtGdiTransparentBlt 0x20000
10 NtUserSendInput 0x20
11 NtUserGetDC 0x20000
12 NtUserGetDCEx 0x20000
13 NtUserGetWindowDC 0x20000
引用到的结构与SSDT Hook一样
Shadow SSDT Inline Hook:
NtGdiGetPixel 0x20000
unknown 0x20 <未使用>
引用到的结构如下:
typedef struct _ShadowSSDTInlineHookInfo{
ULONG FunctionName: // 函数名称字串指针
ULONG PreAddress; // 函数源地址
PVOID JmpCodeAddress; // 跳转指令的地址 这里的内存是分配的大小0x18 从这里跳到代理函数
BYTE IsHookInstalled; // Hook是否已经安装
BYTE UnknowA; // +0xD
USHORT Fill; // 间隙填充
UCHAR OldValue[8]; // 原始值
ULONG Flag; // 一些标志
ULONG UnknowB; // +0x1C
}ShadowSSDTInlineHookInfo;
涉及到Hook的结构就只有上面这些, hs在驱动内部小心地安装或卸载Hook然后配合对各种名单的过滤来实现对游戏的保护
对于名单这一块由于不少操作相关的函数都被vm掉, 所以只逆出来了很少一部分, 主要有一下几个名单:
// 进程白名单
typedef struct _ProcessWhiteList{
ListEntry ProcList; // 白名单链
ULONG Flag; // +0X08 标志<大多数情况下有4就代表存在>
ULONG UnknowA; // +0X0C 这里是个枚举 0 1 2
PEPROCESS eprocess; // +0x10 进程环境体
PWCHAR pProcName[20]; // +0x14 进程名
..
UCHAR // +56 是否打开过游戏进程标志
}ProcessWhiteList;
这个是个白名单的列表,列出了很多进程名称,如果有对应的存在 EPROCESS 域不是空的
这个结构数组是在初始化的时候就写定了, 全部内容如下:
进程白名单:
1. Name: patcher.exe
Flag: 00080004
Flag: 2
+56 :
2. Name: WerFault.exe
Flag: 00080004
Flag: 0
+56 :
3. Name: IAANTmon.exe
Flag: 00080000
Flag: 2
+56 :
4. Name: avp.exe
Flag: 00080000
Flag: 2
+56 :
5. Name: WmiApSrv.exe
Flag: 00080000
Flag: 2
+56 :
6. Name: xsync.exe
Flag: 00080000
Flag: 2
+56 :
7. Name: fssm32.exe
Flag: 00080000
Flag: 2
+56 :
8. Name: LGDCORE.exe
Flag: 00000020
Flag: 2
+56 :
9. Name: ACS.EXE
Flag: 00080000
Flag: 2
+56 :
10.Name: ITPYE.EXE
Flag: 00000020
Flag: 2
+56 :
11.Name: Joy2Key.exe
Flag: 00000020
Flag: 2
+56 :
12.Name: JOYTOKEYHIDE.EXE
Flag: 00000020
Flag: 2
+56 :
13.Name: JOYTOKEYKR.EXE
Flag: 00000020
Flag: 2
+56 :
14.Name: JOYTOKEY.EXE
Flag: 00000020
Flag: 2
+56 :
15.Name: DWM.EXE
Flag: 00080000
Flag: 0
+56 :
16.Name: WMIPRVSE.EXE
Flag: 00080000
Flag: 2
+56 :
17.Name: DK2.EXE
Flag: 00080000
Flag: 2
+56 :
18.Name: CSTRIKE-ONLINE.EXE
Flag: 00080000
Flag: 2
+56 :
19.Name: RAGII.EXE
Flag: 00080000
Flag: 2
+56 :
20.Name: EKRN.EXE
Flag: 00080000
Flag: 2
+56 :
21.Name: GOM.EXE
Flag: 00080000
Flag: 2
+56 :
22.Name: GAMEMON.DES
Flag: 00080000
Flag: 2
+56 :
23.Name: VAIOCAMERACAPTUREUTILITY.EXE
Flag: 00080000
Flag: 2
+56 :
24.Name: IPOINT.EXE
Flag: 00000020
Flag: 2
+56 :
25.Name: NMCOSRV.EXE
Flag: 00080004
Flag: 2
+56 :
26.Name: DEKARON.EXE
Flag: 00080000
Flag: 2
+56 :
27.Name: AUDIODG.EXE
Flag: 00080000
Flag: 0
+56 :
28.Name: NGM.EXE
Flag: 00080004
Flag: 2
+56 :
29.Name: TASKMGR.EXE
Flag: 00080004
Flag: 0
+56 :
30.Name: HGSCRAPEDITORHELPER.EXE
Flag: 00080004
Flag: 2
+56 :
31.Name: SETPOINT.EXE
Flag: 00000020
Flag: 2
+56 :
32.Name: NMSERVICE.EXE
Flag: 00080004
Flag: 2
+56 :
33.Name: NSVCAPPFLT.EXE
Flag: 00080000
Flag: 2
+56 :
34.Name: UPSHIFTMSGR.EXE
Flag: 00080004
Flag: 2
+56 :
35.Name: NOD32KRN.EXE
Flag: 00080000
Flag: 2
+56 :
36.Name: IMJPCMNT.EXE
Flag: 00080000
Flag: 2
+56 :
37.Name: TCSERVER.EXE
Flag: 00080000
Flag: 2
+56 :
38.Name: SPOOLSV.EXE
Flag: 00080000
Flag: 0
+56 :
39.Name: IEXPLORE.EXE
Flag: 000A0024
Flag: 2
+56 :
40.Name: EXPLORER.EXE
Flag: 000A0024
Flag: 1
+56 :
41.Name: WINLOGON.EXE
Flag: 000A0024
Flag: 0
+56 :
42.Name: SERVICES.EXE
Flag: 00080024
Flag: 0
+56 :
43.Name: CSRSS.EXE
Flag: 000A0024
Flag: 0
+56 :
44.Name: LSASS.EXE
Flag: 00080024
Flag: 0
+56 :
45.Name: SVCHOST.EXE
Flag: 00080024
Flag: 0
+56 : 1
// 进程黑名单
typedef struct _ProcessBlackList{
ListEntry list; // 进程链
ULONG ProcessId; // +0x08
ULONG Flag; // +0x0c
}ProcessBlackList;
这里的标记:4应该是代表有效 0代表无效
进程销毁之后在这里会断链
// 句柄名单
句柄名单是有三个的, 应该都是使用了同一种结构
typedef struct _HandleTable{
ListEntry list;
ULONG ProcessId; // +0x0x8
Handle FileHandle; // +0x0C
}HandleTable;
句柄名单应该是两个白名单一个黑名单, 不过内部没有找到很多对于这三个名单的引用,
最直接的是在NtDeviceIoControlFile相关的Hook流程上用来动态添加名单,
顺便说一下NtDeviceIoControlFile中是对ARK进行过滤检测用的<或者说这是一部分功能>,
具体的做法是根据NtDeviceIoControlFile的文件句柄取得文件对象, 进而得到设备对象, 驱动对象,
然后根据驱动对象就得到目标驱动模块的DispatchDeviceIoControl接口, 然后通过一些算法在一个名单中进行匹配,
依此来进行过滤
// 驱动名单
这个结构与一个全局的结构数组相关
该全局数组一共0x19大小,保存了部分驱动名称,初始化的时候填写这部分内容
typedef struct _DriverTable{
ULONG Flag: // 标志 一般都是4
DRIVEROBJECT DriverObject; // 驱动对应的驱动对象地址 使用到的时候才会更新
ULONG Index; // 索引序号
PWCHAR DriverName[0x40]; // 驱动名称
}DriverTable; // size = 0x4C
这个名单在未被VM的代码中没有见到被引用
// 下面这个是最重要的内部结构, 不过很多域都没有看到被引用, 可能是被VM掉了, 遗憾
typedef struct _Important{
ListEntry list;
FileObject fileobj; //+0x08
EPROCESS eprocess; //+0x0C 游戏主进程
ETHREAD ethread; //+0x10
ULONG //+0X14
ULONG //+0x18
ULONG //+0x1C
ULONG //+0x20 这里是一个标记 本进程是否还存在有效
ULONG flag; //+0x24 这里是个标记
ULONG //+0x28
ULONG //+0x2C
LARGE_INTEGER CpuCycleCount; //+0x30 cpu周期计数, 用作反调试
ULONG ProcId; //+0x38 主进程ID
HANDLE hThreads[3F]; //+0X3C 从这里到 0x130都是线程ID 保存了一些游戏主进程的线程ID
..
ULONG //+0x130
PWCHA //+0x13C
PIRP Irp; //+0x15C
.. //+0x160 貌似是个字串指针
.. //+x0164
PIRP Irp: //+0x168
.. //+0x16C
.. //+0x170
PIRP Irp; //+0x174
}Important;
还有几个与游戏线程相关的名单, 不过不怎么重要, 就不列出了
//*****************************************************************
下面说一下HS的过滤, 以进程相关的操作为例 open read write, 过滤步骤如下:
if (当前进程在黑名单中)
{
if (操作目标是要保护进程)
{
if (是游戏进程发起的操作)
{
从黑名单中移除自己;
放行;
}
else
{
拒绝访问;
}
}
else
{
放行
}
}
else
{
if (操作目标是要保护进程)
{
if (是游戏进程发起的操作)
{
放行;
}
else
{
if (当前进程在白名单中)
{
放行
}
else
{
加入黑名单;
拒绝访问;
}
}
}
else
{
放行
}
}
乍一看过滤方式够严密, 不过具体实施上却暴露出了一个大的漏洞,
因为在这一系列的操作中它都是进程ID来判断过滤的, 呵呵, 这样PID+1 +2 +3 就能简单地在三层绕过它了
当然这只针对NtOpenProcess可行, read write函数是传递的是进程句柄,
HS内部通过ZwQueryInformationProcess通过句柄得到进程ID来进行过滤
所以我们还是将自身进程添加到白名单中比较稳妥, 有了上面的白名单结构信息,
我们只需要随便跟踪hs的一个代理函数并找到名单的ListHead就OK了
另外一个重点是反调试这边了, 涉及到这方面的内核处理有:
KiAttachProcess inline Hook
NtSetContextThread inline hook
NtGetContextThread inline hook
PsSuspendThread inline hook <win7>
dpc例程
RING3层:
DbgBreakPoint 指令修改
DbgUiRemoteBreakin 指令修改
我所了解到的只有这些, 也可能还有别的地方, 内核inline Hook的几个函数大家都心知肚明, 不必多说
dpc例程主要用来获取CMOS中的时钟信息, CPU的时钟周期数, 然后进行一些运算, 应该是用来反内核调试用
关于dpc, 我的另一片帖子中有介绍: http://bbs.pediy.com/showthread.php?t=148135
另外RING3层的两个函数的修改也是很猥琐的, 我们在用OD附加到游戏上时会创建一个远程线程,
这个线程就是为了执行DbgBreakPoint而存在, 原来的DbgBreakPoint指令为 int 3 , retn
也就是执行一个中断指令以中断到调试器, 现在已经被修改为 retn, retn 直接返回了,
这样调试器就接收不到中断信号
另外一个DbgUiRemoteBreakin, 是执行DbgBreakPoint前的一个调用, 具体的作用我也没仔细研究,
不过看名称也是中断用的, hs会将这个函数头写入一个jmp, 直接跳转到LdrShutdownProcess,
LdrShutdownProcess将直接给每个已经加载的dll模块发消息, dll将被卸载
这样就导致了OD一加载, dll等模块就被卸载掉了
关于KiAttachProcess NtSetContextThread NtGetContextThread PsSuspendThread如何绕过,
这个是仁者见仁智者见智的了, 不过这几个代理函数中都有这样的指令序列:
最后的jz指令就跳转到原函数了, 呵呵, 这里就不言自明了吧
//*****************************************************************
hs内部的一套Hook框架很不错, 当初让我学到了很多东西, 受益匪浅, 在这里也跟大家分享下,
<这框架是我在hs框架基础上完善的>
// 用于索引
typedef enum _SSDTNameIndex{
ssdtZwCreateFile,
ssdtZwOpenFile,
MAX_SSDT_HOOK_ITEM_COUNT
}SSDTNameIndex;
#define SERVICE_NAME_LEN 64
typedef struct _SSDTHookInfo{
ULONG ServiceIndex; // ssdt索引
hintSSDTNameIndex Number; // 序号
PVOID RealAddress; // ssdt真实地址
PVOID PrevAddress; // hook ssdt之前地址
PVOID ProxyAddress; // 代理地址
ULONG ProxyBusyNow; // 正忙标志
BOOLEAN IsHookInstalled; // 是否安装了hook
BOOLEAN IsInUses; // 是否启用这个hook
WCHAR ServiceName[SERVICE_NAME_LEN]; // ssdt名称
}SSDTHookInfo, *PSSDTHookInfo, *PSSDTHOOKINFO;
NTSTATUS CollectSSDTInfo()
{
在这里初始化结构数组, 获取函数索引, 解析PE得到其真实地址等等
}
// 安装Hook
NTSTATUS SetupAllSSDTHook()
{
..
for ( i = 0; i < MAX_SSDT_HOOK_ITEM_COUNT; i++ ) // 遍历结构数组
{
pEntry = (PSSDTHookInfo)&g_SSDTHookItems[i];
if ( !pEntry ) continue;
if ( !pEntry->IsInUses ) continue; // 根据此标志启动这个函数Hook
if ( pEntry->IsHookInstalled ) continue; // is reinstall?
if ( !pEntry->RealAddress ) continue;
if ( pEntry->ServiceIndex > KeServiceDescriptorTable->ulNumberOfServices ) continue;
..进行Hook
pEntry->PrevAddress = OldAddress;
pEntru->IsHookInstalled = TRUE;
...
}
}
// 代理例程
NTSTATUS Proxy_ZwOpenFile()
{
..
pEntry = (PSSDTHookInfo)&g_SSDTHookItems[ssdtZwCreateFile]; // 取得对应项
InterlockedIncrement(&pEntry->ProxyBusyNow);
..过滤
InterlockedDecrement(&pEntry->ProxyBusyNow);
return status;
}
// 恢复Hook
NTSTATUS RestoreAllSSDTHook()
{
..
for ( i = 0; i < MAX_SSDT_HOOK_ITEM_COUNT; i++ )
{
pEntry = (PSSDTHookInfo)&g_SSDTHookItems[i];
if ( !pEntry ) continue;
if ( !pEntry->IsInUses ) continue;
if ( !pEntry->IsHookInstalled ) continue;
if ( !pEntry->RealAddress ) continue;
..取当前SSDT地址
if ( CurrentAddress == pEntry->ProxyAddress )
{
// 没有被别人恢复时, 恢复Hook
if ( MmIsAddressValid(pEntry->PrevAddress) )
{
..使用Hook之前地址恢复
}
else
{
..使用真实地址恢复
}
}
}
// 在这里等待所有代理函数都处理完毕 正常退出
for ( i = 0; i < MAX_SSDT_HOOK_ITEM_COUNT; i++ )
{
pEntry = (PSSDTHookInfo)&g_SSDTHookItems[i];
if ( !pEntry->IsInUses ) continue;
if ( pEntry->ProxyBusyNow > 0 )
{
DueTime.QuadPart = 0;
KeInitializeTimerEx(&timer, SynchronizationTimer);
KeSetTimerEx(&timer, DueTime, 100, NULL);
for ( j = 0; j < 20; j++ )
{
KeWaitForSingleObject(&timer, Executive, KernelMode, FALSE, NULL);
if ( (LONG)pEntry->ProxyBusyNow <= 0 ) break;
}
KeCancelTimer(&timer);
}
pEntry->PrevAddress = NULL;
pEntry->IsHookInstalled = FALSE;
pEntry->ProxyBusyNow = 0;
}
}
inline hook的框架总结起来比较麻烦了, 大家就去看一下IDA数据库自己总结下吧~~
hs.rar
|
|
|---|---|
 |
|
 |
 前排支持~
|
 |
占一个
|
|
|
|
很精彩，比前些天那啥只放代码的帖子有趣多了
|
|
|
|
|
|
学习学习
|
 |
 前来膜拜，顺便学习
|
|
|
这种帖子必须得顶
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
楼主很厉害
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
膜拜一下~
|
