Protecting Python source

[Alan Sheehan]

Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

Is it possible to load the scripts from zip files where the zip files
are password protected ?

Any other ideas ?

Many thanks,

Alan

[Gerhard Haering]

On Fri, Nov 26, 2004 at 07:01:27AM -0800, Alan Sheehan wrote:

Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. [...]

To get more meaningful answers, please expand on what exactly you mean with
"tamper proof". What is the attacker scenario? Are there passwords for external
systems embedded in the Python source code, or what's the deal about it?

-- Gerhard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBp0eqdIO 4ozGCH14RAoqDAJ 4ub7NKq7fTd+28o KG6rtLxWsP+WgCg mFZQ
UQlXTe8qpcUKITz GhegBdXo=
=7/id
-----END PGP SIGNATURE-----

[Nick Coghlan]

Alan Sheehan wrote:

Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.
If all you want to prevent is casual user tinkering, just shipping compiled
bytecode is probably enough. (yes it *can* be decompiled, but a casual user
isn't going to bother, any more than they bother disassembling standard binaries).

For slightly greater obfuscation, push the key parts you wish to obscure into a
C/C++ extension module.

There's nothing to be done to stop the determined cracker, though, as anyone who
can effectively reverse engineer pure C++ programs is going to be able to figure
out how to interpret .pyc files pretty quickly.
Is it possible to load the scripts from zip files where the zip files
are password protected ?

Since the interpreter needs to read your zipfile, there are potential problems
with that. I believe it could be done, though. You'd need a C extension module
which knew the password and installed a custom import hook to handle opening the
zip file. And disassembling the extension module would also give an attacker
the password, thus allowing them access to the zipfile.

So, as Gerhard said, it really depends on what you mean by "tamper proof".

Cheers,
Nick.

[Thomas Heller]

ad*******@eirco m.net (Alan Sheehan) writes:

Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

Is it possible to load the scripts from zip files where the zip files
are password protected ?

Any other ideas ?

For py2exe created distributions, the simplest and imo most effective
thing is to specify a different extension for the source archive, maybe
app.lib instead of library.zip. This way, there's at least no hint that
is is a zip archive.

For passwords, aren't there lots of zipfile password crackers out there?
And even in a password protected zipfile you are still able to see the
filenames iirc, and unless that has changed.

Thomas

[Josef Meile]

> I am looking for methods of deploying applications with end users so

that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

You could try to obfuscate the code with the pyobfuscate package. The
scripts will be easy to reverse, but difficult to understand. I haven't
tried it because I haven't had this need, but it shoul work:

http://www.lysator.liu.se/~astrand/p...s/pyobfuscate/

Regards,
Josef

[RCS]

Alan Sheehan wrote:

Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

An interesting question is, what makes your source code so innovative as
to mandate this tamper proof thing?

Just wondering.

QXX

[Alex Martelli]

Alan Sheehan <ad*******@eirc om.net> wrote:

Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

Like for any other language, the code you distribute _can_ be
decompiled, analyzed, studied, and modified, by any attacker determined
enough to bypass the technical and legal barriers. If your code is
worth protecting, then it's worth attacking.

Like for any other language, a solid solution is to put crucial parts of
your application on a server that is entirely under your control,
accessed by the rest of the application (the part that you distribute)
via any distributed processing technology -- Corba, XML-RPC, pyro,
whatever. The pluses and minuses are obvious: your application will run
only with network access (which is more and more widely available but
not yet universal); OTOH, you can exert fine control on who and when can
access the crucial parts (by subscription, pay per use, whatever
business model you fancy). It's the only approach that can be made as
solid as the server you use, which is _very_ solid. Even burning some
algorithms into a dedicated chip is less robust, since chips _do_ get
reverse engineered / decompiled too.

If all you want is to make the barriers as high as reasonably feasible,
crypted archives with a dedicated pyrex-coded module to decrypt and make
them accessible to the main program is one way. Legal barriers however
tend to work better than technical ones, which may be perceived as
interesting challenges and stimulate attacks. Note that just about any
piece of software that's widespread, whatever language and protection
scheme it may have used, is available in cracked form in the `warez'
circuits. Go server-side as much as you can, and rely on the awesome
coercive powers of the state for the rest -- "go legal, young man".
Alex

[Armin Steinhoff]

Alan Sheehan wrote:

Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

Is it possible to load the scripts from zip files where the zip files
are password protected ?

Any other ideas ?
Use Pyrex in order to convert the critical parts to C modules ...

Regards

Armin

Many thanks,

Alan

[Peter Maas]

RCS schrieb:

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

An interesting question is, what makes your source code so innovative as
to mandate this tamper proof thing?

I can think of 3 reasons to prevent tampering:

- You need money and want to sell your software on a "per seat" basis.

- You don't want customers to fiddle with your code and then innocently
call for support and demand "bug fixes" for free.

- Your customer demands closed source because the code contains trade
secrets.

Protecting source has nothing to do with innovation. It's about making
money.

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel [phone]
E-mail 'cGV0ZXIubWFhc0 BtcGx1c3IuZGU=\ n'.decode('base 64')
-------------------------------------------------------------------

[Craig Ringer]

On Mon, 2004-11-29 at 18:04, Peter Maas wrote:

I can think of 3 reasons to prevent tampering:

- You need money and want to sell your software on a "per seat" basis.
If you mean that you therefore must add built-in copy-protection, then
sure. Users will always get around it if they really want to, so
tamper-resistance is probably closer to the truth, but it'll slow them
down.

On the other hand, one can license software per-seat quite effectively
without software enforcement, or with only informative software
enforcement ("By the way, you appear to be over your seat count."). In
many cases this is good enough - the user can always crack / steal your
software, tamper resistant or not (witness: the games industry), and
code without copy protection is a LOT friendly.

For example, my employer currently relies on software that has a dongle.
The software manufacturer has gone out of business, so if that dongle
dies we're in trouble, as development of a replacement is moving slowly.
In future, if we're given the choice between a product that's superior
in price or functionality but has opressive copy protection and one
that's more limited or more expensive, but has no software enforcement
of copy protection, we'll buy the inferior or overpriced one.

We're quite capable of monitoring our own license compliance. Those who
aren't are also generally quite capable of 'fixing' the software, tamper
resistant or not, so I really don't see the point.
- You don't want customers to fiddle with your code and then innocently
call for support and demand "bug fixes" for free.
There, what you really want is tamper-evident code not tamper-proof
code. That's quite a bit more practical IMO, and may be a good place to
look at digital signing.
- Your customer demands closed source because the code contains trade
secrets.

My understanding is that that's never guaranteed safe, no? Or are
restrictions against reverse engineering now commonly enforcable?

--
Craig Ringer