Locking down python source.

[david]

Hi Everyone,

First post of the forumn and in process of buying a board for evaluation but excuse my impatience as I have a couple of questions (which I may be able to answer for myself once the board arrives) and thought I'd ask the community for input.

Got to say Micopython looks like a great peice of engineering - so excited at the possiblities as an embedded tool.

I have a possible commercial project which would be a good fit for a board. I know this goes agasint the grain of the open source foundations, but my client would lilkey insist the there is no source code visible on the system.

Reading the kickstarter posts, I can see there are native source emitters, but not sure where the output of the emitter resides - if it internal to the ARM flash then it would suggest I could remove the python source once the program is run - or does it need the source again on boot.

Also, has anyone tried building in sqlite support to micropython? It's something on my todo list once I fully understand how to compile and load micropython onto the ARM mcpu.

Thanks.

[dhylands]

I have a possible commercial project which would be a good fit for a board. I know this goes agasint the grain of the open source foundations, but my client would lilkey insist the there is no source code visible on the system.

Reading the kickstarter posts, I can see there are native source emitters, but not sure where the output of the emitter resides - if it internal to the ARM flash then it would suggest I could remove the python source once the program is run - or does it need the source again on boot.

The emitted code is only stored in RAM, and the source is currently needed everytime you boot. Having said that, it's probably possible to save the generated object code and just instantiate it, but I'm sure that there are things which might trip you up. The intepreter is definitely 2 passes It runs a compile pass to produce stuff and then executes the stuff. Once the compile portion is done, the source isn't needed any more. (until the next boot).

Also, has anyone tried building in sqlite support to micropython? It's something on my todo list once I fully understand how to compile and load micropython onto the ARM mcpu.

The most I've seen is this thread: https://github.com/micropython/micropython/issues/918 but I don't think that anything concrete has come of it.

[david]

Thanks for the info re: emitted code. That makes sense from python point of view. Wonder if the vector of the first pass could be to store in eeprom then second pass executes from there - sorry if that does not make sense on this architecture.

Will look at the link - thanks. My board should be "in the post" and here soon so will be keen to try things out.

[blmorris]

This topic Internal Flash Capacity discusses why the remaining unused sectors of microcontroller flash cannot be used as part of the writeable filesystem - basically an entire sector of flash must be cached into RAM, modified, and re-written to flash each time a filesystem write is made, and there simply isn't enough RAM to cache the larger sectors. @dhylands suggests that it might be possible to use these sectors for a read-only filesystem; I imagine that this idea could even be extended to store executable Python source and not have this filesystem exposed as mass-storage. It might be readable using JTAG or DFU, but there is a mechanism to implement read-protection on a sector-by-sector basis - this is discussed on page 93, section 3.7.3 of RM0090, the STM32F4xx programmers reference manual.
http://www.st.com/web/en/resource/techn ... 031020.pdf

As far as the spirit of the project goes, I certainly can't speak for the developers' personal attitudes, but my impression is that the MIT license was chosen specifically to allow commercial use, the only restriction being that any distribution of MIT licensed code also carries the MIT license with it. I think that applies to Micro Python itself, not to any application code you develop.

Copying the MIT License here so that anyone with a different interpretation can point out if this is wrong:

The MIT License (MIT)

Copyright (c) 2013, 2014 Damien P. George

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

[stijn]

my client would lilkey insist the there is no source code visible on the system

Problem is no matter how much you try to hide, protect or obfuscate your code, someone with enough resources can always get to it. And in this case it would be pretty easy I guess: suppose first pass is stored in eeprom, one could read it back and since the source code of the first pass implementation, i.e. MicroPython, is freely available it's not going to be extremely hard to reveal any secrets stored in source code.
In other words: your client's wish might be impossible to achieve and your client might not properly understand the system completely: no visible source code does not mean it's impossible to get it. Usually it depends on the specific case, but depending on how much time you are going to spend on getting this to work it might be cheaper for your client to just not bother with it.

[pfalcon]

I have a possible commercial project which would be a good fit for a board. I know this goes agasint the grain of the open source foundations, but my client would lilkey insist the there is no source code visible on the system.

Usual disclaimer of "I cannot speak for everyone", but as a regular project contributor, I hope I understand other developers' motives well enough. So, we want MicroPython to be there, we want more and more people to use it, we want it to conquer the world. Surely, that's not possible if it will be just weekend hobby toy, so we want people to do real-world, commercial projects with it.

But we want such people and organizations to contribute back to MicroPython development and ecosystem in general - that's beneficial for everyone in the ecosystem, including mentioned people/organizations.


