AoC 2022 Day 20: Firmware Reverse Engineering

What is Firmware Reverse Engineering

Every embedded device, including cameras, routers, smart watches, and other devices, comes with pre-installed firmware, which has its own set of instructions executing on the hardware’s processor. It makes it possible for the device’s hardware and other software to communicate. The designer or developer can make changes at the root level thanks to low-level control provided by the firmware.
Reverse engineering is working your way back through the code to figure out how it was built and what it does. Firmware reverse engineering is extracting the original code from the firmware binary file and verifying that the code does not carry out any malicious or unintended functionality like undesired network communication calls. Firmware reversing is usually done for security reasons to ensure the safe usage of devices that may have critical vulnerabilities leading to possible exploitation or data leakage. Consider a smart watch whose firmware is programmed to send all incoming messages, emails, etc., to a specific IP address without any indication to the user.

Firmware Reversing Steps

  • The firmware is first obtained from the vendor’s website or extracted from the device to perform the analysis.
  • The obtained/extracted firmware, usually a binary file, is first analysed to figure out its type (bare metal or OS based).
  • It is verified that the firmware is either encrypted or packed. The encrypted firmware is more challenging to analyse as it usually needs a tricky workaround, such as reversing the previous non-encrypted releases of the firmware or performing hardware attacks like Side Channel Attacks (SCA) to fetch the encryption keys.
  • Once the encrypted firmware is decrypted, different techniques and tools are used to perform reverse engineering based on type.

Types of Firmware Analysis

Firmware analysis is carried out through two techniques, Static & Dynamic.

Static Analysis
In order to fully comprehend the functionality of a binary file, static analysis entails understanding its assembly instructions, doing reverse engineering on it, and inspecting the binary file’s fundamental contents. This is done through multiple commonly used command line utilities and binary analysis tools such as:
  • BinWalkA firmware extraction tool that extracts code snippets inside any binary by searching for signatures against many standard binary file formats like zip, tar, exe, ELF, etc. Binwalk has a database of binary header signatures against which the signature match is performed. The common objective of using this tool is to extract a file system like Squashfs, yaffs2, Cramfs, ext*fs, jffs2, etc., which is embedded in the firmware binary. The file system has all the application code that will be running on the device.
  • Firmware ModKit (FMK): FMK is widely used for firmware reverse engineering. It extracts the firmware using binwalk and outputs a directory with the firmware file system. Once the code is extracted, a developer can modify desired files and repack the binary file with a single command.
  • FirmWalker: Searches through the extracted firmware file system for unique strings and directories like etc/shadowetc/passwdetc/ssl, special keywords like admin, root, password, etc., vulnerable binaries like ssh, telnet, netcat etc.
Dynamic Analysis
The process of performing firmware dynamic analysis includes running firmware code on real hardware while simulating its behavior and debugging it using hardware and software. Dynamic analysis has a number of important benefits, one of which is the ability to analyze unauthorized network interactions to spot data theft. The following tools are also commonly used for dynamic analysis:
  • Qemu: Qemu is a free and open-source emulator and enables working on cross-platform environments. The tool provides various ways to emulate binary firmware for different architectures like Advanced RISC Machines (ARM), Microprocessors without Interlocked Pipelined Stages (MIPS), etc., on the host system. Qemu can help in full-system emulation or a single binary emulation of ELF (Executable and Linkable Format) files for the Linux system and many different platforms.
  • Gnu DeBugger (GDB): GDB is a dynamic debugging tool for emulating a binary and inspecting its memory and registers. GDB also supports remote debugging, commonly used during firmware reversing when the target binary runs on a separate host and reversing is carried out from a different host.
NB: When reversing the firmware, use the password Santa1010 if prompted for a sudo password.
After identifying the device id, McSkidy extracted the encrypted firmware from the device. To reverse engineer it, she needs an unencrypted version of the firmware first – luckily, she found it online. Open the terminal and run the dir command.
The bin folder contains the firmware binary, while the firmware-mod-kit folder contains the script for extracting and modifying the firmware.
In this exercise, we will primarily be using two tools:
  • Binwalk: For verifying encryption and can also be used to decrypt the firmware (Usage: binwalk -E -N)
  • Firmware Mod Kit (FMK): Library for firmware extraction and modification (Usage: extract-firmware.sh)

Now coming over to the task, we will perform reversing step by step.

Step 1: Verifying Encryption
In this step, McSkidy will verify whether the binary firmwarev2.2-encrypted.gpg is encrypted through file entropy analysis. First, change the directory to the bin folder by entering the command cd bin. She will then use the binwalk tool to verify the encryption using the command binwalk -E -N firmwarev2.2-encrypted.gpg.

In the above output, the rising entropy edge means that the file is probably encrypted and has increased randomness.

Step 2: Finding Unencrypted Older Version
Since the latest version is encrypted, McSkidy found an older version of the same firmware. The version is located in the bin-unsigned folder. Why was she looking for an older version? Because she wants to find encryption keys that she may use to decrypt the original firmware and reverse engineer it. McSkidy has decided to use the famous FMK tool for this purpose. To extract the firmware, change the directory by entering the command cd .. and then cd bin-unsigned. She extracted the firmware by issuing the following command.
Step 3: Finding Encryption Keys
The original firmware is gpg protected, which means that we need to find a public, and private key and a paraphrase to decrypt the originally signed firmware. We know that the unencrypted firmware is extracted successfully and stored in the fmk folder. The easiest way to find keys is by using the grep command. The -i flag in the grep command ignores case sensitivity while the -r operator recursively searches in the current directory and subdirectories.

Bingo! We have the public and private keys, but what about the paraphrase usually used with the private key to decrypt a gpg encrypted file?

Let’s find the paraphrase through the same grep command.

Step 4: Decrypting the Encrypted Firmware
Now that we have the keys, let’s import them.

While importing the private key, you will be asked to enter the paraphrase. Enter the one you found in Step 3.

Importing the public key. We can list the secret keys.

Once the keys are imported, McSkidy decrypts the firmware using the gpg command. Again change the directory by entering the command cd .. and then cd bin.

Step 5: Reversing the Original Encrypted Firmware
This is the simplest step, and we can use binwalk or FMK to extract code from the recently unencrypted firmware. In this example, we will be using FMK to extract the code.

~ Source: Tryhackme.

Challenge Solution