“Do you hear that, Mr. Anderson? That is the sound of inevitability.” This is a famous phrase from the action movie The Matrix. We refer to this sound as Moore’s law. The constant and inevitable miniaturization of circuits has paved the way for the birth of thousands and thousands of new devices, all equipped with sensors, multiple connections, and operating systems. So, how can a vulnerability researcher cope with so many devices, firmware, and standards?

Owning devices is both expensive and logistically unfeasible – for example, the birth of emulators such as Bleem! In the 90s, emulating the PlayStation on a PC was surely a cheaper option than buying the console, and you could do everything on the same PC.

Nowadays, it is clear that there is a lot of space for doing vulnerability research about any kind of device. Pioneering research was done in the first decade of this century. Tools such as Quick Emulator (QEMU), PANDA, Avatar, and Avatar2 were created. They allow you to control an emulated device and interface it with simulated sensors or real ones. They do not offer 100% functionality and full code reachability for obvious reasons (they don’t replace a real device). Though, over the years, it has been demonstrated that it is possible to find vulnerabilities by emulating a real device stepping through its execution with a debugger attached through a JTAG port.

Still, if we decide to analyze a medium-sized corpus of devices, reversing the firmware code or reading the source code takes a lot of time. Hence, using a fuzzer on the interfaces that are dependent on inputs coming from the user, for instance, may stimulate anomalous behaviors that are easier to backtrack, instead of hunting for them directly.

We will not be able to cope with all devices, interfaces, and protocols, and this is outside the scope of this book. Our aim here is to provide you with the necessary toolkit to understand the process of emulating firmware and hooking it to a fuzzer to trigger anomalous conditions. The examples have been carefully picked to help you understand the process and enable you to adapt the concepts autonomously to new firmware.

In this chapter, we will cover the following topics:

• Who is this book for?
• A custom journey
• Getting a primer
• Jumping into the dirt

Passion, curiosity, and hard work – these are the main drivers for embarking on a journey through two techniques that have become fundamental to security research.

Regardless of whether you are an expert or not, this book is designed to help any kind of reader. We have designed two different paths that can be taken according to your level of experience. To keep you motivated, we have made the effort to provide you with examples, additional material, and useful information to help you foresee the end of every section, chapter, and ultimately this entire book.

Q1 – do you want to start a career in cybersecurity?

Internet of things (IoT) – does this phrase sound familiar now? After years of such claims, we are living in a period where many platforms are connected to our network. From voice assistants to vacuum cleaning robots, smart light bulbs, smart ovens, dishwashers, and, of course, smartphones. So, as software security researchers, how is it possible to analyze all these platforms, firmware, and software stacks?

One of the best candidates that will allow us to avoid buying all these devices is QEMU. QEMU will be our reference platform to embark on a journey into vulnerability research. The reason for our choice is motivated by the fact that QEMU can emulate many platforms and it’s a mature and modular project. Emulation is a great technique for using general-purpose computers (x86) to run any kind of software and firmware. Imagine you want to test an X-ray machine but the entire object doesn’t fit in your room. How would you proceed? For instance, you can get the firmware and emulate its interfaces, fuzz them, and make it crash, crash, crash.

Q2 – are you a passionate programmer? Hobbyist? Tinkerer?

Don’t get afraid of the words emulation, fuzzing, exploit, and vulnerability. Soon, you will become familiar with them. We suggest that you read this book from start to finish and practice the easiest examples. Then, try the most challenging ones.

Q3 – are you a hardened cybersecurity expert?

