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)

iD8DBQFBp0eqdIO4ozGCH14RAoqDAJ4ub7NKq7fTd+28oKG6rt LxWsP+WgCgmFZQ
UQlXTe8qpcUKITzGhegBdXo=
=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*******@eircom.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*******@eircom.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 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------

[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

[Peter Maas]

Craig Ringer schrieb:

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

I can think of 3 reasons to prevent tampering:

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

It's not guaranteed but if protection works in 99.9% of all instal-
lations it makes sense, at least if you are not producing highly
visible software like Windows.

Reverse engineering may be possible but in most cases it is a huge
effort. Think of the samba project which builds Windows server
software by analyzing network packets and this is probably easier
than to analyze machine code.

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?

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

[Grant Edwards]

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?

To avoid embarassment.

--
Grant Edwards grante Yow! Why don't you
at ever enter and CONTESTS,
visi.com Marvin?? Don't you know
your own ZIPCODE?

[Dave Reed]

On Monday 29 November 2004 14:13, Grant Edwards wrote:

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

If the "reverse engineering" argument boils down to "protecting source doesn't make sense" then why does Microsoft try so hard to protect
its sources?

To avoid embarassment.

+1 QOTW

[Marco Aschwanden]

+1 QOTW

[Peter Maas]

Grant Edwards schrieb:

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?

To avoid embarassment.

:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.

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

[Gustavo Córdova Avila]

Peter Maas wrote:

Grant Edwards schrieb:

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?

To avoid embarassment.

:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.

BWAAHHAHAHA!!!

Damn you!! Coke is so hard to clean off a keyboard!!

Good laugh, thankyou so much :-D
--
Gustavo Córdova Avila <gu*************@q-voz.com>
<mailto:gu*************@q-voz.com>
*Tel:* [phone] ext. 127
Integraciones del Norte, S.A. de C.V.
Padua #6047, Colonia Satélite Acueducto
Monterrey, Nuevo León, México.

[Peter Hansen]

Gustavo Córdova Avila wrote:

Peter Maas wrote:

Grant Edwards schrieb:

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?
To avoid embarassment.

:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.

BWAAHHAHAHA!!!

Damn you!! Coke is so hard to clean off a keyboard!!

Yeah, I hate the way the powder builds up between the keys.

Oh.

You meant the _drink_...

-Peter

[Lucas Raab]

Peter Hansen wrote:

Gustavo Córdova Avila wrote:

Peter Maas wrote:

Grant Edwards schrieb:

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

> If the "reverse engineering" argument boils down to "protecting source
> doesn't make sense" then why does Microsoft try so hard to protect
> its sources?

To avoid embarassment.

:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.

BWAAHHAHAHA!!!

Damn you!! Coke is so hard to clean off a keyboard!!

Yeah, I hate the way the powder builds up between the keys.

Oh.

You meant the _drink_...

-Peter

Nice. Very nice!!

[Leif K-Brooks]

Grant Edwards wrote:

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?

To avoid embarassment.

+1 QOTW (Everyone else was doing it, I just wanted to be popular!)