Regarding not disclosing your private source to be run on MicroPython, the best approach would be to implement support for persistent bytecode - essentially, support for .pyc files. We don't have such yet, and it shouldn't surprise you - as open-source people, we are happy with open Python source and have lot of other tasks to do, and supporting persistent bytecode is in the primary interest of people using MicroPython in commercial settings. So, please consider implementing such support, and contribute it back to the project. If you can't implement it yourself, please consider contracting an existing MicroPython developer to implement it. This issue is tracked as https://github.com/micropython/micropython/issues/222.

[david]

Plenty of food for thought - thanks for links and contributions.

I fully agree that if someone has the skills and resources then it's hard to fully protect a system. I've worked on projects where anyone so motivated could have just popped the EPROM out of the DIP socket and work backwards from there.

I guess there are two aspects to this - protection of IP which is not mine, and restriction to the system to prevent tampering which could cause reputational damage (both mine and my client). I can think of some commercial projects where having the source viewable would not be an issue, for example where the actual hardware is the added value and customers of that product can use in-house customisation from the source.

There is plenty of low hanging fruit here - the use of micropython could potientially save £K in development time which makes it a very attractive sell to capture a clients heart. I'm professionaly bound to say to them that the source is in the clear to anyone able to hook up a usb connection might not go down so well. Just to be clear - this may not be true for every commercial project - I'm just trying to preempt the discussions around this issue where I work for someone else, for my own design work I'm not so worried.

I'm certainly happy to contribute to micropython development where I can and thanks to everyone who has worked on micropython for the likes of me to pick up and run with it, I only discovered it after the kickstarter was closed. Yes, bytecode could be a valuable feature.

I've cloned the GIT repository and compiled the UNIX version, so will spent a bit of self learning over this week getting myself familiar with the system. I wonder if there is way to extend the code emitters to the unix version = do the development work in-circuit with all the python/REPL goodness and then use the UNIX version to drop out native code to a file.

[blmorris]

Problem is no matter how much you try to hide, protect or obfuscate your code, someone with enough resources can always get to it.

I can't argue with that. It is a matter of balancing priorities, of course. In many cases, it is sufficient to make sure that your proprietary code isn't available in plaintext to anyone with a USB port on their computer, which is the current state of affairs with uPy. On the other hand, if there are national-security-level secrets in your code, then you probably shouldn't put them in a commercial product at all . Most applications requiring code secrecy will fall somewhere short of that extreme…

Regarding not disclosing your private source to be run on MicroPython, the best approach would be to implement support for persistent bytecode - essentially, support for .pyc files.

I would hate to discourage any development in this direction as I think it will be quite useful and important in the long term. On the other hand, I'm not sure that it is necessary for @david's immediate application. Again, I haven't delved into the flash read-protection implemented on the STM32F405, but I do recall a seminar that I attended when ST was first rolling the architecture out about 3 years ago, where they made a big deal about the security this feature could provide for proprietary commercial applications. I imagine that most use-cases for this would be to prevent a binary file from being extracted via DFU or JTAG, but if Python source were stored in a protected flash sector I would expect that it would be no less secure. Makes debugging and firmware updates more of a challenge - you couldn't send out a firmware update as a DFU file because the Python source could be quite easily extracted from that until source code encryption is implemented - but any IP protection scheme is going to introduce certain inconveniences.

I wonder if there is way to extend the code emitters to the unix version = do the development work in-circuit with all the python/REPL goodness and then use the UNIX version to drop out native code to a file.

You are going to give @pfalcon a heart attack - he is always telling us that it is much easier and more comfortable to use the unix port to do our development.
Just kidding, of course And for the sort of hard algorithm and language development that @pfalcon does he is certainly correct. As for me, the primary value of uPy is in providing a nice comfortable API to use the hardware peripherals, allowing me to design and test hardware with much less time spent struggling with C. I imagine that I will spend more time on the unix port as I learn to do more interesting things with the language itself.
-Bryan

[pythoncoder]

My personal view is that obfuscating Python is a bit of a lost cause, for reasons discussed above. However the Pyminifier package
https://github.com/liftoff/pyminifier.git does claim to be capable of doing this. I've used it without invoking the obfuscator for stripping Python code down to a minimum size for fitting onto the internal Flash of the Micropython board.

Regards, Pete

[Lars R.]

I would like to prefer micropython to raspberry for the reasons discussed here. I have no STM32 experience and no experience with micropython. Here are my suggestions anyway. Could you point out the problems with that?

. Disable python safe mode.
. Disable providing filesystem via USB
. Secure STM32: no debuging, disable (partial) reflash, no flash access from outside
<- Does this prevent flash access from inside? If not, everything could be provided via UART.

thx & regards
Lars