Introduction Have you ever been fuzzing a program and received a crash, only to find the input file was huge? Trying to manually determine which portions of an input file trigger the bug can be an extremely frustrating and time consuming process. Huge input files can make the triage of bugs much harder. This blog post describes a technique known as delta-debugging which can help you automatically produce an input file that is as small as possible while still triggering the bug in the original input file.
One of the things that is important to us at GRIMM is making sure there is time to experiment, and explore new ways of approaching problems. We want to answer the big questions like “How can we find vulnerabilities that other tools and manual analysis has overlooked?” This is what we are passionate about. So when one of our engineers has an idea for a new fuzzer, we try to make time for them to put their idea to the test.
In our spare time, we like to hunt for bugs in various pieces of software. To help teach people this skill, we decided to write up our analysis on some of the crashes we find. The goal is to help people learn how to debug, analyze the problem, determine why it’s happening, and what the impact is. For example, is this just something which will cause the software to crash and merely cause a brief denial of service, or is this a vulnerability which can be exploited to take complete control over the computer?