我们之前的fuzzing往往考虑的都是一个字符串，绞尽脑汁让这个字符串的字符发生变化进而提高某些指标，我们这次把段位上升，不在局限于怎么“美化”句子，而是如何“定义”句子。
还记得最初我们用的bc吗？如果你一味使用Lv4之前的技术，那你其实永远都是在“乱搞”，因为它其实有一套自己的逻辑，如果找到了逻辑你可以绝杀，就像是玄幻小说，掌握规则的人永远比普通修炼的牛，我们也要让我们的史莱姆掌控法则。
语法
我们说话写字都是有一定规则的，编写程序是这样，写数学公式也是这样，现在我们来想想到底是什么“限制”了我们呢？
- 首先当然是范围，你也可以理解为集合当中说的定义域，简单说就是规定哪些符号你能用，哪些不能用，以只包含加减乘除的小学数学表达式为例，我们的定义域就限制在了加减乘除四个符号以及0～9十个数字罢了，你用了a你就是错了，就不是一个合格的表达式了。
- 其次我们可以想到，是一组规则让我们不能乱写。小学数学表达式可不会出现1++这种奇奇怪怪的式子，这就说明背后有一套规则约束，而这套规则还应该是支持无限写下去的，因为按道理来说，你可以写1+1+1+···一直写下去。
如果让我们用一套规范点的方式去概括这两个方面呢？范围我们很好解决，我们可以用正则表达式来检测，不符合规则淘汰就是了，第二点我们该如何做呢？其实我们大学就学过这个问题，这其实就是个有限状态机。
所谓有限状态机，其实就是一组“状态”，它们之间互相能够进行转换。比如Linux的进程状态，那有人就要问了，你刚说了1+1+1+能无限写下出，怎么这会反而有限了呢？其实有限说的是状态是有限的，比如Linux的进程状态，满打满算就五个，但是一个进程你完全可以无限次的经历这些状态。
这两点就组成了我们的语法，我们只需要按照一定的规则，就可以轻松写出对应的语法，比如
<start> ::= <digit><digit>
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
首先是个start标签，标志着开始，::=这个符号表示前者可以由后者代替，而|就代表or的意思，所以上面的语句就代表，以两个数字开头，后面啥也没有，其实就是我们需要写两个0-9的数，比如00，比如12。
那你就要问了，我要是写1000个数你咋整啊，我总不能写1000个<digit>吧？其实也很简单，加一句话就完事了
<start> ::= <integer>
<integer> ::= <digit> | <digit><integer>
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
我们引入了递归的概念来处理这个问题，用递归达到无限循环的目的。直接来看，首先我们以integer开头，而integer可以是数字，也可以是数字然后再来个integer，这就可以一直递归下去了。比如我写1，可以吗？可以，integer=digit=1即可；写23，可以吗？可以，integer=3iteger，再处理第二个integer=3即可，就得到integer = 23，这样我们就轻松实现了无限的概念。
那又有问题了，我如何表达我的数有正负呢？也简单，在状态转换的位置加入限制即可，如下
<start> ::= <number>
<number> ::= <integer> | +<integer> | -<integer>
<integer> ::= <digit> | <digit><integer>
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
假设我们输入的是-3，那么就是number=-integer，integer=3，number=-3，完毕。
有了上面几个例子，相信你已经会利用“解包”的思想读这些语法了，我们每次读时，如果有还不清楚的位置，那就先带着标签，然后一步步把标签给去了，这就是解包的思想，我们不仅仅读需要这种思想，写代码实现也要如此。下面我们就尝试写代码，让程序按照我们定的规则来说话。
DIGIT_GRAMMAR = {
"<start>":
["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"]
}
我们用字典存储标签即可，而对于生成的过程如下：
term = start_symbol
expansion_trials = 0
while len(nonterminals(term)) > 0:
symbol = random.choice(nonterminals(term))
expansions = grammar[symbol]
expansion = random.choice(expansions)
new_term = term.replace(symbol, expansion, 1)
if len(nonterminals(new_term)) < max_nonterminals:
term = new_term
if log:
print("%-40s" % (symbol + " -> " + expansion), term)
expansion_trials = 0
else:
expansion_trials += 1
if expansion_trials >= max_expansion_trials:
raise ExpansionError("Cannot expand " + repr(term))
nonterminals函数用来找非终端的标签，对于能够继续产生标签的标签，我们叫它非终端，比如start；对于只能产生最终结果不能继续生成标签的标签，就是终端，比如digit。
因为我们是一步步解包，所以首先我们得有包，他其实就是在检查当前的term是不是有包，如果有包的话，就在包里随机找一个，然后再从包中找一个标签，我们就到了新的表达式，当然，为了这个过程不会无限循环下去，我们人为定义了循环的最大值，让他不会无限循环。
这样说可能有点抽象，我们举个例子，就用我们的正负数来说：
- nonterminals找到非终端的值，一开始就是number（节省篇幅，跳了start标签）
- 随机选一个作为expansions ，这里只有number
- 随机在number对应的里面选一个，假设选到了+<integer>
- 那么新标签现在就是+<integer>
- 找所有非终端的值，只有<integer>
- 随机选，只能选<integer>
- 随机在integer对应的里面选一个，假设选中了<digit><integer>
- 那么新标签现在是+<digit><integer>
- 重复….
如此，我们就可以生成我们语法要求格式的字符串，同时我们也可以直观看到，如果不限制循环的次数，他完全可以-1111···这样一直生成下去。解包的思想在这里发挥了重要作用。在Fuzzingbook还给了很多例子和如何将这种语法封装为工具箱，因为篇幅限制就不再是详述了，大家可以自行参考。
看了上面的代码我们又会发现一些问题：
- 我们的迭代有点”傻“，我们要遍历字符串，随机抽取，随机生成，这个过程过于繁琐，直接影响效率。而且实际上我们是无法从已有的生成记录中再去进行“学习”的，它的遍历过程没有留下有效的结构信息。
- 我们控制不住它，即使是我们限制了迭代次数，在迭代范围内它也是过于随机了，导致生成的结果我们能插手的地方很少，我们没有办法以合适的粒度对其进行限制。而一不小心，它还经常生成长字符串。
对于第二个问题，我们还可以想办法进行改善，比如，我们限制标签的最大深度和最小深度，超过或者小于这个深度时，标签就不再出现，比如：
"<expr>":
[("<term> + <expr>", opts(min_depth=10)),
("<term> - <expr>", opts(max_depth=2)),
"<term>"]
但这样的解决方案能力有限，因为这样操作相当于我们人为限制了语法的“值域”，也就是说输出的结果范围被限制了，我们可能无法生成所需的fuzzing字符串。而且，我们永远没有探索最短、最长等特殊表达式的能力，比如1+1，这样的表达式你就只能等着它自己慢慢生成。
而对于第一个问题，因为我们使用简单的字符产组织，结构如此，永远没办法改善，只能另谋他路。
语法树
在算法问题中，我们常常一言不合就用树，因为树状结构简单清晰，还弥补了很多数据结构的缺点（虽然很多优点它也没继承），那么我们在这个问题上能不能使用树结构呢？我们简单思考：
- 有限状态机的结构与树非常契合，我们可以认为树的当前的节点就是一个状态，而这个状态的下一个状态，我们可以用该节点的子节点表示，有几个就挂几个子节点，可以一直继续下去。也就是说，节点的种类有限，节点的数量无限。同样用在我们的语法规则上也适用，我们生成的标签就可以作为节点，我们可以按照规则选择接下来的标签挂到节点上。
- 我们语法规则是马尔科夫链（当一个随机过程在给定现在状态及所有过去状态情况下，其未来状态的条件概率分布仅依赖于当前状态。但要注意，有限状态机本身不能算是马尔可夫链，因为实际上有限状态机的状态变换时一定的，没有概率一说，但我们生成字符串的规则却是带有随机性的）的一种特殊情况，它的每次状态变化都只依赖于当前状态，和之前的都没关系，所以对于树结构，我们只需要看当前的叶子节点即可，不需要关心前面节点的情况。
理论上的东西太抽象了，我们来看个例子，我们给出如下的语法规则（实际上就是四则运算规则）：
我们按照上面的思路试试能不能建树：
- start节点作为根节点
- start节点可以转移到expr节点，挂上expr节点
- expr节点有三个包，随机选一个挂上，比如expr + term包
- 现在我们有三个节点，其中，+不是非终端节点，它的使命已经完成，我们对其他两个节点重复操作
- 重复直到所有的叶子节点都是终端节点即可。
如此，我们得到了2+2这个数学表达式。这个东西我们管它叫派生树，也可以叫语法树。我们看看它解决上面的问题了吗？
- 时间上，我们遍历时不需要考虑整棵树，只需要检查叶子节点即可，效率大大提高
- 在控制方面，我们对于每一个叶子节点在遍历过程中都是可控的，我们可以人为在任何一步设置限定，不但不影响性能，编写程序也方便。
并且，我们可以看到，树结构还为我们提供了清晰的结构，让我们有了对于语法的“具体格式”，上面一章虽然也有结构信息保留下来，但结构信息杂乱，难以提取有效格式，而树结构天然就可供我们使用。我们可以进行大量的测试，我们手里有了大量树结构及其对应的代码覆盖等指标，我们完全可以选择其中优质的树结构进行相似度比较，从而提取更加优秀的树结构供我们使用。
比如bc人为限制不能输入+，如果我们按照普通的四则运算语法显然会导致大量的失效，但我们可以从有效的树中进行相似度比较，提取相似部分，这样我们就能慢慢去接近这套规则。因为树结构的存在，我们完全可以自由使用前面的知识，“养蛊”式的优化我们的树。
说完了理论，来简单看看代码实现，对于树结构，我们在python中有一套经典的保存方案：
derivation_tree = ("<start>",
[None])
即用二元组表示一棵树，其中，第一个表示节点，第二个是一个list，表示孩子。这套方案最大的问题是没法解决边的问题，但是我们现在对边也没什么讲究。
class GrammarFuzzer(GrammarFuzzer):
def choose_node_expansion(self, node, possible_children):
return random.randrange(0, len(possible_children))
def expand_node_randomly(self, node):
(symbol, children) = node
assert children is None
expansions = self.grammar[symbol]
possible_children = [self.expansion_to_children(
expansion) for expansion in expansions]
index = self.choose_node_expansion(node, possible_children)
chosen_children = possible_children[index]
chosen_children = self.process_chosen_children(chosen_children,
expansions[index])
return (symbol, chosen_children)
对于节点的扩充，其实和之前类似，都是先查语法，找到当前标签的包，随机选择一个，然后把包里所有的标签挂到节点上即可。到此，我们已经完全可以利用语法树来为我们生成fuzzing字符串了。
但是我们还不满意，我们说了树结构能帮助我们控制生成的过程，那应该怎么做呢？我们一般会定义如下的概念：
- 节点最小代价，即节点到终端节点需要消耗的最小“步数”，比如
<expr>→<term>→<factor>→<integer>→<digit>→ 1，expr走到终端节点最短路径如此，故其最小代价是5 - 节点最大代价，即节点到终端节点最大需要的步数，对于有递归的节点来说，就是无限大，对于digit来说，就是1
这两个概念可以帮助我们限制节点的走向，比如，我们可以规定，每一个节点都必须以最小的代价来进行生成（代码非常简单，我们检查节点所有可能的孩子的代价，对于包的情况，就是包内所有节点的代价的和，选择最小的挂上去即可），那么我们就会得到
我们就得到了一棵相对简单的树，它的表达式长度也让人比较满意。我们同样也可以按照最大代价进行生成，我们限制递归次数即可，如此我们就可以得到较长的表达式。但是这些会导致“僵化”问题，即路径固定，比如如果我们的最短路径只有上面一条，导致我们一直走，那我们生成的格式就永远是x+y/z了
我们目前实际上有了三种节点策略：
- 最小代价生成，即找最小代价的，会造成“僵化”
- 最大代价生成，即找最大代价的，在递归较多的语法中，“僵化”可能性较小
- 随机找一个，不会“僵化”
实际使用中，我们可以对每个节点采取不同的策略，比如有的采取最小，有的采取随机，有的采取最大，然后再人为限制递归次数，我们就即可以保证生成字符串多种多样，得到较为理想的结果了。
总结
我们从没头没脑的随机生成fuzzing字符串到现在终于可以利用语法“随心所欲”的生成符合我们要求格式的字符串，但在语法方面，仍有大量的知识等着我们学习，下一篇内容仍将聚焦于语法部分，期待我们的史莱姆再次升级。