Disassemble bootloader of V850
Posted: 09 Feb 2019, 09:19
My first challenge in using IDA Pro is to try to disassemble and understand a small bootloader (2kb) of an Ford DAB receiver module. This 2nd stage bootloader will be send through CAN to the module to update the firmware. So it would be capable to access the internal Flash of the chip. This may be a way to use an exploid which is able to send the Flash contents over the wire (CAN or any other serial bus of the chip) to get dump of into into the PC.
The module uses a single "70F3352GC(A) SG3" MCU, which is a 32-bit microcontroller from NEC (now Renesas). The MCU belongs to the V850ES/SG3 family and there are public available datasheets for it here https://www.renesas.com/sg/en/products/ ... 3-sj3.html
The 3352 has 768 KB internal Flashmemory and 60 KB of internal RAM, a CAN-Controller, JTAG, and many other periphals. It has protection fuses against reading or writing it's internal Flash memory (let's called it the Firmware ROM) using external programming tools. But they implement some sort of "self updating procedure".
Automotive modules typically gets updated by CAN communications. Shure they are protected somehow by encryption or passwords. Most modules have limited storage capability so they are not able to store their firmware twice. The update procedure is always a risk to "brick" the module if the process get interrupted somehow. All i know is that such an update is divided into two stages.
The first stage opens a secure channel to the device, making it stop its normal function. Usually other components of the car, which normally communicates with the module indicate this as an error and stores DTC (error codes) themselfs. Then a small updater tool is uploaded into the devices RAM and get called. This tool taking over the chip and has only one goal: to update the internal Flash with new software.
This software gets transferred in the seconds stage of the update process, by the former loaded tool. It must "unsecure" the Flash, if there are any fuses set to prevent messing with it's contents, receive the new firmware image over the wire (usually CAN) and store it into flash. This process has to be done in RAM. Because of the limited capacity it must be done in chunks. So i guess it is erasing one secotr of the Flash, loads data and write until the sector is set. This is looped until the flash is fully programmed.
What i try to do now is to get this small updater program and disassemble it to find out how it works and what secret is uses to open the MCUs flash for writing.
The module uses a single "70F3352GC(A) SG3" MCU, which is a 32-bit microcontroller from NEC (now Renesas). The MCU belongs to the V850ES/SG3 family and there are public available datasheets for it here https://www.renesas.com/sg/en/products/ ... 3-sj3.html
The 3352 has 768 KB internal Flashmemory and 60 KB of internal RAM, a CAN-Controller, JTAG, and many other periphals. It has protection fuses against reading or writing it's internal Flash memory (let's called it the Firmware ROM) using external programming tools. But they implement some sort of "self updating procedure".
Automotive modules typically gets updated by CAN communications. Shure they are protected somehow by encryption or passwords. Most modules have limited storage capability so they are not able to store their firmware twice. The update procedure is always a risk to "brick" the module if the process get interrupted somehow. All i know is that such an update is divided into two stages.
The first stage opens a secure channel to the device, making it stop its normal function. Usually other components of the car, which normally communicates with the module indicate this as an error and stores DTC (error codes) themselfs. Then a small updater tool is uploaded into the devices RAM and get called. This tool taking over the chip and has only one goal: to update the internal Flash with new software.
This software gets transferred in the seconds stage of the update process, by the former loaded tool. It must "unsecure" the Flash, if there are any fuses set to prevent messing with it's contents, receive the new firmware image over the wire (usually CAN) and store it into flash. This process has to be done in RAM. Because of the limited capacity it must be done in chunks. So i guess it is erasing one secotr of the Flash, loads data and write until the sector is set. This is looped until the flash is fully programmed.
What i try to do now is to get this small updater program and disassemble it to find out how it works and what secret is uses to open the MCUs flash for writing.