## 4 System Design
### Locating RC Points and Negating Procedure  
In this phase, DeepDiver uses the RC detector that pinpoints the locations of roadblock checkpoints within the target binary. There are various methods of locating the RC point in the program. One of them is TaintScope [35]. This is the first checksum-aware directed fuzz testing technique that can analyze checksum fields in input instances, accurately locate the RC in the target program according to branch profiling as well as concrete and dynamic taint tracking, and bypass detected RC points by execution flow alteration. Another option is using control flow analysis and complex data flow to track cohesion between the complex conditional jump and input. Despite the obviously impressive performance, those approaches are very high overhead and relatively costly (time-consuming). Conditional jump instructions entail a compilation of checks. It is depicted as a node in the program as well as two edges coming out from node which can either be False or True [23] in the CFG. If generated input cannot bypass the conditional jump, it passes either the False or True edge. The key idea behind this step is to find conditional jump instructions that are not covered by fuzzer-generated inputs and gather them for negation. The process of detecting RC candidates consists of two main steps: _Coverage Information_ and _RC detector models._  
To locate RC points, DeepDiver works as follows. First, DeepDiver starts fuzzing non-instrumented target binary with an initial input and during the fuzzing process if nodes and edges covered under the input, statistics of node coverages and edge coverages are collected by coverage statistics model. Then, if generated inputs cannot bypass the check, the detector designates that check as a RC candidate. The next step identifies many RC candidates by applying the _trace analysis_ technique. After the detection process, information about all RC candidates' locations are recorded. Lastly, detected RC candidate locations will negate. To do this, we use _radare2_[36] automatic reverse-engineering framework python script named _r2 pipe_[37; 38]. It should be noted that detected RC candidates may incur false positives. We demonstrate Algorithm 1 to explain the _Coverage Information_ process. In this process, the algorithm uses three inputs including _TB_ (the non-instrumented binary) as a target, the AFL++ _FuzzingTool_ and initial input, _Seed_. This process gives coverage information _CovInfo_ as output. In line 4, to generate new seeds, the _FuzzingTool_ analyzes target binary TB with the initial _Seed_. Next, coverage data is collected for each basic block _BB_ analyzed under each new seed in the _SeedPool_. All covered destinations stored into _CovInfo_ in line 7-9, as well as generated _NewSeeds_, are gathered in the _SeedPool_. By this procedure, we can easily distinguish covered and uncovered destinations, and as a result, it significantly contributes to the detection of RC locations. ```
1:\(TB\) (Target Program)
2:FuzzingTool (AFL++)
3:Seed (Initial input)
4:CovInfo \(\leftarrow\)O
5:SeedPool (NewSeeds) \(\leftarrow\)O
6:whileTrue do {
7:SeedPool \(\leftarrow\)FuzzingTool(TB, Seed)
8:forseed \(\in\)SeedPool do {
9: Coverage \(\leftarrow\)GaintedCoverage (TB, Seed)
10:forBB \(\in\)Coverage do {
11: Mark \(\leftarrow\)Info (BB)
12: CovInfo \(\leftarrow\)CovInfo \(\cup\)Mark
13: }
14: }
15: SeedPool \(\leftarrow\)SeedPool \(\cup\)NewSeeds
16: }
```  
**OUTPUT:** Coverage information (_CovInfo_); ```
**Algorithm 2** RC locations  
Algorithm 2 shows the detection process of RC destinations, and it uses three inputs. These include the coverage information _CovInfo_ as the output of Algorithm 1, _SeedPool_ which has gathered new inputs from the fuzzer and CFG control flow graph of the target program.