Page 1 of 1

OTA -- How to Compute SHA256 of the running firmware?

Posted: Tue Jan 16, 2018 3:16 pm
by hassan789
After completing an OTA, my code would like to compute the SHA256 of itself (the running firmware). This is useful, because I can compare against the SHA256 of the latest firmware in the cloud, and see if I need to do an OTA.

What APIs can I use to read an entire partition? Or is there another way to read/compute the SHA256 of the running app, from the running app?

Note:
Attempting to read the memory directly is causing a LoadProhibited error.

Thanks :D

Re: OTA -- How to Compute SHA256 of the running firmware?

Posted: Tue Jan 16, 2018 9:00 pm
by hassan789
looks like I can use "esp_partition_read()". Ok, easy enough...just have to strip the header.

Re: OTA -- How to Compute SHA256 of the running firmware?

Posted: Wed Jan 17, 2018 5:30 am
by ESP_Angus
Yes, either esp_partition_read() or esp_partition_mmap() will allow you to do this.

As it happens, in recent versions of IDF (v3.0 prereleases) a SHA-256 of most of the .bin file is appended to it and verified by the bootloader to detect corruption. I've added a feature request to add a function to read this SHA-256, as this will allow easy identification of the running image.

However, there's no harm in computing your own in the way you are doing.

Re: OTA -- How to Compute SHA256 of the running firmware?

Posted: Wed Jan 17, 2018 5:49 am
by markwj
ESP_Angus wrote:I've added a feature request to add a function to read this SHA-256, as this will allow easy identification of the running image.
That would be very useful. Is there any timeline for this? Or reference to the feature request (GitHub issue?)

Re: OTA -- How to Compute SHA256 of the running firmware?

Posted: Fri Feb 02, 2018 9:59 am
by SteveOfTheStow
I've been looking to do something similar, and tried the esp_partition_read() idea suggested by hassan789. Unfortunately my SHA256 was muddied by the fact that when you do esp_partition_read, you only really have the partition size to go on, meaning you end up reading past the data on the partition and read blank data (which is rendered as '0xFF'). This isn't a sentinel value as data inside the known 'good' area could also be 0xFF. Thus I had to abandon the idea, sadly.
Instead I've gone with calculating an SHA256 of a downloaded firmware on the fly.