encrypting python modules

[Paul Sijben]

Hello,

this question has come by repeatedly in several guises over the past
years but has never been solved in this forum as far as I have been able
to Google.

However since so many people are asking the question, I hope someone has
made a solution and is willing to share it.

The problem: I have a client-server app written in python. I want to
make sure that the client is not:
1) destabilized by users accidentally or on purpose dropping python
files in the path (after which calling the helpdesk will not be useful)
2) extended with "new features" without me knowing about it (again
resulting in calls to my helpdesk...)
3) trivially decompiled.

Added issue, I want the client to be able to update itself when I have
fixed bugs or created new functionality.

I know that I can not stop a dedicated hacker deconstructing my code.
Since all clients need to go through the server I am not afraid of
"freeloaders".

I am now considering overriding import with some code that will only
import modules signed and crypted by me.

However I can not imagine that I would be the first one planning to do this.
So is there a solution like this available somewhere?

Paul Sijben

 

[Ben Finney]

I know that I can not stop a dedicated hacker deconstructing my code.

A direct consequence of this is that you can not stop *anyone* from
deconstructing your code if it's in their possession. It takes only
one dedicated, skilled person to crack your obfuscation system and
distribute an automated process for doing so to anyone interested.

However I can not imagine that I would be the first one planning to
do this. So is there a solution like this available somewhere?

Trying to make bits uncopyable and unmodifiable is like trying to make
water not wet.

 

[Mike Meyer]

A direct consequence of this is that you can not stop *anyone* from
deconstructing your code if it's in their possession. It takes only
one dedicated, skilled person to crack your obfuscation system and
distribute an automated process for doing so to anyone interested.

Except that's not what he's trying to do.

Trying to make bits uncopyable and unmodifiable is like trying to make
water not wet.

And again, that's not what he's trying to do. He wants to arrange
things so that he doesn't have to support unmodified versions of his
code, by making it impossible to import modified modules. While that's
still impossible, once you decide how difficult you want to make it
for people to do that, you can *probably* make it that difficult - but
the process gets progressively more difficult and expensive as you
make it harder.

I think he's contemplating only the simplest, least expensive step:
adding an import hook that only allows imports of digitally signed
modules. If planning to deploy on Windows, where he has to bundle a
python with his application, he may well implement the hook in the
interpreter instead of in python, so it's harder to find.

If you wanted to go to the expense, you could probably arrange things
so that the digital signatures are the more vulnerable attack vectors,
but I'd expect to spend millions of dollars doing so.

<mike

 

[Steven D'Aprano]

Hello,

this question has come by repeatedly in several guises over the past
years but has never been solved in this forum as far as I have been able
to Google.

However since so many people are asking the question, I hope someone has
made a solution and is willing to share it.

The problem: I have a client-server app written in python. I want to
make sure that the client is not:
1) destabilized by users accidentally or on purpose dropping python
files in the path (after which calling the helpdesk will not be useful)
2) extended with "new features" without me knowing about it (again
resulting in calls to my helpdesk...)

How often do these things *actually* happen?

Of those that actually do it, how many are clueless enough that when they
run into problems they blame you for it? (And remember that you won't
even find out about the non-clueless ones.)

 

[Marc 'BlackJack' Rintsch]

Trying to make bits uncopyable and unmodifiable is like trying to make
water not wet.

Certainly not. I can put water into the freezer, but I have no idea how
to make bits uncopyable and unmodifiable while still delivering them to
the clients for execution. ;-)

Ciao,
Marc 'BlackJack' Rintsch

 

[Ben Finney]

Certainly not. I can put water into the freezer

Turning it into ice, and making it not useable as water. So, to the
extent you've made it not-wet, you've also made it not-water.

To torture the analogy further, this would be equivalent to engraving
the bits in stone and sealing the whole in a concrete slab. While
still technically the bits can be extracted, the extent to which they
are uncopyable and unmodifiable is exactly the extent to which they
are useless as bits. As soon as they become available for use as
digital bits in some way, they become available for copying and
modifying again.

 

[Paul Sijben]

How often do these things *actually* happen?

Of those that actually do it, how many are clueless enough that when they
run into problems they blame you for it? (And remember that you won't
even find out about the non-clueless ones.)

This is a rethorical question, right?

 

[Paul Sijben]

Mike,

