Ember-IO-Fuzzing

KO | EN

gitlite — search

#javascript #ai #llm #golang #machine-learning #rust #deep-learning #linux #macos #java #awesome #awesome-list #openai #ios

Ember-IO-Fuzzing

(★ 11)

No description available.

Ember-IO-Fuzzing Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Ember-IO

Ember-IO is an automated testing tool for embedded systems. More specifically, it's a fuzzing framework focused on monolithic firmware, supporting firmware built for ARM Cortex-M microcontrollers. We aim to assist fuzzing of firmware through alternate input generation and coverage feedback methods. Our Peripheral Input Playback method simplifies value generation to meet constraints placed on status and control registers. FERMCov is used to remove test cases from consideration that show no unique behaviour in the presence of varying interrupt timing.

You can read the full paper, accepted to AsiaCCS '23, regarding our work [here](https://arxiv.org/abs/2301.06689).

# Cite Us
```
@inproceedings{emberio,
title = {{Ember-IO}: Effective Firmware Fuzzing with Model-Free Memory Mapped IO},
author = {Guy Farrelly and Michael Chesser and Damith C. Ranasinghe},
booktitle = {Proceedings of 18th ACM ASIA Conference on Computer and Communications Security (ASIA CCS)},
year = {2023}
}
```

# Installation
We provide instructions based on Ubuntu 20.04, using other linux distros may require you to substitute apt commands with your chosen package manager. For other systems, additional dependencies may be required; which should be indicated in any error message presented. If you encounter any issues during installation, please open an [issue](https://github.com/Ember-IO/Ember-IO-Fuzzing/issues).

```bash
# install dependencies
sudo apt install build-essential ninja-build pkg-config libglib2.0-dev libpixman-1-dev

# clone Ember-IO
git clone https://github.com/Ember-IO/Ember-IO-Fuzzing

# setup environment
cd Ember-IO-Fuzzing
export EMBER_BASE_DIR=$(pwd)

# retrieve AFLplusplus and QEMU
git submodule update --init --recursive

# compile AFLplusplus
cd AFLplusplus
make

# compile QEMU
cd qemu_mode
./build_qemu_support.sh
```

# Repository Structure
```
- AFLplusplus               Main Fuzzer Integrated with Ember-IO
    - qemu_mode             Modified QEMU based MCU Emulator with Ember-IO Implementation
- Ember-IO-Experiments      Repository for Ember-IO Experimentation
    - Crashes               Scripts and Inputs for Reproduction of Previously Known Crashes
    - New Crashes           Scripts and Inputs for Reproduction of Newly Found Crashes
    - Fuzzing               Scripts for Fuzzing Test Binaries
- Extras                    Miscellaneous items and documentation
- README                    Installation and Operating Instructions
```

# Instructions
To use Ember-IO, appropriate parameters must be provided to confiure both the fuzzer and emulated MCU components.

## Fuzzer Configuration
Ember-IO is based on AFL++'s QEMU mode. In order to fuzz firmware with Ember-IO, the AFL++ interface is used.

To operate AFL++, a minimum of an input seed directory (using *-i*), and output directory (using *-o*) must be supplied to the program afl-fuzz, and the fuzzer must be set to QEMU mode (using *-Q*). For optimal usage, you may also want to set an appropriate timeout (using *-t*). For more details about seeds and timeouts for fuzzing, we refer you to [the documentation from AFLplusplus](https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md).

Ember-IO operates on unmodified ELF files. No source code or binary changes are required to test firmware, just the .elf file produced by the compiler is used.

## MCU Emulator Configuration
Several additional parameters are provided to QEMU to allow fuzzing of the target firmware.

First, the location of the binary to test needs to be defined. This is simply a directory to a .ELF file. E.g. *~/test_firmware.elf*

Second, the embedded machine has to be selected with *-machine embedded_fuzz*

Third, the location of the file to used for MMIO input has to be specified. As this file is generated by AFL++, we use the substitute value @@ to inform AFL++ it needs to include this directory. Include the parameter *-fuzz_input @@*

Lastly, the parameters for the target device's memory map need to be configured. This includes both the SRAM and flash sections. The SRAM setup is performed with the *-sram_base* and *-sram_size* commands. For a device with 128KB of RAM at address 0x20000000, append *-sram_base 0x20000000 -sram_size 128k* to the command. Similarly flash, for a device with 1MB of flash at address 0x8000000, the parameters *-flash_base 0x8000000 -flash_size 1M* would be appended to the command.

All combined with the fuzzer parameters, this results in the command ``./afl-fuzz -i ./seeds -o ./output -Q ~/test_firmware.elf -machine embedded_fuzz -fuzz_input @@ -sram_base 0x20000000 -sram_size 128k -flash_base 0x8000000 -flash_size 1M``

Examples using Ember-IO on real world binaries can be viewed in our scripts [here](https://github.com/Ember-IO/Ember-IO-Experiments/tree/main/Fuzzing).

## Post Fuzzing Analysis
In order to analyse interesting test cases discovered during fuzzing, they can be rerun with debug information printed during execution. This may be desirable to investigate both crashing inputs, or inspect reached code.

### Replaying an Input
Rather than executing the fuzzer, QEMU can be executed directly to emulate a single test case. Compared to the command used to run the initial fuzzing campaign, all fuzzing specific parameters can be removed, and the *@@* value used by the fuzzer to specify the location for the generated input can be substituted for the desired input. the text *-kernel* must also be placed infront of the binary's path. Following our prior example, and assuming we want to execute a test case stored at */path/to/input* this results in the command:

``./afl-qemu-trace -kernel ~/test_firmware.elf -machine embedded_fuzz -fuzz_input /path/to/input -sram_base 0x20000000 -sram_size 128k -flash_base 0x8000000 -flash_size 1M``

Information about translation blocks executed during this test case can be observed by appending *-d exec* to the end of the command.

### Crash Analysis
The same replay process can be applied after crashes have been identified by the fuzzer, this is useful for further analysis.

To debug a crash, run afl-qemu-trace with the same values for -sram_base, -sram_size, -flash_base and -flash_size. Load the ELF file with the -kernel parameter, and set the machine to embedded_fuzz. The MMIO input file is selected through the -fuzz_input parameter.

All combined, based on the previously given usage example, this results in a command similar to ``./afl-qemu-trace -kernel ~/test_firmware.elf -sram_base 0x20000000 -sram_size 128k -flash_base 0x8000000 -flash_size 1M -machine embedded_fuzz -fuzz_input ./output/crashes/1``

To assist in locating faults QEMU's debug outputs can be enabled. Useful ones include *exec*, *int* and *mmu*. To enable this extra output, add *-d exec,int,mmu* to the end of your afl-qemu-trace command. To see the state of all registers at each block, you can also try *cpu* and *nochain*, but this will create a very large output. It's also possible to connect with GDB to this instance, by adding *-s -S* to the parameters, and using the *target remote tcp::1234* command in GDB. This allows more in-depth debugging and single stepping of instructions.

NOTE: Monitoring in GDB can influence execution under certain circumstances. Be sure to verify the crash still occurs in the same manner as without GDB. More details are available [here](https://github.com/Ember-IO/Ember-IO-Fuzzing/Extras/gdb.md).

# Project Details
Full technical details of the problems and our solutions can be viewed in our paper [here](https://arxiv.org/abs/2301.06689). But a basic description of the problem and our techniques is as follows:

## Peripheral Input Playback
Many firmware repeatedly access peripheral registers to monitor the state of a peripheral and determine an appropriate response. To reduce the amount of fuzzer generated input that has to be mutated to find valid values, we use Peripheral Input Playback to allow the simple repetition of existing values recently seen in the same register. For commonly polled registers, this can greatly reduce the amount of data required to overcome hurdles in firmware execution. However, playback is not forced, allowing the fuzzer to still generate any possible combination of values for each register, preventing over-restriction of the fuzzing search space.

## FERMCov
Unlike desktop applications more often tested by fuzzers, embedded firmware depends on hardware interrupts in order to signal certain events. It's common-place to trigger these events periodically during fuzzing based on the number of blocks executed. However, small variations in the timing of interrupts causes a change in execution flow from the perspective of the fuzzer. While the different timing of the interrupt doesn't usually represent any new interesting behaviour, the fuzzer is normally unable to determine this. Thus many paths with slightly varied timing will all be saved to be fuzzed further in future. To simplify scheduling for the fuzzer, FERMCov seperates the coverage of interrupt handlers from the main program code, preventing jumps between the two being an indicator of new coverage. Instructions for a simple implementation of FERMCov for Fuzzware is [here](https://github.com/Ember-IO/Ember-IO-Fuzzing/Extras/fuzzware-fermcov.md).

# Experiments
Information regarding our experiments and results are made available [here.](https://github.com/Ember-IO/Ember-IO-Experiments)

# Found an issue? Let us know
If you encounter an issue using Ember-IO please open an [issue](https://github.com/Ember-IO/Ember-IO-Fuzzing/issues).

Ember-IO-Fuzzing

Ember-IO-Fuzzing Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Ember-IO-Fuzzing

Ember-IO-Fuzzing Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README