 Now you know a lot more about SBSFU theory, let's practice it and see how easy it is to use it. So what's the purpose of this hands-on? We will start from a simple application that is supposed to be your application. We will make sure this application is running standalone without any secure boot. And then we will make the necessary modification to be able to integrate it in the SBSFU in some way to be started by the SBSFU unchecked. And then the application will be checked and launched by SBSFU. The application we will be using was created by Cubemix. And it is just displaying hard bit traces on the terminal and is blinking a LED. And it is by default mapped at the beginning of the flash like this. So first let's clean our environment, the one we left from the first hands-on. So we had this, so just select everything here and close the projects. Then reset the target. So we use our script. There are reset the target. So it's performing a regression. And we can see that now it's RDP level 0. And the Terra Term should be launched. So I kept it from the previous one. So now nothing happens. I can clean the screen. Clear buffer. Okay. Now let's build a simple application. So we need just to import it in our workspace, file, open project. And let's go back to our road directory, L4 and simple app. Select the folder and open. Then just build it. So we build the application. It should be 14.9K. The simple application is following the Cubemix generation rule here. So we get the same size. That's okay. And now we will launch this application using the debugger. So click here, debug as application. So we launch automatically the debugger. It will ask if we change the perspective, yes, switch. So here we are at the beginning of our application. So here in the slides, we're here. And then we run the application and see what's on the display. So I open here the terra term and click run. And I have a hello world on a heartbeat. That's our simple application. So now let's stop the debugger. And we should still have the heartbeat running. Now we have our application that is working fine. We test it. We want to adapt it to the SBSFU. So to adapt it, you need to change the location of the simple application to be in the slot active one. And here we have the mapping of our board, a nucleo. The reason why the slot active is that the end of the flash is related to the protection of the firewall, which needs to keep all this area reserved just after the bank one. So the beginning of the slot is this address 0808600. At the beginning of the slot, we have our header. So the application needs to be put 512K later, 200 XR offset from the beginning of the active slot. So this should be the new location of our simple application. So what we will do, first we need to change the mapping from flash.ed to put the address of the beginning of the application. Change the size also of the application. So back here, the size is 424. And also we need to reserve a 4K byte of RAM for the secure engine that will not be accessible anymore. And there is a need to align the firmware to 16 bytes. So the firmware size, the binary generated should be aligned with 16 bytes. The reason is that it is encrypted using AES. So it is a constraint related to the encryption. And also what is very important is to change the offset of the vector table. If I come back here, the interrupt vector is now located here instead of here. So you need to make the simple app work and the interrupts work correctly. So that the interrupts go in these interrupt vectors and not in these ones. You need to change the offset. So first go to the settings in the linker script general and we will change the linker.ed. So here simple app, properties, settings. We come back to tool settings here and linker general. Open a bit more and here if I browse here, there is another file that was prepared for you that is doing the necessary changes I described. So it's flash sbsfu. Apply and close. And the second thing you have to do, it is described. So here we just made selected the sbsfu. The second thing is to open this file and put these values 8, 6, 2, 0, 0 here in the system file. So just go in SRC system here and change it in the vector table. So 0, 8, 0, 8, 6, 2, 8, 6, 2, 0, 0. And save and build. So we will reset the target. So here the new application is built. We reset the target here. So we start from a clean target. Okay. And next step, we use the disassembly view. So we first activate the debugger. So as we already configured, we can click here. It starts the debugger. So download the image. And we can see that the main now is in 8, 6, 6 something so that it's not starting from 0. So we are now in a... And if I activate the debugger by instruction stepping for instance, or you could do it through Windows and show view disassembly to open this. And you can see here also that we are in our slot active. And if we run the application and open the start box, it is working fine even here. Okay. So that's what we made. And then I will ask you to press the reset button. So I will do it here. I click the reset button. I've just done it and the trace stopped. So why after reset we didn't restart? Why is it stopping working? So here is the explanation. After system reset, the ARM reads the reset address at flash base address. So here we have erase the flash before reflashing the new application. So here the application is linked at flash base address. So when it is linked at base address, it's working fine. So this was the application we had at the beginning. But when it's linked another place of the flash, it cannot work anymore. So why it worked the first time? And the reason is that because the debugger knew that it was at an offset in the flash. So after downloading the image, the debugger is setting correctly the program counter and the stack pointer. That's the reason why it was working with the debugger. So now that we have our application that is running in our new slot but is not able to reset, we want to launch it by the SBSFU. So we need to create the application metadata so that SBSFU can check it. So to do this, SBSFU as we could see provides a post-built script. That is launched automatically at the end of the user app building. So that's why what we saw on the first hand zone, this line where we could change the version for instance. So for our simple app, we don't have this script that is made to run with the user app. So we need to adapt for the application this script. So for this, we took the script provided by SBSFU and adapted it. And we hard-coded the parameters instead of here providing these parameters are now hard-coded in the post-build. We adapt the directory between the SBSFU and the new application. And also we added some traces. And also we add the version in the file name so that it's easier to manage. So these are called post-build scripts in the scripts directory. And here at the beginning, the two main files we already seen. The .sfb file that contains the binary with the header and the encrypted firmware. And the full binary containing SBSFU, the validated header and the firmware in clear. So let's launch the post-build simple app v1.bat. Go back to the scripts here 0201 post-build. You have here the trace of what it is actually doing. So first it is encrypting the application in the encrypted file with AES key. It computes the signature of the firmware in clear here. And it generates the update firmware. So it generates the header with the simple app.sign, which is actually the digest of the firmware. And also it is generating the signature of the header and concatenates the first encrypted file. And the next step is to generate the big image. So in two steps, first it is generating the new header of this big image, which is the pre-validated header. And then it is concatenating the SBSFU binary, this header and the application firmware in clear. And that's it. We have our firmware that we can see. So let's check the content of what was generated here in our simple app binary. So we have our two files that have just been generated, simple app v1 and simple app v1.sfb. So this is, we will flash the full binary. So to flash it, we'll reset first the target. So before we need to stop the debugger, which is still attached to the target. So I come back to the scripts, flash, no, reset target. And flash, SBSFU, simple app. So it is flashing the simple app v1. So if we go back to the console, we are back to this trace indicating that SBSFU is running and has activated RDP level one. So we need to restart our board. So I'm coming back to the teratum and plug it again. So here you can see we are resetting after two hard bits resetting. So why is it resetting? It's working, but resetting. Here you have the answer in the SBSFU trace. So here we need, we have something that is not working basically. We detected an error in our, so we want to update it. So here let's change and activate the watchdog. So to do it, you need to first define this redot key and then to update, to reload this watchdog. And it will change the delay. So let's do in live, I open the main. So here on the user code begin, I define, I will go faster, carry load 0x000AA and sign. And then in the code, here in the while loop, here I just change the delay to see something's changed. And then in the TG control space, it's not detected. Okay, R equal K reload. So that should be okay. Rebuild. So here I've rebuilt this and we need to generate the simple app V2. So here launch, possibly simple app V2. Okay, simple app V2 is generated. So to update, here we have something different from the first hand zone is that we don't have the ability to update from the application. So what we need to do is to use the SBSFU internal loader. And this one can be activated thanks to the blue button. So first press the blue button, keep it pressed and press the reset. And you see that it is switching to the internal loader. We are still inside the SBSFU. Okay. And then select the simple app V2. So file, transfer, why modem, send. And we need to go back to our simple app binary and simple app V2 here. So here you have, you see it is waiting a little and then transferring. The reason is that it is first erasing the slot and then writing the new image in the slot download. And then it resets and installs the new firmware. So let's see what happens after the reset. You can see that now we are much faster in the update. And oops, it has reset. Watch the reset again. So I didn't update correctly. Okay, reload. The value of the reload is not accurate. Yes. Missing A apparently. Yes. So let's download again. So I need to create again the binary. And then create again the simple app V2. I can download V2 again on the same version but I couldn't load V1. Let's continue. And here I press the button to go in the transfer in the update mode. I send again the V2 that I just created. And now it should work. Install new firmware again swapping images. Here we are. Now it's not resetting anymore. That's it. So you could see again what happened. Here we downloaded in the slot download one. Once the download has been done, SBSFU is resetting to go back to its normal finished state machine and detecting a new firmware downloaded in slot download one. Checking its digest and signature and install it using the swap process. Reset again and launch without watchdog. So here we will check the anti-rollback. So just try to update with V1 version. Here we have the V2 and the V1. So press again the blue button to enter in download mode and transfer the V1. And here you see that it has detected an issue. The firmware version rejected by anti-rollback. So as we are directly in the SBSFU loader, it is able to check to verify the header and that's why it stopped directly the download of the new firmware. So to conclude this little hands-on, you could see that the integration of an application in SBSFU is quite simple, very few things to do, a few changing codes in the mapping file, just changing the vector table and the location of the application. You could see that one script is still required to generate the files containing many because of the generation of the header and you can reuse the original script to adapt to your environment. What was not addressed in this hands-on is the firmware loader in the application that we could see on the first hands-on. This requires the integration of the code that is provided in the sample application. So we would need to reintegrate what is done in the sample application, integrate in our own application. So the second hands-on here is to check what happens when we try to corrupt the update image, just to show you how SBSFU is behaving. So what we will do is edit the update binary file to change only one bit in the firmware and try to update using this template file and see what happens. So here is the... we'll tamper the simple app V2 that we know that can be used to update and first we will tamper the content of the firmware. So here is the header and here is the firmware. So firmware is encrypted. So tampering, you need to know what you do. So to do this, we will use a binary editor called hxd and let's do it. Let's go to the tools and launch the hxd file, hxd editor. Here it is. And then go back to the simple app binary and drag and drop the SFB file. So here at the beginning, the first is the header and then let's change something in the binary. So let's go maybe at the end, we have 2f which is only one bit 2e for example and file savers simple app V2 so corrupt the firmware corrupted. Then let's try to load this firmware corrupted. So again, launch the header, transfer send the corrupted file. So it will erase the slot. It cannot detect the corruption right now because it needs to read all the firmware. But on the next check, it will try to install it. So it will decrypt it. And as you can see here, firmware signature fail. So we could see that during the installation it is checking the new firmware signature and it is failing. Let's now try to... So here it's what we just seen. So let's try to tamper the header file now. So close this one and open again the correct one and tamper. So I want to tamper just here put a 1 here, 0, 1 and save as header corrupted. And try to update again. File, transfer, ymodem, oops, transfer, ymodem send, header corrupted. So here, as it is checking the header during the process it will reject it directly. Or maybe I need to check again because I made a mistake on the first... So try transfer, ymodem, send, header corrupted. So here it detected the error and will reset and the authentication failed. So here this is what we made. We have tampered inside the part that is signed. So we just changed here in the version something. So header corruption detected. In conclusion, you can see that the file that is transferred, the update file cannot be changed in any way. It will be directly detected by the SPSFU and will be rejected. And this is the main purpose of the secure firmware update. Thank you for your attention. Now in this appendix I would like to give you some detail about the post-built scripts that we have used during this hands-on. So here are the four steps, basically, that I used first. We use this tool called PrepareImage that takes different parameters. So the first one we encrypt using a key with an initialization vector, the simple app.bin we produce the simple app.sfu that will be encrypted. So the key initialization vector ASCBC algorithm and we produce the sfu. The second step is the generation of the signature or the digest of the firmware. So just running the SHA-256 and put it in a simple binary file. Next step, here we create the .sfb file. So as you can see, here is detailed the complete firmware, the complete header, sorry. And so here are the basic parameters we use. So the version that is provided, the simple app.sign that we just created before initialization vector that we provide in the header. And the principle here as explained during the theoretical part is to first create the header useful part I would say and then to sign it thanks to first create a digest and sign it using the private key, ECC private key. So the signature is located here and the next part is not signed it's just used for this and the state management of the firmware and also for internal use of the sbsfu. And then sorry, we put the firmware encrypted at the end and we concatenate everything in a binary file. So here are some details what is used for what you can come back here to have better understanding. So next step is the generation of the pre-validated header. Pre-validated means here we have we put some pre-validation so that the firmware can be used as it if it was already installed. So it is exactly the same process as previously for the .sfb except for this part. And then the last step, so there are five steps actually is to make the big image so concatenate the sbsfu add some padding to match the memory mapping add the header, the one we just created and put the application in clear. So that's it for this appendix to show you what is done in all these scripts.