PEACHTECH

PEACH FUZZER® FOR FIRMWARE FUZZING WHITEPAPER

Peach.tech

2

PEACHTECH1-844-55-PEACH | sales@peach.tech

www.peach.tech

The Peach Fuzzer Platform is a general-purpose fuzzer capable of testing a wide variety of targets. The Peach Platform excels at fuzzing complex configurations and custom data formats and interfaces. Fuzzing firmware on embedded systems, or individual chips presents several challenges that differ from typical fuzzing scenarios. Additionally, the interfaces used to communicate with the firmware are custom in the data formats they accept and the protocols they speak. In this document, the solutions to these challenges are discussed.

About Firmware and Embedded SystemsFirmware implements various functions inside an embedded system and should be considered low-level code that accesses resources directly. The function of firmware varies, depending on the device or chip in question. The one constant is the ability to process data—making an embedded system an interesting target for fuzzing. The interfaces used to communicate with firmware also vary widely, ranging from standard low-level bus protocols such as SPI, I2C or USB, to proprietary hardware interfaces and custom protocols. As such, this is not a one-solution-fits-all scenario.

Generally, communication with firmware divides into two broad categories: external and internal to the device. In the following diagram, external communication is shown on the left and internal on the right. In both cases, an interface provides the communication ability.

About the Test ConfigurationIn the external case, this interface is physical. A hardware interface is needed that allows Peach to communicate with the firmware. If the interface is already supported by Peach, the process is relatively easy. Otherwise, a module will need to be written to provide support, using the Peach plugin API. This module is an I/O adapter, or a publisher in Peach terminology. Deja vu Security, LLC, can be contracted to write the module if needed.

The internal case requires a local agent running on the device that facilitates brokering the data between Peach and the firmware interface. The Peach SDK contains several examples of such agent code in different languages such as C, C++, and Python. If the device is running a modern operating system supported by Peach with a sufficiently-powerful processor, the .NET Peach agent can also be used. The agents provided in C and C++ are intended for use on smaller architectures that do not support the Linux .NET runtime.

MonitoringOnce Peach can communicate with the firmware interface selected for fuzzing, methods for performing fault detection, data collection, and automation must be configured. These actions are performed using the monitoring features of Peach. Peach Fuzzer ships with a number of monitor modules already included for performing common functions such as attaching debuggers, taking network captures, and running programs.

Monitoring consists of the following aspects:

• Identify a fault that occurred in the target firmware

• Cause Peach to log information about the test case in which the issue was detected

• Reset the target to a known good state so testing can continue

Fault detection for the firmware depends on the expected result of the fault. If the entire device stops functioning, detection could be simple, such as sending a network ping if

External Process or

Device

Firmware

Device

Inte

rfac

e

ProcessFirmware

Device

Inte

rfac

e

AdapterFirmware

Device

Inte

rfac

e

Module

Peach

AdapterFirmware

Device

Inte

rfac

e

Peach

3

PEACHTECH1-844-55-PEACH | sales@peach.tech

www.peach.tech

the device has a network interface. If only the firmware stops responding, Peach can be configured to check for proper responses (called control iterations). More advanced fault detection configurations can use kernel debugging, which enables the collection of additional information about crashes.

Data collection is performed to collect useful information to help analyze faults found through fuzzing. Any data deemed interesting can be collected: network traffic, files from the device, and log output.

Finally, automation allows the target to be started and correctly configured for testing. If a fault occurs, the automation should restart the device in a clean state that allows testing to continue. Automation tasks can include

controlling power to the device through a networked power strip, running commands both locally on the device and remotely from another device, and interfacing with physical components such as static LEDs or buttons

Additional monitor modules—fault detecting, data collecting, and automating—can be added to Peach using the plugin API. This enables support for proprietary tools used by your organization.

More InformationFor more information about testing firmware, please refer to our User and Developer Guides.