防外挂的那些事儿

对于一个要上线的游戏，防外挂是必须的，历史上因为外挂而造成大量玩家流失的游戏数不胜数。随着游戏研发技术的发展，对外挂的预防业内其实做的已经越来越好了。下面总结一下防外挂的基础知识，以及我们的移动模块为防外挂做了哪些工作。
本文是6月23号讲的沙龙的一部分。在这之前的读者有兴趣可以报名参加，之后的读者可以看录像了解更多。http://salon.km.netease.com/salon_detail?salon_id=1930

1 预防外挂的基础知识

在做外挂预防工作之前，我们要先了解外挂有哪些。根据我的了解，市面上常见的外挂主要有以下几种：

• 修改客户端的内存信息
  这类外挂通过分析游戏所使用的内存，找到内存中的变量去分析猜测变量是代表的什么含义。由于客户端本身保存着很多游戏信息，比如技能cd、移动速度等。由于我们游戏技能的管理和发起是由客户端控制的，若外挂能去把技能cd改为了0，客户端就可以无限放此技能。
  常见外挂工具：葫芦侠、八门神器
• 加速齿轮
  加速齿轮可以加速某一个进程的时间流逝速度，通过加速齿轮，可以让游戏客户端进程的时间加速N倍。真实时间可能只过了1s，而客户端进程的时间已经过了Ns。通过加速齿轮，可以让人物移动速度加快、技能cd加速等。
  常见外挂工具：加速齿轮
• 重发、篡改同步消息
  此类外挂可以截获客户端发送给服务器的消息，然后进行篡改或者重发。比如可以截获一个释放技能消息，然后再无限重发给服务器，服务器若没有验证，就会无限执行技能。
  常见外挂工具：WPE三件套（eg+wpe+ccp）
• 脚本自动模拟点击
  这类外挂对游戏破坏相对较小，但是也最常见。这种外挂比较普遍，对游戏的影响主要是看游戏机制。比如我一个哥们弄了20多台手机，用按键精灵刷传奇世界手游的金币，然后卖给其他玩家。但是对于不能自由交易的游戏，就不会出现这种问题，最多是导致玩家自己使用，从而可以24小时在线，缩短了游戏寿命。
  常见外挂工具：按键精灵（我感觉这东西都已经产生了一条产业链...

防外挂是一个系统工程，需要不同的模块配合实现。而且，对于不同的游戏对外挂的预防要求也是不同的，具体游戏需要具体分析。
常见的外挂预防手段有以下几种：

• 进程检测
  游戏开始时检测手机正在执行的进程，若发现某个进程在黑名单上，则不能进入游戏。这种方式可以预防市面上常见的外挂，对于不常见的或者新开发的外挂则束手无策。若游戏不火没人玩，这个手段就够了。希望大家都能遇到针对自己游戏专门开发的外挂，哈哈。
• 行为统计分析
  把玩家的行为（常常是点击行为）记录下来并进行分析。这种方式可以辅助检测玩家是否使用按键精灵这种工具。
• 内存、通信加密
  之前介绍了外挂可能修改内存或者篡改同步消息以达到他们的目的，若我们对客户端的内存信息和通信信息加密，外挂拿到了信息也不能分析，从而也就无从下手了。
• 举报
  moba游戏或者fps这种对抗性的游戏中，玩家使用外挂对手能明显感知到。对于这种游戏，举报机制是一个很有用的防外挂手段。
• 验证码
  梦幻就有这个模式。

以上介绍的通用方法并不能解决所有的外挂问题，因此我们在游戏的逻辑实现过程中要需要做对应的防外挂机制。

在游戏逻辑实现中进行防外挂的基本方法是：

• 服务端保存验证信息
• 收到客户端发来的消息后，对消息的合法性进行验算。

在具体的游戏执行逻辑中增加防外挂机制的时候需要秉持一些原则：

• 保证外挂收益不抵支出
  这个有两层含义，一层含义是要让外挂使用者无法获得收益；另一层含义是，若外挂使用者只能通过非常麻烦复杂的工作才获得一些小小收益，那么这种情况我们可以放过，也就是说不需要对所有的情况都需要增加防外挂逻辑。
• 不影响游戏性能
  在增加防外挂逻辑的时候，需要考虑为了防外挂增加的性能开销。若因为防外挂增加了巨大的性能开销，那么往往是不值得的。这种情况可以考虑不要在逻辑里面放外挂，而且是通过其他方式。
• 区分什么是不可信的，什么是可信的。
  可信的不需要验证，不可信的选择性验证。在我们游戏里面，所有客户端发送的消息都认为是不可信的，所有服务端发起的调用都是可信的。比如在下面介绍的移动模块防外挂机制，当服务端的其他模块比如机关模块通知我的移动模块瞬移，这种情况我不考虑机关模块是否可能是被外挂操作了，我认为都是可信的。当然这个机关可能是被客户端操作，那么这时候客户端是不是用了外挂应该是由机关模块来判断和验证。

下文以玩家在客户端操作自己的单位移动为例，介绍移动模块为了防外挂做了什么工作。
之前写过技能模块的防外挂内容，大家可以阅读：http://km.netease.com/article/209006

