Today, let’s talk about Firmware Ninja, functionality included in Binary Ninja Ultimate Edition that speeds up firmware analysis by offering specialized capabilities tailored to the complexities of embedded reverse engineering.

Introducing Firmware Ninja

Firmware Ninja (FWN) provides advanced analytical capabilities to aid in overcoming distinct challenges in firmware reverse engineering. Firmware Ninja’s features are particularly valuable for examining bare-metal programs with a static memory model, such as microcontroller firmware, bootloaders, kernel images, and real-time operating systems. FWN addresses key challenges in firmware analysis, including constructing accurate memory maps, interpreting code interactions with external hardware peripherals, and understanding inter-device communications interfaces.

Challenges in Embedded Reverse Engineering

Before exploring Firmware Ninja’s capabilities, it is important to understand some of the challenges of embedded system reverse engineering. This section describes a typical workflow using a quad-copter as an example. The process begins with examining the main board which houses multiple microcontrollers and hardware peripherals. Auxiliary modules, like the GPS module and electronic speed controllers (ESC), are wired to the main board.

Next, the firmware is extracted from flash memory and loaded into Binary Ninja. Typically, microcontroller firmware is in a raw binary format, lacking headers and debugging symbols that contain valuable information for reverse engineering. The correct load base address must be determined and code and data sections must be manually created within the file-backed memory region to improve analysis. Without sections, linear sweep will run across the entire binary, leading to bad function creation and other issues in decompilation as just one example of why proper section and segment semantics matter.

Firmware often interacts with SRAM and memory-mapped peripherals at static locations. If a microcontroller’s datasheet is available, it provides a hardware memory map that helps define memory segments in Binary Ninja. The screenshot below shows a function that is accessing an unidentified memory region. Without creating a segment at this location, Binary Ninja cannot create data variables or cross-references, inhibiting analysis.

Unlike desktop applications that run under an operating system, firmware directly interacts with hardware through memory-mapped I/O. Identifying register accesses and referencing datasheets is crucial to understanding these interactions. The screenshot below shows a spinlock that is repeatedly checking the value of a data variable. There is no code in the binary that sets the value of this variable. At a glance, it might appear that this code deadlocks. However, the variable represents a memory-mapped status register belonging to a UART. The register is being polled to determine when data is available. This memory state is changed by the UART hardware, not code.

In the case of a quad-copter, reversing a single firmware image is only the first step; the process must be repeated for each connected device to fully understand inter-device communication. For instance, the main flight controller board communicates with the GPS module via a serial interface to obtain location data, while motor speed is controlled by exchanging commands with the ESCs over a Controller Area Network (CAN) bus. Each of these components operates with its own microcontroller and firmware, introducing additional complexity.

Identifying communication interfaces across multiple binaries is a challenging task. It requires analyzing how firmware running on each auxiliary microcontroller interacts with hardware peripherals, determining how peripherals are connected between microcontrollers, and understanding the protocols governing communication between the main and auxiliary devices.

Firmware Ninja Features

Having outlined some of the challenges of embedded reverse engineering, let’s now explore Firmware Ninja’s key features and show how they solve these problems.

Entropy Analysis

Firmware Ninja provides an entropy analysis tool that aids in triaging firmware to identify code and data regions and to discover “interesting” blobs. This tool can be used to quickly create sections within file-backed memory regions prior to running initial analysis by enabling the analysis.initialAnalysisHold setting on load. By adjusting the sliders, users can identify entropy thresholds and block sizes to quickly identify code, data, compression, and padding region boundaries, as well as create sections from the selected regions.

Entropy analysis is also a valuable tool for identifying interesting blobs or patterns. For example, the screenshot below shows entropy analysis on a flash dump that contains a file system. The repeated pattern in the entropy graph reveals the start of each 512 KB block. Identifying these patterns quickly can save a lot of headaches, considering this file is not in a format that should be analyzed as a single binary.

Memory Insights

Firmware Ninja’s memory insights tool analyzes the generated Binary Ninja Intermediate Language (BNIL) to detect accesses to static memory regions including memory-mapped I/O and RAM. It employs multiple heuristics to identify hardware interaction patterns such as loads and stores to external memory, repeated reads and writes to specific locations, and other indicative behaviors. The user interface presents a high-level overview of memory accesses, while the search bar enables rapid identification of constant values, device names, and other relevant elements. This capability is particularly valuable when correlating firmware behavior with descriptions found in hardware datasheets.

