在工具前端，主要是与安全检查员的交互场景，在这里，可以决定使用的效率。要想更有效地发现漏洞，我们需要实现以下目标：对不同类型的协议字段进行字段值推荐，从而产生BUG，减少数据中被评测人填充数据的环节，对某个或某些协议实现Fuzz的高级自动发送功能，一键覆盖可能出现的问题，针对不同的测试环境，提供PC版和网页版前端界面，PC截图如下：

在前端，核心框架中的hook引擎主要用于数据交互，数据交互过程更加简洁。装入程序和hook引擎，装入模块主要提供了注入游戏的功能，需要将包含游戏脚本hook引擎功能的库文件装入游戏的相同进程和名称空间下，以便我们可以将自定义的游戏测试逻辑注入游戏上下文中，从而修改和操纵游戏的本地逻辑。加载程序有两种技术选择，一种是针对root环境，通过附加Zygote完成注入；另一种是针对非root环境，使用虚拟多开技术进行注入，而root模式对测试终端的环境有一定要求，但其适配游戏范围很广；非root模式不需要额外的root环境，但需要为某些游戏和机型提供特殊适配。

在Hook引擎的注入过程如下：hook引擎包括hook对各种游戏引擎的支持，以及它们的技术选择，这些都可以为游戏脚本注入和替换，这是这组技术的重点内容。就拿Unity3d引擎mono选择来说，主要是通过使用libmono.so自身的接口和Mono的JIT机制进行选择：

先装入我们自己的逻辑模块，这是我们用C#开发的dll文件。使用mono_class_get_methods来定位要替换的目标方法，替换方法，以及空指针来替代原始方法。接着通过libmono.so的mono_compile_method来进行JIT编译，并返回nativecode的地址。用hook实现目标逻辑的方法替换。

逻辑层是控制游戏运行逻辑和游戏协议管理的核心，我们需要在逻辑层完成下列预定功能：由于游戏开发人员众多，他们使用的Unity的.NetFrameWork版本也不一样，而且.NET的高版本特性不能在低版本上运行。因为游戏的逻辑需要被引入，所以想要以动态库的形式来解析游戏的脚本，就需要支持解析的合适版本。

由于这本书的游戏界面各不相同，需要根据不同的情况，将数据解析到明文数据中，一般是针对proto和json进行解析。即将解析完的数据以Json的形式传递到UI前端，这里最大的问题是Json的构建，因为游戏Unity版本存在问题，一些.net版本不支持通用Json库，因此需要根据游戏的运行环境选择相应的Json代码。除C#层的hook外，还需要操作游戏的热更脚本，因为热更脚本中包含了部分游戏的主要逻辑。