Discoverer

Discoverer是微软研究院的Cui团队开发的，用来做基于Net-trace的协议逆向，而且是格式提取，并没有做状态机提取内容。主要思想就是按照文本和二进制两种属性对报文字节流进行分词，再采用序列比对算法对报文属性序列进行初始聚类，进而对各个域进行语义推断，根据识别出的格式标识域取值进行再分类，不断重复这一过程。最后对属性和语义序列相似度高的子类进行合并，解决过分类问题。
主要亮点：
- 通过分词进行初始字段划分
- 以域为单位进行序列比对
- 能够识别各种特殊字段的语义信息

---

技术细节：

1.Tokenization
对报文序列每一个字节按从左至右顺序依次进行扫描，如果是可打印字符则标记为文本类型，如果不是则标记为二进制类型。随后将两个二进制字节之间的连续文本字节标记为一个segment，通过分隔符delimiter（用常见的一些分隔符如空格）将segment划分成token，并且为了避免将二进制字节识别为文本字节，要求一个token序列长度必须大于某一个阈值（潘璠递归聚类论文设置为5）；对于二进制字节由于不好区分边界，所以将每一个二进制字节单独作为一个token。同时在报文序列中匹配Unicode码。最后得到的每一个token都可能与最终对应推断结果中的某一个字段相关联（可能就是这个字段或者是一部分）。
可能存在的问题：
- 有的文本类型的字段可能长度小于设置的阈值，导致被判别为二进制字段；
- 有的二进制字节的ASCII值在可打印字符范围内（如空格或者tab），几个连续出现的这种字节可能会识别成文本token；
- 如果一个文本域中恰好含有分隔符符号，但是并不是用作分隔符，就会导致被错误地分成多个token。
2.Initial Clustering by token pattern
这里利用多序列比对算法对报文序列进行对齐比对的时候，Cui等人认为对报文token模式进行比对效果会优于对实际报文序列进行比对，例如，具有相同格式的两个报文，如果有一个字段是变长字段，那么对实际报文序列进行比对可能会得到误差较大的比对结果。而且在对报文序列进行比对过程中，对两个字节的match、dismatch以及gap分数设置也不好确定。
所以基于token模式序列对报文进行聚类，如，一个报文的的token模式序列可以定义为(dir,class_of_token1,class_of_token2,…)注意dir表示报文的方向，class_of_token1是token的类型，而不是指token值。之所以加入方向属性，是因为不同方向的报文通常都具有不同的格式。最后得到的聚类只是一个粗糙的结果，因为不同格式的报文序列可能会有相同的token类型序列，譬如SMTP协议中的两个文本token：“MAIL receiver”，“HELO server-name”他们的token类型是一样的都是两个文本token（因为有空格分隔符），但是他们属于不同格式的报文。于是Discoverer为了解决这个问题，通过对FD格式标识字段的辨识来对上面得到的聚类分组进行再分类。
3.Recursive Clustering
首先说明一下对于token格式推断以及FD格式标识字段的定义。token格式包括两方面含义：Property以及Semantic。

• Format Inference：

  • Property：包括token是文本类型还是二进制类型，以及token是常量还是变量。类型根据tokonization就可以判断；是常量还是变量，也很好判断，对于上面得到的初始聚类结果，对每一类中的某一个token位置的取值作比较，如果是不变的自然是常量，如果是变化的，则是变量(对于变量的识别还可以加上是定长还是变长的判断)。
  • Semantic：包括长度、偏移、cookie的识别，每一个都有一套启发式规则进行辨识。

• Format Comparison：
  格式比较就是为了将推断得到报文格式进行比较，评判他们是不是相同的格式，如果是的话就会对其进行合并。对于推断得到的两种格式，按照token从左到右一次扫描，将他们每个token的Property以及Semantic进行比较。
  理想意义上，如果知道了两个token的语义是一样的那么这两个token就是匹配的。但是通常有一些字段并没有实际语义或者我们目前还不能推断得到其准确的语义信息，所以我们就需要比较这两个token的Property，包括他们的取值类型等等。在匹配时候，遵循下面一些规则：

  • 如果一个定值token的取值在一个变值token的取值范围内出现过至少一次，那么可以认为这个变值token和定值token相匹配；
  • 如果两个变值token之间取值有交叉，呢么也认为他们是匹配的
  • ……..

• Format Distinguishers：
  因为后面需要用FD字段来进行递归聚类，由于FD字段标识了协议字段之间的层次结构，而且可能一个之内存在很多各层次，所以才会使用基于FD字段的递归聚类，以eDonkey协议中的hello报文为例，其格式的BNF形式如下：
  Message –>Protocol+Length+Type+Payload
  Payload –>Hash+IP+Port+ListSize+Tag
  Tag –> ……….
  通过如下规则来辨识FD字段：

  • 首先将每一个token的取值所出现的频数记录下来，由于FD字段的取值比较固定，所以设定一个阈值，将频数小于这个阈值的token记录下来，作为FD候选字段；
  • 对于满足第一个条件的FD候选字段，将初始聚类得到的结果按照每一种FD候选集中FD的取值进行再分类，每一类对应着FD字段取值相同的一些列报文。这里会设置一个得到的子类的最小数目。
  • 最后，对上一步得到的子类进行Format Comparison，去掉格式相同的子类，那么最终留下的子类中的FD字段也就是最终确定下来的FD字段了
    正如上面的eDonkey例子所示，这样的层次可能不止一层，也就是说可能忽悠多个FD字段，所以才会有递归聚类，就是按照每次辨识出来的FD候选字段集进行聚类得到一个FD字段，再一次寻找下一个FD字段，直到结束。

需要注意的是，在每一次的聚类过程中，确定了一个FD字段后，都需要进行格式推断，因为很可能进行了再分类，以前的字段信息会发生变化，如一个变值字段变成了一个定值字段（子类范围缩小了，这个应该很好理解，举个例子之前一个类里面某一个字段取值有‘a’、‘b’、‘a’、‘c’，之前是一个变值字段，经过再聚类其中得到一个子类中其取值是‘a’、‘a’，自然也就变成了一个定值字段，正式通过这种递归聚类使得得到的初始结果不断精确）。

3.Merging
在进行初始聚类以及递归聚类过程中，其实相应的规则比较Conservative，目的是为了尽可能的将格式相同的报文分到一类中，避免将不同的分到一类中，同时也带来了问题就是可能会将相同格式的报文分到了不同的类，也就是分类太细造成过分类，于是需要Merging这一步，来进行合并。
论文中是使用token序列对其进行合并，首先只允许两个相同类型（文本类型，二进制类型）token进行合并，然后将其token类型序列进行对序列比对。在比对过程中会插入gap，gap过多其实也就意味着他们的相似度较低，于是设置了gap数量限制。个人觉得具体规则没有必要介绍，真的需要实现的话一两句话也说不清楚。
在判断两种格式是否相同时，首先判别gap限制，如果不满足，那么他们肯定不是同一类型；如果满足了，再检查他们之间不匹配的token的数量，如果最多只有一那么就认为是同一中格式进行合并。正式由于这种规则，所以其实我们在使用type-based 序列比对的时候，对于match、mismatch以及gap的分数设置是很重要的，因为结果对这些值比较敏感。