ESP Delta Usage

[thebigbeepbop]

Hello All,

I hope this forum post finds you well. I've got a question about using the esp delta ota library and tools. I've looked as much as I can for an answer (I crashed this site's search feature a couple of times) so I thought I'd post my question here (instead of raising an issue on the esp github).

Would anyone happen to have experience with / know how one does repeated patching on firmware using esp delta ota? My assumption is something like the following:

patch = create new firmware patch (base firmware, new firmware)
patch 2 = create new firmware patch (new firmware, edited new firmware)

Basically your edited firmware becomes your new "base firmware" for the purposes of applying the procedure again. Like, if you were emitting continuous updates to an esp board, would you just keep creating patches from the rolling binary? Is the "patched" binary an exact copy of the new binary? For example, let's say I have base_binary. I then edit base_binary to get edited_binary. I create a patch called patch from base_binary and edited_binary. I then apply this patch to an esp board. Is that update that has been stored in flash (using the patch) equal to a fresh build (using the same esp-idf version) of the edited_binary?

idf.py build (edited_binary) === board update by patch (base_binary, patch) ?

Thanks for your time in shedding some light on this question. Let me know if any clarification of the question is needed. Sorry if I come off like a newb, but what ya gonna do.

Cheers,
The Beepiest and the Boppiest

[hmalpani]

Hello @thebigbeepbop

A fresh build of the edited_binary will not be same as board update by patch (base_binary, patch) because the firmware has compile date and time embedded in it. So if you rebuild the updated binary, the date and time will get updated and therefore the new build for updated binary and the updated binary on the device will be different. Hope this helps.

[thebigbeepbop]

@hmalpani, isn't there an option to not include the date and time via menuconfig (the enable reproducible build option)? Are there any security type problems that aren't listed in the esp-idf docs? I am not currently using any dynamic macros (__TIME__, __FILE__) etc. Also not doing any real gdb debugging either...

If reproducible builds were enabled and I could ensure repeatability of the build environment (maybe the idf docker image?), would I then be able to achieve the previously mentioned flow?

patch = (base, edited)

esp chip applies patch (base, patch) === idf.py build (edited) ?

Thanks again for your time.

[hmalpani]

Hello @thebigbeepbop

You can enable the APP_REPRODUCIBLE_BUILD config in menuconfig. Enabling this will exclude the time/date stamp from the app image. This way, the workflow you mentioned can be used. Can you try and let me know if this work.

[thebigbeepbop]

@hmalpani I was able to confirm that at least the sha256 validation hashes of a patched firmware and a freshly built firmware match when enabling reproducible builds and building on the same machine/environment. I was able to do successive patches while checking the validation hash successively (patched twice and validation hashes matched up with the last built firmware) using a slightly modified version of the esp http delta example. Modifications only included some print statements and my own wifi connect function.

sha256( update firmware on esp32 (base firmware, patch) ) === idf.py build (new firmware)

Thanks,
David V.