Disassemble and unterstand SBL of preFL Convers+

[Go4IT]

I'd like to start an intiative to disassemble this code and see how it works. The SBL usually get's loaded by a Tester (UCDS oder IDS or whatever) to start a programming of a module like the IPC. The one we use für updating preFL Convers+ is called "7M2T-14C025-AA" and is somewhat universal for all kind of preFL Convers+. It's embedded into a VBF.

Before digging into the code, let's see if we can work out how it's really going to be used!

To put any kind of software from an Tester onto a module, the first thing that's needed is a secure programming session between the Tester and the module itself. This is done via UDS CAN messages. So CAN is only the transport-media, and the CAN protocol tells about how to chunk data into small messages to transport them. The UDS protocol tells about how to enter a secure session, so that the receiver is willing to accept the data and do something usefull with it.

Now, it's clear that UDS needs support on both sides. First, the sender (Tester) needs to createn such a secured session, this is where the secret and the challenge-response come to play. Let's skip this task for now and just notice that a special handler inside the firmware of the Convers+ decided to enter a programming session with the Tester. This part of firmware needs to be found, as it also decides how to handle the rest of the procedure.

Now, the SBL code from the VBF get's transferred to the target (IPC) and as this one has limited RAM it needs to decide early what to do with that data. In the case of the SBL, it is only a view KB in size (1.740 Bytes to be precise), which could easily be fit into the 48 KB RAM of the MAC7116. For larger VBF content, there must be a different stragety, for shure. The VBF-header could(!) instruct the handler on the IPC to put the data at a specific place, in our case at 0x0000 0000. But this way it would replace the Boot-Vectors of the IPC also and, it would be permanent. So if the handler in the IPC really does erase the first block of the internal Flash and program the SBL onto it, this is a permanent change. So after a powerloss, the SBL is the only thing that could bring the IPC back to live, but the programming cannot be aborted anymore.

Is that really the case?! If not, the handler will ignore the address and put it into RAM instead, which we know starts at 0x4000 0000.

This is what's need to be clearified first. If the SBL code goes to somewhere else, this is something the handler in the IPC firmware decides and we need to find it to know where it really put's the code. If not, we need to look for the consequences.

[DGAlexandru]

It is loaded in RAM and then executed from there.
The same SBL is used for all European Convers+.

Beeing so small I wonder why didn't they wrote it in Main Flash, near PBL and by CAN only instruct MAC7116 to load and execute it.

You can use something like J-Mem from Segger if you have J-Link interface to read RAM from MAC7116 by JTAG, before sending SBL and after sending SBL by CAN, to see where is written. I did this in the past and I remember I put the RAM dump somewere here on this forum.

[Go4IT]

I suspected it to be, thanks DGAlexandru
Now, if it goes to RAM the programming and calling address inside VBF is wrong (fake) and the firmware-hanlder is putting it somewhere else and execute it. This is what we need to find out.

If we know the final location of the code, we can disassemble it correctly. I also expect that the code itself does not rely on any of the Firmware functions. It would fully take over control of the device and it's only purpose is to erase the flash and write the contents it receives through CAN.

As the normal update-process only update MAIN from 0x5000 upwards, the PBL and Boot-Vectors remain untouched. So it is not a problem if something goes wrong, the PBL can always reload the SBL through CAN and start over. Good to know we have such a backup.