Custom firmware (Safely disabling WEBREPL and REPL)

[BrunoESP32]

Hi, I'm developing a custom firmware for a plant that will allow users to run small portions of python code through a webserver on an ESP32. The problem is that I need to manage this well, because malicious users can try to use the REPL to gain access to the plant/code, and I would like to protect the firmware and prevent the use of REPL and WEBREPL. I already searched the forums, but I found some things about ESP8266 that didn't help me a bit, so I had to investigate on my own...

[WEBREPL]

I managed to disable webrepl import by changing manifest.py in (lib\micropython-lib\micropython\net\webrepl), I thought that just changing "mpconfigboard.h" was enough, however it wasn't (I didn't quite understand why)...so I did both.
But there is still a module that I couldn't identify where it is to remove, which is "_webrepl", would anyone have any tips? I didn't find information about it (or I missed something).

[REPL]

I managed to disable repl by changing "mpconfigboard.h" and using MICROPY_HW_ENABLE_UART_REPL (0), it worked fine in my attempts, but should I be worried about something? I know a malicious user could copy the fiwmware, however that wouldn't be a problem if he can't edit easily...

I would like to know if this was the best and safest methodology to avoid using REPL and WEBREPL.

Thank you for your attention.

[glenn20]

To completely omit the _webrepl module, you could add #define MICROPY_PY_WEBREPL (0) to your ports/esp32/boards/XXXX/mpconfigport.h file. The code for this module is in extmod/modwebrepl.c.

As to the rest of your questions, unfortunately I am ill-equipped to provide definitive advice on securing your micropython instance.

[BrunoESP32]

Hi, @glenn20. Thanks for the reply!

I already did that, I put #define MICROPY_PY_WEBREPL (0) in ports/esp32/boards/build-GENERIC_SPIRAM/mpconfigport.h but _webrepl is still there as available module. If I enable the REPL I can even import it. I don't know if it's functional, I didn't find documentation about this module or its purpose... I saw that there is a #if MICROPY_PY_WEBREPL in extmod/modwebrepl.c as you said, this must have removed the functionality of this module. However _webrepl is still there, maybe I have to dig a little more into the code....

[glenn20]

Yeah sorry, the definition of MICROPY_PY_WEBREPL, is unconditionally set in ports/esp32/mpconfigport.h. You have to change it there.

[BrunoESP32]

Hey @glenn20. Sorry to bother you again, but when I make the change in ports/esp32/mpconfigport.h with #define MICROPY_PY_WEBREPL (0) I can't compile.

[232/234] Linking CXX executable micropython.elfFAILED: micropython.elf
/root/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/main_esp32/libmain_esp32.a(objmodule.c.obj):(.rodata.mp_builtin_module_table+0x8c): undefined reference to `mp_module_webrepl'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
ninja failed with exit code 1, output of the command is in the /home/bruno/micropython/ports/esp32/build-GENERIC_SPIRAM/log/idf_py_stderr_output_1309 and /home/bruno/micropython/ports/esp32/build-GENERIC_SPIRAM/log/idf_py_stdout_output_1309
-e See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: *** [Makefile:54: all] Error 1

i think i can't directly modify ports/esp32/mpconfigport.h,

[andrewleech]

If you have pre-written functions that you want to be able to run in demand via web browser (ie using microdot server), you can freeze your code into a custom firmware build that's got the entire compiler disabled. This way even if they get to a uart interface, the repl won't exist at all.

That being said I've often just disabled the uart/USB interface to repl, either via compile args like that or even just with dupterm.

[BrunoESP32]

Hi @andrewleech. Thanks for the answer!

I'm following this path, I already have my custom firmware with my frozen codes. Now I'm in the step of protecting the firmware/plant, as users have the power to run small portions of code and modify it, I need to protect it from misuse. I even already removed the dupterm module completely!

[andrewleech]

Yeah maybe try building with MICROPY_ENABLE_COMPILER (0) if you want to be really certain, then no custom code of any kind can be run except what's already frozen in!

[Josverl]

Note that on a esp8266, without any option to even try to encypher the code, physical access is the end of security.
I can copy the firmware using jtag, extract the custom modules, and reverse engineer at my leisure.

You can add a few more speedbumps such as name mangling, minification, and perhaps @viper or similar decorators and that may be worth the effort.
Important is to match these against the capabilities of your expected attackers.

Threat_Modeling helps you think out what and how you can improve security, and avoids bolting down the front door while leaving the gardendoors open.

If you really need to protect the software op on the device, you will need more capable MCUs

[BrunoESP32]

Hi @Josverl. Thanks for the reply!

Do you think .mpy could be some kind of "speedbumps" for for reverse engineering? I never cared about security before, but now I'm more interested in the subject.

[Josverl]

Yes,
I think both minification, and compiling to bytecode are quite good speedbumps to slow down casual inspection and reverse engineering.

• I've found the python-minifier to be quite useful to shorten code, and as a side effect it also mangles names and Def's to something that is hard(er) for mere mortals to read.
• adding bytecode will require a micropython decompiler as well, these are a bit harder to find.

So yes, these methods do have value

Its a matter of matching a lock's capability to the value of the IP and Impact

The lock om my front door is better than on my travel bag, but not good enough for a research facility.
And the lock on my bike needs to be as good as the one on my home, as the opportunity to steal it is much greater.

That is very clear in the physical world, but sometimes gets obfuscated in IT

[shariltumin]

To completely remove "webrepl" from the firmware, you need to modify 4 files in the micropython directory

1. "ports/esp32/boards/manifest.py"

...
# Useful networking-related packages.
# require("bundle-networking")
require("mip")
require("urequests")
require("ntptime")
# require("webrepl")
...

2. "ports/esp32/mpconfigport.h"

...
#define MICROPY_PY_WEBREPL                  (0)
#define MICROPY_PY_SOCKET_EVENTS            (1)  /* need for socket event capability */
...

3. "micropython/extmod/extmod.cmake

$ diff extmod.cmake extmod.cmake-ORIG
39a40
>     ${MICROPY_EXTMOD_DIR}/modwebrepl.c

4. "micropython/extmod/extmod.mk"

$ diff extmod.mk extmod.mk-ORIG
36a37
> 	extmod/modwebrepl.c \

[BrunoESP32]

Hi, @shariltumin. Thanks, it work just fine! You are the man! =D