JMPscare: Introspection for Binary-Only Fuzzing

Abstract

or may even actively guide the fuzzer with waypoints [4].Especially for binary-only fuzzing, after the initial setup runs, getting deeper knowledge about the fuzzer's actual performance, and figure out shortcomings and roadblocks, can be a daunting task. Often, reverse engineers will look at the resulting coverage maps, debug hand-picked, interestinglooking inputs, and load up several collected traces in existing tools like Lighthouse [12] and Dragondance [1]. However, with thousands of queue entries for a fuzzer like AFL ++ , the tools reach their limits. Even if loading all traces as once succeeds, it is hard to spot interesting unreached jumps. A fuzzing queue, or corpus, is commonly used in feedback-based fuzzers and collects interesting test cases that led to new coverage or otherwise new feedback during execution. We deem insights into this queue important to improve the overall harness and fuzzer performance. It shows us which parts of the harness the fuzzer explored and at which branches it got stuck. On complex targets, like a full-blown RTOS, a complete view of basic-blocks (not) reached would not provide the researcher with the same insights. No harness covers all basic blocks in the target: reaching some of the branches may rely on the target to be in a different state. Non-covered basic blocks may be reached with better harnessing and mutations or be completely unreachable. The human-in-the-loop has no chance to see this difference immediately just by looking at a coverage map.To improve this situation, we developed JMPscare, an analysis toolkit that takes all traces in a fuzzer queue into account. The goal is to provide reverse engineers with full insight into their fuzzing campaigns. JMPscare efficiently uncovers nevertaken branches, so-called frontiers. To guide the human-inthe-loop towards interesting frontiers, it performs a Potential New Coverage (PNC) analysis, surfacing frontiers that can lead to large new control flows if traversed., leading to additional corner cases. JMPscare offers a quick solution to overcome simple frontiers through a single click binary patching to force execution in this direction. With this, the fuzzer traverses any roadblocks but triggers false positives if the prior condition is directly responsible for a crash. While JMPscare will work with any target, as long as a program counter trace of the executions can be acquired, JMPscare features a stand-alone trace collection with native unicornafl [11], BaseSAFE [17], and qiling [22] support. For the course of this paper, we evaluate JMPscare using the publicly available MediaTek harness and test case corpus of BaseSAFE. We are able to gather further knowledge about the harness that the original work could not collect and use, for the lack of JMPscare.

Effective fuzz testing via model-guided program synthesis

“…This demonstrates the use of the synthesized QEMU virtual machines to trigger, understand, and exploit vulnerabilities in rehosted Linux kernels. Second, we ported two fuzzing tools, UnicoreFuzz [143] and TriforceAFL [144], to show the ability to support other dynamic analysis tools on rehosted Linux kernels. These applications are not our main contribution, but they do illustrate the use cases of FIRMGUIDE.…”

Towards rigorous evaluation of binary testing and analysis

“…Another closely related effort is Maier et al 's JMPscare [172], which analyzes the cumulative coverage of a fuzzing campaign to identify the coverage frontier. The system supports patching target binaries in order to then use forced execution to cover new code across this frontier.…”