2.3.1 Key values

The key values are as follows:
● RDPRT key = 0x00A5
● KEY1 = 0x45670123
● KEY2 = 0xCDEF89AB

2.3.2 Unlocking the Flash Memory

After reset, the FPEC block is protected. The FLASH_CR register is not accessible in write mode. An unlocking sequence
should be written to the FLASH_KEYR register to open up the FPEC block. This sequence consists of two write cycles,
where two key values (KEY1 and KEY2) are written to the FLASH_KEYR address (refer to Section 2.3.1 for key values). Any
wrong sequence locks up the FPEC block and FLASH_CR register until the next reset.

Firmware Ninja’s memory insights tool can generate reference trees for memory-mapped regions, control and status registers, data variables, and functions. This feature visually represents which functions and data variables interact with memory-mapped hardware. For instance, examining the reference tree for UART5 quickly reveals its role in debugging, as the firmware interacts with it to output crash dumps. By consulting the microcontroller’s datasheet, the corresponding UART5 pins can be identified, allowing the UART peripheral to be connected to a serial port for debugging purposes.

Board Descriptions

Firmware Ninja includes hardware descriptions for over 1,000 microcontrollers, providing predefined memory maps that can be used to efficiently create sections in Binary Ninja. The tool leverages memory insights analysis to suggest potential microcontrollers based on the number of accesses to memory-mapped peripherals for a given board.

The screenshot below displays the results from the FWN board descriptions tool, ranking candidate devices by memory accesses to peripherals. In this example, the firmware is identified as most likely running on an STM32F0x0 series microcontroller. This is correct, as the firmware runs on a STM32F070RB microcontroller.

Firmware Ninja does not include board descriptions for every microcontroller. To address this, the board description tool allows users to define custom devices when necessary. Additionally, if a System View Description (SVD) file is available for a specific microcontroller, users can leverage Binary Ninja’s built-in SVD loader. This approach is preferred, as SVD files provide more detailed hardware information and enable Binary Ninja to automatically create data variables representing each device’s control and status registers.

Relationships

Firmware relationships can be complex. Firmware Ninja’s relationships tool enables users to model both inter-binary and intra-binary relationships between functions, data variables, symbols, and memory addresses. This is particularly valuable for analyzing interactions between separate binaries communicating over CAN, SPI, I2C, or other data buses. By defining these relationships, users can seamlessly navigate between related code regions across multiple binaries.

The screenshot below illustrates user-defined relationships between functions and sections in two firmware images: one running on a main microcontroller as an I2C master and another on an auxiliary microcontroller as an I2C slave. These firmware images exchange data via I2C, demonstrating the tool’s ability to model inter-device communication.

Firmware Ninja API

Firmware Ninja’s Python and C++ APIs enable batch processing of memory insights across multiple firmware images. The following snippet shows how to run FWN memory insights analysis, and then output a reference tree for a specific device, such as a flash controller.

def print_tree(node, indent=0):
    if node.object:
        print("  " * indent, node.object)

    for child in node.children:
        print_tree(child, indent + 1)

fwn = FirmwareNinja(bv)
fmas = fwn.get_function_memory_accesses()
flash_device = FirmwareNinjaDevice("FLASH", 0x40023c00, 1024, "Flash controller")
reftree = fwn.get_reference_tree(flash_device, fmas)
print_tree(reftree)

   int32_t stm32_flash_unlock()
     int32_t stm32_flash_write(int32_t* arg1, int16_t* arg2, int32_t arg3)
       int32_t ChibiOS::Flash::write(uint32_t arg1, void const* arg2, uint32_t arg3)
     void stm32_flash_keep_unlocked(int32_t arg1)
       int32_t ChibiOS::Flash::keep_unlocked(bool arg1)
     int32_t stm32_flash_erasepage(int32_t arg1)
       int32_t ChibiOS::Flash::erasepage(uint32_t arg1)
...

All of Firmware Ninja’s features are accessible through the API. Documentation for the API can be found here.

Sidekick Integration

Firmware Ninja’s analysis results can be seamlessly integrated into a Sidekick index, enabling users to query the Sidekick Assistant with questions while leveraging FWN’s insights as contextual information. To automate this process, I developed a Python snippet that extracts memory insights analysis from the Binary Ninja database and adds the results to a Sidekick index.

