Prevent flashing (bricking) ESP32 if secureboot and/or flashencryption is enabled about fluidnc HOT 25 CLOSED

So in theory the perfect candidate for excellent open source projects like yours. :-)

Except for the fact that open source projects generate a lot of work for the developers with no obvious source of compensation. If you sell hardware, as Bart does, then you can recoup some of it, but then when people repurpose Chinese hardware instead of buying the developer's product, then have problems that come back not to the Chinese vendor but instead to the developer, well, you see where I am going...

from fluidnc.

How about.

Be careful uploading firmware to an existing controller with firmware other than Grbl_ESP32 or FluidNC. You need to make sure that the existing firmware is not encrypted or it may brick the device. If in doubt ask on Discord.

from fluidnc.

I found a way to read fuses with esptool; you can use read_mem with the address of the appropriate efuse word. Using that technique, I added a check to the install scripts. There is a test version of those scripts at https://github.com/bdring/FluidNC/releases/tag/WMB_Test9 . It would be great if you could check them against your bricked chip.

from fluidnc.

Thanks for the very detailed report with extremely useful data. I'll look into it. Note that this will be tricky/expensive to test - as you have found. Ideally, the fix would be in esptool, but we will try to paper over it.

from fluidnc.

i understand and i share the feeling. Maybe its more easy to add a "unsupported devices list" in the wiki. Also creating an issue on espressif esptool about this issue would be more beneficial to the rest of the world. (Sadly i am not experienced enough to do it and discuss this issue with them on appropriate level)

Your discussion with us has been entirely appropriate so I encourage you to do it. I need to get back to doing productive work.

from fluidnc.

voidmicro an appropriate name.

We have not heard about that controller.

Do you have a picture of it?

from fluidnc.

Sure, i also reverse engineered the pinout.
voidmicro_singlearm_engraver.pdf
My plan was it use it on some small 2-axis builds.
There is also a "frame engraver" version with a 3rd 4988 driver for the second y-motor.

I like these, because of the small footprint and the onboard 8mb flash. As there is no SD interface, i think they used the extra space to buffer gcode. But due to the fact that esp32 is secured, it is no option for "buy'n'use".

Maybe you can add a section of known incompatible devices and use my 3rd picture to allow other users identify their controller.

t

from fluidnc.

Seems like they won't be easy to repurpose with soldered down modules and locked firmware.

from fluidnc.

Is it possible to put a factory-signed binary back in the bricked module?

from fluidnc.

No, i would not recommend those due to my experience.
The esp32 is easy to swap if you have the right tools and some experience, but it is not worth the hassle.
I came across these boards on ali. They are sold as replacemant parts and i thought it would be fun to play with.
Unfortunately they are not, but i learned a lot. So its still a win for me.

I agree with you that the best fix would be a warning or a -f force option in esptool to prevent this kind of issue, as esptool is used in nearly any other flash-software.

On the reflash... it depends.
As far as i understand there are to methods of encryption.
a: flash factory-keys to the esp32 and upload pre-encrypted binarys and signed bootloader
b: the esp32 can generate a random key and encrypt the flash on the first boot (in this case the key is unknown)

I have no backup or factory-binary for the controller. I've also not seen any firmware updates to download.
It could be an option to create a backup before flashing, in this case you should be able to reflash the backup (if there is no readout protection, which my module has not).

Btw. i already swapped the esp32 and flashed fluidnc successfully. I will use it anyway somehow ;-P

from fluidnc.

I am trying to figure out how to incorporate the check in the installer without spending so much time that I end up resenting it. It potentially involves adding espefuse.exe in three OS versions, some scripting to decode the output, and a buttload of testing that I cannot do easily without possibly destroying some hardware. And something is bound to go wrong down the line that prevents somebody who would otherwise not be affected from successfully installing. I hate security work.

from fluidnc.

What firmware was on there before?

from fluidnc.

It was some stock firmware using an smarthone-app. No Web-Interface. Nothing i really want to use.
I prefer not to install android apks from unknown sources. So in theory the perfect candidate for excellent open source projects like yours. :-)
You can checkout the app here if you are interested:
http://voidmicro.com/Download/downloadApp-en.html?page=page_download

from fluidnc.

Adding espefuse binaries for the three architectures increases the size of the .zip release download from 30MB to 70MB, without increasing utility at all for the typical user.

from fluidnc.

I am starting to get the "cost/benefit much greater than 1" vibe.

from fluidnc.

i understand and i share the feeling.
Maybe its more easy to add a "unsupported devices list" in the wiki.
Also creating an issue on espressif esptool about this issue would be more beneficial to the rest of the world.
(Sadly i am not experienced enough to do it and discuss this issue with them on appropriate level)

