首先，看下modules下源码结构：
从源码的目录结构可以看到，在modules下面有两个部分。fingerprints我们在之前已经分析过了，这篇主要分析一下discovery目录下面各部分的源码。
这里先看一下util下面的manager.py源码。这里基本就是按照discovery每个子目录构建一个初始化函数。
先来分析attack子目录的实现过程。下面是attack子目录下面的检测脚本，检测脚本比较少，其实算是比较单薄的。
attack.py脚本定义了一个Attack类，类中对各攻击脚本先做了参数初始化，然后调用各攻击脚本的run方法执行特定漏洞验证。
分析sql.py脚本看下实现方式。思路都是一贯的：用payload替换掉输入点的参数值，然后提交判断返回值是否含有特定字符串。
sql注入的测试很简单，看着data下面sql.txt给的几个payload很简单，比如没有延迟注入。可以预见这个sql注入脚本也只是简单验证性质的。其实，sql注入这块可以把sqlmap接进去。后续我会相信分析sqlmap源码。
util下params.py下实现payload的替换操作，函数如下：
替换之后，在sql.py中就是提交替换好的url，然后判断是否存在特定字符串。判断的函数如下所示：
整个sql.py的核心函数如下所示：（这里有对单个参数和多个参数的注入验证）
基本上这个sql注入的检测就分析完了。
接下来，看看brute子目录下的实现细节。首先看一下data下面的文件列表：
这个主要是各种payload的文件集合，payload比较少，所以只能触发各种漏洞的部分情况。
看下file.py文件的源码，关键部分的代码在下面：
思路很简单，从payload文件选取文件名与url组合成新的url，然后提交访问一下，看是否返回状态码200。有没有发现，其实自己很好写利用代码，这个框架相关利用脚本都是遵循统一的编写格式。
继续看下面的disclosure目录。这里主要对网站返回值进行ip、email、credit_cards格式正则匹配，获取相关信息。
util目录下parser.py下获取ip、email、credit_cards的函数如下：
后面的other也类似，就不继续分析了。
看下vulns目录下，对部分漏洞的验证。看shellshock.py的源码：
这里包含了payload，后续验证的代码如下：
仔细看看其实代码编写格式都是一致的。discovery这一块大致分析都到这里。