前一段提到，新方案主要是为了提高漏洞发现的效率，所以我们要解决的第一个问题是无法直观地看到游戏中漏洞的表现效果。要实现这一目标，需要一种不脱离客户的测试方案：将数据流的起点和终点定位于客户和服务器，测试工具利用中间层的思想，在信道中进行测试操作，与客户和协议链无关。本文的设计大致如下：为了实现tcp中间商的操作，我们研究了多种应用iptables&pfctl实现端口转发和应用代理实现流量转发的方法，经过一段时间的摸索与验证，最后采用socks5代理服务器实现数据流的转发和中间商操作。

之所以选择socks5代理，是因为它非常简单，因为它不需要协议类型，只需要简单地进行分组传输，所以socks5的速度比较快，不会影响游戏的正常运行，另外socks5代理对客户端环境没有特殊要求，比端口转发方法更轻便快捷。代理方法socks5的工作流程如下：我们应用socks5的代理客户机，在测试端构建代理服务器，测试逻辑主要运行在代理服务器上；本次设计的方案，其核心框架设计如下：

通过新的工具方案，我们已经能够正常地应用代理模式进行游戏，并且可以看到游戏的上下行数据流，但是为了测试，我们还需要将数据管道中的数据取出来，经过修改后再写回数据管道，这里的解析和封装模块与前一种方案一致，不再详细展开。为了控制测试过程和目标，我们重新编写了本地测试文件，现在我们的新方案已经初步成型。但目前，我们仍有以下问题：

中间商模式能够测试的协议都是由游戏客户端发起的，比如购买商品，这样就不能绕过客户端的限制，比如当金币不足时不能发起购买，但事实上游戏服务器上可能有金币不足购买不扣费的漏洞；简言之，就是仅仅依靠中间商模式测试覆盖面不够：虽然可以覆盖所有游戏协议，但不能覆盖游戏在特殊情况下的问题。我希望，能够在任何情况下都能够主动地开始测试协议，从而绕开客户端的逻辑限制，深入挖掘游戏服务器的问题(或者说这个原则，客户端不受信任)。这是一个非常巧妙的方法：协议劫持。具体的劫持方法是：找一个简单的，不受客户端逻辑限制的协议，比如游戏中的动作，表情等等。由于这种类型的协议是冗余的，并且对游戏安全很可靠。