Disassemble bootloader of V850

[Go4IT]

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.

[Go4IT]

As i updated my DAB-module in the car i used UCDS and found that it downloads the necessary software somewhere from the Internet. So it will store it somehwere local on the PC and thats where i can grab it for closer inspection.

Screenshot 2019-01-27 20.47.52.png

As you can see there are several numbers involved. The first one is the Ford partnumber of the device itself "CS7T-19C128-AG". The next partnumber signals the software-version if it "CS7T-14D403-AH", for which an update to "*-AJ" is available. When proceeding to the update itself, there is another list which show interesting details:

Screenshot 2019-01-27 20.48.10.png

So there is a "Secondary Bootloader" (SBL) with partnumber "CS7T-14D405-AA" and the Firmware itself with the partnumber from the screen above. The SBL is only needed for the update process. I Wiresharked the download via UCDS and found their gateway-service URL: http://www.ucdsys.ru/calibration/. I called this URL by hand, put the software partnumbers from above into the form and got two ZIP-files. After uncompressing i had two *.vbf files: "CS7T-14D403-AJ.vbf" and "CS7T-14D405-AA.vbf". After a little research i found out how to extract the binary part of this file and also other valuable information. Read here for further details: https://mk4-wiki.denkdose.de/en/artikel/vbf/start

The SBL is 2.572 Bytes and the Firmware 761.856 Bytes. Looking into the binary image shows that in fact the firmware only uses 204.708 Bytes of the available space. The rest is filled with 0xFF. I guess this is a security feature to prevent other software remaining inside the Flash after an update

Now that i have a dump of the SBL it will try to disassemble it. I'm pretty shure to finde some secrects inside, like the Flash password for unlock it, and also the CRC calculation algo and maybe other parts that ensure only genuine software is loaded into the device.

[Go4IT]

Now that i have the dump file, i need some more information to get it disassembled using "IDA Pro".
First thing IDA needs to know is the processor type. Here i choose "V850E1/ES".
Next i need to choose the layout of the systems RAM and ROM. IDA chooses a ROM-Section automatically. But let's think about it. This SBL gets uploaded by a CAN programmer tool. This tool uses a special CAN-Command to send the SBL into the RAM of the chip and executes it. For now i don't know how this is done, but regardless of how, in the end the image must be at some valid RAM address.

Looking into the readable portion of the VBF-file i found some helpfull notes:

Code: Select all

//Description
description = {"This is the flash driver (SBL) for",
               "V850 microcontrollers with MF2 flash."};

Well, who had thougt this?

Code: Select all

//call address
call = 0xFFFF0000;

If it gets called at 0xFFFF0000, i wonder how the programmer nows where to put it. Maybe at the same address.
The V850 is a 32 Bit CPU, so it has an 32 Bit PC (program counter) register. This it can address memory locations from 0x0000 0000 up to 0xFFFF FFFF.

Looking into the datasheet of the V850ES i found this memory map for the 60KB RAM type:

v850es-sg3_70f3352_ram_space.jpg

On the right side i found the start of the "logical address space" beginning at 0xFFFF 0000 and goes up to 0xFFFF EFFF which is in fact 60KB (61.439 bytes) of size. To as the RAM starts at this adress and VBF says it calls here, the image must be put there. So i told IDA to put it into a RAM section starting at 0xFFFF 0000. Next i tell IDA that the first bytes must be code (pressing "C" on the first address) and i get this:

Code: Select all

RAM:FFFF0000                 jr      loc_FFFF0022

A relative jump to location 0xFFFF 0022, where i also find another jump:

Code: Select all

RAM:FFFF0022                 jr      loc_FFFF0514

now at 0xFFFF 0514:

Code: Select all

RAM:FFFF0514                 add     -4, sp
RAM:FFFF0516                 st.w    r1, 0[sp]
RAM:FFFF051A                 br      loc_FFFF053A
RAM:FFFF051C                 br      loc_FFFF051C

It's reducing the Stack-Pointer register (SP) by 4 and exeuctes the next operation, doing something with the value the SP is pointing to. The Mnemonic "br" seems unknown, but i guess its branching to 0xFFFF 053A, like a "call".

[Stevebe]

This is very interesting , are you using the free version of IDA, ? I did look into it some time ago but found it to expensive , let alone the various addon s,