Main Content

Hacking A Mileage Manipulator Can Bus Filter Device

What it does and how it does it?



The devices are designed to be connected to the CAN bus in a MITM (Man In The Middle) setup, by intercepting the CAN communication between the instrument cluster and the rest of the car. The circuits are quite simple. By identifying the main components and following the PCB traces I reversed the schematics. At the first look there are some trivial differences in the HW design and in the components used, but the main structure is identical. Both boards use the STM32F105 (STM32F105RBT6 to be precise) general purpose microcontroller. Its notable features are: 32 bit ARM Coretex-M3 core, 128k flash, 64k SRAM, Serial Wire Debug (SWD) and JTAG interfaces, 2x CAN interfaces. There are solder jumper pads connected to the MCU’s GPIOs (PC10, PC11, PC12 and PA15) for device configuration, 2 CAN transceivers to drive the physical CAN bus, and 2 LDOs providing regulated 3.3V for the MCU and 5V for the CAN transceivers. Config selector solder jumpers, when shorted, are actually pulling the given GPIOs to ground. As there is no additional resistor connected to these pins, the GPIOs should be configured to input, with internal pull-ups. This means that their default read value is logic high until the solder jumper config does not pull them down to ground. The only meaningful difference between the two boards is that the #green CAN filter device exposes serial programming connections (PA9/USART1_TX, PA10/USART1_RX together with BOOT0 boot mode selector), while the #blue CAN filter board exposes the SWD debug interface (PA13/SWDIO, PA14/SWCLK and BOOT0 pins) on the unpopulated pin headers. Note that the #green CAN filter also exposes the SWD connections, but on small test points only.

Obvious next step is to connect to the debug and programming interfaces to try to download the firmware. Normally, this should not be possible, because with basically zero effort the debug access could be easily disabled, and firmware readout could be also prevented. Important to mention that we are talking about a general purpose microcontroller, which is not supposed to be resilient against advanced HW hacking attacks, that can be used to bypass the applied protections. Nevertheless, using the device provided security features is the bare minimum to raise the bar for the attackers.

With unrestricted access to low level debug interfaces, such as JTAG or SWD, one could take full control over the device, such as stopping and altering the code execution, accessing memory and registers, or even dumping the firmware. There are circumstances, where debug access is possible, but its features and memory access are limited. For example, flash dumping is not possible, so this should be always tested according to the given device’s security features.

For this test, I flashed the Black Magic Probe firmware (JTAG/SWD debugging tool, with built-in GDB server) to my custom HW hacking interface and connected it to the exposed SWD connections (PA13/SWDIO, PA14/SWCLK) on the #blue CAN filter. After powering on the environment just couple of steps were needed:

With ‘arm-none-eabi-gdb’ (architecture specific GNU debugger) I connected to the Black Magic Probe remote GDB server
With ‘swdp_scan’ available device was checked on the SWD interface
After attaching to the identified target device, access to registers and memory were checked
Then a simple ‘dump memory binary’ command targeting 0x08000000 address (where the flash memory is mapped, see memory mapping from datasheet) was executed
Voila, the firmware was dumped. Surprisingly, the “vendor” did not make any effort to lock down the MCU. Access was not restricted neither to the debug interface nor to the flash memory. I was surprised and to be honest, disappointed a bit.”

Link to article