docs/notebooks/PICS/Sitemap.svg

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
 "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 9.0.0 (20230911.1827)
 -->
<!-- Pages: 1 -->
<svg width="1482pt" height="622pt"
 viewBox="0.00 0.00 1481.88 622.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 618)">
<polygon fill="white" stroke="none" points="-4,4 -4,-618 1477.88,-618 1477.88,4 -4,4"/>
<!-- Fuzzer -->
<g id="node1" class="node">
<title>Fuzzer</title>
<g id="a_node1"><a xlink:href="Fuzzer.ipynb" xlink:title="Fuzzing: Breaking Things with Random Inputs (Fuzzer)&#10;&#10;In this chapter, we&#39;ll start with one of the simplest test generation techniques. &#160;The key idea of random text generation, also known as fuzzing, is to feed a string of random characters into a program in the hope to uncover failures.">
<polygon fill="white" stroke="black" points="1009.62,-534 873.62,-534 873.62,-472 1015.62,-472 1015.62,-528 1009.62,-534"/>
<polyline fill="none" stroke="black" points="1009.62,-534 1009.62,-528"/>
<polyline fill="none" stroke="black" points="1015.62,-528 1009.62,-528"/>
<text text-anchor="middle" x="944.62" y="-516.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing: Breaking</text>
<text text-anchor="middle" x="944.62" y="-498.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Things</text>
<text text-anchor="middle" x="944.62" y="-480.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">with Random Inputs</text>
</a>
</g>
</g>
<!-- Coverage -->
<g id="node2" class="node">
<title>Coverage</title>
<g id="a_node2"><a xlink:href="Coverage.ipynb" xlink:title="Code Coverage (Coverage)&#10;&#10;In the previous chapter, we introduced basic fuzzing – that is, generating random inputs to test programs. &#160;How do we measure the effectiveness of these tests? &#160;One way would be to check the number (and seriousness) of bugs found; but if bugs are scarce, we need a proxy for the likelihood of a test to uncover a bug. &#160;In this chapter, we introduce the concept of code coverage, measuring which parts of a program are actually executed during a test run. &#160;Measuring such coverage is also crucial for test generators that attempt to cover as much code as possible.">
<polygon fill="white" stroke="black" points="599,-352 498.25,-352 498.25,-316 605,-316 605,-346 599,-352"/>
<polyline fill="none" stroke="black" points="599,-352 599,-346"/>
<polyline fill="none" stroke="black" points="605,-346 599,-346"/>
<text text-anchor="middle" x="551.62" y="-329.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Code Coverage</text>
</a>
</g>
</g>
<!-- Fuzzer&#45;&gt;Coverage -->
<g id="edge1" class="edge">
<title>Fuzzer&#45;&gt;Coverage</title>
<path fill="none" stroke="black" d="M873.14,-486.36C827.57,-475.14 767.86,-458.12 717.62,-436 668.87,-414.53 617.1,-381.12 584.59,-358.67"/>
<polygon fill="black" stroke="black" points="586.99,-356.07 576.79,-353.22 582.99,-361.82 586.99,-356.07"/>
</g>
<!-- SearchBasedFuzzer -->
<g id="node3" class="node">
<title>SearchBasedFuzzer</title>
<g id="a_node3"><a xlink:href="SearchBasedFuzzer.ipynb" xlink:title="Search&#45;Based Fuzzing (SearchBasedFuzzer)&#10;&#10;Sometimes we are not only interested in fuzzing as many as possible diverse program inputs, but in deriving specific test inputs that achieve some objective, such as reaching specific statements in a program. When we have an idea of what we are looking for, then we can search for it. Search algorithms are at the core of computer science, but applying classic search algorithms like breadth or depth first search to search for tests is unrealistic, because these algorithms potentially require us to look at all possible inputs. However, domain&#45;knowledge can be used to overcome this problem. For example, if we can estimate which of several program inputs is closer to the one we are looking for, then this information can guide us to reach the target quicker – this information is known as a heuristic. The way heuristics are applied systematically is captured in meta&#45;heuristic search algorithms. The &quot;meta&quot; denotes that these algorithms are generic and can be instantiated differently to different problems. Meta&#45;heuristics often take inspiration from processes observed in nature. For example, there are algorithms mimicking evolutionary processes, swarm intelligence, or chemical reactions. In general, they are much more efficient than exhaustive search approaches such that they can be applied to vast search spaces – search spaces as vast as the domain of program inputs are no problem for them.">
<polygon fill="white" stroke="black" points="872.5,-432 726.75,-432 726.75,-396 878.5,-396 878.5,-426 872.5,-432"/>
<polyline fill="none" stroke="black" points="872.5,-432 872.5,-426"/>
<polyline fill="none" stroke="black" points="878.5,-426 872.5,-426"/>
<text text-anchor="middle" x="802.62" y="-409.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Search&#45;Based Fuzzing</text>
</a>
</g>
</g>
<!-- Fuzzer&#45;&gt;SearchBasedFuzzer -->
<g id="edge2" class="edge">
<title>Fuzzer&#45;&gt;SearchBasedFuzzer</title>
<path fill="none" stroke="black" d="M894.96,-471.57C877.04,-460.59 857.13,-448.39 840.39,-438.14"/>
<polygon fill="black" stroke="black" points="842.59,-435.38 832.24,-433.14 838.93,-441.35 842.59,-435.38"/>
</g>
<!-- Grammars -->
<g id="node4" class="node">
<title>Grammars</title>
<g id="a_node4"><a xlink:href="Grammars.ipynb" xlink:title="Fuzzing with Grammars (Grammars)&#10;&#10;In the chapter on &quot;Mutation&#45;Based Fuzzing&quot;, we have seen how to use extra hints – such as sample input files – to speed up test generation. &#160;In this chapter, we take this idea one step further, by providing a specification of the legal inputs to a program. &#160;Specifying inputs via a grammar allows for very systematic and efficient test generation, in particular for complex input formats. &#160;Grammars also serve as the base for configuration fuzzing, API fuzzing, GUI fuzzing, and many more.">
<polygon fill="white" stroke="black" points="986.75,-436 896.5,-436 896.5,-392 992.75,-392 992.75,-430 986.75,-436"/>
<polyline fill="none" stroke="black" points="986.75,-436 986.75,-430"/>
<polyline fill="none" stroke="black" points="992.75,-430 986.75,-430"/>
<text text-anchor="middle" x="944.62" y="-418.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing with</text>
<text text-anchor="middle" x="944.62" y="-400.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Grammars</text>
</a>
</g>
</g>
<!-- Fuzzer&#45;&gt;Grammars -->
<g id="edge3" class="edge">
<title>Fuzzer&#45;&gt;Grammars</title>
<path fill="none" stroke="black" d="M944.62,-471.57C944.62,-463.83 944.62,-455.47 944.62,-447.62"/>
<polygon fill="black" stroke="black" points="948.13,-447.76 944.63,-437.76 941.13,-447.76 948.13,-447.76"/>
</g>
<!-- SymbolicFuzzer -->
<g id="node5" class="node">
<title>SymbolicFuzzer</title>
<g id="a_node5"><a xlink:href="SymbolicFuzzer.ipynb" xlink:title="Symbolic Fuzzing (SymbolicFuzzer)&#10;&#10;One of the problems with traditional methods of fuzzing is that they fail to exercise all the possible behaviors that a system can have, especially when the input space is large. Quite often the execution of a specific branch of execution may happen only with very specific inputs, which could represent a minimal fraction of the input space. The traditional fuzzing methods relies on chance to produce inputs they need. However, relying on randomness to generate values that we want is a bad idea when the space to be explored is huge. For example, a function that accepts a string, even if one only considers the first $10$ characters, already has $2^{80}$ possible inputs. If one is looking for a specific string, random generation of values will take a few thousand years even in one of the super computers.">
<polygon fill="white" stroke="black" points="1128.62,-432 1010.62,-432 1010.62,-396 1134.62,-396 1134.62,-426 1128.62,-432"/>
<polyline fill="none" stroke="black" points="1128.62,-432 1128.62,-426"/>
<polyline fill="none" stroke="black" points="1134.62,-426 1128.62,-426"/>
<text text-anchor="middle" x="1072.62" y="-409.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Symbolic Fuzzing</text>
</a>
</g>
</g>
<!-- Fuzzer&#45;&gt;SymbolicFuzzer -->
<g id="edge4" class="edge">
<title>Fuzzer&#45;&gt;SymbolicFuzzer</title>
<path fill="none" stroke="black" d="M989.39,-471.57C1005.24,-460.8 1022.83,-448.85 1037.73,-438.72"/>
<polygon fill="black" stroke="black" points="1039.54,-441.72 1045.85,-433.2 1035.61,-435.93 1039.54,-441.72"/>
</g>
<!-- FuzzingInTheLarge -->
<g id="node6" class="node">
<title>FuzzingInTheLarge</title>
<g id="a_node6"><a xlink:href="FuzzingInTheLarge.ipynb" xlink:title="Fuzzing in the Large (FuzzingInTheLarge)&#10;&#10;In the past chapters, we have always looked at fuzzing taking place on one machine for a few seconds only. &#160;In the real world, however, fuzzers are run on dozens or even thousands of machines; for hours, days and weeks; for one program or dozens of programs. &#160;In such contexts, one needs an infrastructure to collect failure data from the individual fuzzer runs, and to aggregate such data in a central repository. &#160;In this chapter, we will examine such an infrastructure, the FuzzManager framework from Mozilla.">
<polygon fill="white" stroke="black" points="1286.5,-432 1152.75,-432 1152.75,-396 1292.5,-396 1292.5,-426 1286.5,-432"/>
<polyline fill="none" stroke="black" points="1286.5,-432 1286.5,-426"/>
<polyline fill="none" stroke="black" points="1292.5,-426 1286.5,-426"/>
<text text-anchor="middle" x="1222.62" y="-409.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing in the Large</text>
</a>
</g>
</g>
<!-- Fuzzer&#45;&gt;FuzzingInTheLarge -->
<g id="edge5" class="edge">
<title>Fuzzer&#45;&gt;FuzzingInTheLarge</title>
<path fill="none" stroke="black" d="M1015.86,-479.71C1059.07,-466.18 1113.85,-449.04 1156.17,-435.8"/>
<polygon fill="black" stroke="black" points="1156.98,-439.21 1165.48,-432.88 1154.89,-432.53 1156.98,-439.21"/>
</g>
<!-- MutationFuzzer -->
<g id="node8" class="node">
<title>MutationFuzzer</title>
<g id="a_node8"><a xlink:href="MutationFuzzer.ipynb" xlink:title="Mutation&#45;Based Fuzzing (MutationFuzzer)&#10;&#10;Most randomly generated inputs are syntactically invalid and thus are quickly rejected by the processing program. &#160;To exercise functionality beyond input processing, we must increase chances to obtain valid inputs. &#160;One such way is so&#45;called mutational fuzzing – that is, introducing small changes to existing inputs that may still keep the input valid, yet exercise new behavior. &#160;We show how to create such mutations, and how to guide them towards yet uncovered code, applying central concepts from the popular AFL fuzzer.">
<polygon fill="white" stroke="black" points="604.25,-276 493,-276 493,-232 610.25,-232 610.25,-270 604.25,-276"/>
<polyline fill="none" stroke="black" points="604.25,-276 604.25,-270"/>
<polyline fill="none" stroke="black" points="610.25,-270 604.25,-270"/>
<text text-anchor="middle" x="551.62" y="-258.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Mutation&#45;Based</text>
<text text-anchor="middle" x="551.62" y="-240.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;MutationFuzzer -->
<g id="edge7" class="edge">
<title>Coverage&#45;&gt;MutationFuzzer</title>
<path fill="none" stroke="black" d="M551.62,-315.69C551.62,-307.46 551.62,-297.33 551.62,-287.73"/>
<polygon fill="black" stroke="black" points="555.13,-287.95 551.63,-277.95 548.13,-287.95 555.13,-287.95"/>
</g>
<!-- MutationAnalysis -->
<g id="node9" class="node">
<title>MutationAnalysis</title>
<g id="a_node9"><a xlink:href="MutationAnalysis.ipynb" xlink:title="Mutation Analysis (MutationAnalysis)&#10;&#10;In the chapter on coverage, we showed how one can identify which parts of the program are executed by a program, and hence get a sense of the effectiveness of a set of test cases in covering the program structure. &#160;However, coverage alone may not be the best measure for the effectiveness of a test, as one can have great coverage without ever checking a result for correctness. &#160;In this chapter, we introduce another means for assessing the effectiveness of a test suite: After injecting mutations – artificial faults – into the code, we check whether a test suite can detect these artificial faults. &#160;The idea is that if it fails to detect such mutations, it will also miss real bugs.">
<polygon fill="white" stroke="black" points="294.25,-272 171,-272 171,-236 300.25,-236 300.25,-266 294.25,-272"/>
<polyline fill="none" stroke="black" points="294.25,-272 294.25,-266"/>
<polyline fill="none" stroke="black" points="300.25,-266 294.25,-266"/>
<text text-anchor="middle" x="235.62" y="-249.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Mutation Analysis</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;MutationAnalysis -->
<g id="edge8" class="edge">
<title>Coverage&#45;&gt;MutationAnalysis</title>
<path fill="none" stroke="black" d="M497.88,-320.46C449.79,-309.15 377.39,-291.89 314.62,-276 313.63,-275.75 312.63,-275.49 311.63,-275.24"/>
<polygon fill="black" stroke="black" points="312.71,-271.9 302.16,-272.8 310.97,-278.68 312.71,-271.9"/>
</g>
<!-- GrammarCoverageFuzzer -->
<g id="node10" class="node">
<title>GrammarCoverageFuzzer</title>
<g id="a_node10"><a xlink:href="GrammarCoverageFuzzer.ipynb" xlink:title="Grammar Coverage (GrammarCoverageFuzzer)&#10;&#10;Producing inputs from grammars gives all possible expansions of a rule the same likelihood. &#160;For producing a comprehensive test suite, however, it makes more sense to maximize variety – for instance, by not repeating the same expansions over and over again. &#160;In this chapter, we explore how to systematically cover elements of a grammar such that we maximize variety and do not miss out individual elements.">
<polygon fill="white" stroke="black" points="1101.25,-272 972,-272 972,-236 1107.25,-236 1107.25,-266 1101.25,-272"/>
<polyline fill="none" stroke="black" points="1101.25,-272 1101.25,-266"/>
<polyline fill="none" stroke="black" points="1107.25,-266 1101.25,-266"/>
<text text-anchor="middle" x="1039.62" y="-249.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Grammar Coverage</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;GrammarCoverageFuzzer -->
<g id="edge9" class="edge">
<title>Coverage&#45;&gt;GrammarCoverageFuzzer</title>
<path fill="none" stroke="black" d="M605.34,-327.86C684.36,-319.78 836.33,-302.27 963.62,-276 965.22,-275.67 966.82,-275.33 968.44,-274.97"/>
<polygon fill="black" stroke="black" points="968.81,-278.48 977.76,-272.8 967.23,-271.66 968.81,-278.48"/>
</g>
<!-- ProbabilisticGrammarFuzzer -->
<g id="node11" class="node">
<title>ProbabilisticGrammarFuzzer</title>
<g id="a_node11"><a xlink:href="ProbabilisticGrammarFuzzer.ipynb" xlink:title="Probabilistic Grammar Fuzzing (ProbabilisticGrammarFuzzer)&#10;&#10;Let us give grammars even more power by assigning probabilities to individual expansions. &#160;This allows us to control how many of each element should be produced, and thus allows us to target our generated tests towards specific functionality. &#160;We also show how to learn such probabilities from given sample inputs, and specifically direct our tests towards input features that are uncommon in these samples.">
<polygon fill="white" stroke="black" points="466.75,-196 346.5,-196 346.5,-152 472.75,-152 472.75,-190 466.75,-196"/>
<polyline fill="none" stroke="black" points="466.75,-196 466.75,-190"/>
<polyline fill="none" stroke="black" points="472.75,-190 466.75,-190"/>
<text text-anchor="middle" x="409.62" y="-178.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Probabilistic</text>
<text text-anchor="middle" x="409.62" y="-160.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Grammar Fuzzing</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;ProbabilisticGrammarFuzzer -->
<g id="edge10" class="edge">
<title>Coverage&#45;&gt;ProbabilisticGrammarFuzzer</title>
<path fill="none" stroke="black" d="M498.09,-325.43C443.97,-316.56 365.8,-299.95 347.62,-276 335.8,-260.42 339.76,-249.91 347.62,-232 352.25,-221.46 359.9,-212.01 368.27,-203.97"/>
<polygon fill="black" stroke="black" points="370.5,-206.68 375.67,-197.43 365.86,-201.44 370.5,-206.68"/>
</g>
<!-- ConcolicFuzzer -->
<g id="node12" class="node">
<title>ConcolicFuzzer</title>
<g id="a_node12"><a xlink:href="ConcolicFuzzer.ipynb" xlink:title="Concolic Fuzzing (ConcolicFuzzer)&#10;&#10;In the chapter on information flow, we have seen how one can use dynamic taints to produce more intelligent test cases than simply looking for program crashes. We have also seen how one can use the taints to update the grammar, and hence focus more on the dangerous methods.">
<polygon fill="white" stroke="black" points="946,-112 833.25,-112 833.25,-76 952,-76 952,-106 946,-112"/>
<polyline fill="none" stroke="black" points="946,-112 946,-106"/>
<polyline fill="none" stroke="black" points="952,-106 946,-106"/>
<text text-anchor="middle" x="892.62" y="-89.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Concolic Fuzzing</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;ConcolicFuzzer -->
<g id="edge11" class="edge">
<title>Coverage&#45;&gt;ConcolicFuzzer</title>
<path fill="none" stroke="black" d="M579.14,-315.62C593.05,-305.57 609.16,-291.79 619.62,-276 651.47,-227.95 615.2,-191.02 657.62,-152 713.2,-100.9 750.56,-135.01 823.62,-116 824.29,-115.83 824.95,-115.65 825.62,-115.48"/>
<polygon fill="black" stroke="black" points="826.44,-118.88 835.16,-112.86 824.6,-112.13 826.44,-118.88"/>
</g>
<!-- DynamicInvariants -->
<g id="node13" class="node">
<title>DynamicInvariants</title>
<g id="a_node13"><a xlink:href="DynamicInvariants.ipynb" xlink:title="Mining Function Specifications (DynamicInvariants)&#10;&#10;When testing a program, one not only needs to cover its several behaviors; one also needs to check whether the result is as expected. &#160;In this chapter, we introduce a technique that allows us to mine function specifications from a set of given executions, resulting in abstract and formal descriptions of what the function expects and what it delivers.">
<polygon fill="white" stroke="black" points="468.62,-276 356.62,-276 356.62,-232 474.62,-232 474.62,-270 468.62,-276"/>
<polyline fill="none" stroke="black" points="468.62,-276 468.62,-270"/>
<polyline fill="none" stroke="black" points="474.62,-270 468.62,-270"/>
<text text-anchor="middle" x="415.62" y="-258.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Mining Function</text>
<text text-anchor="middle" x="415.62" y="-240.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Specifications</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;DynamicInvariants -->
<g id="edge12" class="edge">
<title>Coverage&#45;&gt;DynamicInvariants</title>
<path fill="none" stroke="black" d="M521.44,-315.69C504.25,-305.83 482.33,-293.26 462.9,-282.11"/>
<polygon fill="black" stroke="black" points="464.74,-279.13 454.32,-277.19 461.25,-285.2 464.74,-279.13"/>
</g>
<!-- PythonFuzzer -->
<g id="node14" class="node">
<title>PythonFuzzer</title>
<g id="a_node14"><a xlink:href="PythonFuzzer.ipynb" xlink:title="Testing Compilers (PythonFuzzer)&#10;&#10;In this chapter, we will make use of grammars and grammar&#45;based testing to systematically generate program code – for instance, to test a compiler or an interpreter. Not very surprisingly, we use Python and the Python interpreter as our domain.">
<polygon fill="white" stroke="black" points="786.38,-272 666.88,-272 666.88,-236 792.38,-236 792.38,-266 786.38,-272"/>
<polyline fill="none" stroke="black" points="786.38,-272 786.38,-266"/>
<polyline fill="none" stroke="black" points="792.38,-266 786.38,-266"/>
<text text-anchor="middle" x="729.62" y="-249.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Testing Compilers</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;PythonFuzzer -->
<g id="edge13" class="edge">
<title>Coverage&#45;&gt;PythonFuzzer</title>
<path fill="none" stroke="black" d="M591.13,-315.69C617.19,-304.27 651.56,-289.21 679.54,-276.95"/>
<polygon fill="black" stroke="black" points="680.78,-280.22 688.54,-273 677.97,-273.81 680.78,-280.22"/>
</g>
<!-- WhenToStopFuzzing -->
<g id="node15" class="node">
<title>WhenToStopFuzzing</title>
<g id="a_node15"><a xlink:href="WhenToStopFuzzing.ipynb" xlink:title="When To Stop Fuzzing (WhenToStopFuzzing)&#10;&#10;In the past chapters, we have discussed several fuzzing techniques. &#160;Knowing what to do is important, but it is also important to know when to stop doing things. &#160;In this chapter, we will learn when to stop fuzzing – and use a prominent example for this purpose: The Enigma machine that was used in the second world war by the navy of Nazi Germany to encrypt communications, and how Alan Turing and I.J. Good used fuzzing techniques to crack ciphers for the Naval Enigma machine.">
<polygon fill="white" stroke="black" points="147.25,-272 0,-272 0,-236 153.25,-236 153.25,-266 147.25,-272"/>
<polyline fill="none" stroke="black" points="147.25,-272 147.25,-266"/>
<polyline fill="none" stroke="black" points="153.25,-266 147.25,-266"/>
<text text-anchor="middle" x="76.62" y="-249.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">When To Stop Fuzzing</text>
</a>
</g>
</g>
<!-- Coverage&#45;&gt;WhenToStopFuzzing -->
<g id="edge14" class="edge">
<title>Coverage&#45;&gt;WhenToStopFuzzing</title>
<path fill="none" stroke="black" d="M498.04,-326.84C422.61,-317.79 280.98,-299.41 161.62,-276 159.73,-275.63 157.81,-275.24 155.88,-274.84"/>
<polygon fill="black" stroke="black" points="156.69,-271.44 146.17,-272.75 155.21,-278.28 156.69,-271.44"/>
</g>
<!-- GrammarFuzzer -->
<g id="node18" class="node">
<title>GrammarFuzzer</title>
<g id="a_node18"><a xlink:href="GrammarFuzzer.ipynb" xlink:title="Efficient Grammar Fuzzing (GrammarFuzzer)&#10;&#10;In the chapter on grammars, we have seen how to use grammars for very effective and efficient testing. &#160;In this chapter, we refine the previous string&#45;based algorithm into a tree&#45;based algorithm, which is much faster and allows for much more control over the production of fuzz inputs.">
<polygon fill="white" stroke="black" points="1029.25,-356 906,-356 906,-312 1035.25,-312 1035.25,-350 1029.25,-356"/>
<polyline fill="none" stroke="black" points="1029.25,-356 1029.25,-350"/>
<polyline fill="none" stroke="black" points="1035.25,-350 1029.25,-350"/>
<text text-anchor="middle" x="970.62" y="-338.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Efficient Grammar</text>
<text text-anchor="middle" x="970.62" y="-320.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing</text>
</a>
</g>
</g>
<!-- Grammars&#45;&gt;GrammarFuzzer -->
<g id="edge17" class="edge">
<title>Grammars&#45;&gt;GrammarFuzzer</title>
<path fill="none" stroke="black" d="M951.73,-391.69C954.25,-384.12 957.15,-375.43 959.91,-367.16"/>
<polygon fill="black" stroke="black" points="963.21,-368.32 963.05,-357.72 956.57,-366.1 963.21,-368.32"/>
</g>
<!-- Intro_Testing -->
<g id="node7" class="node">
<title>Intro_Testing</title>
<g id="a_node7"><a xlink:href="Intro_Testing.ipynb" xlink:title="Introduction to Software Testing (Intro_Testing)&#10;&#10;Before we get to the central parts of the book, let us introduce essential concepts of software testing. &#160;Why is it necessary to test software at all? &#160;How does one test software? &#160;How can one tell whether a test has been successful? &#160;How does one know if one has tested enough? &#160;In this chapter, let us recall the most important concepts, and at the same time get acquainted with Python and interactive notebooks.">
<polygon fill="white" stroke="black" points="999.12,-614 884.12,-614 884.12,-570 1005.12,-570 1005.12,-608 999.12,-614"/>
<polyline fill="none" stroke="black" points="999.12,-614 999.12,-608"/>
<polyline fill="none" stroke="black" points="1005.12,-608 999.12,-608"/>
<text text-anchor="middle" x="944.62" y="-596.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Introduction to</text>
<text text-anchor="middle" x="944.62" y="-578.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Software Testing</text>
</a>
</g>
</g>
<!-- Intro_Testing&#45;&gt;Fuzzer -->
<g id="edge6" class="edge">
<title>Intro_Testing&#45;&gt;Fuzzer</title>
<path fill="none" stroke="black" d="M944.62,-569.94C944.62,-562.61 944.62,-554.11 944.62,-545.7"/>
<polygon fill="black" stroke="black" points="948.13,-545.92 944.63,-535.92 941.13,-545.92 948.13,-545.92"/>
</g>
<!-- GreyboxFuzzer -->
<g id="node16" class="node">
<title>GreyboxFuzzer</title>
<g id="a_node16"><a xlink:href="GreyboxFuzzer.ipynb" xlink:title="Greybox Fuzzing (GreyboxFuzzer)&#10;&#10;In the previous chapter, we have introduced mutation&#45;based fuzzing, a technique that generates fuzz inputs by applying small mutations to given inputs. In this chapter, we show how to guide these mutations towards specific goals such as coverage. The algorithms in this chapter stem from the popular American Fuzzy Lop (AFL) fuzzer, in particular from its AFLFast and AFLGo flavors. We will explore the greybox fuzzing algorithm behind AFL and how we can exploit it to solve various problems for automated vulnerability detection.">
<polygon fill="white" stroke="black" points="604.38,-192 490.88,-192 490.88,-156 610.38,-156 610.38,-186 604.38,-192"/>
<polyline fill="none" stroke="black" points="604.38,-192 604.38,-186"/>
<polyline fill="none" stroke="black" points="610.38,-186 604.38,-186"/>
<text text-anchor="middle" x="550.62" y="-169.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Greybox Fuzzing</text>
</a>
</g>
</g>
<!-- MutationFuzzer&#45;&gt;GreyboxFuzzer -->
<g id="edge15" class="edge">
<title>MutationFuzzer&#45;&gt;GreyboxFuzzer</title>
<path fill="none" stroke="black" d="M551.35,-231.69C551.24,-223.09 551.11,-213.05 550.99,-203.82"/>
<polygon fill="black" stroke="black" points="554.49,-203.81 550.87,-193.86 547.5,-203.9 554.49,-203.81"/>
</g>
<!-- GrammarMiner -->
<g id="node24" class="node">
<title>GrammarMiner</title>
<g id="a_node24"><a xlink:href="GrammarMiner.ipynb" xlink:title="Mining Input Grammars (GrammarMiner)&#10;&#10;So far, the grammars we have seen have been mostly specified manually – that is, you (or the person knowing the input format) had to design and write a grammar in the first place. &#160;While the grammars we have seen so far have been rather simple, creating a grammar for complex inputs can involve quite some effort. &#160;In this chapter, we therefore introduce techniques that automatically mine grammars from programs – by executing the programs and observing how they process which parts of the input. &#160;In conjunction with a grammar fuzzer, this allows us to &#10;1. take a program, &#10;2. extract its input grammar, and &#10;3. fuzz it with high efficiency and effectiveness, using the concepts in this book.">
<polygon fill="white" stroke="black" points="1093.12,-116 1002.12,-116 1002.12,-72 1099.12,-72 1099.12,-110 1093.12,-116"/>
<polyline fill="none" stroke="black" points="1093.12,-116 1093.12,-110"/>
<polyline fill="none" stroke="black" points="1099.12,-110 1093.12,-110"/>
<text text-anchor="middle" x="1050.62" y="-98.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Mining Input</text>
<text text-anchor="middle" x="1050.62" y="-80.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Grammars</text>
</a>
</g>
</g>
<!-- GrammarCoverageFuzzer&#45;&gt;GrammarMiner -->
<g id="edge25" class="edge">
<title>GrammarCoverageFuzzer&#45;&gt;GrammarMiner</title>
<path fill="none" stroke="black" d="M1068,-235.53C1081.15,-225.71 1095.45,-212.18 1102.62,-196 1110.56,-178.13 1109.69,-170.23 1102.62,-152 1098.75,-142 1092.21,-132.68 1085.06,-124.6"/>
<polygon fill="black" stroke="black" points="1087.64,-122.23 1078.2,-117.43 1082.58,-127.07 1087.64,-122.23"/>
</g>
<!-- ConfigurationFuzzer -->
<g id="node25" class="node">
<title>ConfigurationFuzzer</title>
<g id="a_node25"><a xlink:href="ConfigurationFuzzer.ipynb" xlink:title="Testing Configurations (ConfigurationFuzzer)&#10;&#10;The behavior of a program is not only governed by its data. &#160;The configuration of a program – that is, the settings that govern the execution of a program on its (regular) input data, as set by options or configuration files – just as well influences behavior, and thus can and should be tested. &#160;In this chapter, we explore how to systematically test and cover software configurations. &#160;By automatically inferring configuration options, we can apply these techniques out of the box, with no need for writing a grammar. &#160;Finally, we show how to systematically cover combinations of configuration options, quickly detecting unwanted interferences.">
<polygon fill="white" stroke="black" points="1087.75,-196 985.5,-196 985.5,-152 1093.75,-152 1093.75,-190 1087.75,-196"/>
<polyline fill="none" stroke="black" points="1087.75,-196 1087.75,-190"/>
<polyline fill="none" stroke="black" points="1093.75,-190 1087.75,-190"/>
<text text-anchor="middle" x="1039.62" y="-178.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Testing</text>
<text text-anchor="middle" x="1039.62" y="-160.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Configurations</text>
</a>
</g>
</g>
<!-- GrammarCoverageFuzzer&#45;&gt;ConfigurationFuzzer -->
<g id="edge26" class="edge">
<title>GrammarCoverageFuzzer&#45;&gt;ConfigurationFuzzer</title>
<path fill="none" stroke="black" d="M1039.62,-235.69C1039.62,-227.46 1039.62,-217.33 1039.62,-207.73"/>
<polygon fill="black" stroke="black" points="1043.13,-207.95 1039.63,-197.95 1036.13,-207.95 1043.13,-207.95"/>
</g>
<!-- Carver -->
<g id="node26" class="node">
<title>Carver</title>
<g id="a_node26"><a xlink:href="Carver.ipynb" xlink:title="Carving Unit Tests (Carver)&#10;&#10;So far, we have always generated system input, i.e. data that the program as a whole obtains via its input channels. &#160;If we are interested in testing only a small set of functions, having to go through the system can be very inefficient. &#160;This chapter introduces a technique known as carving, which, given a system test, automatically extracts a set of unit tests that replicate the calls seen during the system test. &#160;The key idea is to record such calls such that we can replay them later – as a whole or selectively. &#160;On top, we also explore how to synthesize API grammars from carved unit tests; this means that we can synthesize API tests without having to write a grammar at all.">
<polygon fill="white" stroke="black" points="937.25,-36 814,-36 814,0 943.25,0 943.25,-30 937.25,-36"/>
<polyline fill="none" stroke="black" points="937.25,-36 937.25,-30"/>
<polyline fill="none" stroke="black" points="943.25,-30 937.25,-30"/>
<text text-anchor="middle" x="878.62" y="-13.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Carving Unit Tests</text>
</a>
</g>
</g>
<!-- GrammarCoverageFuzzer&#45;&gt;Carver -->
<g id="edge27" class="edge">
<title>GrammarCoverageFuzzer&#45;&gt;Carver</title>
<path fill="none" stroke="black" d="M1077.47,-235.69C1093.22,-226.35 1109.84,-213.16 1118.62,-196 1130.13,-173.52 1113.94,-77.89 1108.62,-72 1088.15,-49.32 1013.47,-35.08 954.69,-27.14"/>
<polygon fill="black" stroke="black" points="955.42,-23.7 945.05,-25.88 954.51,-30.64 955.42,-23.7"/>
</g>
<!-- GUIFuzzer -->
<g id="node27" class="node">
<title>GUIFuzzer</title>
<g id="a_node27"><a xlink:href="GUIFuzzer.ipynb" xlink:title="Testing Graphical User Interfaces (GUIFuzzer)&#10;&#10;In this chapter, we explore how to generate tests for Graphical User Interfaces (GUIs), abstracting from our previous examples on Web testing. &#160;Building on general means to extract user interface elements and activate them, our techniques generalize to arbitrary graphical user interfaces, from rich Web applications to mobile apps, and systematically explore user interfaces through forms and navigation elements.">
<polygon fill="white" stroke="black" points="1394.25,-196 1277,-196 1277,-152 1400.25,-152 1400.25,-190 1394.25,-196"/>
<polyline fill="none" stroke="black" points="1394.25,-196 1394.25,-190"/>
<polyline fill="none" stroke="black" points="1400.25,-190 1394.25,-190"/>
<text text-anchor="middle" x="1338.62" y="-178.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Testing Graphical</text>
<text text-anchor="middle" x="1338.62" y="-160.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">User Interfaces</text>
</a>
</g>
</g>
<!-- GrammarCoverageFuzzer&#45;&gt;GUIFuzzer -->
<g id="edge28" class="edge">
<title>GrammarCoverageFuzzer&#45;&gt;GUIFuzzer</title>
<path fill="none" stroke="black" d="M1103.47,-235.51C1107.92,-234.31 1112.34,-233.13 1116.62,-232 1166.34,-218.84 1222.45,-204.44 1265.81,-193.4"/>
<polygon fill="black" stroke="black" points="1266.54,-196.83 1275.37,-190.97 1264.82,-190.05 1266.54,-196.83"/>
</g>
<!-- APIFuzzer -->
<g id="node29" class="node">
<title>APIFuzzer</title>
<g id="a_node29"><a xlink:href="APIFuzzer.ipynb" xlink:title="Fuzzing APIs (APIFuzzer)&#10;&#10;So far, we have always generated system input, i.e. data that the program as a whole obtains via its input channels. &#160;However, we can also generate inputs that go directly into individual functions, gaining flexibility and speed in the process. &#160;In this chapter, we explore the use of grammars to synthesize code for function calls, which allows you to generate program code that very efficiently invokes functions directly.">
<polygon fill="white" stroke="black" points="640.38,-112 550.88,-112 550.88,-76 646.38,-76 646.38,-106 640.38,-112"/>
<polyline fill="none" stroke="black" points="640.38,-112 640.38,-106"/>
<polyline fill="none" stroke="black" points="646.38,-106 640.38,-106"/>
<text text-anchor="middle" x="598.62" y="-89.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing APIs</text>
</a>
</g>
</g>
<!-- ProbabilisticGrammarFuzzer&#45;&gt;APIFuzzer -->
<g id="edge32" class="edge">
<title>ProbabilisticGrammarFuzzer&#45;&gt;APIFuzzer</title>
<path fill="none" stroke="black" d="M461.52,-151.58C487.74,-140.76 519.5,-127.66 545.84,-116.78"/>
<polygon fill="black" stroke="black" points="547.09,-120.06 554.99,-113.01 544.42,-113.59 547.09,-120.06"/>
</g>
<!-- GreyboxGrammarFuzzer -->
<g id="node17" class="node">
<title>GreyboxGrammarFuzzer</title>
<g id="a_node17"><a xlink:href="GreyboxGrammarFuzzer.ipynb" xlink:title="Greybox Fuzzing with Grammars (GreyboxGrammarFuzzer)&#10;&#10;In this chapter, we introduce important extensions to our syntactic fuzzing techniques, all leveraging syntactic parts of existing inputs.">
<polygon fill="white" stroke="black" points="809.12,-116 664.12,-116 664.12,-72 815.12,-72 815.12,-110 809.12,-116"/>
<polyline fill="none" stroke="black" points="809.12,-116 809.12,-110"/>
<polyline fill="none" stroke="black" points="815.12,-110 809.12,-110"/>
<text text-anchor="middle" x="739.62" y="-98.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Greybox Fuzzing with</text>
<text text-anchor="middle" x="739.62" y="-80.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Grammars</text>
</a>
</g>
</g>
<!-- GreyboxFuzzer&#45;&gt;GreyboxGrammarFuzzer -->
<g id="edge16" class="edge">
<title>GreyboxFuzzer&#45;&gt;GreyboxGrammarFuzzer</title>
<path fill="none" stroke="black" d="M592.57,-155.69C617.45,-145.42 649.46,-132.21 677.25,-120.74"/>
<polygon fill="black" stroke="black" points="678.37,-124.07 686.28,-117.02 675.7,-117.6 678.37,-124.07"/>
</g>
<!-- GrammarFuzzer&#45;&gt;GrammarCoverageFuzzer -->
<g id="edge18" class="edge">
<title>GrammarFuzzer&#45;&gt;GrammarCoverageFuzzer</title>
<path fill="none" stroke="black" d="M989.48,-311.69C997.94,-302.13 1007.98,-290.77 1016.85,-280.74"/>
<polygon fill="black" stroke="black" points="1019.27,-283.29 1023.28,-273.48 1014.03,-278.65 1019.27,-283.29"/>
</g>
<!-- GrammarFuzzer&#45;&gt;PythonFuzzer -->
<g id="edge23" class="edge">
<title>GrammarFuzzer&#45;&gt;PythonFuzzer</title>
<path fill="none" stroke="black" d="M905.72,-311.99C871.26,-300.84 829.01,-287.17 794.54,-276.01"/>
<polygon fill="black" stroke="black" points="795.67,-272.7 785.08,-272.95 793.52,-279.36 795.67,-272.7"/>
</g>
<!-- Parser -->
<g id="node19" class="node">
<title>Parser</title>
<g id="a_node19"><a xlink:href="Parser.ipynb" xlink:title="Parsing Inputs (Parser)&#10;&#10;In the chapter on Grammars, we discussed how grammars can be&#10;used to represent various languages. We also saw how grammars can be used to&#10;generate strings of the corresponding language. Grammars can also perform the&#10;reverse. That is, given a string, one can decompose the string into its&#10;constituent parts that correspond to the parts of grammar used to generate it&#10;– the derivation tree of that string. These parts (and parts from other similar&#10;strings) can later be recombined using the same grammar to produce new strings.">
<polygon fill="white" stroke="black" points="948.25,-272 849,-272 849,-236 954.25,-236 954.25,-266 948.25,-272"/>
<polyline fill="none" stroke="black" points="948.25,-272 948.25,-266"/>
<polyline fill="none" stroke="black" points="954.25,-266 948.25,-266"/>
<text text-anchor="middle" x="901.62" y="-249.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Parsing Inputs</text>
</a>
</g>
</g>
<!-- GrammarFuzzer&#45;&gt;Parser -->
<g id="edge19" class="edge">
<title>GrammarFuzzer&#45;&gt;Parser</title>
<path fill="none" stroke="black" d="M951.77,-311.69C943.31,-302.13 933.27,-290.77 924.4,-280.74"/>
<polygon fill="black" stroke="black" points="927.22,-278.65 917.97,-273.48 921.98,-283.29 927.22,-278.65"/>
</g>
<!-- GeneratorGrammarFuzzer -->
<g id="node20" class="node">
<title>GeneratorGrammarFuzzer</title>
<g id="a_node20"><a xlink:href="GeneratorGrammarFuzzer.ipynb" xlink:title="Fuzzing with Generators (GeneratorGrammarFuzzer)&#10;&#10;In this chapter, we show how to extend grammars with functions – pieces of code that get executed during grammar expansion, and that can generate, check, or change elements produced. &#160;Adding functions to a grammar allows for very versatile test generation, bringing together the best of grammar generation and programming.">
<polygon fill="white" stroke="black" points="756.75,-196 666.5,-196 666.5,-152 762.75,-152 762.75,-190 756.75,-196"/>
<polyline fill="none" stroke="black" points="756.75,-196 756.75,-190"/>
<polyline fill="none" stroke="black" points="762.75,-190 756.75,-190"/>
<text text-anchor="middle" x="714.62" y="-178.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing with</text>
<text text-anchor="middle" x="714.62" y="-160.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Generators</text>
</a>
</g>
</g>
<!-- GrammarFuzzer&#45;&gt;GeneratorGrammarFuzzer -->
<g id="edge20" class="edge">
<title>GrammarFuzzer&#45;&gt;GeneratorGrammarFuzzer</title>
<path fill="none" stroke="black" d="M905.9,-311.54C883.72,-302.49 859.5,-290.63 839.62,-276 818.81,-260.68 821.06,-249.02 801.62,-232 789.49,-221.37 775.23,-211.22 761.81,-202.51"/>
<polygon fill="black" stroke="black" points="763.83,-199.64 753.51,-197.25 760.08,-205.56 763.83,-199.64"/>
</g>
<!-- Reducer -->
<g id="node21" class="node">
<title>Reducer</title>
<g id="a_node21"><a xlink:href="Reducer.ipynb" xlink:title="Reducing Failure&#45;Inducing Inputs (Reducer)&#10;&#10;By construction, fuzzers create inputs that may be hard to read. &#160;This causes issues during debugging, when a human has to analyze the exact cause of the failure. &#160;In this chapter, we present techniques that automatically reduce and simplify failure&#45;inducing inputs to a minimum in order to ease debugging.">
<polygon fill="white" stroke="black" points="1357.62,-276 1239.62,-276 1239.62,-232 1363.62,-232 1363.62,-270 1357.62,-276"/>
<polyline fill="none" stroke="black" points="1357.62,-276 1357.62,-270"/>
<polyline fill="none" stroke="black" points="1363.62,-270 1357.62,-270"/>
<text text-anchor="middle" x="1301.62" y="-258.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Reducing Failure&#45;</text>
<text text-anchor="middle" x="1301.62" y="-240.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Inducing Inputs</text>
</a>
</g>
</g>
<!-- GrammarFuzzer&#45;&gt;Reducer -->
<g id="edge21" class="edge">
<title>GrammarFuzzer&#45;&gt;Reducer</title>
<path fill="none" stroke="black" d="M1035.57,-320.11C1085.78,-309.84 1157.22,-294.56 1228.4,-276.5"/>
<polygon fill="black" stroke="black" points="1229.07,-279.94 1237.89,-274.07 1227.34,-273.16 1229.07,-279.94"/>
</g>
<!-- FuzzingWithConstraints -->
<g id="node22" class="node">
<title>FuzzingWithConstraints</title>
<g id="a_node22"><a xlink:href="FuzzingWithConstraints.ipynb" xlink:title="Fuzzing with Constraints (FuzzingWithConstraints)&#10;&#10;In previous chapters, we have seen how Grammar&#45;Based Fuzzing allows us to efficiently generate myriads of syntactically valid inputs.&#10;However, there are semantic input features that cannot be expressed in a context&#45;free grammar, such as">
<polygon fill="white" stroke="black" points="1215.75,-276 1125.5,-276 1125.5,-232 1221.75,-232 1221.75,-270 1215.75,-276"/>
<polyline fill="none" stroke="black" points="1215.75,-276 1215.75,-270"/>
<polyline fill="none" stroke="black" points="1221.75,-270 1215.75,-270"/>
<text text-anchor="middle" x="1173.62" y="-258.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Fuzzing with</text>
<text text-anchor="middle" x="1173.62" y="-240.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Constraints</text>
</a>
</g>
</g>
<!-- GrammarFuzzer&#45;&gt;FuzzingWithConstraints -->
<g id="edge22" class="edge">
<title>GrammarFuzzer&#45;&gt;FuzzingWithConstraints</title>
<path fill="none" stroke="black" d="M1026.36,-311.58C1053.84,-301.03 1086.98,-288.29 1114.85,-277.58"/>
<polygon fill="black" stroke="black" points="1115.76,-280.98 1123.84,-274.13 1113.25,-274.45 1115.76,-280.98"/>
</g>
<!-- WebFuzzer -->
<g id="node23" class="node">
<title>WebFuzzer</title>
<g id="a_node23"><a xlink:href="WebFuzzer.ipynb" xlink:title="Testing Web Applications (WebFuzzer)&#10;&#10;In this chapter, we explore how to generate tests for Graphical User Interfaces (GUIs), notably on Web interfaces. &#160;We set up a (vulnerable) Web server and demonstrate how to systematically explore its behavior – first with handwritten grammars, then with grammars automatically inferred from the user interface. &#160;We also show how to conduct systematic attacks on these servers, notably with code and SQL injection.">
<polygon fill="white" stroke="black" points="1467.88,-276 1381.38,-276 1381.38,-232 1473.88,-232 1473.88,-270 1467.88,-276"/>
<polyline fill="none" stroke="black" points="1467.88,-276 1467.88,-270"/>
<polyline fill="none" stroke="black" points="1473.88,-270 1467.88,-270"/>
<text text-anchor="middle" x="1427.62" y="-258.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Testing Web</text>
<text text-anchor="middle" x="1427.62" y="-240.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Applications</text>
</a>
</g>
</g>
<!-- GrammarFuzzer&#45;&gt;WebFuzzer -->
<g id="edge24" class="edge">
<title>GrammarFuzzer&#45;&gt;WebFuzzer</title>
<path fill="none" stroke="black" d="M1035.55,-328.29C1113.41,-321.65 1247.76,-307.04 1370.01,-276.41"/>
<polygon fill="black" stroke="black" points="1370.76,-279.84 1379.58,-273.97 1369.03,-273.05 1370.76,-279.84"/>
</g>
<!-- Parser&#45;&gt;ProbabilisticGrammarFuzzer -->
<g id="edge29" class="edge">
<title>Parser&#45;&gt;ProbabilisticGrammarFuzzer</title>
<path fill="none" stroke="black" d="M848.6,-240.89C833.48,-237.7 816.95,-234.47 801.62,-232 663.91,-209.84 623.97,-223.41 484.21,-196.35"/>
<polygon fill="black" stroke="black" points="485.05,-192.95 474.57,-194.44 483.7,-199.82 485.05,-192.95"/>
</g>
<!-- Parser&#45;&gt;GreyboxGrammarFuzzer -->
<g id="edge30" class="edge">
<title>Parser&#45;&gt;GreyboxGrammarFuzzer</title>
<path fill="none" stroke="black" d="M866.5,-235.72C848.27,-225.7 826.38,-211.92 809.62,-196 788.09,-175.54 769.28,-147.47 756.59,-126.11"/>
<polygon fill="black" stroke="black" points="759.67,-124.44 751.63,-117.53 753.61,-127.94 759.67,-124.44"/>
</g>
<!-- InformationFlow -->
<g id="node28" class="node">
<title>InformationFlow</title>
<g id="a_node28"><a xlink:href="InformationFlow.ipynb" xlink:title="Tracking Information Flow (InformationFlow)&#10;&#10;We have explored how one could generate better inputs that can penetrate deeper into the program in question. While doing so, we have relied on program crashes to tell us that we have succeeded in finding problems in the program. However, that is rather simplistic. What if the behavior of the program is simply incorrect, but does not lead to a crash? Can one do better?">
<polygon fill="white" stroke="black" points="961,-196 818.25,-196 818.25,-152 967,-152 967,-190 961,-196"/>
<polyline fill="none" stroke="black" points="961,-196 961,-190"/>
<polyline fill="none" stroke="black" points="967,-190 961,-190"/>
<text text-anchor="middle" x="892.62" y="-178.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Tracking Information</text>
<text text-anchor="middle" x="892.62" y="-160.7" font-family="Patua One, Helvetica, sans-serif" font-size="14.00" fill="#b03a2e">Flow</text>
</a>
</g>
</g>
<!-- Parser&#45;&gt;InformationFlow -->
<g id="edge31" class="edge">
<title>Parser&#45;&gt;InformationFlow</title>
<path fill="none" stroke="black" d="M899.63,-235.69C898.68,-227.46 897.51,-217.33 896.4,-207.73"/>
<polygon fill="black" stroke="black" points="899.9,-207.48 895.27,-197.94 892.94,-208.28 899.9,-207.48"/>
</g>
<!-- GeneratorGrammarFuzzer&#45;&gt;APIFuzzer -->
<g id="edge33" class="edge">
<title>GeneratorGrammarFuzzer&#45;&gt;APIFuzzer</title>
<path fill="none" stroke="black" d="M682.93,-151.69C667.71,-141.45 649.42,-129.15 633.77,-118.63"/>
<polygon fill="black" stroke="black" points="635.93,-115.87 625.68,-113.19 632.02,-121.68 635.93,-115.87"/>
</g>
<!-- WebFuzzer&#45;&gt;GUIFuzzer -->
<g id="edge37" class="edge">
<title>WebFuzzer&#45;&gt;GUIFuzzer</title>
<path fill="none" stroke="black" d="M1403.31,-231.69C1393.49,-223.09 1382.02,-213.03 1371.49,-203.8"/>
<polygon fill="black" stroke="black" points="1373.88,-201.24 1364.05,-197.29 1369.27,-206.51 1373.88,-201.24"/>
</g>
<!-- InformationFlow&#45;&gt;ConcolicFuzzer -->
<g id="edge35" class="edge">
<title>InformationFlow&#45;&gt;ConcolicFuzzer</title>
<path fill="none" stroke="black" d="M892.62,-151.69C892.62,-143.09 892.62,-133.05 892.62,-123.82"/>
<polygon fill="black" stroke="black" points="896.13,-123.86 892.63,-113.86 889.13,-123.86 896.13,-123.86"/>
</g>
<!-- InformationFlow&#45;&gt;GrammarMiner -->
<g id="edge34" class="edge">
<title>InformationFlow&#45;&gt;GrammarMiner</title>
<path fill="none" stroke="black" d="M935.8,-151.69C954.71,-142.35 977.09,-131.3 997.04,-121.45"/>
<polygon fill="black" stroke="black" points="998.45,-124.66 1005.87,-117.09 995.36,-118.38 998.45,-124.66"/>
</g>
<!-- APIFuzzer&#45;&gt;Carver -->
<g id="edge36" class="edge">
<title>APIFuzzer&#45;&gt;Carver</title>
<path fill="none" stroke="black" d="M643.69,-75.54C647.37,-74.29 651.05,-73.09 654.62,-72 703.33,-57.17 759.04,-43.97 802.72,-34.46"/>
<polygon fill="black" stroke="black" points="803.32,-37.91 812.36,-32.38 801.85,-31.07 803.32,-37.91"/>
</g>
</g>
</svg>