Firmware enumeration

Once the firmware extraction is complete, ONEKEY begins analyzing the extracted data. At this stage, the platform collects metadata and artifacts.

Analysis steps

1. Collecting file metadata provided by unblob (size, chunks, entropy levels, hashes).
2. Categorizing all extracted files (for example FILE:TEXT:SCRIPT:SHELL, FILE:IMAGE:PNG).
3. Extracting strings from extracted files and unknown chunks.
4. Collecting information about ELF executables (architecture, symbols, sections, binary hardening flags) and resolving linked libraries for dynamically linked executables.
5. Decompiling ELF executables and building a graph from enriched decompiled source code for future analysis. Only a subset of ELF executables is selected for decompilation.
6. Collecting cryptographic materials (public keys, private keys, certificates) from extracted files and unknown chunks, regardless of their format. Also, resolving public/private key pair relationships.
7. Identifying the presence of management protocols (such as ONVIF, UPnP) within extracted files.
8. Collecting URIs from extracted files.
9. Identifying and collecting components for SBOM.

0-day binary analysis

This function decompiles and analyzes ELF binaries (executable binaries)¹ for potential security issues. The platform automatically selects binaries that are remotely reachable to attackers, removing the need for manually investigating which binaries should undergo 0-day binary analysis. This approach also reduces the number of false positives.

Note

For the platform, remotely reachable means the executables consume data over the network either as a client or as a server, including those launched by front servers such as inetd or CGI scripts.

The greatest strength of 0-day binary analysis is it can find vulnerabilities in code that is not yet publicly available, as it does not rely on external issue libraries; it can find vulnerabilities in both the homegrown code and in the configuration files.

To reduce the number of false positives, we only report an issue if both an insecure/dangerous function is used and there is an input from an untrusted source (for example user input).

0-day binary findings are listed together with the regular static code issues in Analysis view --> Issues:

0-day binary issue types

• Command Injection Issue
• Format String Issue
• Stack Buffer Overflow Issue
• Binary Start Dangerous Service Issue

See Security issues to learn more.

To learn more about 0-day binary analysis, see our research article on the subject.

RTOS analysis

ONEKEY supports the analysis of Real Time Operating Systems (RTOS), including the detection of components such as:

• cryptographic libraries (for example mbedTLS)
• TCP/IP stacks (for example lwIP)
• standard libraries (for example newlib)
• and the operating system itself (for example FreeRTOS)

ONEKEY can identify the exact architecture, load address, and components (compiled units) of the firmware image, and the specific functions of the components (symbols). To see this information, click on the firmware in the Files page and select the Executable tab:

Architecture detection is based on machine learning technology and AI.

Supported RTOS

• FreeRTOS
• ESP-IDF
• VxWorks
• ThreadX
• Zephyr OS

Similar to Linux firmware, after identifying the components, the platform performs CVE matching, so you can see a list of known vulnerabilities in your firmware.

Important

RTOS analysis uses reverse engineering technology.

RTOS analysis is deactivated by default. You can activate it on the Analysis Configuration page.

Binary Hardening

ONEKEY looks for binary hardening features in each ELF binary file extracted from the firmware.

See the Binary Hardening page in Analysis view (under Artifacts) for web diagram with a binary hardening protection on each edge.

1. Full Relocation Read-Only (RELRO): Ensuring that certain parts of the binary are read-only after loading into memory prevents attackers from modifying critical sections.
2. Stack canaries enabled: Special values in the stack that, if changed, indicate a buffer overflow attempt.
3. Non-executable stack: Preventing the stack from executing code can help defend against attacks that attempt to run malicious code.
4. Position-independent code (PIC): Code that can be executed at any memory address reduces the risk of an attack, because it is more difficult for attackers to predict where the code will be located in memory.
5. Debug symbols are stripped: Removing debug symbols from binaries makes it harder for attackers to reverse-engineer the code and find vulnerabilities.

---

1. An executable binary is a file that holds instructions in a format that the computer's CPU can directly understand and execute. This file typically has a specific format, such as PE on Windows or ELF on Linux. The file is usually obtained by compiling code from languages like C or C++. ↩