Ninebot Max G30 II firmware patching

or how to use Ghidra to analyse a STM32F1 Series ARM Cortex M3 uController firmware

Ninebot eScooters are renowned globally for their robustness and reliability. However, they come with certain restrictions tailored to the market in which they’re sold. A notable example is the speed limit, which varies by country. In this post, we’ll delve into the firmware to understand how these restrictions are applied and how they might be modified.

Ninebot scooters feature three distinct microcontrollers (uControllers):

1. The dashboard uController, handling Bluetooth communication, speed control, on/off switch, etc.
2. The drive controller uController, managing motor control and parameters such as speed and current.
3. The battery management system (BMS) uController, overseeing battery health and usage.

To explore how speed limits are implemented across different markets, we’ll focus on the drive controller.

These uControllers typically don’t run conventional operating systems like Windows, Linux, Android, or FreeRTOS. Instead, they operate on what’s often referred to as a bare-metal application.

In this post, we will look into reverse-engineering such firmware implementations.

How to Obtain the Firmware

Getting the firmware isn’t straightforward, as most uControllers have readout protection, preventing the internal flash memory—where the code is stored—from being read. I’ll cover this more in a future post, but here’s a summary of potential attack vectors:

• Unprotected flash memory (unlikely).
• Interception of the manufacturer’s update process, which might contain the bitfile. However, these bitfiles are sometimes encrypted, so this isn’t always viable.
• Hardware attacks, like glitching, can be effective even on modern uControllers. Specialized hardware, often controlled by FPGAs, briefly disrupts the uController’s power supply. This can cause unexpected behavior, such as skipping over security checks.
  Let us have a look at a very simple example: If (!debug_release) {Lock_firmware()}
  
  For example, if we disrupt the power supply when the uController is checking debug_release, we might bypass the Lock_firmware() function.

The Ninebot scooter uses a STM32F103, a widely-utilized basic uController for embedded systems, featuring a USB controller, timers, I2C, CAN, and UART interfaces. Given Ninebot’s purchasing volume, the expected cost for this uController is between 1-2 EUR. The datasheet for this uController is linked below, which will be referenced frequently in understanding reverse engineering.

Starting the Analysis

Assuming we’ve obtained the binary raw file by one of the aforementioned methods or downloaded it from the internet, we can begin analysis. A link to the firmware will be provided at the end of this post.

A great tool for analysis is Ghidra, developed by the NSA and now open-sourced for security researchers, with strong community support.

Workflow for STM32

In Ghidra, you’ll find many addresses marked in red, indicating ‘Address not in memory.’ Remember our earlier discussion about bare-metal applications? Ghidra is unaware of the memory structure, which we can clarify by consulting the datasheet.

Here’s a snapshot of the memory overview:

• Flash memory is mapped to 0x0800 0000.
• SRAM is mapped to 0x2000 0000.
• Peripherals, like GPIOs and ADCs, to 0x4000 0000.

This is known as memory-mapped I/O, which allows the software to configure and access various parts of the uController.

When we map our firmware binary, it must be aligned to 0x0800 0000. However, it’s important to consider the bootloader utilized by Ninebot, which occupies a portion of the flash memory.

Flash Memory map (from Github)

Addr	Name
0x08000000	bootloader
0x08001000	app
0x0800E800	update
0x0801C000	app_config
0x0801F800	upd_config