471,337 Members | 896 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,337 software developers and data experts.

encrypting python modules

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

Jan 11 '08 #1
13 1464
Paul Sijben <pa*********@xs4all.nlwrites:
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.

--
\ "The shortest distance between two points is under |
`\ construction." -- Noelie Alito |
_o__) |
Ben Finney
Jan 11 '08 #2
On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney <bi****************@benfinney.id.auwrote:
Paul Sijben <pa*********@xs4all.nlwrites:
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.
Except that's not what he's trying to do.
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.
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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
Jan 11 '08 #3
On Fri, 11 Jan 2008 10:44:36 +0100, Paul Sijben wrote:
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.)


--
Steven
Jan 12 '08 #4
On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote:
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
Jan 12 '08 #5
Marc 'BlackJack' Rintsch <bj****@gmx.netwrites:
On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote:
Trying to make bits uncopyable and unmodifiable is like trying to
make water not wet.

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.

--
\ "People demand freedom of speech to make up for the freedom of |
`\ thought which they avoid." -- Soren Aabye Kierkegaard |
_o__) (1813-1855) |
Ben Finney
Jan 12 '08 #6
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?
Jan 14 '08 #7
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

Mike Meyer wrote:
On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney <bi****************@benfinney.id.auwrote:
>Paul Sijben <pa*********@xs4all.nlwrites:
>>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.

Except that's not what he's trying to do.
>>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.

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
Jan 14 '08 #8
Paul Sijben wrote:
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
Jan 14 '08 #9
Robert Latest wrote:
Paul Sijben wrote:
>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
indeed but I still need to hook into import to do that reliably, right?
Jan 14 '08 #10
On Mon, 14 Jan 2008 09:49:49 +0100, Paul Sijben wrote:
>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?
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.

--
Steven
Jan 14 '08 #11
Paul Sijben wrote:
>>
You could check the MD5 hashes of your files.

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
Jan 14 '08 #12
Steven D'Aprano wrote:
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
Jan 14 '08 #13
Robert Latest <bo*******@yahoo.comwrites:
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.

--
\ "Everything is futile." -- Marvin of Borg |
`\ |
_o__) |
Ben Finney
Jan 14 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by dzieciou | last post: by
2 posts views Thread by . | last post: by
3 posts views Thread by Paul Mc Gee | last post: by
12 posts views Thread by Byte | last post: by
4 posts views Thread by Fabian Braennstroem | last post: by
5 posts views Thread by Why Tea | last post: by
3 posts views Thread by kyosohma | last post: by
reply views Thread by J. Peng | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.