In this tutorial I’ll be detailing the process used to develop a Peach Pit for the RAR file format. I’ll also be discussing the use of Fixups and the steps required to implement your own custom Fixup. This article is intended to build upon the skills described in my first article so if you haven’t read it, I highly recommend doing so before continuing. You can find that article here. With that said, the following will assume that you have working level knowledge of the Peach Pit format.
A quick update, after posting this article I realized that Mike also has a very informative section on extending peach with custom fixups. You can find that article here.
To begin, let’s grab a copy of the most recent RAR tech note available here. Please note that since the tech note does not fully describe the specification, some of the information contained in this Pit has been enumerated from the UnRAR source, 010 RAR Binary Template, and other sources.
Moving right along we see that the specification is defined as a series of block-like structures, each of which contains several recurring elements. As we are unable to tell which order some of these blocks will occur, we will wrap all blocks in a choice element. Let’s first begin by creating the block structure for the “Marker Block”.
For the past several months I’ve been doing a fair amount of work with the Peach fuzzing framework. At times (many in fact), I’ve struggled with performing somewhat basic tasks with Peach but with a little perseverance and a lot of help (thanks Mike and Mikhail), I’ve been able to develop some fairly complete Peach templates. In an attempt to save those of you just beginning with Peach, I thought I’d put together a few short tutorials to help expose some of the more advanced features within the framework.
If this is your first time hearing of the Peach fuzzing framework, I invite you to take a look at the Peach project page.
I would also like to mention that this tutorial will be very similar to the one provided by Mike Eddington, on creating a Peach template for parsing WAV files. That document can be found here, at the Peach project page.
For this tutorial, we’ll be looking at the Zip file format. We’ll try and define a Peach template that covers as much functionality defined in the specification as possible. The latest Zip file format specification can be found here.
Before we begin, there are a few tools you’ll need to follow along with this tutorial.
Peach Fuzzing Framework
You must have the latest version of Peach to use the Pit included in this tutorial (rev. 2468 at the time of release). Several of the functions included in this tutorial will not work with the Peach installer. You can find the SVN information here.
010 Binary Editor
The 010 Binary Editor utilizes binary templates for parsing a variety of file formats. Included in the base install is a template for the Zip file format. This will help us to debug our Pit as we progress. You can find this software here.
In order to instruct Peach on what we’d like to fuzz, we’ll begin by creating a Peach Pit, an XML based file that provides Peach with the structure of our data, how we’d like it fuzzed, and what application we’d like to target. A Peach Pit is comprised of 5 main sections:
The DataModel is the element within our pit that we’ll use to define the structure of our data. In this case, we’ll use the DataModel to provide Peach with the structure, layout, and functionality of the Zip file format. We also have the ability within the DataModel to inform Peach which elements we do and do not want to fuzz (fuzzable elements can also be defined in the Test block).
The StateModel is responsible for managing the flow of data during the fuzz process.
The Agents are used for monitoring the behavior of an application during the fuzz process. This includes capturing data related to application state and any crashes that may be triggered during the fuzz process.
The Test Block is responsible for correlating the configuration of the StateModel, Agents, and Publishers (responsible for managing the data generated by the DataModel) into a single test case.
The Run Block is used for defining which tests will be executed during the fuzz process.. This block also manages logging of any data generated by the Agents during the fuzz process.