# SATFuzz: A Stateful Network Protocol Fuzzing Framework from a Novel Perspective
## 3 Architecture
### Test Sequence Selector  
The existing stateful network protocol fuzzing methods mainly include three steps [26; 27; 28]. First, the protocol entity is guided to a specific state to be tested through the interaction of normal messages. The sequence formed by these messages is called the pre-lead sequence. A test case composed of one or more mutated messages is then fed into the protocol entity.  
If the protocol entity crashes or does not respond for a long time after processing the test case, it is necessary to save errors for further analysis. Finally, if no abnormality is found, the communication needs to be terminated through the interaction of normal messages, and the next testing step is prepared. The sequence formed by these messages is called the post-end sequence. The test sequence is composed of the pre-lead sequence,  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline \(\mathbf{x}\)/\(\mathbf{y}\) & \(\mathbf{0}\) & \(\mathbf{1}\) & \(\mathbf{2}\) & \(\mathbf{3}\) & \(\mathbf{5}\) \\ \hline
**1** & high \({}^{*}\) & high & high & high & high & high \\
**2** & high & high & high & high & high \\
**3** & high & high & low \({}^{\#}\) & low & high \\
**4** & high & high & low & low & high \\
**5** & high & high & low & low & high \\ \hline \hline \end{tabular} \({}^{*}\) high-priority states.  
\end{table}
Table 2: State classification results.  
Figure 3: State transition diagrams produced when different states are selected for testing. (**a**) 230 as a state to be tested. (**b**) 530 as a state to be tested.  
test case, and post-end sequence, and the messages composing the pre-lead sequence and post-end sequence are called auxiliary messages.  
Once the state to be tested is selected, the existing methods select any test sequence that can reach this state from the queue, and no further screening is performed. The main components of the test sequence are auxiliary messages, which cause additional time overhead during waiting, processing, and transmission, thereby, affecting the efficiency of vulnerability discovery. Simply reducing the lengths of auxiliary messages can save time; however, this approach influences the post-end sequence when exploring the state space, which also affects the efficiency of vulnerability discovery.  
Therefore, by reasonably optimizing the auxiliary messages, we screen out the optimal test sequence (including the minimum pre-lead sequence), which is responsible for quickly leading the protocol entity to the state to be tested, and the fittest post-end sequence, which is responsible for exploring the state space in depth after no abnormalities are detected. The above information is recorded in the test file for the test sequence selector to read. The test file is written in XML, including eight different elements, as shown in Table 3. Among them, GuidingMesNum controls the minimum pre-lead sequence, which, as the name implies, is the pre-lead sequence with the least number of request messages. BackMesNum and HiPriMesPro jointly control the fittest post-end sequence to ensure that the proportion of request messages that can trigger high-priority states within a certain length remains maximized.  
In addition to ending the communication process, another function of the fittest post-end sequence is to explore the state space in depth, which requires more request messages that can be received and processed normally by the protocol entity. The request messages that meet this condition correspond to high-priority states. When a certain state to be tested simultaneously meets the minimum pre-lead sequence and fittest post-end sequence, the corresponding test sequence is recorded in OptimSeqName for the test sequence selector to select from the queue.