Sidekick 2.0 introduces a powerful set of features that significantly enhance firmware analysis capabilities. In this post, we’ll demonstrate how Sidekick, in conjunction with the Firmware Ninja plugin (currently in development) for Binary Ninja, can streamline the process of analyzing Memory Mapped I/O (MMIO) in firmware samples.
Introduction
We’ll be analyzing two firmware samples:
android-bootloader: An Android U-boot image for a Samsung phone with an Exynos 5422 SoC.arducopter: ArduCopter OS build for a Pixhawk 6x flight controller, using an STM32 H750 series board with an ARM processor running the ArduCopter ChibiOS RTOS.
Preparation: Setting Up the Environment
Before leveraging Sidekick’s capabilities, we need to prepare our analysis environment:
- Use Firmware Ninja to identify possible MMIO accesses and select the appropriate board for each binary. These accesses will be stored in an index, which Sidekick will access later.
- Create sections/segments representing memory-mapped hardware device ranges using Firmware Ninja. This setup is crucial for indexing the MMIO data later.
Here’s an example of an index entry for resolved MMIO locations:
Sidekick in Action: Enhancing Firmware Analysis
Now, let’s see how Sidekick transforms our firmware analysis workflow:
Step 1: Data Indexing with Sidekick
Sidekick’s indexing capabilities play a crucial role in organizing and making the Firmware Ninja analysis data accessible:
- Run Firmware Ninja’s scripts that:
- Retrieve raw Firmware Ninja analysis data from Binary Ninja’s metadata
- Post-process the data
- Create Sidekick indexes for MMIO information
This step results in two key indexes:
- “Firmware Ninja: Resolved MMIO Accesses”
- “Firmware Ninja: Functions accessing MMIO”
Step 2: AI-Assisted Script Generation
Sidekick’s Analysis Workbench shines in this step, enabling us to create sophisticated analysis scripts through natural language interaction:
- Use the Analysis Workbench to generate scripts that leverage the indexed Firmware Ninja data.
- Employ Sidekick’s LLMOperator to craft queries about:
- Identifying communication protocols associated with each MMIO access
- Determining the make/model of each memory-mapped hardware device
Step 3: Executing AI-Enhanced Analysis
With our AI-generated scripts ready, we can now run them to gain deeper insights:
- Execute the scripts to create new indexes containing the analysis results.
- Review the AI-assisted identifications of communication protocols and hardware devices.
Results
Identifying MMIO Communication Protocol on arducopter
Figure 1. The Analysis Workbench leverages AI to recognize communication protocols from MMIO accesses.
On the arducopter binary, from the simple task description “Identify MMIO communication protocols”, the Analysis Workbench generated a script that opens the resolved MMIO accesses in the binary from the “Firmware Ninja: Resolved MMIO Accesses” index and uses the information from those accesses to infer the data communication protocol being used over the MMIO device. We additionally asked the Sidekick Coding Assistant to include the reasoning behind the LLMOperator’s determination. Lastly, Sidekick also output its results to an index (“MMIO Data Communications Protocols”) for convenient reference.
Identifying Hardware Device Models from MMIO Accesses on arducopter
Figure 2. The Analysis Workbench leverages AI to identify the clock controller device model from MMIO accesses.
Figure 3. The Analysis Workbench leverages AI to identify the gpio controller device model from MMIO accesses.
On the arducopter binary, we described a new task - “Identify each hardware device model from MMIO Accesss”. From there, the Analysis Workbench generated a script that opens the resolved MMIO accesses in the binary from the “Firmware Ninja: Resolved MMIO Accesses” index and passes information from those accesses to an LLMOperator initialized with the task of identifying the manufacturer and model of the hardware device associated with those MMIO accesses. Like before, we also asked for its reasoning and also requested the results be output to an index. As you can see, Sidekick is able to identify the manufacturer and model for the clock controller and gpio controller devices on the board accessed via MMIO.
Identifying Manufacturer/Model for Memory-Mapped Hardware Devices on android-bootloader
Figure 4. The Analysis Workbench leverages AI to identify the PMU device model from MMIO accesses.
For the android-bootloader binary, we performed the same task of identifying the hardware device manufacturer and model based on MMIO accesses that we performed on the arducopter binary. As you can see, Sidekick was able to correctly identify the hardware manufacturer and model when examining MMIO accesses.
Observations and Insights
Sidekick’s AI capabilities demonstrated impressive knowledge and reasoning:
- The AI showed familiarity with device datasheets, recognizing common patterns and conventions in MMIO access.
- It provided reasoning for hardware identifications based on code patterns and I/O register offsets.
- While not always 100% accurate in device identification, Sidekick’s guesses were consistently close and often accompanied by convincing rationales.
Conclusion
Sidekick 2.0, when combined with tools like Firmware Ninja, significantly enhances the firmware analysis process. Its ability to index complex data, generate sophisticated analysis scripts through natural language interaction, and provide AI-assisted insights makes it an invaluable tool for reverse engineers working with firmware.
By automating tedious tasks and providing intelligent analysis, Sidekick allows analysts to focus on higher-level understanding and decision-making, ultimately leading to more efficient and effective firmware analysis.
Future posts will explore more advanced uses of Sidekick in firmware analysis and discuss potential improvements to increase the accuracy of hardware device identification.
If you are not already using Sidekick, then sign up today to start making your firmware analysis easy.