测试步骤：

1、  分别在客户机和服务器安装sulley fuzzing框架并为私有二进制协议编写相应测试脚本，此时服务器端上的VTM进程正常工作，如图所示：

2、  在服务器端通过sulley分别启动VTM进程监听和fuzzing数据的网络抓包，如下图所示：

3、  在客户机启动sulley fuzzing测试，sulley将根据我们自定义的协议脚本进行数据变异，并发送到服务器的VTM进程，如图所示：

4、  观察服务器端的sulley进程监听窗口，发现出现异常信息，如图：

5、  观察服务器端的任务管理器，发现VTM进程已经退出，如图所示：

6、  观察服务器端的sulley网络抓包窗口，发现问题出现在第109个fuzzing用例，如图：

7、  该用例数据包为pcap格式数据包，由sulley自动抓取并保存在C:\crash目录下，如图所示：

8、  使用wireshark打开该用例数据包，发现sulley在tts请求的IP字段填充了由多个”%n”组成的格式化字符串，该数据是导致VTM异常退出的主要原因，如图所示：

9、  由于字符串是由多个”%n”字符组成的，因此我们需要进一步判断到底是字符串的超长溢出还是对特殊格式化字符解析错误导致的进程异常退出，为此，我们使用python脚本进行手动验证。

10、              打开wireshark，并启动抓包功能，设置过滤条件为tcp.port == 8664，如图所示：

11、              编写python脚本，模拟步骤8的数据包格式，向tts请求的IP字段填充200个’A’字符，并进行发送，并通过wireshark抓包确认发包准确，如图所示：

12、              观察服务器端的VTM进程，并未发现异常，如图：

13、              模拟步骤8的数据包格式，重新向tts请求的IP字段填充200个’%n’字符，并进行发送，并通过wireshark抓包确认发包准确，结果发现VTM进程异常退出，如图所示：

14、              以下为VTM进程异常退出时，使用ollydbg抓取的调用栈信息，如图所示：

15、              根据步骤13，不断调整向服务器发送的”%n”字符串的个数，发现当”%n”字符>=6个时，VTM进程就会崩溃，因此，可以确定并非缓冲区溢出造成的进程崩溃，而是进程在对格式化字符串进行解析时出现的异常。

问题扩展：

1、  通过不断的验证和测试，发现tts请求的其它字段也同样存在类似问题，比如port字段，talk字段等等，只是针对不同的字段在重现问题时所需要的”%n”字符串的最少个数是不一样的，此外，不同的字段产生的异常栈信息也不一样。

2、  除了使用”%n”字符串可导致VTM进程异常以外，”%s”字符串亦能重现此问题，可能还存在其它的格式化字符或特殊字符能够导致该问题，应平行排查.

YS VTM模块存在格式化字符串漏洞，可导致VTM进程异常退出【高危】