thanks for the constructive feedback.Indeed i probably need to patch
import in some way. Looks like there is no standard way to get this
done. So I guess I have do it myself...

In the famous last words department: how hard can that be? ;-)

Paul

 

[Robert Latest]

The problem: I have a client-server app written in python. I want to
make sure that the client is not:
1) destabilized by users accidentally or on purpose dropping python
files in the path (after which calling the helpdesk will not be useful)
2) extended with "new features" without me knowing about it (again
resulting in calls to my helpdesk...)

You could check the MD5 hashes of your files.

robert

 

[Paul Sijben]

You could check the MD5 hashes of your files.

robert

indeed but I still need to hook into import to do that reliably, right?

 

[Steven D'Aprano]

This is a rethorical question, right?

No, it's a serious question. You distribute Python code, and you're
worried that your users will modify the source code and then neglect to
mention it when they report bugs which they introduced.

Before you build an elephant-proof fence around your house, it is quite
reasonable to ask whether or not there are actually elephants in your
neighbourhood.

 

[Robert Latest]

indeed but I still need to hook into import to do that reliably, right?

Depends. In a job I once had I just supplied a shell script that spat out
the MD5 sums of my sources. When I got a support request I had the customer
run the script and email the result to me so I could check if anything had
changed. (A malicious person could of course have stored the good MD5 sums,
then done his changes, and then made his request, sending me the old sums.)
If your customer is cooperative and trustworthy, this is a good way to find
stupid mistakes. If he ain't, drop him ;-)

robert

 

[Robert Latest]

No, it's a serious question. You distribute Python code, and you're
worried that your users will modify the source code and then neglect to
mention it when they report bugs which they introduced.

Before you build an elephant-proof fence around your house, it is quite
reasonable to ask whether or not there are actually elephants in your
neighbourhood.

Depending on where you are, there are probably plenty. Recently I started
hacking around in a GPLed Python app (GRAMPS, if anybody cares). This
program has a built-in bug report feature which makes it easy to email bugs
with associated stack trace etc. to the developers. Unfortunately the bug
report window also automatically popped up even when stuff went wrong within
my own broken code. For such a case it would be good if a software could
somehow detect modifications of itself and its associated modules.

And, contrary to the advice I gave elsethread, unfortunately it's impossible
to just drop uncooperative customers when you develop GPL software ;-)

robert

 

[Reedick, Andrew]

-----Original Message-----

From: [email protected] [mailtoython-
[email protected]] On Behalf Of Paul Sijben
Sent: Friday, January 11, 2008 4:45 AM
To: (e-mail address removed)
Subject: encrypting python modules


The problem: I have a client-server app written in python. I want to
make sure that the client is not:
1) destabilized by users accidentally or on purpose dropping python
files in the path (after which calling the helpdesk will not be useful)
2) extended with "new features" without me knowing about it (again
resulting in calls to my helpdesk...)

Would the site module help with that? It looks like site will
let you put your modules first in sys.path. Or what about just updating
sys.path as the first action in your program?

Or what about pulling clean copies of the files from a
tar/zip/archive before execution? A shell script creates a temp dir and
extracts the files to the temp dir to run. Not sure it would do any
good to pull from an encrypted tar/zip/archive.

Or what about pulling the client files from the server instead
of a tar/zip/archive...?



*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

 

[Steven D'Aprano]

And, contrary to the advice I gave elsethread, unfortunately it's
impossible to just drop uncooperative customers when you develop GPL
software ;-)

Just because you are writing GPLed code doesn't mean you are permanently
linked to anyone you have supplied code to. You can send their emails
straight to /dev/null. You don't have to give them any support, only the
source code. And if you do give them support, the GPL doesn't limit what
your hourly rates are: you are free to charge them one million dollars
per hour, payable in advance in blocks of fifteen hours.

If they don't like it, they can always fork the code, or find another
person to support it, or simply stop being dicks.

 

[Ben Finney]

And, contrary to the advice I gave elsethread, unfortunately it's
impossible to just drop uncooperative customers when you develop GPL
software ;-)

On the contrary. The GPL includes a big fat "NO WARRANTY" clause. If
you're not selling warranties to people, don't provide any more
support to them than you want to.

The main benefit of software licensed under the GPL is that your
customer has the freedom to take the software and get someone else to
improve it instead of you. That's good for them *and* good for you,
since you *can* drop them if it's to your advantage to do so.