以某款防封为基础对LXL检测的展开分析

123456868

0x0 须知
      文章内容无任何不正当目的与非法企图, 仅仅是为了公开交流学习!


0x1 准备工作

      我的调试环境: Windows 10-1809
      技术支持(非自愿): 小冰雹防封软件
      我用到的工具: 1. x32dbg  2. PCHunter(一款强大的ARK工具, 缺点: 作者长时间未更新, 现已不支持1809往后的新系统).

0x2 进入正题

小冰雹防封
      出处: *群下载的
      开发语言: 易语言
      主要功能:
      1. 针对对两款主流脚本(HanBOT, GE)的过检测, 使用者可以配合脚本在LXL游戏中实现自动走A, 连招, 躲避而不被封号.
      2. 躲避机器码封禁, 使用者可以在已经被T*P封禁的电脑设备上正常游戏.


      未发现小冰雹加载驱动, 所有功能均在应用层完成.


      注入姿势: 将其核心功能Dll释放到游戏目录, 以hid.dll命名
      补充: hid是一个系统Dll的名字, 位于系统盘Windows\\System32\\目录下. LXL游戏进程在启动初期会尝试载入一次同目录下的hid.dll文件, 并且载入时机十分早, 在T*P保护未覆盖游戏时就已将hid.dll载入内存.


      Step1. 观察其对机器码封禁检测的处理方式
      在开始之前, 我们要对游戏的机器码封禁检测有个基本构思, 首先IP地址显然不可能作为判断机器封禁的依据, 那么只能是玩家进行游戏的本机设备信息了, 例如硬盘, CPU, 网卡, 键盘鼠标这一系列设备的信息, LXL玩家众多, 考虑到要防止误封的情况, 必然是要采集多个设备的信息综合判断, 而若是在R3层面完成这些信息的获取, 无疑就是使用Win32 API获取. 而防封软件无非就是使用Hook, 阻止游戏调用相关API或者将获取后的缓冲区中的设备信息随机化再作返回. 而Hook位置则可以选为相关API函数处, 或是在返回的T*P检测模块调用处. 而显然是在API函数处Hook更省力, 因为API函数所在地址可以通过GetProcAddress获取到, 可视为固定地址, 而若是在游戏相关模块内存地址作处理, 在这些模块更新后我们都要重新找到对应偏移, 且还会触发其CRC, 是吃力不讨好的方式.
      如上, 我们应先观察防封对API的Hook情况, 但是如果逐个跳转至API函数头部查看是否被Hook显然十分低效且可能会遗漏, 这时我们可以借助PCHunter工具中的进程应用层钩子扫描功能, 可以快速查看指定进程中模块内存的Hook情况, 某些加壳的模块和非可执行代码的区域(例如数据段)这些位置的数据改变是无法侦测的, 但对API函数所在系统模块的钩子扫描是绝对没有问题的.


      如上图, 可以看到大量的API函数头部被Hook了, 使用x32dbg附加游戏进程, 随便转到到其中一个被Hook API函数ReadFile的头部


      可以看到ReadFile函数头部被改为jmp了, 跳转至到防封的hid.dll内了, 在他的函数内处理完后在返回出去, 标准的Hook流程.


      这些API函数都是十分常用的并且网上资料丰富, 不作过多叙述, 下面我会演示其中两个比较复杂的API函数用法和Hook后的处理方式


      1. SetupDiGetDeviceInstanceIDA    功能: 检索指定设备实例Id
      此函数原型:
[C++] 纯文本查看 复制代码BOOL WINAPI SetupDiGetDeviceInstanceIdA(    HDEVINFO         DeviceInfoSet, // 设备信息集合的句柄    PSP_DEVINFO_DATA DeviceInfoData, // SP_DEVINFO_DATA结构体的指针    PSTR             DeviceInstanceId, // 用于接收返回的设备Id字符串, 此参数为我选取的处理点    DWORD            DeviceInstanceIdSize, // 缓冲区大小    PDWORD           RequiredSize // 接收返回Id的实际大小)

      以下是我写的该函数调用例子:
[C++] 纯文本查看 复制代码void Test(){    HDEVINFO hDevInfo = SetupDiGetClassDevsA(&GUID_DEVCLASS_NET, nullptr, nullptr, DIGCF_PRESENT);     cout