How to flash custom firmware?

I’m trying to build the very cool GhostSpool (https://makerworld.com/de/models/2177880-ghostspool?from=search#profileId-2363240), but extend it with an IMU and balance control, like on my D-O (https://youtube.com/shorts/WtvNBd9PXNw). The print files are made for a CyberBrick kit. My code is C++ / PlatformIO based and works on ESP32C3, but apparently the CyberBrick’s flash storage is encrypted?! so it only runs MicroPython? Can anyone help in removing that encryption? Google doesn’t reveal anything unfortunately.

I’ve tried to hack the CyberBrick flashing tool by replacing one of the firmware *.bin files with the firmware PlatformIO makes out of my code and uploading that, but to no avail… board still runs, but doesn’t run my code. Help?

1 Like

Use something like Getting Started with Seeed Studio XIAO ESP32C3 | Seeed Studio Wiki instead or desolder the ESP32-C3 chip from the CyberBrick core module and replace with a stock one that has not been locked.

Desoldering the C3 on the core module is madness :slight_smile: Using a Xiao ESP32 (C3 or better S3) came to mind too. That would need a different dual motor driver board and completely different mount points in the 3D print though, so quite a bit of work. But you sound like it’s actually not possible to reflash with a different firmware due to the encryption? Why do they do this? So senseless…

1 Like

IMO, replacing the Core with an XIAO variant is your best bet. You’ll get more GPIOs and you’ll be able to program it any way you want. It may be possible to create a carrier board that will allow you to use the Cyberbrick Receiver board but I haven’t scoped that completely.

Python is on a partition in the Flash of the ESP32. You can blow it away if you want. You just need an IDE that understands the ESP32 partitioning scheme. Arduino IDE will probably be able to do it, but I use Visual Studio for my MCU development so I don’t know for sure.

Yeah, that’s the likely course of action. May use an Adafruit Qt Py, that’ll allow connecting an IMU too.

I think you’re wrong here. The ESP32 on the CyberBrick seems to be locked into encrypted flash, so you can’t blow away anything. Unless I misunderstand you.

Encryption prevents you from extracting and decoding the contents of the partition. It doesn’t prevent you from deleting it. Flashing new FW with a different partition scheme will do it.

I bought some ESP32 boards a year or two ago, came with Python, which I had no use for. Was easy to get rid of it once I understood the process. Was even able to restore it later (just to see if I could).

1 Like

OK, open for suggestions on how to instruct PlatformIO to flash my own firmware then. Because when I try, esptool tells me the firmware is encrypted and it refuses to flash anything. This is its output:

esptool v5.1.0
Connected to ESP32-C3 on /dev/cu.usbmodem1101:

A fatal error occurred: WARNING: Detected flash encryption and secure download mode enabled.
Flashing plaintext binary may brick your device! Use the force argument to override the warning.
Chip type:          ESP32-C3 in Secure Download Mode

Warning: Stub flasher is not supported in Secure Download Mode, it has been disabled. Set --no-stub to suppress this warning.
Changing baud rate to 460800...
Changed.

Enabling default SPI flash mode...

Hard resetting via RTS pin...
*** [upload] Error 2

Are you holding the User Key (GPIO9) on power up to make sure you’re in bootloader mode?


From Espressif doc’s

Select Bootloader Mode
GPIO9
The ESP32-C3 will enter the serial bootloader when GPIO9 is held low on reset. Otherwise it will run the program in flash.

GPIO9 Input

Mode

Low/GND

ROM serial bootloader for esptool

High/VCC

Normal execution mode

GPIO9 has an internal pullup resistor, so if it is left unconnected then it will pull high.

Many boards use a button marked “Flash” (or “BOOT” on some Espressif development boards) that pulls GPIO9 low when pressed.

I don’t do PlatformIO.

But it does say “use the force” (argument) so you could always try the Jedi approach. :).

But yeah, I’d try putting it in Bootloader mode first.

1 Like

Yes I am holding the bootloader button, and yes I have (of course) tried the –force argument. I have been using ESP32s in my own projects since 5 years and know them quite well.

The fact is (as I’ve found out by now) that ESP32s have a fuse that locks down hardware encryption, that you can only set once. From there on, the chip doesn’t accept unencrypted firmware anymore, and you have to have access to the AES key that the original firmware was uploaded with, otherwise you can maybe flash (although I have not managed to get ESPtool to upload due to the fuse being set) but the flashed results will be garbled and not run.

The question to you guys here was is there any nonobvious way to bypass this encryption, and has anyone managed to do so on this specific type of board? Because the internet yields nothing.

1 Like

Welcome to the forum! This is where we have LOTS of expertise, generously offered, even without the experience to back it up.

1 Like

I don’t have an ESP32 with encryption turned on to try, but I did a little more digging… Everything I read says that encrypted FW can be erased, overwritten, and repartitioned unless secure boot is enabled.

So it’s not encryption that’s getting in the way. You can overwrite the flash and the data written will be encrypted. The issue is secure boot and the OTP eFuses. Burning the fuses permanently locks the ESP32’s hash key and makes the bootloader read-only. So it will download new FW that’s not signed with the key, but it won’t run it.

There might be a backdoor override, but I doubt it. Secure Boot is designed to be secure. There are actually standards that must be met to claim this functionality is supported. If there was a backdoor, someone would have found it by now.

Having said all that, there’s nothing particularly special about the Cyberbrick ESP32 other than its shape, since you don’t care about the firmware it comes loaded with, you could always just replace it with your own un-secure-booted device.

Huh. Same as a conclusion reached even before your first post in this thread.