Did it ever really do anything except set a persistent variable?

Unclear, since the source isn't included. Would like to hear that from the horse's mouth, though.

Ping. Any comment from the Espressif folks?

Later versions of esp-idf mark the esp_wifi_get_auto_connect() and esp_wifi_set_auto_connect() functions as deprecated. However no mention is made of an alternate API in either the comments or the commit message.

How is one supposed to control WiFi auto-connect in modern versions of esp-idf?

Weave is the technology that underlies most of Nest’s products. OpenWeave is an open-source implementation of Weave that grew out of Nest’s internal codebase. In a nutshell, OpenWeave is an application-level communication framework for building IoT ecosystems. It’s highly portable, and runs on all ...

Thanks. Final code will have a SHA256 integrity check.

SUCCESS!

I resolved the restart issue by creating a small program to initiate a system reboot using the RTC watchdog:

#include "esp_attr.h"
#include "soc/cpu.h"
#include "soc/soc.h"
#include "soc/rtc.h"
#include "soc/rtc_cntl_reg.h"

void main()
{
// Fire the RTC watchdog after about a second ...

inject a bundle of data into RAM
this has to be platform specific on the tool side
stores in the appropriate way for the particular platform
this has to be platform specific on the device side

So is it really just sleight of hand to force the process to appear consistent across platforms ...

The project I’m working on is in support of Nest’s OpenWeave application framework (main code here , esp32 example here ). We are developing a tool for factory and developer provisioning of devices that works across multiple platforms. A common strategy used by the tool is to inject a bundle of data ...

So how do you reboot into your app while preserving the memory? Esptool would normally do a hard reset. Put a call to a rom restart function at the beginning of the binary and let it execute? Use rtc ram and mark it as noinit in your app?



This is the crux of the issue. I've set the entry point ...

Well the additional on device code could just be (open uart, write data to memory location). The rest of the code could be the same.


Certainly worth considering, although if I can avoid having the firmware operate modally like this it would be logistically more convenient.



So the attackers ...