[CentralOH] Zip Files Distro .pyc

[Mark Erbaugh]

On Oct 30, 2010, at 6:24 AM, James - Atlantix wrote:

> Mark;
>  
> Your suggestion is much appreciate & I see it as an excellent approach. I will try this. This suggestion is on the line of using the "compile" command in Python to generate .pyd / .pyc files.
>  
> ( See http://docs.python.org/library/py_compile.html )


The zipfile.PyZipFile class will do the compilation for you. I just re-read the docs on it and discovered that it doesn't compile to .pyo, but to .pyc; however, it will use a .pyo file if present. If the .pyo file was created with the -OO command line switch to the python interpreter, docstrings will be removed. That would provide you with some additional security, as otherwise, well-written docstrings which you need for maintenance might give away your secrets to someone who browses the code.

>  
> On another note, I have this crazy idea:
>  
> I will use a small non-volatile FPGA (such as one from Lattice Seminconductor, such as their LatticeXP2 device) and power it from the USB port. I will then make a small kernel in the GUI program that will use some form of encryption and talk to the FPGA over the USB port . .  making sure to get the right security key back to enable the program. The kernel will then hand off operation to the rest of the program. During the main GUI operation, there will periodically be a polling or a "self internalized cron job" that will go out an access the security key on the FPGA. This is a bit more homegrown that using a USB key and Aladdin driver, etc. Funny thing is, I have all the code working to do this, as well as hardware to test the idea.
>  

Sometimes, it's best to work with what you know. That's why I bet there are more 'database' applications out there written in Excel than in a proper database.  As far as verifying the security device, rather than having an automatic task, you might just have your code check for the device a key points in the process. For example, right before the program generates any output. If that check slows things down too much, you could keep a counter of how many times a certain step has been executed and check the device every n-th time.  In fact, you could code the check into a simple class and just call it's 'check_security' (or similar) method at strategic points throughout the program. If no check was needed (because one had been done recently), it would just return.  Otherwise it would check the device and and return if it was okay or take whatever action (probably shut down the program with a message) if the device wasn't present. If you put all the calls to check the security device in one place, it would be easy to enable or disable checks or change the behavior.

If you wanted to be even more secure, you could encrypt the .pyo files and have the decryption routine in the FPGA. You could hook python's import mechanism to take the encrypted file and run it through the decryption before loading it. Thus the unencrypted code would only exist in memory, making it harder (but not impossible - I just read COhPy's copy of "Gray Hat Python" and they discuss methods of getting at code in similar situations).

How much do you think it would cost to make the FPGA device? Would this be something that could be marketed to other Python programmers who need to protect their source code?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/mailman/private/centraloh/attachments/20101030/af162c7c/attachment.html>