Python obfuscation

[petantik]

Are there any commercial, or otherwise obfuscators for python source
code or byte code and what are their relative advantages or
disadvantages. I wonder because there are some byte code protection
available for java and .NET, although from what i've read these seem to
be not comprehensive as protection schemes



http://petantik.blogsome.com - Telling it like it is

[The Eternal Squire]

Come on! I was only just trying to accomodate the OP with a plausible
method to fit his business model, based on techniques passed on to me
by my various teachers at school and my senseis at workplaces..
Please don't judge me for attempting to pass on experience. It's his
choice.

While I'd like to figure out myself a nice software package to write
and market and earn a good living now that I've walked away from the
rat race, I can also see myself having humanity as my client (the FOSS
model).

The Eternal Squire

[Bill Mill]

On 10 Nov 2005 08:40:17 -0800, Ben Sizer <ky*****@gmail. com> wrote:

Alex Martelli wrote:

This is (a minor) one of the many reasons that make webservices the way
of the future (hey, even *MSFT* noticed that recently, it seems...).

But they are not suitable for all applications, and probably never will
be.

Your only solution, then, is to write unpopular code. Because, as Alex
said, it will otherwise be broken into. Let's look at two very popular
pieces of code: Half-Life 2 and Windows XP. How are they secured?
Previous version of these software products used sophisticated
client-side programming to try and be secure, but the security was
nonexistant. Users share keys and cracks with each other.

Now, both of these programs require verification (phone and/or web) to
be used. The only truly secure method of assuring that they're not
used in ways you don't intend is to require the user to contact you to
use it, and that's a deal with the devil. One you might need to make
if security is that important to you, as Microsoft and Valve have
decided it is, but it's a deal with the devil nonetheless.

Peace
Bill Mill
bill.mill at gmail.com

[Mike Meyer]

"petantik" <pe***********@ gmail.com> writes:

Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

Nah. Compiling/interpreting is an implementation detail, and
orthogonal to the issue of "high level". There are compilers for high
level languages, and interpreters for low level languages. At the
lowest level, a machine emulator is an interpreter for machine code,
which is the lowest level most programmers deal with (at least I think
it is....).

If you really wanted "compiler-like" security for Python, you could
write a Python compiler. There have been posts about a compiler that
generated C++ recently, though it's still under development, and I
haven't followed it closely. You might also consider retargetting one
of the existing Python compilers to your architecture of choice, or to
another language. You might also consider translating Python to a
language with similar capabilities for which a compiler exists, like
Common LISP.

Of course, once you've got machine code, it doesn't matter how high
level the source was. That may make getting the source back harder,
but people who are cracking your program don't want to do that - they
just want to find the place where the security happens, and either
figure out the input that will make it happy, or invert the behavior
after a test.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Steven D'Aprano]

On Thu, 10 Nov 2005 08:23:07 -0800, petantik wrote:

Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

Dude, a comprehension protection for *any* software can never be built
because of the fundamental nature of computers. Trying to stop bytes from
being copyable is like trying to stop water from being wet, and once
copied, all copies are identical and therefore indistinguishab le.

It isn't a matter of protecting software or data. It is a question of how
hard do you want to make it for people to copy/crack? That itself has
costs, costs of time, space, complexity, bugs, lost opportunities,
customer dissatisfaction , and even legality.

Sony has just found that out: having been caught installing root-kits on
peoples computers, they are now being sued.

--
Steven.

[Timothy Smith]

Reliability is
important but so is protecting your code in an effective manner

there is no way to prevent people disassembling your code compiled or
otherwise. once you give then the program they can easily take it apart.
no if's, no but's; do NOT rely on binary's for security.

the big software companies might say 'trusted computing will save us'
but I for one will never truly trust it.

trusted computing it about your computer not trusting YOU. the computer
you pay for will decied based on some other company's whim's what you
are and are not allowed to do.
Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

i repeat. there is no such thing as protected code. i've seen people de
construct exe's written in C.

[Mike Meyer]

"Ben Sizer" <ky*****@gmail. com> writes:

For example, I'd like to write a game in Python. I'd like to give the
game away free and charge for extra content. In C++ I can make it
difficult for users to share content with others who haven't paid for
it, with cryptographic hashes and the like. No, not impossible, but
difficult enough to deter most people. In Python it's much harder, when
the end user can open up the relevant file and quickly remove the
license check. No doubt this is another of the reasons why Python isn't
catching on quickly for game development, sadly.

What makes you think this is the case? There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules. Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".

Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.

Not that I'm convinced that putting everything on a "secure server" is
proof against getting your code stolen. Last time I was involved with
security people, it was commonly acknowledge that there were two types
of security people: those who knew when their systems were last broken
into, and those who didn't. Source - and other things - gets stolen
from "secure servers" on a regular basis, and those machines don't
have to provide some way for the potential thieves to execute the
code. But at least with this model, some of the advantages are on your
side, so you stand a fighting chance.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Carsten Haese]

