# SATFuzz: A Stateful Network Protocol Fuzzing Framework from a Novel Perspective
## 3 Architecture
### State Selector  
Existing methods treat states equally and use polling to select states for testing. Different states have different capabilities for exploring the state space of the protocol entity, and this directly affects the efficiency of vulnerability discovery. A state in this paper is identified by xyz, which is a three-digit number, where each number has a specific meaning [25]. The first digit defines the type of the state, which is 1 yz (the initial state), 2 yz (the complete state), 3 yz (the intermediate state), 4 yz (the temporary rejection state), or 5 yz (the permanent rejection state); the second digit defines the meaning of the state, which is x0z (syntax), x1z (request), x2z (connection), x3z (authentication), or x5z (file); and the third digit gives the state a richer meaning. Therefore, we rank states in order of importance by referring to the meaning of the first two digits, and the classification results are shown in Table 2.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**State Symbol** & **Status Code** & **Input Symbol** &
\begin{tabular}{c} **Request Message** \\ **Type** \\ \end{tabular} \\ \hline \(s_{0}\) & 220 & \(i_{1}\) & USER \\ \(s_{1}\) & 331 & \(i_{2}\) & PASS \\ \(s_{2}\) & 230 & \(i_{3}\) & PWD \\ \(s_{3}\) & 257 & \(i_{4}\) & TYPE \\ \(s_{4}\) & 200 & \(i_{5}\) & STOR \\ \(s_{5}\) & 150 & \(i_{6}\) & MKD \\ \(s_{6}\) & 250 & \(i_{7}\) & RETR \\ \(s_{7}\) & 221 & \(i_{8}\) & RMD \\  & & \(i_{9}\) & CVD \\  & & \(i_{10}\) & DELE \\  & & \(i_{11}\) & CDUP \\  & & \(i_{12}\) & QUIT \\ \hline \hline \end{tabular}
\end{table}
Table 1: Specific values corresponding to different state symbols and input symbols.  
Figure 2: The SFSM of the FTP.  
One contains low-priority states, including 32z, 33z, 42z, 43z, 52z, and 53z. A protocol entity in these states remains unchanged with a high probability after processing test cases. In contrast, the remaining cases belong to high-priority states. A protocol entity in these states transitions to the new state with a high probability after processing test cases.  
In the beginning, the state selector randomly selects states to test among the high-priority states for certain cycles. Then, it chooses the states that achieved outstanding performance in contributing to increased code or state-space coverage when previously selected. Now, we illustrate how the selected states affect state-space exploration. Suppose we perform fuzzing on LightFTP, a server that implements the FTP and one of the subjects in our evaluation, with the test case (\"MKD test\") and the post-end sequence (\"CWD test+STOR test.txt+LIST+QUIT\").  
As shown in Figure 3a, the number of covered unique state transitions is 6 when one of the high-priority states (230) is tested. In contrast, as shown in Figure 3b, the number of covered unique state transitions is only 2 when one of the low-priority states (530) is tested, and the state-space coverage rate is reduced by 66.7%. For the FTP, 230 means that the user logs in successfully, and subsequent request messages can play their original role only under this condition. Otherwise, all these requests are not allowed, resulting in a loop in the single state.