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 |