# On the Analysis of Coverage Feedback in a Fuzzing Proprietary System
## 5 Discussion
### Example Case Where Coverage Feedback Is Beneficial  
In Listing 1, a parser code snippet in one of the OSS-Fuzz projects (ntpsec-secure network time protocol implementation) demonstrates taking an array of 16-bit array data from the client as a potentially malicious input. In this example, each value in 16 bits of data determines which code to execute next. As 16 bits is a relatively small bit space to explore based on randomness, the fuzzer will quickly test all possible 65,536 cases and find new functions for additional data processing. The new function (e.g., nts_next_protocol()) triggered by specific data in this case subsequently processes the same input orthogonal to previously processed data (e.g., bytes of the buff array from the previous loop iterations). Therefore, in this case, a randomly discovered test case (that happens to trigger a new function) for invoking such a function is valuable to remember (the genetic algorithm in fuzzing applies more mutation attempts in the future to interesting inputs). Therefore, feedbacking and storing this special test case for future input mutation is beneficial for finding additional code coverage.  
```
1#include^libntp.h^
2#include^ntp.h^
3#include^ntp_proto.h^
4...
5 boolfuzz(uint8_t!>buff,intsize){
6//Whilethebuffhasmorethan4 bytes,thereisdattopcross
7 while(size>=4){
8
```
8 uint16_ttype=(uint16_t*)buff;
9 buff+=2;
10 intlength=(uint16_t*)buff;
11 buff+=2;
12 size=4;
13
14 switch(type){
15 casets_next_protocol_negotiation:
16 nego_next_protocol(&buff,&size);
17 break;
18 casets_algorithm_negotiation:
19 nego_algorithm(&buff,&size);
20 break;
21 casets_new_cookie:
22 new_cookie(&buff,&size);
23 break;
24...
25 default:
26//skipcurrentdata
27 buff+=length;
28 size==length;
29 break;
30}
31}
32 return0;
33}
```
Listing 2: Example code snippet from the Apache-APR implementation demonstrating useless coverage finding due to inline-counter feedback.

### Example Case Where Fine-Grained Coverage Feedback Is Ineffective

Listing 2 demonstrates a detailed example case in Apache-APR from the OSS-Fuzz project, where coverage expansion based on fine-grained (counting the execution attempt of the same code location and considering a greater execution count as a new code coverage) feedback is useless. For example, the SKIP_WHITESPACE macro implementation is responsible for counting white space characters from the given input byte stream. In this implementation, libFuzzer will provide feedback as a new coverage for every white-space character appended to the mutated input, as the block execution count will increase proportionate to the number of white-space characters. However, this feedback and coverage expansion do not actually contribute to finding a meaningful code path at all. However, the fuzzer will keep accumulating such mutated test cases because of the coverage feedback result. This could hinder the fuzzer's efficiency and might explain some of the evaluation results in Table 1 where coarse-grained feedback demonstrated better performance.
```
1#include\"apr_h\"
2#include\"apr_strings.h\"
3#include\"apr_private.h\"
4#include\"apr_lib.h\"
5...
6
7#defineSKIP_WHITESPACE(cp){
8 for(;*cp==''||*cp=='{'t';}{
9 cp++;}{
10};
11
12#defineCHECK_QUOTATION(cp,isquoted){
13 isquoted=0;}
14 if(*cp=='''){
15 isquoted=1;{
16 cp++;}
17}
18 elseif(*cp=='\'){
19 isquoted=2;