Disassemble and unterstand SBL of preFL Convers+
Posted: 07 Nov 2021, 11:52
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.
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.
