distribute Pylons app with bytecode files only?
phlee
Is it possible to distribute a Pylons app in which only .pyc (or .pyo)
files are included?
If not, can I just say web2py is currently the only Python web
framework supporting bytecode distribution?
Dean Landolt
If you're that worried about your IP, don't code in python. Of course, given enough effort you can pretty much decompile anything. So if you're that worried, perhaps you shouldn't distribute that code at all -- just provide a web service.
Shannon -jj Behrens
a Berkeley DB and then used a custom import hook to get at it.
-jj
--
It's a walled garden, but the flowers sure are lovely!
http://jjinux.blogspot.com/
phlee
I didn't know that by just decompiling bytecode, the source code could
be easily derived
Will this fact be a limitation for Python apps on embedded systems? I
think source code protection seems to be a great concern when
deploying apps on embedded systems.
On 7月4日, 上午9時40分, "Shannon -jj Behrens" <jji...@gmail.com> wrote:
> In the past, I worked at a company that stored all Python encrypted in
> a Berkeley DB and then used a custom import hook to get at it.
>
> -jj
>
>
>
> On Thu, Jul 3, 2008 at 8:45 AM, Dean Landolt <d...@deanlandolt.com> wrote:
> > You do realize it's trivial to decompile python bytecode, right?
>
> > If you're that worried about your IP, don't code in python. Of course, given
> > enough effort you can pretty much decompile anything. So if you're that
> > worried, perhaps you shouldn't distribute that code at all -- just provide a
> > web service.
>
Mike Orr
> I didn't know that by just decompiling bytecode, the source code could
> be easily derived
>
> Will this fact be a limitation for Python apps on embedded systems? I
> think source code protection seems to be a great concern when
> deploying apps on embedded systems.
You'd have to ask an embedded systems businessman; it's not really a
Python question. Many of the people on this list are fans of
open-source software, so making code obscure is not one of our top
priorities, and for some it's an anti-priority. But embedded software
is much more specific to its device than general PC software is, so
even if you have the source there's not as much you can do with it.
The situation is not much different from Javascript. You can't hide
Javascript if you want it to run on the user's computer, but that
doesn't stop companies from making money with Javascript applications.
--
Mike Orr <slugg...@gmail.com>
Jonathan Vanasco
interpreter needs to be able to run it. Bytecode can easily be turned
back into source with a decompiler on any language.
The 'trick' some use is to obfuscate it - basically do a quick pass
before compiling to make the code unintelligible. It's still wholly
readable, but you have variable names like "Ya1209ASD5kjIad" which can
make no sense.
Some people use 'encryption' as a trick - which is quite stupid -- the
interpreter needs to decrypt the code , so it's a reversible
encryption which can easily be undone.
A firm I once worked with *mistakingly* bought several dozen units of
an embedded system made by a foreign firm that was unable to support
or alter their code - contractors built it for them, and they
basically killed relations with them. They insisted that the
contractors encrypt the code and obfuscate it so people couldn't copy
it.
It took us 20 minutes to track down the right library to decrypt the
code and export the source. Then we spent 10hours de-obfuscating it
with simple find&replace.
The moral of the story is: when you're dealing with interpreted
languages, the ONLY thing you will be able to do is to make it harder
for people to decompile.
This is true of python, perl, ruby, flash, etc etc
If you want to protect code on embedded systems, make it harder to get
at the code through hardware limitations... then cover it with
copyright, patent and contract law in the countries where you think it
will be accessed and litigate. Cellphones, Iphones, Every gaming
console, etc has been hacked. If people want to get at your code,
they will.
Cliff Wells
> Thanks, all
>
> I didn't know that by just decompiling bytecode, the source code could
> be easily derived
>
> Will this fact be a limitation for Python apps on embedded systems? I
> think source code protection seems to be a great concern when
> deploying apps on embedded systems.
This is a limitation for all languages on any system, embedded or
otherwise. Ask any vendor who has had their firmware disassembled. At
any rate, usually source code for embedded devices is specific enough
that protecting code is almost moot, since the code will only run on a
particular device.
There are better ways to protect code on embedded devices, such as using
secure media to store the software (encryption keys can be stored in
firmware). Further, firmware can validate code checksums, so that even
if someone obtains the code from the device you can ensure that they
can't run a modified version of the code on the same device.
Of course, assuming any of these devices make it into anyone's
possession, a determined hacker will almost certainly break whatever
scheme you come up with. It's mostly a question of how determined and
skilled they will have to be.
Sometimes this type of security is required (by law or PHB's), but most
people who ask this sort of question are simply following a cargo-cult
mentality of believing that source code must be kept secret, without
much thought as to why and what the risks/benefits really are. If your
code is so unique as to be worth protecting this way then it's probably
worth patenting whatever amazing algorithm it contains. If it's not
worth the few thousand dollars you'll spend applying for a patent, then
it's probably not worth the few thousand dollars of development time
you'll spend trying (almost certainly unsuccessfully) to protect your
code by technological means.
Cliff
Shannon -jj Behrens
I would have enjoyed your email much more if you didn't use such
strong language ;)
I've used obfuscation tools for Perl before, and yes, they're nice.
When we encrypted the Python code, the only way to unencrypt it was to
understand the unencryption code which was written in C and compiled
statically into Python. Sure, it's not perfect. However, it's
definitely a strong deterrent. On top of this is the DMCA, etc.
By the way, major props to Mike Orr. I agree. I hate closed source
software even when I get paid to write it ;)
-jj
Jonathan Vanasco
On Jul 7, 7:58 pm, "Shannon -jj Behrens" <jji...@gmail.com> wrote:
> I would have enjoyed your email much more if you didn't use such
> strong language ;)
>
> I've used obfuscation tools for Perl before, and yes, they're nice.
> When we encrypted the Python code, the only way to unencrypt it was to
> understand the unencryption code which was written in C and compiled
> statically into Python. Sure, it's not perfect. However, it's
> definitely a strong deterrent. On top of this is the DMCA, etc.
>
> By the way, major props to Mike Orr. I agree. I hate closed source
> software even when I get paid to write it ;)
>
if you want to throw away your money at encryption to make it harder,
so be it. but someone who wants to reverse engineer and decrypt and
decompile something will - you're just going to make it harder and
waste their time. and when someone does steal it, you're going to be
in the same situation in terms of needing to litigate.
so, IMHO, i think firms are better off building software, being clear
on the license/copyright, and focusing on making things work -- not
locking them down.
and despite me saying 'lawyer' many times -- open sourcing as much as
they can.
Dean Landolt
* rimshot *
mdipierro
it is true that it is possible to decompile bytecode python but it is
also true that it is possible to decompile or disassemble any
language. That in itself does not make it worthless for two reasons:
The first is that it is illegal (if you say so in the license). How
easy it is to open the front door of your house? that does not mean
anybody does it. People have sued and have won trials in similar
circumstances. VB and C# sell because they claim compilation
protection but it is not better than in Python.
In the specific case of web2py. web2py does one more step before
bytecode compiling. It translates all view hierarchy for every action
into a single python file (resolves all extended and included
templates into one view, and then tuns the html into python code), the
it bytecode compiles it. It manly does this to serve pages faster
without parsing and string substitution at runtime. This also means
that even if they were to decompile it, they would not get exactly the
original code and what they'd get would not be too easy to turn into a
working web2py application.
I am here temporarily so if you have questions we have a google list
for web2py.
Massimo
P.S. Sorry for intruding but I thought this was relevant. Pylons rocks!
Mike Orr
>
> Hi Phlee,
>
> it is true that it is possible to decompile bytecode python but it is
> also true that it is possible to decompile or disassemble any
> language. That in itself does not make it worthless for two reasons:
>
> The first is that it is illegal (if you say so in the license).
It may or may not be illegal, depending on the laws about reverse
engineering, DMCA, and the validity of shrinkwrapped or
click-to-assent licenses in the recipient's country.
--
Mike Orr <slugg...@gmail.com>
Cliff Wells
It may not be illegal to decompile the code (reverse-engineering has
some limited protections), but it would almost certainly be illegal to
redistribute that code as copyright law is pretty well established in
most countries.
Much of the relevance of all of this revolves around why the OP thinks
he needs to protect his code (which he so far hasn't revealed). If it's
simply to protect IP then my personal feeling is that it's most likely
counter-productive. If it's for security reasons, then obfuscation is a
poor substitute for building an actual secure device.
Cliff
Jorge Vargas
>
> Sometimes this type of security is required (by law or PHB's), but most
> people who ask this sort of question are simply following a cargo-cult
> mentality of believing that source code must be kept secret, without
> much thought as to why and what the risks/benefits really are. If your
> code is so unique as to be worth protecting this way then it's probably
> worth patenting whatever amazing algorithm it contains. If it's not
> worth the few thousand dollars you'll spend applying for a patent, then
> it's probably not worth the few thousand dollars of development time
> you'll spend trying (almost certainly unsuccessfully) to protect your
> code by technological means.
>
all binary which can be turned into opcodes which can be turned into
ASM which can be turned into C,etc. There is no way you can't hide
something that is supposed to run on the client machine from the
client. So if you want to do it for being cool, go ahead if not use
the correct way.
Someone ones said, any security scheme can be broken with enough time
in your hands.
> Cliff
>
>
> >
>