ESP8266 Developer Zone The Official ESP8266 Forum 2016-07-29T14:08:19+08:00 https://bbs.espressif.com:443/feed.php?f=65&t=2422 2016-07-29T14:08:19+08:00 2016-07-29T14:08:19+08:00 https://bbs.espressif.com:443/viewtopic.php?t=2422&p=8187#p8187 <![CDATA[Re: How to avoid corrupted firmware?]]>
i have a problem with cloud update.

The update is soft-bricking my devices. The problems come up in the last months. Before everything was ok. Now iam now on latest SDK. Problem is still the same.

The problem is that it is sporadic.

Only some of my devices are currently affected. Strange
They are different in
- debug output
- size of usr.bin
- reflashes

On one device 20% went wrong (thats my main testig device with a lot of reflashes), on an other 5%. Its no crc problem.

Currently observing:
- possible reason 1 bad flash chips not detected by sdk flash
- possible reason 2 to much serial debug output while flashing
- possible reason 3 timer interrupts (but the code is not new and worked in past). Only the all hardware interrupt have no ICACHE_FLASH_ATTR. All other code with ICACHE_FLASH_ATTR.
- possible reason 4 rom that is flashed is too big (but it fits)

To restore the device i flash Boot, $0 $1000 $81000 (not the range 3fb000-3fff000)
Just reflashing the boot block does not solve the problem (tested).

Environment: 1.5.1(e67da894) (Now on 2.0.0), Chip-Id: FE4A11 , Boot-Version: V1.5(now on 1.6)


Do you have an hint to locate the problem?
Is the SDK writing any cfg in the range $01000-$FFFFF when correctly flashed as 32MBit ? (Its not the new RF-calibration sector.)

Log when OK
totallen = 445308
totallen = 445812
upgrade file download finished.
flash_crc = 445277592
img_crc = 445277592
upgrade_check
reboot to use1
state: 5 -> 0 (0)
rm 0
del if0
bcn 0
del if1
usl

Log when NOK
totallen = 442404
totallen = 443856
totallen = 445308
totallen = 445812
upgrade file download finished.
flash_crc = 1395164708
img_crc = 1395164708
upgrade_check
reboot to use2
state: 5 -> 0 (0)
rm 0
del if0
bcn 0
del if1
usl
I:Sy_E WIFI evt:1
I:Disconn from ssid SF4_2,4GHZ, reason 8
????`fx??????????f~?f?ff??????`fx??????????f~?f?ff?????

Statistics: Posted by SpenZerX — Fri Jul 29, 2016 2:08 pm


]]>
2016-07-14T13:01:28+08:00 2016-07-14T13:01:28+08:00 https://bbs.espressif.com:443/viewtopic.php?t=2422&p=7955#p7955 <![CDATA[Re: How to avoid corrupted firmware?]]>
Please refer to this updated document about FOTA just in case you have not:
https://espressif.com/en/file/755/downl ... n=stpSK5xL

The process can be secured with SSL and therefore, the upgrade process can only take place with trusted sources. If you feel you are facing any specific vulnerability, please let us know.
But normally, validating the BIN is not required if it is downloaded from a credible source. If you want to manually checksum the BIN, you might do that by simply running one BIN and reading the other BIN from flash. But I feel that would be an overkill.

Statistics: Posted by Guest — Thu Jul 14, 2016 1:01 pm


]]>
2016-07-12T17:57:39+08:00 2016-07-12T17:57:39+08:00 https://bbs.espressif.com:443/viewtopic.php?t=2422&p=7921#p7921 <![CDATA[How to avoid corrupted firmware?]]> example/at_upgrade.c

For that example, we have one question:
How to avoid the corrupt bin file?

Because if malicious users put a corrupted file in web server and then sent AT+CIUPDATE to upgrade.
Then ESP8266 could be enter in broken state... we hope to upgrade the firmware released by our company only.

Does system_upgrade_start(...) or other internal function
will check some checksum/signature of upgrade file?

Can ESP8266 provided by a callback API for checking the upgrade bin firmware by signature?
For example: add some hash section information in the end of the bin firmware.
The user can use their private key to verify the hash data, if hash value is matched, then system can run the new file image, otherwise never run the new bin file.

Statistics: Posted by udmder — Tue Jul 12, 2016 5:57 pm


]]>