from fluidnc.

I totally agree with you in terms of the compensation part.
Keep on the good work and thanks for all the innovations you have brought to us.

Your discussion with us has been entirely appropriate so I encourage you to do it. I need to get back to doing productive work.

Thanks!

Feel free to close this issue, but i would still suggest an "incompatible hardware list" at least so save you work and frustration to other users.

from fluidnc.

i would still suggest an "incompatible hardware list"

The point is well taken, but I do not know how we would maintain such a list, given the rate at which China creates and obsoletes difficult-to-identify products. I think the best we can do is describe the potential problem in general terms - and even that is of questionable value given the fact that people don't read the wiki until after they have had a problem. You would be amazed at the number of people who do not realize that FluidNC does not usually require recompiling, despite the fact that it is in in the README.md on the first screenful of text.

from fluidnc.

Thanks for the encouragement:
espressif/esptool#699

from fluidnc.

That's a very good bug report. It clearly states the problem and the desired solution.

from fluidnc.

@MitchBradley
awesome Work, Thanks!

Side note:
As the stdout from esptool is now piped to findstr, the dots appearing while connecting as well as other outputs are not visible in the batch-terminal anymore.
This may be confusing and may cause difficulties while debugging other issues.
I tried to modify the batch script, and found a solution.
Maybe this can be translated to mac and linux as well.

I used 'dump_mem' instead of read_mem. But this resulted in a binary written file.
I was not able to compare it using your method. So i needed to add a reference file 'SecurityFusesOK' to compare against.
The dumped file gets deleted to prevent accidentally execution (not sure if this is could happen)

@echo off

set BuildType=wifi
set EsptoolPath=win64\esptool.exe

set BaseArgs=--chip esp32 --baud 921600

rem Read the security fuses
%EsptoolPath% %BaseArgs% dump_mem 0x3ff5a018 8 SecurityFuses

if not %ErrorLevel% equ 0 (
   echo esptool failed
   pause
   exit
)

fc /b SecurityFuses SecurityFusesOK > nul 2>&1
if not %Errorlevel% equ 0 (
   echo *******************************************
   echo *  Secure boot is enabled on this ESP32   *
   echo * Loading FluidNC would probably brick it *
   echo *    !ABORTED! Read Wiki for more Info    *
   echo *******************************************
   del SecurityFuses
   pause
   exit
)
del SecurityFuses

set SetupArgs=--before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect

set Bootloader=0x1000 common\bootloader_dio_80m.bin
set Bootapp=0xe000 common\boot_app0.bin
set Firmware=0x10000 %BuildType%\firmware.bin
set Partitions=0x8000 %BuildType%\partitions.bin

echo %EsptoolPath% %BaseArgs %SetupArgs% %Bootloader% %Bootapp% %Firmware% %Partitions%
%EsptoolPath% %BaseArgs% %SetupArgs% %Bootloader% %Bootapp% %Firmware% %Partitions%

echo Starting fluidterm
win64\fluidterm.exe

pause

Please find my modifications in the attached zip.
install_wifi_secureboot.zip

from fluidnc.

Why dump 8 bytes? As far as I can tell, there are only 6 fuses in block 0, so 8 bytes gets you a nonexistent fuse.

from fluidnc.

"Read Wiki for more Info". Please supply the text for said wiki page. I have done about 10 times more work on this front that I can stand.

from fluidnc.

I admit i do not unterstand how the efuse controller and efuse program register shuffle around the bits.
I tried to understand the "esp32 technical reference manual", but i have to many missing links to understand completely how it works.
So i thought 8 bytes should be correct because of the 8x zero in the last section of BLOCK0 😇

I will provide the text for the wiki page shortly 👍

from fluidnc.

Hi there!

I bypassed the warning and I got it to work! I checked and I think this is false positive. I'm attaching the report and it seems the board is not encrypted and that it doesn't have restrictions.

I'm using the esptool that can be installed with Ubuntu 22.04, should I be testing with another one?

The text for the FAQ could be:

While flashing the firmware I get the message
   Secure boot is enabled on this ESP32
   Loading FluidNC would probably brick it

ESP32 supports secure boot, which allows restricting how software runs in the controller. We don't provide assistance for secure boot issues. We try to determine whether your device can be flashed with heuristics and those are not perfect. Users have reported that their controllers work properly after being flashed when this warning was present, but your device could be bricked as well. More details in this [GitHub issue](https://github.com/bdring/FluidNC/issues/149).

espefuse_report.txt

from fluidnc.