 The second hands-on for former protection is about protecting the integrity of the former. In this hands-on, we're going to build a project of application with hash verification of the former itself. So for that purpose, we will need to have a binary that includes not only the former code itself, but also the hash digest. So to achieve that, we will run a hostPC2, basically a Windows bed script. You will see how we can do that. And then after we have such kind of binary, we will program it to the board and then we can observe the hash verification result. Then we will make one-bit modification of the existing binary and see what is the impact. This will help you to understand why hash verification can help to guarantee the former integrity. And in the end, we will add the protection to the flash page where hash data is stored. The hardware board and software tool to be required for this hands-on is almost the same as the first one, except that we would require execute crypto library for the hash computation. So please make sure you download it from SD website. And make sure you have downloaded the patch of crypto library, the latest version of this patch package, which is version 3.1.3 because the support of G0 board is included in this package. So for the hands-on, we're still going to use the pre-generated projects. The one to be used for this hands-on will be this one, AppIntProt.zip. The name means its application with integrity and protection. There is another one named AppInt.zip. It's very similar to this one. For the hash verification part, that's the same. The only difference is that this one also includes the activation of write protection of the hash flash page. That's it. So we will use this one. And we will also use some script coming from host tools folder. And we will use postbuild hash.bat. This script will be used to generate the binary with hash. Before we start the practice, let me explain a little bit of the flash layout that we're going to have. So starting from the base address of user flash, there will be the application firmware. And then after that, there will be some padding bytes. Those bytes are just to make sure that the data that is going to be used for the digest computation will be aligned to flash page size. So that the hash value will be put on the standalone flash page after the firmware. If you have everything ready, then we can start. The second hands-on, we're going to practice to have a practice to see how to use hash verification to ensure the firmware integrity. And the project, we're still going to use some project that has been created for you. For this one, we will use project in folder G0 app int prot. That stands for an application with integrity check and some protection of the integrity check values. Be careful about one thing. Here you can see a folder named sdm-solid to cryptographic. This is not there by default when you download a package of the hands-on. You need to make sure you downloaded the crypto library from SD website. And especially, you need to make sure that you have downloaded this patch crypto library. And make sure that you use, you have downloaded the latest version of the patch, which is version 3.1.3. Inside this one, you will be able to find some folders. Definitely there will be one for G0. You can find the G0 folder. And inside the middleware ST, you will find this sdm-solid to cryptographic folder. And you can just copy this one to the project folder that you have. And if you go inside, you will find all the necessary header files and the libraries to be used in the project. Then again, you can still choose the ID that you like or you have. So we can just open any one of them. First, we can take a look at the source code. So it's the same application, but added some additional function calls before running the application procedure itself. So there were two things added here. The first is the hash verification. This function will verify the hash value of the former that is running. And before then, there is also one function to check and apply static protections. This function will actually protect at the right protection to the flash page where the former hash value is stored. And this one, we can take a look, go inside. This function will expect a flash page with hash value stored. And the address is defined by this one. So this function will read the content from flash and make a computation of former hash and compare with the hash value that is located in this address. So in terms of the former to be used for the digest computation, of course, the starting address will be the base address of the user flash. And the size will be a size that is not exactly the former size, but the former size aligned to flash page size. Okay, so if we go to definition of this one, you can see that this is computed from former size, but also aligned to flash page size. And the former size is guided from linker file symbols. In case of KO, there is nothing very special to be added in the linker file because those symbols are there by default. In case of IR, for example, we can open the IR project and have a look. In the linker file, there will be, okay, we will make a build first at the same time. You can also build here, it's the same. And then we will see the ICF file, which is a linker file. So here, we added one block named the firmware and put all the read-only content to former block and then put former block to ROM region. That is how this former end is linked to the linker file, okay. And if you are using IDE, Q by DE, then there will be another symbol added to the linker file to export the symbol to the code. Okay, it's similar. So now you can either build in KO or IR, both should be fine. Then we can first program the binary to the board. I will do a full erase, full chip erase first. Make sure your RDP level is in zero, no write protection, no piece of rub, okay. And then do a full chip erase. And then we can download the binary and we can reset the board and check the print message. So here the software is trying to print the hash value. This is supposed to be the location where the hash value is stored on the flash. Currently we didn't have any same program there, so this is not a valid hash. And this is the hash value computed from the former. And since the comparison didn't match, these two values doesn't match, so the verification fails and it will enter to a fatal error handler, which is for the moment just an endless loop and with this print message. So that means we need to make sure we can generate the hash value for the former. So for that purpose we have something created for that purpose as well. So in the package you should be able to find a folder named hash tools. Here we have some scripts running on the Windows console, command console. So for hash computation we will use this one. We can take a look at the content of this file. So this script expects input parameter, which specifies the binary file that you want to process. And first it will do a padding to make sure the data to be used for digest computation will be the size that is aligned to flash page size. And then it will run an open SSL command using this digest tool to generate the digest. So the hash SHA 256 value for the binary. And then we will combine this digest value to the former binary with padding. That's it. So we can run this script. Post build hash. And we have already built in IR so we can give IR project build. It will be located in this folder. There is one thing you need to make sure that you have converted. So we have, we should have this binary generated. Okay, it's not in this folder. Sorry. It's in, sorry, this folder. So we have this binary generated. And then can run this script. So there will be some print message coming from the script. Showing you the hash value that is computed. And also point out what is the final binary that should be programmed on the board. Okay, so we can do a programming using the cube programmer. Okay, we open this here. See. So out with hash dot bin. This is file to be programmed on the board. Okay. Then we can take a look at the print message once again, reboot the board. So this time verification is successful because the computed value is in line with the value that is read from the flash. Okay. And then let's connect to the board and take a look at the flash content. So here from the print message, you can see that the hash value is located in this address. We can take a look there and read the flash content. So this is the starting address of the firmware and we can go to 0800 and see. So here we have the hash value for the, for this firmware. So we go back a little bit. So here's the hash value. Those are the stuffing bytes, padding bytes. And before that is the former content. So next thing we're going to do. We're trying to modify just one bit of the binary that we have generated program on the board. And then see what is the effect. This will help you to better understand why we can use hash digest to ensure the former integrity. Okay. So I would just change one bit in the padding bytes. For example, I changed it to one here. Okay. So now we have one bit different from the binary that we have previously. All the rest are the same. Okay. Then we disconnect and report for see what happens. Now you see that the hash verification failed. That's because the computed value is different from the values that is read from the flash. And you can see that actually, even though I just modified one bit, the computed digest is totally different from one that we have previously. So it's not just one bit different. Okay. So now you have a better idea of how this hash verification works. And then the next thing we're going to do is to enable the right protection of the flash page where this hash value is stored. Okay. So in this security check.c file, we have a function named the check applies static protections. This one will basically activate the right protection of the flash page where this hash value is stored. That is also one of the reasons why we want to make a padding to the former because we want to put the hash value to a separate flash page following the former binary. Okay. So this code is inside, is inside a definition of a macro. So we need to make sure it is defined. So by default, it's, it's not so I'll comment this line. And we can build again. And then we need to run the same that script to generate the hash value for it. Okay. Then we can program this new binary to the board. So right now, there's no right protection. Okay, then we download again this new binary. Okay. And we will take a look at the print message. So we do a reset. So this time we will see some additional print message coming from the former says it apply the WIP protection to page 10. This is where this hash value is stored on the flash page. And that's all for this sense. Okay. Let's have a recap of this sense. So in this sense on, we have seen how hash verification can be added in the application former to help on the former integrity protection. And we have also seen how to generate a hash value and make a binary with both former and its hash digest. What kind of tool can be used to achieve that? And we have also seen what is the effect in case one bit of the flash content is modified. This will let us better understand why hash verification can help on the former integrity protection. And we also see how we can protect the hash value on the flash using WRP.