Page 1 of 1

V3.2.2 to V4.0 migration

Posted: Sat Mar 07, 2020 1:28 pm
by brp80000
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

Re: V3.2.2 to V4.0 migration

Posted: Sun Mar 08, 2020 5:14 pm
by brp80000
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.

Re: V3.2.2 to V4.0 migration

Posted: Sun Mar 08, 2020 5:49 pm
by boarchuz
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.

Re: V3.2.2 to V4.0 migration

Posted: Sun Mar 08, 2020 8:36 pm
by brp80000
I'm trying to replace the IDF file by my modify file
esp_ota_ops.c
what I specified wrong in Cmake ?

Re: V3.2.2 to V4.0 migration

Posted: Sun Mar 08, 2020 10:40 pm
by ESP_Angus
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

Re: V3.2.2 to V4.0 migration

Posted: Sun Mar 08, 2020 11:01 pm
by brp80000
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?

Re: V3.2.2 to V4.0 migration

Posted: Sun Mar 08, 2020 11:04 pm
by brp80000
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

Re: V3.2.2 to V4.0 migration

Posted: Sun Mar 08, 2020 11:25 pm
by ESP_Angus
brp80000 wrote:
Sun Mar 08, 2020 11:01 pm
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?
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.

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.)
brp80000 wrote:
Sun Mar 08, 2020 11:04 pm
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
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.

Re: V3.2.2 to V4.0 migration

Posted: Mon Mar 09, 2020 12:00 am
by brp80000
ESP_Angus wrote:
Sun Mar 08, 2020 11:25 pm
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.
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.)
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)
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

Re: V3.2.2 to V4.0 migration

Posted: Mon Mar 09, 2020 12:02 am
by brp80000
ESP_Angus wrote:
Sun Mar 08, 2020 11:25 pm
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.
it is also difficult to follow your instructions now that the devices are already manufactured and sold