Firmware Hacking

Obtaining

Just Google it

The first step to testing firmware is obtaining it. Oftentimes this as simple as visiting the vendors websites, forums or hobbyist forums.

Dumping from Flash Chips

Sometimes it will require a bit more digging. If the firmware you want to test is on a local device, you can usually open it up and identify the chip containing the firmware. Usually this chip will be small and have eight pins connecting it to the board. Google will be your friend when identifying the chip and what each pin is for. In order to dump the firmware from this point, you'll need a microcontroller that can communicate with SPI chips, such as the Attify Badge. Once you have connected the pins to the microcontroller you will need to connect your microcontroller to your computer. You can use a script like spiflash.py to dump the firmware.

OTA DFU Sniffing

Another scenario where you can grab firmware is by dumping an Over-the-Air Device-Firmware-Update. For this to be viable, the device traffic must be over HTTP if traffic is being captured by a transparent proxy such as Burp. If the device traffic is encrypted then traffic must be captured in a MitM scenario.

Encrypted

XOR

Coming across encrypted firmware is becoming more common. The most common form of encryption for firmware is just a simple XOR. You can identify XOR'd firmware by the repitition of strings when viewing the hexdump

Not XOR

In the case that the firmware is not XOR'd an attacker must perform manual analysis using a disassembler or dump from memory while the firmware is decrypted.

Not Encrypted

Extracting and Analysing

Occasionally, you will obtain unencrypted firmware. This makes analysis quite a bit easier. Running binwalk -e firmware.bin will extract the file system

Hardcoded Secrets

I usually start off by looking for configuration files and identifying any hardcoded credentials or certificates. You can do this manually or with a tool such as firmwalker.

Dissassemble

I like using radare2 to check for strings and functions in the individual binaries of the firmware. You can also use radare to easily search for Xrefs to system(). It may be possible to identify backdoors or injection vulns here too.

Emulation Station

We can emulate the binaries here to allow us to find overflow vulns. sudo chroot . ./qemu-arch -L optional-lib-path -g gdb-port binary.bin will get the binary running and attach it to gdb-multiarch. At this point I set breakpoints at strcmp and other functions. If I find an overflow vulnerability I will usually exploit it using a ROP chain.

Modifying with FMK

Extracting and Backdooring

Using Firmware-Mod-Kit will allow us to upload a modified version of the firmware to the device allowing us to check if there are integrity checks. First we extract the firmware with extract-firmware.sh. Then we can add a backdoor or bindshell to the firmware and build it with ./build-firmware.sh -nopad -min

Uploading

Now we can upload the firmware to the device and determine if there are any integrity checks, if there are, we can try to identify where it's checking for signature verification and see if there is a way to bypass it.

Neko