V3.2.2 to V4.0 migration
V3.2.2 to V4.0 migration
I'm trying to compile my project from old v3. 2. 2 to v4. 0
My project has a components directory with changed code for app_update. Now I get errors in 4.0
My project has a components directory with changed code for app_update. Now I get errors in 4.0
- Attachments
-
- 111111.jpg (183.91 KiB) Viewed 12421 times
-
- 1111111.txt
- (23.48 KiB) Downloaded 565 times
Re: V3.2.2 to V4.0 migration
how can I replace a file in esp-idf with a modified file? When I replace the file directly in the heart of the asp-id everything works , but when I make the components\app-update folder in my project , the compilation goes wrong. I want to have modified files outside of the esp-idf core so as not to erase them when updating the idf.
in esp-idf-v3. 2. 2, this method worked.
in esp-idf-v3. 2. 2, this method worked.
Re: V3.2.2 to V4.0 migration
Your CMake variables aren't quite right. Have a read of this: https://docs.espressif.com/projects/esp ... ystem.html
INCLUDE_DIRS is for specifying where to find that component's header files; use REQUIRES if there are other components required by this one.
INCLUDE_DIRS is for specifying where to find that component's header files; use REQUIRES if there are other components required by this one.
Re: V3.2.2 to V4.0 migration
I'm trying to replace the IDF file by my modify file
esp_ota_ops.c
what I specified wrong in Cmake ?
esp_ota_ops.c
what I specified wrong in Cmake ?
- Attachments
-
- 333.jpg (131.89 KiB) Viewed 12264 times
Re: V3.2.2 to V4.0 migration
Hi brp,
It's not possible to replace individual files in ESP-IDF without editing them in the IDF directory, but it is possible to override an entire component by placing it in the project components directory (as you've done). The overridden component replaces the IDF one of the same name.
The solution to fixing the linker error for the missing esp_ota_get_app_elf_sha() function - added in newer version - may be to copy the new esp_app_desc.c file from $IDF_PATH/components/app_update/esp_app_desc.c into (project)/components/app_update/ . Then add the new filename to the SRCS list in app_update/CMakeLists.txt so this file is built in your project. Then the esp_ota_get_app_elf_sha symbol will be available at link time .
If this doesn't work, you may need to make a whole new copy of app_update from IDF v4.0 and then re-apply whatever patch(es) had been applied to the v3.2.2 app_update to the new copy. Do you mind if I ask what did need to change in this component for v3.2.2? There might be an alternative solution that we can suggest.
Angus
It's not possible to replace individual files in ESP-IDF without editing them in the IDF directory, but it is possible to override an entire component by placing it in the project components directory (as you've done). The overridden component replaces the IDF one of the same name.
The solution to fixing the linker error for the missing esp_ota_get_app_elf_sha() function - added in newer version - may be to copy the new esp_app_desc.c file from $IDF_PATH/components/app_update/esp_app_desc.c into (project)/components/app_update/ . Then add the new filename to the SRCS list in app_update/CMakeLists.txt so this file is built in your project. Then the esp_ota_get_app_elf_sha symbol will be available at link time .
If this doesn't work, you may need to make a whole new copy of app_update from IDF v4.0 and then re-apply whatever patch(es) had been applied to the v3.2.2 app_update to the new copy. Do you mind if I ask what did need to change in this component for v3.2.2? There might be an alternative solution that we can suggest.
Angus
Re: V3.2.2 to V4.0 migration
I use this patch to OTA pre encrepted firmware in my devices
https://esp32.com/viewtopic.php?f=2&t=7467
i dont use http or https, i use my server and OTA via TcpSocket with additional second on line encription on server and decription in OTA module esp32
I have no desire to send unencrypted code to the server.
You also promised to add this feature in the new version, perhaps it is already supported?
https://esp32.com/viewtopic.php?f=2&t=7467
i dont use http or https, i use my server and OTA via TcpSocket with additional second on line encription on server and decription in OTA module esp32
I have no desire to send unencrypted code to the server.
You also promised to add this feature in the new version, perhaps it is already supported?
Re: V3.2.2 to V4.0 migration
However, all the protection of the program , after this article, almost does not make sense and my about 1000 devices can be hacked.
https://esp32.com/viewtopic.php?f=12&t=14626
https://esp32.com/viewtopic.php?f=12&t=14626
Re: V3.2.2 to V4.0 migration
Thanks for the explanation. I'm afraid we don't yet have support for pre-encrypted binary files in ESP-IDF, the recommended approach is still to use HTTPS to load from a trusted server.brp80000 wrote: ↑Sun Mar 08, 2020 11:01 pmI use this patch to OTA pre encrepted firmware in my devices
https://esp32.com/viewtopic.php?f=2&t=7467
i dont use http or https, i use my server and OTA via TcpSocket with additional second on line encription on server and decription in OTA module esp32
I have no desire to send unencrypted code to the server.
You also promised to add this feature in the new version, perhaps it is already supported?
It should be possible to apply the same modifications to the v4.0 app_update component. But please note that there are other security concerns with this approach, as were mentioned in that thread (downgrade attacks against a plaintext protocol, and that the Flash Encryption documentation recommends generating unique keys on each device and not re-using them between devices.)
I don't know anything about your product or security concerns and the threat model you have, but in many cases there is still value in enabling the ESP32 security features. The "FIA Analysis" link posted on that thread has some recommended guidelines about potential things to consider.brp80000 wrote: ↑Sun Mar 08, 2020 11:04 pmHowever, all the protection of the program , after this article, almost does not make sense and my about 1000 devices can be hacked.
https://esp32.com/viewtopic.php?f=12&t=14626
Re: V3.2.2 to V4.0 migration
1. The fact is that https is very easy to hack and get unencrypted code, at least much easier than doing the injection, as described in this article. (This is my opinion)ESP_Angus wrote: ↑Sun Mar 08, 2020 11:25 pmThanks for the explanation. I'm afraid we don't yet have support for pre-encrypted binary files in ESP-IDF, the recommended approach is still to use HTTPS to load from a trusted server.
It should be possible to apply the same modifications to the v4.0 app_update component. But please note that there are other security concerns with this approach, as were mentioned in that thread (downgrade attacks against a plaintext protocol, and that the Flash Encryption documentation recommends generating unique keys on each device and not re-using them between devices.)
2. Several other people have access to the server with OTA data and I can 't risk an unencrypted code on the server
3. Based on # 1, I can 't afford to have different encoding keys for each device. Otherwise, I would have to make a separate pre- encrypted code for each device , and one firmware for each of the 1000 is already 10 and will be even more
4. I use several additional software checks to avoid copying code inside the program code itself
Last edited by brp80000 on Mon Mar 09, 2020 12:05 am, edited 1 time in total.
Re: V3.2.2 to V4.0 migration
it is also difficult to follow your instructions now that the devices are already manufactured and soldESP_Angus wrote: ↑Sun Mar 08, 2020 11:25 pmI don't know anything about your product or security concerns and the threat model you have, but in many cases there is still value in enabling the ESP32 security features. The "FIA Analysis" link posted on that thread has some recommended guidelines about potential things to consider.
Who is online
Users browsing this forum: No registered users and 103 guests