You are probably the kind of TLDR learner who looks directly at the code snippets in Stack Overflow (https://stackoverflow.com/questions/44991703/a-buffer-overflow-exercise-using-a-shellcode), without even reading the question. Our suggestion is to start from Part 2, Practical Examples, and follow along with all the examples.

While this book tries to be as self-contained as possible, and the code snippets from the book will be commented, we recommend that you have a basic knowledge of the following topics:

• The C programming language
• The Linux operating system and general knowledge of operating systems
• The Python scripting language
• Embedded device functioning principles and electronics

This book has been designed to be in three self-contained parts – Foundations, Description of Emulation and Fuzzing, and Advanced Concepts – all of which include examples with famous open source firmware. The first part provides a deep and thoughtful understanding of emulation and fuzzing. These two techniques are extremely common and widespread in security research. Nonetheless, there are no reference books that talk about these matters in detail and help people start their journey toward understanding one of the most ancient and fascinating concepts in computer science, which is emulation. Fuzzing too is a very old technique, but it has become so sophisticated and advanced that evolutionary algorithms have been implemented to select the best inputs to trigger weird machine states and hunt for some vulnerabilities.

The second part has the hard task of gluing very ancient concepts together with everyday reality. 80 years in computer science are probably comparable to millions of years in biology if you think about circuit miniaturization as a reference point. For that reason, in the second part of this book, we will deep-dive into practical examples where we will use the main tools from this book to get in touch with the world of vulnerability analysis of IoT devices with fuzzing techniques. While this is just an introduction, you will grasp the main concepts, and you will be able to practice these concepts with the proposed exercises.

Finally, in the third part of this book, we will guide you through real examples of fuzzing IoT devices. Here, you will learn how to configure the tools to work with emulated hardware, such as the iPhone 11, and how to use emulation with the corresponding configuration to fuzz this machine to look for vulnerabilities. Once we find possible attack vectors (possible vulnerabilities found by the fuzzer), we will learn how to exploit them using the tools professionals use to search for and exploit those vulnerabilities (for example, disassemblers, and debuggers).

Vulnerability analysis and software exploitation are related and well-known topics in the area of cybersecurity. The purpose of this book is to look for security bugs in embedded firmware through emulation and later search for a way to exploit (take advantage of) these vulnerabilities. There are various types of security flaws. The most known and often exploitable bug is known as the buffer overflow, where an incorrect bound check makes a program buffer and becomes filled with user-provided data, and in some cases allows that user to execute code inside of the process memory. In the cybersecurity world, the code that’s injected and run through the exploitation of that vulnerability is known as shellcode. While it’s possible to run a shell to run commands, this isn’t always the only option, as it’s possible to be creative and execute different codes to put a foot inside of a machine.

Not all bugs are created equal

A bug is a software flaw. In many cases, bugs do not lead to security breaches or exploits. They just exhibit a behavior that is not expected by the user or the developer. In other cases, a bug may also be a software vulnerability, meaning that it may generate security issues, such as data leakages, denial of service, or exploitation. Exploiting a vulnerability normally leads to privilege escalation or to taking control of the CPU to execute arbitrary code.

Since the first document that explained this process was published (http://phrack.org/issues/49/14.html#article), many countermeasures have been created to stop an attacker who could exploit a vulnerability if one was found in a program. Protections help us avoid massive exploitations of buffer overflow vulnerabilities. However, many other flaws exist:

• Program logic errors (a mistake during the development phase can a cause program to end in an undefined/unexpected state)
• Buffer overread (where an improper bound check allows an attacker to have access to unauthorized program data)
• Format string vulnerabilities (https://www.win.tue.nl/~aeb/linux/hh/formats-teso.html)
• Heap overflow (an evolution of the buffer overflow in the heap), and many other kinds of vulnerabilities

While the process of searching for these vulnerabilities is hard and tedious due to the time it can take to manually find one, there are different techniques to help security researchers automatically discover some types of vulnerabilities, and in the case of this book, we will cover those that involve the use of a tool called a fuzzer. These kinds of tools take advantage of vulnerabilities such as the incorrect handling of user-provided data in programs to find an input that makes a program crash. The fuzzer will then run the program, giving different inputs and monitoring them to know when that program crashes. To improve the success of the fuzzing process, these programs take a set of inputs and mutate them (for example, changing some bits in the case of some file structures) to give a weird input to the program that it will not be able to handle and will make it crash, where this could or couldn’t be used to take advantage of the vulnerability (sadly, not all vulnerabilities are exploitable).

The utility belt

We have already roughly mentioned what we’ll see in each part of this book, as well as what tools we will use throughout. We will use this section to move a step forward and provide a better overview of the tools we will use, as well as install them (we will not deep-dive into these tools as they will be part of future chapters).

Git, Python3, build-essential

Git is a software version control system that helps keep track of code modifications, which allows us to store our code in a remote server. One of the main servers that contains Git repositories is GitHub. Everybody can upload their artifacts and share them with other people.

Python was created in 1991 by Guido Van Rossum and has exploded as a prototyping language in the last decade thanks to the myriad of libraries written in this language. Without any doubt, Python represents a milestone in computer science because it made programming accessible and readable to everyone. The build-essential package is a basic collection of packages that help compile software in Ubuntu/Debian Linux distributions. Often, Python3 comes already installed and git can be installed with a package manager; for example:

• Arch: pacman -S git python3 make gcc cmake g++
• Debian/Ubuntu: apt-get install git python3 build-essential
• RHEL/CentOS: yum install git python3 make gcc cmake g++
  • Also, for build essentials in RHEL/CentOS, you can use dnf group install "C Development Tools and Libraries" "Development Tools"
• SUSE: zypper install git python3 make gcc cmake g++

QEMU

QEMU is a piece of software that aims to provide users with a tool where they can emulate different systems, as well as some system peripherals. QEMU uses an intermediate representation (IR) to represent these operations, and through binary translation, it will transform the instructions of the given system or binary into the IR and compile those instructions into the current architecture-supported instructions (just-in-time mode, faster), or it will interpret those IR instructions on its own interpreter (interpreter mode, slower).

To use QEMU, we have two options. The first and simplest one is to use a package manager. The command that’s used will depend on the system that we are using. If we look at the QEMU web page, we will see that they provide different sets of commands, depending on the system:

• Arch: pacman -S qemu
• Debian/Ubuntu: apt-get install qemu
• RHEL/CentOS: yum install qemu-kvm
• SUSE: zypper install qemu

In our case, we will make use of an Ubuntu system, so we will use the commands for Debian/Ubuntu. Therefore, the command will be super user: sudo apt-get install qemu or sudo apt install qemu.

The other option is to download the QEMU source. This can be downloaded from its download web page or directly from git. In both cases, we will compile and install the tool. Sometimes, this option can be a better fit for us if we want to decide what to install or not during the installation phase.

If we decide to download from its web page (to download the last version, 6.2), we can use the following code:

wget https://download.qemu.org/qemu-6.2.0.tar.xz
tar xvJf qemu-6.2.0.tar.xz
cd qemu-6.2.0
./configure
make
make install

Alternatively, if we want to download using git (this will download the last version in the master), we can do the following:

git clone https://gitlab.com/qemu-project/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure
make
make install

AFL/AFL++

American Fuzzy Lop (AFL) (https://lcamtuf.coredump.cx/afl/) has become the de facto standard for program fuzzing and vulnerability research. Michal Zalewski (https://lcamtuf.coredump.cx/silence/), a famous Google security engineer, developed AFL for internal purposes at Google, which, as a company, owns trillions of lines of code and among them, potentially thousands of vulnerabilities. The approach of AFL follows a genetic algorithm that makes the initial program input evolve and makes AFL smart. Moreover, it offers a suite for analyzing crash dumps that are generated by the program that is being fuzzed. AFL helped users find thousands of vulnerabilities, even in famous software such as MySQL, Adobe Reader, VLC, and IDA Pro, as well as several browsers.

AFL++ has been presented as an evolution of AFL and includes patches to hook in a full system emulator (QEMU) or to instrument a binary (QEMU user mode). In this book, we will start with AFL++ and apply some patches that come from other projects to show how flexible it is to have a fuzzing suite embedded with an emulator to hunt for vulnerabilities in embedded firmware. The following is an example of how to install AFL. Throughout this book, we will provide all the instructions we will need to install what is needed for every specific exercise:

git clone https://github.com/google/AFL.git
cd AFL && make

The Ghidra disassembler

Ghidra is a powerful free alternative to IDA Pro. This software was previously owned by the NSA and it was released publicly in 2019. It’s extremely portable since its UI and most of the disassembler internals are written in Java, and it is not dependent on any specific architecture. However, the internal components are compiled natively for the different architectures. This marks a huge difference from other disassemblers because the Java UI makes Ghidra very versatile. Also, Ghidra includes a free decompiler for various architectures, which will be useful when analyzing difficult code.

Installing Ghidra

First of all, as stated previously, Ghidra is written in Java, so we will need to install the Java 11 SDK.

For Linux, follow these steps:

1. Download the JDK:

   wget https://corretto.aws/downloads/latest/amazon-corretto-11-x64-linux-jdk.tar.gz

2. Extract the JDK distribution (the .tar.gz file) to your desired location, and add the JDK’s bin directory to your PATH: directory.
3. Extract the JDK:

   tar xvf <JDK distribution .tar.gz>

4. Open ~/.bashrc with an editor of your choice; for example, see the following:

   vi ~/.bashrc

5. At the very end of the file, add the JDK bin directory to the PATH variable:

   export PATH=<path of extracted JDK dir>/bin:$PATH

6. Save the file.
7. Restart any open Terminal windows for changes to take effect.

Once the JDK is installed, we will download Ghidra from https://ghidra-sre.org/ and download the ghidra_10.1.2_PUBLIC_20220125.zip file or a more recent version if there is one. Unzip the archive and execute ghidraRun to start the application. Ghidra keeps consistent on its commands, so newer versions will fit what we see in this book. If you are hungry for knowledge about this tool, we recommend reading Ghidra Software Reverse Engineering for Beginners from Packt (https://www.packtpub.com/product/ghidra-software-reverse-engineering-for-beginners/9781800207974). We will also install GNU Debugger, gdb, with some plugins and for different architectures. This tool can help you analyze executables while they’re running. Normally, Ghidra is mostly used for static analysis.

GDB Multiarch and GEF/Pwndbg

GDB is the default debugger on Linux systems. It is a command-line debugger, and we can use it to debug binaries from architectures different from our current one. To do this, we need to install the multiarch version. We will also install a couple of plugins that improve the view of the tool since gdb without plugins can be tough at the beginning. The scripts will show the views from the stack, the registers, and the assembly code at every moment. Throughout this book, we will learn how to use gdb for debugging purposes. The installation commands for the different environments are as follows:

• Arch: pacman -S gdb-multiarch
• Debian/Ubuntu: apt-get install gdb-multiarch
• SUSE: zypper install gdb-multiarch

Then, download or clone https://github.com/apogiatzis/gdb-peda-pwndbg-gef and, from its main directory, execute install.sh.

Avatar2

The Eurecom institute in South France often hosts very talented students and researchers. This is where Avatar2 was designed by Marius Muench, Dario Nisi, Aurelienne Francillon, and Davide Balzarotti. It’s a Python framework that helps orchestrate embedded systems with the help of QEMU. It contains code to patch memory, emulate peripherals, and mock interfaces to bring firmware to a specific state. Some recent Samsung baseband vulnerabilities (disclosed in September 2020) were discovered thanks to Avatar2, AFL, and QEMU. These vulnerabilities were extremely critical and led to remote code execution within the connection processor (CP) of Samsung phones.

If you have ever been in a playground, you know there are different levels of difficulty in the equipment you can use. Our book is designed to help you figure out which is the best combination of exercises and tools to get your hands dirty with, without getting lost. In our case, the equipment will be different devices, made by different vendors, with different software. Given that we are working with embedded devices, we have had to carefully choose which hardware and software to play with so that you can have the most fun and get the most out of this book.

QEMU basic instrumentation

Instrumentation in computer science is a term that signals that some extra code has been added to an application to analyze or observe a particular behavior or a class of several behaviors. We will explain how it is possible to introduce a new CPU in QEMU and start to execute the first bits of firmware. The code will be almost entirely written in Python. Here, you will see how far this horizon can go, but immediately, you’ll understand the difficulties of running software that expects to interact with sensors, actuators, radio signals, and so on.

OpenWrt full system emulation

OpenWrt (https://openwrt.org/) is a Linux operating system dedicated to baseband routers. It’s a very powerful mod of the world’s favorite penguin software. It is quite easy to install on many old and recent routers and it brings them back to life with a smooth web UI and support for many features of the network. It also includes a package manager. For example, OpenWrt could be instrumented to eavesdrop on HTTPS and save it locally through USB storage if your router has such hardware. At the time of writing, OpenWrt supports almost 2,000 devices. This means that a vulnerability in this system can potentially expose millions of users. Since this firmware embeds an entire operating system, we will be able to perform full system emulation and plug in our harness to hunt for some vulnerabilities. We will show this harness for x86 and ARM32 architectures.

Samsung Exynos baseband

Shannon is the software that’s running within the Exynos chips of Samsung. In this book, we will use it to fuzz into the protocol stack to rediscover some nasty vulnerabilities. This research has been foundational to exploiting GSM and gaining root privileges within cellular phones’ radio chips and eventually escalating to the application processor through the kernel driver. In Android, this interface driver is called RILD (https://hernan.de/research/papers/firmwire-ndss22-hernandez.pdf).

iOS and Android

We will embark on a difficult journey and show how mobile operating systems and their libraries can be executed and fuzzed on your PC. Standing on the shoulders of many giants, we have taken the chance to explain the nuts and bolts of these gems, to empower everyone that has the will to access these precious resources. The final chapter will include a syscall fuzzer for iOS and a library fuzzer for Android.

In this introductory chapter, we have provided a small overview of what this world is about, and we have also summarized what you will find in this book, along with a set of prerequisites that, while not mandatory, are recommended for fully enjoying this book. Please keep reading this book if you want to learn more about emulation from a security perspective and how to use this powerful tool, together with fuzzing, to start in the world of vulnerability discovery.

In the next chapter, we will provide some coverage of the history of emulation and underline its importance in the world of cybersecurity.