方法1：
如果我们手头上有TgServer的源代码，通过代码审查显然可以找到可能的漏洞。就算没有源代码，通过逆向工程方式，用代码审查的方式也可以达到找到漏洞的目的。当然，这必然要求审查者具有足够好的技能，而且，被测应用规模越大，需要付出的成本也就越高。
方法2：
尝试抓取到客户端和服务器之间的通信数据，根据这些数据分析出客户端与服务器之间的通信协议，然后根据协议的定义，自行编造数据发起攻击，尝试找到可能的漏洞。
方法2在成本上比方法1要低，而且由于方法2关注的是协议层面的攻击，效率会更高。但是，稍微想一下，方法2还是存在一些问题：
完整的协议分析难度很大；
人工编造数据的成本很高；
在方法2的基础上，我们尝试引入模糊测试的概念，由于机器生成和发送数据的能力足够强，因此我们完全可以把生成数据的任务交给机器去完成。当然，协议的分析主要还是依赖人工来进行，模糊测试领域内有一些自动化的协议分析手段（《模糊测试》一书中有专门的章节描述），但从效率和效果上来说，在面对复杂协议的时候，人工分析的方式更为有效。
假如根据抓取到的数据包，我们发现被测应用使用的协议如下（|仅表示字段间的分割，不是实际的数据内容）：
|00 01| GET | 11 | user:dennis
2字节的包头（00 01）
10字节定长的命令（GET）
一个1字节的数据，表示命令参数的长度
不定长的命令参数
根据这些信息，使用模糊测试方法，我们就可以借助通用的模糊测试工具（如Spike），用模板方式将协议描述出来，并让模糊测试工具自动填充可变字段的内容，生成大量的测试用例并发送给TgServer。同时，通过模糊测试工具提供的功能监视TgServer，一旦TgServer出现可被识别的问题（如性能下降，不再响应，或是返回异常数据等），我们就可以停止模糊测试，并通过日志找到导致问题的请求，进而确认问题。
简单的说，模糊测试尝试降低安全性测试的门槛，通过半随机方式的数据发送来找出被测系统的漏洞。显然，测试这对被测应用越了解，模糊测试的生成就能越准确。但与渗透测试或是代码审查相比，模糊测试显然更加易于进行。而且，通过自动化工具，模糊测试可以把安全方面的经验积累到工具中，为组织持续的安全性测试提供帮助。
这是本系列的第一篇，后续还将写两篇来介绍不同类型应用的模糊测试，以及常用的模糊测试工具。
《模糊测试——强制发掘安全漏洞的利器》这本书全面覆盖了模糊测试这一技术。
