FiPy code protection

[R.W]

hi,

How do we protect the code on a FiPy from being read or altered? We are planning to develop some real world product/application and thinking of using FiPy for that. But worried that some end users may alter the code. These are not serious hackers that we are talking about. So is there any basic code protection that we can incorporate in FiPy to keep the code from being read or altered? Thanks - R.W

[robert-hh]

@r-w A first level protection is embedding the code as frozen bytecode into the flash memory. Still, the standard mechanisms of starting boot.py and main.py would be present, but there is also a _main.py option for the frozen code, which could avoid starting the external ones, unless the device is in safe boot mode.
An interested user could still start own scripts and dump the memory, or change the memory, but would have the need understand the flash layout and then to decompile the code.
Pycom is considering options for code protection, but I have no clue yet how far they went. In principle, the ESP32 supports encryption of the code space, but that comes not for free, both speed- and handling-wise.

[R.W]

This post is deleted!

[R.W]

@robert-hh

Cool, thanks for the info. Seems like that could do for now. Is there any links or documentation that you could point me to? The users would not be savvy enough to really hack into stuff but main worry is that we may be storing some credentials for the device to connect to our servers. If those gets compromised then there'd be some problems. One of the way we thought of mitigating this is by having per device username/account. That way if something goes wrong we could perhaps disable the particular account on that device.

We've had a whole bunch of projects lined up where we could consider FiPy or LoPy and if not for the code protection worry, Pycom stuff would've come real handy :)

Thanks once again for the clarification. Cheers, R.W

[seb]

@r-w This is something we are actively working on. Support for encrypting firmware should be available "soon" but I am afraid I cannot provide a precise date.

[R.W]

@seb Thanks. Shall keep looking out for updates on this. Talking of encryption, the biggest risk is the username/password ( or other credentials stored on the device which allow it to post data to the server ). If this information can be protected, part of the battle is won.