On Thu, 2005-11-10 at 16:53, Steven D'Aprano wrote:

Dude, a comprehension protection for *any* software can never be built
because of the fundamental nature of computers. Trying to stop bytes from
being copyable is like trying to stop water from being wet, and once
copied, all copies are identical and therefore indistinguishab le.

+1 QOTW!

--
Carsten Haese - Software Engineer | Phone: [phone]
Unique Systems, Inc. | FAX: [phone]
1687 Woodlands Drive | Cell: [phone]
Maumee, OH 43537 | Email: ca*****@uniqsys .com

[Yu-Xi Lim]

Bill Mill wrote:

Your only solution, then, is to write unpopular code. Because, as Alex
said, it will otherwise be broken into. Let's look at two very popular
pieces of code: Half-Life 2 and Windows XP. How are they secured?
Previous version of these software products used sophisticated
client-side programming to try and be secure, but the security was
nonexistant. Users share keys and cracks with each other.
and

Mike Meyer wrote: What makes you think this is the case? There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules. Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".

Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.

Funny you should mention Half-Life 2. I actually went out and bought
Half-Life 2 from the store instead of waiting for a crack to be released
(the unique scheme they used meant that crackers will take a little
longer than usual). I really wanted to play this game (i.e., it's very
popular) and couldn't wait.

My brother is bugged by Civilization IV's copy protection. A couple of
days ago, after consulting me on what other options he could try, he
finally said in frustration, "Maybe I should go buy the game."

This is a personal anecdote, but I'm sure it applies to at least some
people. Obviously I'm not an honest person. But I'm not so against
spending money on software that I won't buy it if there's a pretty good
copy protection system on it. The "keeping honest people honest"
argument is simplistic and as Ben said, "black and white thinking".

Ben's analogy of the house is not a perfect example, but it's still a
fair one. You know that if some one really wants to break into your
house, he will get in, regardless of your sophisticated laser trip wire
system, ex-SAS guards, and genetically-engineered guard dogs. But as
long as the cost of protection is less than the cost of the item you're
protecting (multiplied by the relevant probabilities, factoring
recurring costs, etc), it's worthwhile to spend money on protection. If
that fails, then you will of course fall back on the law, but you still
try to prevent it from happening in the first place.

I do believe that code obfuscation and copy protection measures work, to
a limited extent. Few software companies believe that their copy
protection will be uncrackable (though their marketing droids may say
otherwise), but are most willing to invest in it to at least temporarily
stave off the piracy.

Distribution of python modules as compiled bytecode is a limited form of
obfuscation. Some believe it's enough. But if there's a free obfuscator
out there than can increase the difficulty of reverse engineering, why
not use that too? Costs you nothing, and may get you a customer or two
more before some one manages to crack that.

