hiding python code on the board

[v923z]

Hi all,

This question has been raised in various forms, the last occurrence might probably be this: http://forum.micropython.org/viewtopic.php?f=3&t=2842

In short, I would like to hide certain critical portions of my code. It seems to me that there are 3 options.

1. With the cross-compiler, one can generate byte code in the form of .mpy files
2. The .mpy files one can compile into the firmware
3. One can write the code in C, and compile that.

The security of the first option depends on the (non-)existence of a disassembler, therefore, it is not particularly safe. I am not sure about the second option (if it is possible to pull the .mpy out of the compiled firmware, then we are back to option 1.) With the third option, the main appeal of micropython is lost. 2 and 3 would also render in-the-field updates impossible.

So, I would like to ask if a different approach could, perhaps, work. This would go like follows.
One could do the development in python, when the code is ready for release scramble it with a key on the computer, and then give the scrambled stuff to whoever needs it. One would then write a very simple module in C that would do nothing but unscramble the python code. This C module would have to be compiled only once, and it would then be part of the micropython firmware. Something like this (pseudo-code)

Code: Select all

key = read_key_from_disc()
code  = read_scrambled_code_from_disc()

ucode = unscramble(key, code)
exec(ucode)

(I would read the key from disc, so that it would not have to be compiled into the firmware.) The question is, whether it is possible to somehow dump ucode, once it is in RAM. If not, then I believe this would be a relatively secure approach to obfuscating the python code, and one would not lose flexibility/extendability. I would really appreciate any comments on the issue.

Cheers,
Zoltán

[pythoncoder]

If an attacker can access your hardware he has access to the scrambled code and the key, and has hardware with firmware containing an unscramble() function. So I'm struggling to understand how it is secure.

[v923z]

If an attacker can access your hardware he has access to the scrambled code and the key, and has hardware with firmware containing an unscramble() function. So I'm struggling to understand how it is secure.

Peter,

The scrambled code, or the key would not have to be hidden. I could give both to you without risks. Only the appropriate firmware could unscramble it. If you don't know which method I used to scramble the code, the key or the scrambled code itself is of no use without the firmware. Or did you mean that the compiled C code could be disassembled?

Zoltán

[pythoncoder]

I thought that only unscramble() was written in C If all your pseudocode was written in C a disassembler would be needed. The question is, would an attacker sophisticated enough to tackle Python bytecode be put off by this? It is "security by obscurity".

In most cases I'm doubtful of the merits of going to lengths to decipher someone else's code if it has to be done at disassembly level. Provide a decent programmer with a definition of the problem to be solved and await a solution: the clean room approach.

[v923z]

I thought that only unscramble() was written in C

No, I didn't make that clear, sorry.

In most cases I'm doubtful of the merits of going to lengths to decipher someone else's code if it has to be done at disassembly level. Provide a decent programmer with a definition of the problem to be solved and await a solution: the clean room approach.

The problem is, it is not only the code that I would like to obscure, but the solution to a particular physical problem. If I show you the python code, then you would immediately know not only the software implementation, but also, how the physical device works. In my case, this latter is probably more important than the software itself.

[Roberthh]

I do not agree that extracting and disassembling the unscramble code is more difficult than to do the same with the target code. Not considering the risk, that the disassembled target code in RAM may be accessible to debuggers.
If you really want to protect information on a controller, you have to use a controller dedicatedly built for that. Maxim has quite an offering, as well as TI and Freescale. These controllers typically have secure RAM and battery back-up key storage, some of the offer encrypted program space, they have anti-tamper circuitry, which will erase your keys in an attempt of tamper within a few ns, and support for crypto engines in hardware.
With using a standard controller, you'll always end up in just hiding the information.

[kfricke]

To think that kind of security is easily implemented in an open source and hacker friendly environment is a false conclusion. It might be possible, but not well supported, because it is not designed into this platforms as it is on those Roberthh did outline.

To be constructive... The intent you forshadow might be implemented on a kind of dedicated controller for your to be protected hardware/circuitry. That one could implement the secret stuff and be implemented on aore closed MCU with secured flash or the like. While your overall logic is in a micropython MCU.

[v923z]

To be constructive... The intent you forshadow might be implemented on a kind of dedicated controller for your to be protected hardware/circuitry. That one could implement the secret stuff and be implemented on aore closed MCU with secured flash or the like. While your overall logic is in a micropython MCU.

To me, the main advantage of micropython is not necessarily the fact that I can write the code in python, but that it is interpreted. That makes it possible to extend the code after the firmware was written, in the field. I see your point, but for any degree of extendability, one would have to implement an interpreter on that particular platform.

[dhylands]

You can set the RDP (read protection bits) to disable access by a debugger. I haven't heard from anybody who has done this. I've unset the RDP bit (by doing a mass erase) since some of the boards (the ones I get from GHI Electronics) come with some RDP protection.

You'd also want to modify the firmware to not execute any code from an external source, like an SD card. It's trivial to write a small python script which dumps the entire contents of flash and RAM to a file on the sdcard.

[v923z]

You'd also want to modify the firmware to not execute any code from an external source, like an SD card. It's trivial to write a small python script which dumps the entire contents of flash and RAM to a file on the sdcard.

Does it matter, where the code is executed from? Once you have the REPL, anything is fair game, isn't it? The other question is, what is the content of the RAM (the flash's content is either compiled C code, or scrambled anyway)? Is that python code, or machine code, or python byte code?