How to protect Python source from modification

Frank Millman frank at chagford.com
Mon Sep 12 11:33:10 EDT 2005


Gerhard Häring wrote:
> Frank Millman wrote:
> > Hi all
> >
> > I am writing a multi-user accounting/business system. Data is stored in
> > a database (PostgreSQL on Linux, SQL Server on Windows). I have written
> > a Python program to run on the client, which uses wxPython as a gui,
> > and connects to the database via TCP/IP.
> >
> > The client program contains all the authentication and business logic.
> > It has dawned on me that anyone can bypass this by modifying the
> > program. As it is written in Python, with source available, this would
> > be quite easy. My target market extends well up into the mid-range, but
> > I do not think that any CFO would contemplate using a program that is
> > so open to manipulation. [...]
>
> My suggestion is to use py2exe or cx_Freeze to package your application.
> It's then not as trivial to modify it. Btw. you don't need to ship the
> .py source code files, it's enough to ship only .pyc bytecode files.
>
> Using py2exe it's not even obvious that your application is written in
> Python at all.
>
> It's not a silver bullet, but at least it makes recompiling/modifiying
> your app not easier than with Java (and/or .NET I suppose).
>

My problem is that, if someone has access to the network and to a
Python interpreter, they can get hold of a copy of my program and use
it to knock up their own client program that makes a connection to the
database. They can then execute any arbitrary SQL command.

> That being said, even if you continue with the GUI approach, it may
> still be a good idea to factor out all the business logic in a separate
> module so you can eventually switch to a web application or a three-tier
> model without too much effort.
>

Agreed

> Also, there's no need at all to put in countless hours implementing your
> own network protocol. If you really want to separate client and app
> server, then why not use something simple as PyRO, or even XML/RPC.
>

Perhaps 'protocol' is the wrong word. I already have a simple socket
server program running. If explain how I do it, perhaps you can
indicate whether PyRO or XML/RPC would make my life easier.

The server program is currently programmed to accept a number of
message types from the client program. Each message's data string
starts with a numeric prefix, which indicates the type of message,
followed by a pickled tuple of arguments. The server program reads the
string, extracts the numeric prefix, and passes the rest of the string
to the appropriate function using a subthread.

For example, I keep track of who is currently logged in. On startup,
the client connects to my server and sends a '1' followed by their
userid and other information. The server receives this and passed the
data to a 'login' function, which uses a Python dictionary to store the
information. If the server detects that the user is already logged in,
it sends back an error code and the client program displays a message
and terminates. Otherwise it sends back an 'ok' code, and the client
can continue. When the client logs off, it sends a '2' followed by
their userid, which the server receives and passes it to a 'logoff'
function, which deletes the entry from the dictionary.

The system of numeric prefixes and associated data string making up a
message is what I mean by a protocol.

> HTH,
> 
> -- Gerhard

Thanks

Frank




More information about the Python-list mailing list