Firmware Reviewer Emulation Framework is an automated and scalable scalabile system for performing Dynamic Analysis of RTOS, QNX and Linux-based embedded Firmware, with No need of related physical Device.
...
The bootloader is the first code that is executed after a system reset. Its goal is to bring the system to a state in which it can perform its main function. This requires hardware initialization and choosing the correct image to load from flash or other sources. Because of its key role, the bootloader is usually placed in a part of the Flash that is protected from accidental erasure or corruption. Hardware initialization may imply enabling access to RAM, setting up clocks and PLLs, and configuring other key peripherals. However, hardware initialization should be restricted to the essential at this level leaving the rest of the initializations for upper application code. The bootloader is a critical part of an embedded system because, if it is corrupted, there is no solution to start a program or to update a new bootloader. This is the reason why today, in all systems, there is a safe bootloader, stocked in ROM. The users or extrernal systems cannot access this memory and so cannot modify it. In case of problem, the system can use this bootloader to start. Generally, it allows to download a new bootloader to fix the older one which has been corrupted. Our Emulation Framework can simulate a bootloader corruption and modify the bootloader, inserting a Bootloader Agent /wiki/spaces/KC/pages/1455980582.
...
Modified Kernels
MIPS, ARM, PPC, x86 and other libnvram-compatible architectures are supported, for instrumentation of firmware execution
...
Consumer firmware are often limited in computing power. This limitation rules out slower, harder-to-crack asymmetrical encryption such as RSA. Also, vendors sometimes use the same encryption scheme for multiple routers. Look for routers that are in the same product line, with same processor architecture. Look around there and you might find the right decryption executable. In case of firmware related to Enteprise products, there is no easy method to obtain the decryption routine, other than using the Bootloader Agent /wiki/spaces/KC/pages/1455980582.
Full system emulation
Sometimes, we’ll need to analyze the firmware more comprehensively and will benefit from full system emulation. There are many ways to fully emulate a device.
...
Several techniques exist for hardening ELF binaries in RTOS, QNX and Linux. Firmware Reviewer is able to detect them all and measure their level of hardening.
...
Debugging Information
Discover debugging information, like: Left developer’s configuration files, SCM archives (GIT, SVN, CVS, etc.), Debuggable executables and Libraries. Debugging information in beta versions of IoT devices equips developers with internal systems knowledge of a device. Unfortunately, debugging systems are often left in production devices, giving hackers access to the same inside knowledge of a device.
...
Finds backdoors based in: Suspicious open TCP ports, suspicious connection to external IPs and URIs, presence of Non-standard services and Suspicious executables. When it comes to firmware, hidden backdoors are a favorite hacker exploit. Backdoors are intentional vulnerabilities that are planted into an embedded device to provide remote access to anyone with the "secret" authentication information. Although backdoors are potentially helpful for customer support, when they're discovered by malicious actors, they can have severe consequences. And hackers are great at finding them.
...
...
Insecure executables
Firmware Reviewer detects exposed vulnerable standard library functions, like strcpy, sprintf, strcat, strncat, memcpy, memmove, gets, getw, scanf, system, etc, by analyzing all binaries existing in the firmware. They can expose it to Buffer Overflow, Heap Overflow and Stack Overflow, DoS, Comman Command Injection and Integer Overflow vulnerabilities, as described by CISA CERT coding practices and CERT C Secure Coding Standard. They can be included both in system components and application components. In case of system components it is suggested to update to a non-vulnerable version, while in case of vulnerable application components it is suggested to use safe functions, like: strcpy_s, sprintf_s, etc. The vulnerabilities are classified using CVE standard and CVSS scoring. Firmware Reviewer immediately identifies this binary as a High-risk Insecure executable, and viewing the details we see the code analysis has identified some insecure function calls inside of unsafe_functions as potential vulnerabilities.
As their names imply, safe_functions plugin handles safe functions handle the user supplied data in a safe manner, while unsafe_insecure function plugin handles user supplied data in an unsafe manner.
...
Although simplistic, these potential vulnerabilities are indicative of the bugs found in the vast majority of embedded devices.
...
Firmware Reviewer detects components, libraries or executables with known vulnerabilities classified by CVE (Common Vulnerability and Exposure). CVE is a list of entries—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities. Firmware Reviewer extracts every day such vulnerabilities regarding Firmware, to be used during Firmware Analysis.
...
Hardening Compliance
Other tools typically use the same data files to perform tests. Instead, Firmware Reviewer is not limited to a specific OS distribution, therefore it uses the knowledge of 10+ years from a wide range of sources. It may help you to automate or test against security best practices from sources like:
...
The Firmware of modern IoT devices is complex and made of multiple components. These components can take the form of either different binaries, packaged in an embedded QNX or Linux distribution, or different modules, compiled into a large, single-binary embedded OS (“blob firmware”).
...
The former type of firmware is, by far, the most ubiquitous: a large-scale experiment analyzed 19K firmware samples, and found that 86% of them were Linux-based. Similar to other Linux-based systems, Linux-based firmware includes a large number of interdependent binaries. The different binaries (or components) of the firmware on embedded devices share data to carry out the device’s tasks. Under our attacker model, this interaction is critical, as we focus on bugs that can be triggered by attacker input from “outside” of the device (i.e., over the network), but may affect binaries other than those directly facing the network.
...
IoT devices exchange data over the network. This data can come directly from the user (e.g., through a web interface), or indirectly from a trusted remote service (e.g., cloud backends). Many devices, especially routers, smart meters, and a host of low-power devices, such as smart light bulbs and locks, use the former paradigm. Moreover, recent attacks have shown that such devices can be exploited by clever remote attackers, even when their communication is restricted to a closed local network. In this work, we consider builind or own network-based attack tasks who communicate directly with the device, either through a local network or the Internet. However, our Embedded Framework can be easily extended to other scenarios.
...
We first identify the set of binaries that export network services (i.e., network-facing binaries) in a, even encrypted, Firmware sample. We leverage the observation that network-facing binaries are the components of the Firmware sample that receive and parse user-provided data.
...
Therefore, we identify those binaries within the Firmware sample that parse data read from a network socket. We utilize three features to identify functions in embedded systems that implement parsers:
...