现在的位置: 首页 > 综合 > 正文

暴雪和黑客的战争三:黑客的反击

2012年10月14日 ⁄ 综合 ⁄ 共 2408字 ⁄ 字号 评论关闭
暴雪在1.10补丁中加入hack检测机制,在某种程度上直接导致了原本和谐的D2X游戏黑客社群的分裂。一部分出于对检测机制的顾虑,停止更 新自己的作品,如d2hackit;另一部分则把他们的hack具有的反检测功能当成卖点开始收费,如d2maphack和d2jsp;还有一部分黑客出 于不满开始制作这些收费hacks的替代品,如d2hackmap,C3PO,d2bs等;甚至有些黑客出来破解这些收费hacks。

如前一篇文章所说,暴雪在1.10中加入packet 64/65检测。最早公布packet 64被用作hack检测的是jhj。当然Mousepad在jhj之前就已知道这一点,但是他当时正打算对maphack收费,反检测是一大卖点,因此一 直没有公布。在jhj公布了他的发现后,我检查了相关代码,又发现了packet 65也被用作hack检测。

如前文的分析,packet 64/65检测用的都是memory probe方法,那么memory probe该怎么对付呢?一种简单的想法是在客户端截获packet 64/65检测,不让它返回检测结果。截获packet 64/65检测思路是对的,但不返回检测结果其实也是一种信息,暴雪完全可能根据这点判断你在使用hacks,最不济也会把你踢下线,显然不是好的做法。 对付memory probe,更好的做法是伪造检测结果。这需要截获packet 64/65检测,然后根据要检测的内存地址返回该地址被修改前的数据(如果已经被修改了的话),这样无论检测哪个地址,检测结果都和没有使用hacks时 的一样。

具体到实现方法,大约又有三种。

一种是hack在安装旁路点时,先保存原先的数据,这样在遇到检测时就能知道patch前的数据。使用这种方法的有d2maphack、d2jsp等。这种方法最简单,实现起来也容易,占用额外内存也不大。缺点只能保护自己,不能保护其他hacks。

第二种方法由jhj实现,其原理是在加载任何hack之前,先对游戏中用到的重要的dll做备份,这样就获得了这些dll干净的副本。然后截获 packet 64/65检测入口,根据检测地址,从干净的副本中返回相应的数据。这就是jhj在 1.10时期发布的antidetection.dll。这种方法最大的优点是通用,可以保护其它hacks-其他hack不需要有任何反检测措施就能避 开检测。但是这种实现也有不小的缺陷。其一是它必须抢在其他所有hack之前加载,否则无法获得干净副本-如果无法获得干净副本这种方法就完全失去意义- 这在有些情况下是不容易做到的,比如无人职守的BOT。其二是所有重要的dll都要备份,这会额外消耗不少内存,对机器配置差或者多开BOT的玩家有很大 影响。其三是antidection.dll只备份了它认为重要的dll,而不是所有dll,这样如果有的hack修改的dll不在它的保护范围,还是有 可能被抓到。

第三种方法由我实现,称之为模块重建法(module re-construction),首先在d2hackmap中实现,后来ABin升级d2hackit时请我帮忙实现anti-detection模 块,因此我又把它集成进了d2hackit 2.00版本中。这种方法的思路是截获packet 64/65检测入口(显然所有反检测方法都需要这一步),根据检测地址判断出目标模块名称和其在硬盘文件路径,然后从该模块的硬盘文件开始重建一份干净的 副本,最后从干净的副本中返回相应的数据。这种方法在没有检测活动时(其实1.10时期packet 64/65检测很少出现)不会消耗额外内存,可保护所有dll,也无需抢先加载。我个人觉得是一种比较理想的方法。当然,模块重建法的难点在于如何从一个 dll文件重建一份和已加载模块被修改前完全一样的副本(其实是代码段和只读数据段完全一样,读写数据段无所谓),这在以后的文章中应该有机会介绍到。

另外,除了packet 64/65检测,别忘了1.10以前一直就有的version-checking.dll和extrawork.dll机制。虽然它们在前1.10时期从 未被用作hack检测,但是显然暴雪在1.10时期开始重视打击hacks,因此也不得不防。回想一下这两处机制,由于这两个dll都存放在服务器端,必 要时发送到客户端运行并返回结果。不让它们运行显然是不行的。并且显然它们的检测手段也是无限、未知的,伪造检测结果也不可行。那该怎么办呢?

对付这种手段的一种比较有效的方法是,截取并保存尽可能多的从服务器端传过来的dll,逐一分析,标出安全的和不安全的,并对每个dll建立签名 (signature)。这样在每次客户端接收到dll时,先计算出其签名然后和已事先分析过的所有dll签名比较,这样就可知道该dll安不安全(即能 否检测出我的hack),如果安全则让它执行,如果不安全则hack会自己卸载,然后再让该dll执行。这样就不会被它抓到。另外对于未知模块(即该 dll的签名不在列表里),应该把它保存下来以供事后分析,同时为保安全hack自己卸载,在以后分析后再把它标识为安全或不安全。当然对于不安全的模块 还应进一步研究反检测方法然后把它标为安全模块。d2maphack、d2jsp采取的都是这种策略。d2hackmap由于我后来没有太多精力人工分析 这些模块,因此只在配置文件里设置开关变量,指示d2hackmap遇到这些模块时如何处理(有忽略、卸载自身、保存模块文件并卸载自身三种选择)。至于 jhj的AntiDetection.dll是没有这方面的反检测保护的。事实证明这种策略是比较有效的。一个可能的原因是由于设计所限,这种发送dll 检测机制尚不具备快速变形、频繁运行的能力。

总之在1.10时期,暴雪和黑客之间的对抗以黑客的胜利告终-在整个1.10时期,我的记忆中没有出现大规模BAN CD-KEY和封帐号事件。

 

抱歉!评论已关闭.