虽然维护登录状态、密钥交换和心跳包需要花费时间和精力，但是在这个过程中可以发现很多安全漏洞，比如密钥交换不合理，甚至出现固定密钥、固定登录密码、多次登录状态等严重问题。因为游戏业务和常规业务在通信上是不同的:很多特殊的协议及其有效的判断只有在特定的场景和环境下才会生效，可以理解为只有正确的协议链才会得到服务器的正常反馈和数据；因此，我们正在进行以下改进。

首先整体运行游戏客户端，记录游戏正常运行时的协议调用链，根据调用链重构并自动读取协议。虽然这个过程很费时间，但是我们可以发现很多游戏中无法触发的隐藏bug。这类问题主要是游戏进程没有按照预定的调用链进行通信，造成多协议组合漏洞。比如在战斗中跳下，在商店里开始战斗。

对于游戏自主开发的DSL处理，大部分模块都是通用的协议重构方案，尤其是协议解析和序列化部分；但在某些情况下，游戏除了通用的protobuf、json等数据序列化格式外，还会对自带协议格式的游戏使用自带的私有DSL协议。我们做了一些研究，发现大部分私有协议格式都有相同的根，将明文数据序列化为二进制流的关键点差别不大。因此，我们集成这些公共部分，开发通用的序列化和反序列化接口，并设置几个可选参数来适应不同的格式。

好的，目前为止，我们可以通过访问安全审查来测试大多数游戏的协议安全性，但是这个方案仍然存在一些问题。看到这里，相信有同学发现了这个方案的一些不足。

根据复习工作的开展，我们发现这个方案存在几个问题:不能直接看到游戏中漏洞的显示效果，我们期待服务器发送一个特殊字段的测试协议后得到负(负)反馈，但是不同游戏设计的反馈不一样，有的游戏不反馈，有的游戏只反馈一个错误码。这是判断测试字段是否有效的一大障碍(有效是指服务器直接执行了我的错误字段而没有拒绝，比如我告诉服务器我出生了，我满了)。协议访问时间较长，需要彻底掌握协议链的各种细节，工具才能完美适应游戏。对于一些急于上线的游戏，这个审核周期可能会影响发布进度。

对游戏更新的适应性较弱。我们完成一个游戏的第一次测试后，游戏的登录状态、登录过程、密钥交换逻辑都会发生很大的变化，协议重构是一个耗时的操作，会影响后续增量测试的效率。