2 移动模块如何防外挂

我们游戏的移动同步逻辑的基本原理是：单位在主控端（玩家自己的客户端）根据玩家输入执行移动逻辑，然后将位置点以及时间信息以一定的频率发送给从端，服务端以及其他客户端根据主控端发来的移动同步信息模拟、预测、纠正单位的位置。

基于以上同步机制，移动模块需要考虑三种外挂情况：
1.主控客户端伪造或篡改瞬移消息。
2.主控客户端修改本地内存中的移动速度。
3.主控客户端使用加速器

2.1防止客户端发送非法瞬移消息

由于我们游戏所有的移动都是在主控客户端发起和执行，然后服务端跟随，所以瞬移也是客户端先执行，然后通知服务端。

为了保证客户端不能发送非法瞬移消息，我们将瞬移流程定义为：由服务端发起、客户端执行、服务端再验证。

瞬移逻辑如下图所示：

1.服务端发起瞬移，但是并不将单位移动到对应位置，而是将瞬移信息发送给客户端。
2.客户端收到位移信息后，将单位移动到对应位置。
3.客户端发送一个瞬移消息给服务端，服务端收到后，将单位移动到对应位置。

基于以上瞬移流程，可以比较简单的实现瞬移防外挂功能。

1. 服务端发送瞬移信息给客户端时，记录下来瞬移目标的位置。
2. 服务端收到客户端的瞬移消息，进行以下验证：

• 若服务端没有发送瞬移消息给客户端，则瞬移非法。
• 若收到的瞬移位置与记录的瞬移位置不同，则瞬移非法。

基于以上流程，可以保证瞬移虽然是客户端执行的，但是仍然由服务端发起和验证。

2.2检测不合理的移动速度

对于移动逻辑，还需要防止一种外挂：改内存中的移动速度。

对于这种外挂的预防，一般有两种：1.在客户端通过一定的加密手段使玩家无法找到移动速度，从而无法改变。2.服务端验证。我们使用的是服务端验证的方式。

服务端验证的基本原理：
当客户端发来一个移动消息时，服务端根据此条消息和上一条消息可以计算出来两消息之间的移动速度，然后根据服务端信息可获得对应时间的服务器认为可以达到的最高速度，比较后即可以验证。

其中服务端如何获得对应时间的允许最高速度是其中的难点。刚开始，我们使用的方式是记录每次移动速度改变的时间和速度值，当收到客户端消息时，根据客户端发送消息的时间去查该时间对应的速度值。

但这里有一个问题：当一个击飞事件移动速度改为300，击飞事件结束前又来了一个普通移动事件速度改为40，其实这时的移动速度其实是300，但根据我们的算法计算出来的是40.

因此，我们实现了一套基于改变移动速度事件的移动速度验证机制。我们并不记录速度改变得值，而是记录速度改变事件的开始&结束时间和速度值，因此每次需要计算某时间对应的速度时，根据速度改变事件的信息可以计算出准确的值。

2.3检测加速器

游戏外挂最常见的就是加速器，在我们的游戏移动机制中，加速器可以让客户端的单位移动速度变快，而我们是将客户端单位位置同步给服务端，若服务端没有任何验证，则服务端就会跟随客户端位置，加速器外挂就会生效。

加速器外挂的原理是加快的客户端的时间流逝，因此，最简单的方式是当服务端收到同步消息时，从同步消息中拿出来客户端发送消息的时间，若客户端发送时间大于服务端当前时间（会加一个阈值），则认为是使用外挂。

游戏中有时间校准机制，当玩家短线重连时，客户端和服务端会重现校准时间，而校准后的时间由于网络延迟和网络波动问题，可能出现各种情况，包括客户端时间快于服务器时间。对于这种情况，会造成误判。

为了解决这个问题，我分析了加速器的特点。加速器会导致客户端时间持续不断的加快，并和服务器的差距越来越大。因此，我们使用以下验证机制，基本可以避免误判：
1.若客户端时间>服务端时间+[阈值]，则[阈值] += (客户端时间-服务端时间)
2.第1步重复n次，n是我们给客户端出现异常的机会次数，我们游戏n=2。
3.若客户端时间>服务端时间+[阈值]，则认为客户端是外挂。

通过这种方式，我们给客户端一次或者多次机会，对于加速外挂，它会导致客户端时间持续加速，最终使用掉所有的机会。而由于网络波动导致的客户端校准后的时间快于服务端时间的情况，不太会使用掉所有的机会。

当然，这种监测方案理论上仍然存在误判。但因为每次切换场景都会重置，当n=2时，经测试分析出现的误判情况极少。

若把n改成更大，会导致玩家进入一个新场景后，若加速倍率比较小，比如加速0.1倍，可以使用较长一段时间的加速外挂。

因此n的选择和初始阈值的选择都是一个权衡。

附：运维log可以检测加速器外挂的使用，但log更多的是检查，而不是预防。我们这里实现的是预防，保证玩家无法使用加速器获得任何收益。