Firmware Analysis
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Firmware is essential software that enables devices to operate correctly by managing and facilitating communication between the hardware components and the software that users interact with. It's stored in permanent memory, ensuring the device can access vital instructions from the moment it's powered on, leading to the operating system's launch. Examining and potentially modifying firmware is a critical step in identifying security vulnerabilities.
Gathering information is a critical initial step in understanding a device's makeup and the technologies it uses. This process involves collecting data on:
The CPU architecture and operating system it runs
Bootloader specifics
Hardware layout and datasheets
Codebase metrics and source locations
External libraries and license types
Update histories and regulatory certifications
Architectural and flow diagrams
Security assessments and identified vulnerabilities
For this purpose, open-source intelligence (OSINT) tools are invaluable, as is the analysis of any available open-source software components through manual and automated review processes. Tools like Coverity Scan and Semmle’s LGTM offer free static analysis that can be leveraged to find potential issues.
Obtaining firmware can be approached through various means, each with its own level of complexity:
Directly from the source (developers, manufacturers)
Building it from provided instructions
Downloading from official support sites
Utilizing Google dork queries for finding hosted firmware files
Accessing cloud storage directly, with tools like S3Scanner
Intercepting updates via man-in-the-middle techniques
Extracting from the device through connections like UART, JTAG, or PICit
Sniffing for update requests within device communication
Identifying and using hardcoded update endpoints
Dumping from the bootloader or network
Removing and reading the storage chip, when all else fails, using appropriate hardware tools
Now that you have the firmware, you need to extract information about it to know how to treat it. Different tools you can use for that:
If you don't find much with those tools check the entropy of the image with binwalk -E <bin>, if low entropy, then it's not likely to be encrypted. If high entropy, Its likely encrypted (or compressed in some way).
Moreover, you can use these tools to extract files embedded inside the firmware:
File/Data Carving & Recovery ToolsOr binvis.io (code) to inspect the file.
With the previous commented tools like binwalk -ev <bin> you should have been able to extract the filesystem.
Binwalk usually extracts it inside a folder named as the filesystem type, which usually is one of the following: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
Sometimes, binwalk will not have the magic byte of the filesystem in its signatures. In these cases, use binwalk to find the offset of the filesystem and carve the compressed filesystem from the binary and manually extract the filesystem according to its type using the steps below.
Run the following dd command carving the Squashfs filesystem.
Alternatively, the following command could also be run.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
For squashfs (used in the example above)
$ unsquashfs dir.squashfs
Files will be in "squashfs-root" directory afterwards.
CPIO archive files
$ cpio -ivd --no-absolute-filenames -F <bin>
For jffs2 filesystems
$ jefferson rootfsfile.jffs2
For ubifs filesystems with NAND flash
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
Once the firmware is obtained, it's essential to dissect it for understanding its structure and potential vulnerabilities. This process involves utilizing various tools to analyze and extract valuable data from the firmware image.
A set of commands is provided for initial inspection of the binary file (referred to as <bin>). These commands help in identifying file types, extracting strings, analyzing binary data, and understanding the partition and filesystem details:
To assess the encryption status of the image, the entropy is checked with binwalk -E <bin>. Low entropy suggests a lack of encryption, while high entropy indicates possible encryption or compression.
For extracting embedded files, tools and resources like the file-data-carving-recovery-tools documentation and binvis.io for file inspection are recommended.
Using binwalk -ev <bin>, one can usually extract the filesystem, often into a directory named after the filesystem type (e.g., squashfs, ubifs). However, when binwalk fails to recognize the filesystem type due to missing magic bytes, manual extraction is necessary. This involves using binwalk to locate the filesystem's offset, followed by the dd command to carve out the filesystem:
Afterwards, depending on the filesystem type (e.g., squashfs, cpio, jffs2, ubifs), different commands are used to manually extract the contents.
With the filesystem extracted, the search for security flaws begins. Attention is paid to insecure network daemons, hardcoded credentials, API endpoints, update server functionalities, uncompiled code, startup scripts, and compiled binaries for offline analysis.
Key locations and items to inspect include:
etc/shadow and etc/passwd for user credentials
SSL certificates and keys in etc/ssl
Configuration and script files for potential vulnerabilities
Embedded binaries for further analysis
Common IoT device web servers and binaries
Several tools assist in uncovering sensitive information and vulnerabilities within the filesystem:
LinPEAS and Firmwalker for sensitive information search
The Firmware Analysis and Comparison Tool (FACT) for comprehensive firmware analysis
FwAnalyzer, ByteSweep, ByteSweep-go, and EMBA for static and dynamic analysis
Both source code and compiled binaries found in the filesystem must be scrutinized for vulnerabilities. Tools like checksec.sh for Unix binaries and PESecurity for Windows binaries help identify unprotected binaries that could be exploited.
The process of emulating firmware enables dynamic analysis either of a device's operation or an individual program. This approach can encounter challenges with hardware or architecture dependencies, but transferring the root filesystem or specific binaries to a device with matching architecture and endianness, such as a Raspberry Pi, or to a pre-built virtual machine, can facilitate further testing.
For examining single programs, identifying the program's endianness and CPU architecture is crucial.
To emulate a MIPS architecture binary, one can use the command:
And to install the necessary emulation tools:
For MIPS (big-endian), qemu-mips is used, and for little-endian binaries, qemu-mipsel would be the choice.
For ARM binaries, the process is similar, with the qemu-arm emulator being utilized for emulation.
Tools like Firmadyne, Firmware Analysis Toolkit, and others, facilitate full firmware emulation, automating the process and aiding in dynamic analysis.
At this stage, either a real or emulated device environment is used for analysis. It's essential to maintain shell access to the OS and filesystem. Emulation may not perfectly mimic hardware interactions, necessitating occasional emulation restarts. Analysis should revisit the filesystem, exploit exposed webpages and network services, and explore bootloader vulnerabilities. Firmware integrity tests are critical to identify potential backdoor vulnerabilities.
Runtime analysis involves interacting with a process or binary in its operating environment, using tools like gdb-multiarch, Frida, and Ghidra for setting breakpoints and identifying vulnerabilities through fuzzing and other techniques.
Developing a PoC for identified vulnerabilities requires a deep understanding of the target architecture and programming in lower-level languages. Binary runtime protections in embedded systems are rare, but when present, techniques like Return Oriented Programming (ROP) may be necessary.
Operating systems like AttifyOS and EmbedOS provide pre-configured environments for firmware security testing, equipped with necessary tools.
AttifyOS: AttifyOS is a distro intended to help you perform security assessment and penetration testing of Internet of Things (IoT) devices. It saves you a lot of time by providing a pre-configured environment with all the necessary tools loaded.
EmbedOS: Embedded security testing operating system based on Ubuntu 18.04 preloaded with firmware security testing tools.
To practice discovering vulnerabilities in firmware, use the following vulnerable firmware projects as a starting point.
OWASP IoTGoat
The Damn Vulnerable Router Firmware Project
Damn Vulnerable ARM Router (DVAR)
Azeria Labs VM 2.0
Damn Vulnerable IoT Device (DVID)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