Obfuscation has it's place. It's not the final solution for software
protection (and there probably isn't one), but it is one more lock you
can use to deter or delay theives. You can't expect to win against
determined theives, but you can remove as many advantages that they have.

Now, both of these programs require verification (phone and/or web) to
be used. The only truly secure method of assuring that they're not
used in ways you don't intend is to require the user to contact you to
use it, and that's a deal with the devil. One you might need to make
if security is that important to you, as Microsoft and Valve have
decided it is, but it's a deal with the devil nonetheless.

This seems to be opposite to what you said in the previous paragraph.
Contacting and verifying with the company every time you use the
software is obviously not "the only truly secure method", since there
are cracks and keys floating around. It is also not quite as evil as it
may seem, since authorization is only required on initial use (and
online gaming).

[Mike Meyer]

Yu-Xi Lim <yu**@ece.gatec h.edu> writes:

Bill Mill wrote:

Your only solution, then, is to write unpopular code. Because, as Alex
said, it will otherwise be broken into. Let's look at two very popular
pieces of code: Half-Life 2 and Windows XP. How are they secured?
Previous version of these software products used sophisticated
client-side programming to try and be secure, but the security was
nonexistant. Users share keys and cracks with each other. Mike Meyer wrote:

> What makes you think this is the case? There are ways to distribute
> Python modules so that the user can't just open them in a text
> editor. There are also ways to get cryptographic security for
> distributed modules. Yes, if you use the same methods you use in C++,
> it's "much harder". But by the same token, if you tried to use the
> methods you'd use in a Python program in C++, you'd find that the C++
> version was "much harder".

This is a personal anecdote, but I'm sure it applies to at least some
people. Obviously I'm not an honest person. But I'm not so against
spending money on software that I won't buy it if there's a pretty
good copy protection system on it. The "keeping honest people honest"
argument is simplistic and as Ben said, "black and white thinking".

And how much software is out there that you actually want so badly
that you'll buy it rather than wait unti it's cracked? Does it make up
a significant portion of the software you use? If not, then you as an
example of not merely "keeping honest people honest" are that it's
difference from reality is insignificant.
Ben's analogy of the house is not a perfect example, but it's still a
fair one. You know that if some one really wants to break into your
house, he will get in, regardless of your sophisticated laser trip
wire system, ex-SAS guards, and genetically-engineered guard dogs. But
as long as the cost of protection is less than the cost of the item
you're protecting (multiplied by the relevant probabilities, factoring
recurring costs, etc), it's worthwhile to spend money on
protection. If that fails, then you will of course fall back on the
law, but you still try to prevent it from happening in the first place.
Sounds like you just said that manufacturers should improve their
protection until they aren't making any profit on the product. That's
silly. The goal isn't to maximize protection, it's to maximize
profit. That means it only makes sense to spend money on better
protection if the cost of the protection is less than the expected
profit from adding it. The cost of the item you're protecting is
irrelevant. The cost of adding copy protection is *noticably* more
than the cost of the copy protection bits. A recent, heavily
publicized case where Sony added copy protection to a product cost
them sales, and from what I've heard, even legal fees.
I do believe that code obfuscation and copy protection measures work,
to a limited extent. Few software companies believe that their copy
protection will be uncrackable (though their marketing droids may say
otherwise), but are most willing to invest in it to at least
temporarily stave off the piracy.
Anything at all acts in the "keeping honest people honest"
capacity. It also delays the inevitable cracking - which is all you
can do. The only thing spending more on it does is lengthen the
delay. Hard data on how many sales that extra delay is responsible for
is, by it's very nature, impossible to come by. You've provided
anecdotal evidence that copy protection can improve sales. I've
provided anecdotal evidence that adding copy protection cost sales.
Distribution of python modules as compiled bytecode is a limited form
of obfuscation. Some believe it's enough. But if there's a free
obfuscator out there than can increase the difficulty of reverse
engineering, why not use that too? Costs you nothing, and may get you
a customer or two more before some one manages to crack that.

Um, if you think adding steps to the release process costs you
nothing, you don't understand the release process. If you've got a way
to obfuscate the code that doesn't require extra steps in the release
or development process, I'd love to hear about it.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Alex Martelli]

petantik <pe***********@ gmail.com> wrote:
...

I think that is not workable because it is easy to say the the internet
is available everywhere.
This implies that, if it were difficult to say it, then the scheme WOULD
be workable... which I doubt is what you mean, of course;-)

It is not available in developing countries or in rural areas and so
Things are getting better all the time in these respects - and they will
keep getting better, quite apart from "web apps", because access to
information is MUCH more precious than mere computation.
these people who live/work there will never benefit from a webservice
type protection scheme,
It's debatable whether the customer BENEFITS from having their ability
to run an application RESTRICTED. It appears that the trend (in
developing countries even more than in rich ones) is towards using open
source, anyway.
and what if the network in your area goes down?
bye bye app that I *really* need for tomorrow. Reliability is
But the risk of your specific MACHINE going down is much higher than
that of the NET going down in all of its forms at once! If I rely on a
web app, and need to use it tonight to have something ready tomorrow,
then if my machine goes down (or I suffer a power brown-out in my area,
an occurrence that is frequent in many developing countries, and not
unheard of in developed ones), then I stand a chance to rush elsewhere,
to a library, town hall, internet cafe, or ANY other location where I
may be able to grab a machine, ANY machine, connect to the net, identify
and authenticate myself, and keep using that crucial web app. If said
app is well designed and mature, it will have autosaved most of my work
up to the point of my machine's crash (or the area brown-out, etc), too.

The importance of reliability speaks in FAVOUR of keeping important
stuff on the internet, rather than on unreliable, crash-prone local
machines (...and when's the last time you did a full backup of all of
your work with all proper precautions...? For most users, "never" --
for users of web apps hosted on well-maintained sites, on the other
hand, backups ARE taken care of, professionally and properly!).

important but so is protecting your code in an effective manner
There is no effective manner of protecting your code, except running it
only on well-secured machines you control yourself. If you distribute
your code, in ANY form, and it's at all interesting to people with no
interest in respecting the law, then, it WILL be cracked (and if users
choose to respect the law, then you need no "protecting ").

I do believe that you are right about those that crack software for
kicks or money. If you look around at you local market place i'm sure
there are many 'discounted' commercial softwares/games sold. of course
the big software companies might say 'trusted computing will save us'
but I for one will never truly trust it.

Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

Many, perhaps most, of those cracked commercial programs have NOT been
written in "interprete d languages" (whatever that means), but in
assembly code, C, C++... so your last paragraph is easily shown to be an
irrelevant aside -- it's not an issue of what language the code is in.
Alex