随着游戏玩法越来越复杂，单一上下行协议在部分场景下无法准确的描述玩家的状态，于是客户端采取了协议组来告诉服务器更多的信息。很多时候，服务器未对这样一组组协议的顺序，频率，完整性等方方面面做校验，导致了各种各样的问题产生：

某游戏对局房间中，当玩家更换装备时，服务器并不知道玩家更换了哪件装备，于是将玩家整个装备信息下行广播到所在房间中的每一个玩家的客户端，客户端调用引擎进行装备的特效渲染。于是漏洞可能就产生了，恶意玩家在短时间内高频重发同步状态的协议，导致了对方客户端在渲染特效时消耗了大量的资源而导致游戏卡死。

某游戏中具有一套序列的UDP数据包，数据包中有一个字段每次随着数据包发送，递增1，于是漏洞可能又产生了，恶意玩家去人为修改这个数据包中的标记顺序，导致一个房间的所有玩家全部退出（炸房）

某游戏的攻击协议较为复杂，为了描述某一技能的攻击效果，用了3条协议协议A,B,C，A,B,C具有强相关性，描述了玩家的一套攻击，则漏洞可能又出现了，恶意玩家去屏蔽了协议B的发送，只发送了协议A和C，服务器收到后触发异常，直接崩溃，一台服务器上成千上万的玩家全部退出

综上案例，可以将基于协议时序的挖掘方法归纳为以下3个方面：

l 协议频发：短时间发送大量协议，多用于测试协议性能问题

l 时序混乱：改变顺序协议的上行序列，多用于测试协议的兼容性问题

l 序列完整性缺失：丢弃掉完整协议序列中的部分协议，多用于测试协议兼容性和协议逻辑问题。

关于不同的挖掘方向，挖掘方法也不同，可简单归纳为如下方法

下面逐一详细讲解：

l 协议频发：

协议频发主要影响的是对方客户端的性能，那么可能导致这样性能的问题的协议有2种，一种是大数据包下行的，因为大多数协议均经过加解密，用小的上行数据包去触发大的下行数据包，协议加密强度因为数据包较小，所以带来的机器消耗不是特别高，但是服务器转发的下行协议，就特别大，这样大的下行协议由其他玩家接受，进行协议数据包解密，带来的计算消耗就会很大，在短时间内如果频发的话，就会导致客户端卡死的现象。

比较多见的，就是玩家的状态同步，攻击者A，修改了自己的戒指，上报给服务器，上行协议只包含修改戒指这一项，服务器接受后，并不清楚玩家的哪一项状态发生了变化，于是将整个玩家A的状态（包括皮肤，武器，服饰，装饰，宠物）全部下发给了每一个玩家，于是一个经典的小换大的风险就产生了，你不停的上报自己状态的改变，每次可能只需要发送10个字节给服务器，但是服务器为了同步，可能需要发送1000个字节给其他的玩家，如果频率很快的话，自然就导致了对方客户端的卡死。

另外一种就是消耗本地资源的。比较常见的是一些场景特效，比如你在一个房间内可以释放燃放烟花的特效，但是这个特效会调用游戏引擎，进行3D特效渲染，于是风险产生，你在短时间内通过协议，释放大量烟花，别的玩家收到对应协议后，不停渲染，导致了本地的卡死。

l 时序混乱/完整性缺失

这两类漏洞的验证方式比较一致，都是需要分析协议的前后关系，判断关联性后，去改变其关联方式。有的协议自身就含有序列字段，类似与TCP中的ACK，发送后会累加，这样的协议通过分析字段就可以发现规律，然后去修改他的序列字段，观察服务器的状态即可。

还有的协议，自身不含有序列字段，但却具有着强相关性，他们无论什么时候触发，都是按照固定的顺序依次发送至服务器，此时就可针对中间的一条或多条协议做丢弃和提前发送。

基于协议时序的挖掘，很多时候都是在大胆猜想下进行的尝试，因为服务器完全黑盒，我们无法知道在特定的情况下，服务器是否会对异常的数据包进行校验和判断。因为只能去修改原先的逻辑，去验证自己的猜想。

*转载请注明来自游戏安全实验室（GSLAB.QQ.COM）

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课