Once indexed, Sidekick can utilize this data to provide more informed responses about the firmware. In the screenshot below, Sidekick was tasked with generating an SVD file for the microcontroller running this firmware. It accurately identified the microcontroller as belonging to the STM32H7 series and proceeded to generate an SVD file detailing each peripheral, demonstrating the integration’s effectiveness in enhancing firmware analysis.

To further validate the analysis, I asked Sidekick to explain why it identified the firmware as targeting an STM32H7 series microcontroller. Sidekick’s response is provided below:

Based on the memory-mapped I/O (MMIO) accesses shown in the index, this appears to be running on an STM32H7 series
microcontroller from STMicroelectronics. This can be determined from several key characteristics:
    1. GPIO Port Structure:
        - Presence of GPIOA through GPIOK ports with similar register layouts
        - GPIO ports (A-K) is characteristic of STM32H7 series
    2. RCC (Reset and Clock Control) Register Layout:
        - Multiple RCC register accesses at offsets matching STM32H7 memory map
        - Specific clock configuration registers and bit patterns match STM32H7 RCC layout
    3. Power Management:
        - PWR peripheral accesses with register patterns matching STM32H7 power management
        - Voltage scaling and power control register values typical of STM32H7
    4. Memory Architecture:
        - AXI bus interface presence (shown by AXI peripheral access)
        - Flash memory interface accesses matching STM32H7 flash controller
    5. Peripheral Set:
        - MDMA presence (reference at 0x52000000) is specific to STM32H7
        - TIM2 timer peripheral at characteristic STM32H7 address (0x40000000)

The register layouts, peripheral addresses, and overall memory map strongly indicate this is an STM32H7 series
microcontroller, which is a high-performance ARM Cortex-M7 based MCU commonly used in advanced embedded applications
like drone flight controllers (which makes sense given this is the ArduCopter firmware).

Earlier in this post, we determined that UART5 in this firmware sample is used for debugging, based on FWN memory insights analysis and reference trees. To confirm this finding, I asked Sidekick to reference the FWN index and analyze the code to describe the role of UART5 within the firmware. Sidekick’s response is provided below:

Based on the code analysis from the memory access index and function search results, UART5 appears to be primarily used
for crash dump and debugging functionality in this ArduCopter firmware. Specifically:

    1. Crash Dump Interface:
    - UART5 is used to output crash dump information when the system encounters a crash or breakpoint
    - Key functions using UART5 for this purpose:
        - CrashCatcher_DumpStart: Initializes crash dump output
        - CrashCatcher_DumpMemory: Dumps memory contents over UART5
        - CrashCatcher_DumpEnd: Finalizes crash dump output
        - dumpBytes: Helper function to output hex dumps over UART5
    2. UART Configuration:
    - The init_uarts() function configures UART5 with:
        - Baud rate register (BRR) set to 0x6D
        - Control register (CR1) set to 0x0D (enabling transmitter, receiver and UART)
        - Interrupt clear register (ICR) clearing all flags
    3. Serial Driver Integration:
    - UART5 is integrated into the system's serial driver framework:
        - Initialized as SD5 (Serial Driver 5) in sd_lld_init
        - Has dedicated input/output buffers (sd_in_buf5/sd_out_buf5)
        - Uses interrupt-driven transmission with notify5 callback

The primary purpose of UART5 appears to be providing a debug/diagnostic interface for:
    1. Outputting crash dumps when the system encounters faults
    2. Providing hex dumps of memory regions for debugging
    3. Allowing interactive debugging features (like the crash log command interface)

This suggests UART5 is intended as a diagnostic port rather than for normal flight control or telemetry communication.

Conclusion

Firmware Ninja provides a comprehensive toolkit to tackle complex embedded reverse engineering tasks. Additionally, its compatibility with Binary Ninja’s API and additional integrations, such as Sidekick, further enhances its capabilities by enabling automation and advanced analysis.

Firmware Ninja is set to debut in the Ultimate Edition of Binary Ninja at the release of 5.0 (Gallifrey) but users with active licenses can test it out now on dev! Binary Ninja Ultimate can be purchased here. We are excited to see how the community leverages Firmware Ninja to push the boundaries of embedded system reverse engineering. Stay tuned for future updates, and let us know how Firmware Ninja enhances your analysis workflow!