  Fuzzing is one of the most popular and widely used techniques to find
vulnerabilities in any application. Fuzzers are fast enough, but they still
spend a good portion of time to restart a crashed application and then fuzz it
from the beginning. Fuzzing an application from a point deeper in the execution
is also important. To do this, a user needs to take a snapshot of the program
while fuzzing it on top of an emulator, virtual machine, or by utilizing a
special kernel module to enable checkpointing. Even with this ability, it can
be difficult to attach a fuzzer after restoring a checkpoint. As a result, most
fuzzers leverage a form of fork-server design.
  We propose a novel testing architecture that allows users to attach a fuzzer
after the program has started running. We do this by natively checkpointing the
target application at a point of interest, and attaching the fuzzer after
restoring the checkpoint. A fork-server may even be engaged at the point of
restoration. This not only improves the throughput of the fuzzing campaign by
minimizing startup time, but opens up a new way to fuzz applications. With this
architecture, a user can take a series of checkpoints at points of interest,
and run parallel tests to reduce the overall state-complexity of an individual
test. Checkpoints allow us to begin fuzzing from a deeper point in the
execution path, omitting prior execution from the required coverage path. This
and other checkpointing techniques are described in the paper to help improve
fuzzing.
