Anti-reverse Python-based binaries?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Anti-reverse Python-based binaries?

Jun Koi
hi,

sorry if this is a bit off-topic, but i think many people here must
have the same concern, and have to cope with it somehow.

i am developing a Windows project using Python. the final executable
file .EXE and its libs will be generated with py2exe.

my concern is that: even if the binary is without the source, the code
is still Python bytecode.
and as far as i am aware, it is pretty trivial to reverse the binary
back to the Python code. (i am not very sure which tools can be used
to reverse Python-based .exe files, though)

i have few questions:

1) how serious this problem is in your opinion? is it really true that
it is impossible to protect the binaries from reversing?

2) how efficient are the reversing tools on Python binaries now? would
be great if somebody can share some experiences on using those tools.

3) if it is true that it is quite trivial to reverse the Python
binaries, how are you currently protecting your binaries? perhaps with
some obfuscated tools, making it much harder to reverse?

please share your ideas. thanks so much,
Jun
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Niki Spahiev-2
On  9.02.2012 08:51, Jun Koi wrote:
>
> 3) if it is true that it is quite trivial to reverse the Python
> binaries, how are you currently protecting your binaries? perhaps with
> some obfuscated tools, making it much harder to reverse?

We are using Wibu Keys for our software http://www.vintech.bg
Without the key files are unusable.

Niki
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Aahz
In reply to this post by Jun Koi
On Thu, Feb 09, 2012, Jun Koi wrote:
>
> sorry if this is a bit off-topic, but i think many people here must
> have the same concern, and have to cope with it somehow.
>
> my concern is that: even if the binary is without the source, the
> code is still Python bytecode. and as far as i am aware, it is pretty
> trivial to reverse the binary back to the Python code. (i am not very
> sure which tools can be used to reverse Python-based .exe files,
> though)

Most people have learned to not have this concern.

> 1) how serious this problem is in your opinion? is it really true that
> it is impossible to protect the binaries from reversing?

Not serious enough to warrant your time and money.  Absolutely true.

The only way to protect your code is to put it on a server.  But then
people can only use your software when connected to the Internet.
--
Aahz ([hidden email])           <*>         http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over."
--Remco Gerlich
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

StoneBeat
In reply to this post by Jun Koi
Check this


:)

On Thu, Feb 9, 2012 at 7:51 AM, Jun Koi <[hidden email]> wrote:
hi,

sorry if this is a bit off-topic, but i think many people here must
have the same concern, and have to cope with it somehow.

i am developing a Windows project using Python. the final executable
file .EXE and its libs will be generated with py2exe.

my concern is that: even if the binary is without the source, the code
is still Python bytecode.
and as far as i am aware, it is pretty trivial to reverse the binary
back to the Python code. (i am not very sure which tools can be used
to reverse Python-based .exe files, though)

i have few questions:

1) how serious this problem is in your opinion? is it really true that
it is impossible to protect the binaries from reversing?

2) how efficient are the reversing tools on Python binaries now? would
be great if somebody can share some experiences on using those tools.

3) if it is true that it is quite trivial to reverse the Python
binaries, how are you currently protecting your binaries? perhaps with
some obfuscated tools, making it much harder to reverse?

please share your ideas. thanks so much,
Jun
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32


_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Tim Roberts
In reply to this post by Jun Koi
Jun Koi wrote:

> sorry if this is a bit off-topic, but i think many people here must
> have the same concern, and have to cope with it somehow.
>
> i am developing a Windows project using Python. the final executable
> file .EXE and its libs will be generated with py2exe.
>
> my concern is that: even if the binary is without the source, the code
> is still Python bytecode.
> and as far as i am aware, it is pretty trivial to reverse the binary
> back to the Python code.

It won't necessarily be READABLE Python code.  It won't have local
variable names, and it won't have comments, but it's usually pretty
understandable.

> 1) how serious this problem is in your opinion? is it really true that
> it is impossible to protect the binaries from reversing?

Yes.  If this is an issue for you, then you should not be using an
interpreted language at all.  You need to use something that is
compiled, like C++.  Even compiled code can be reverse-engineered, but
it's much harder.

Note that this same issue exists with C#.  The binaries for a C# program
are in an Intermediate Language that is very similar to Python byte
codes, and which can be decompiled back to barely readable C# code.

What are you protecting here?  In many cases, Python code is a front-end
for a core library where the real IP lives.  There's no point in
protecting a user interface, for example.
 
> 3) if it is true that it is quite trivial to reverse the Python
> binaries, how are you currently protecting your binaries? perhaps with
> some obfuscated tools, making it much harder to reverse?

Remember that Python comes from the open source world, where obfuscation
is eschewed.  Most Python projects ship the source code.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.

_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Niki Spahiev-2
On  9.02.2012 20:41, Tim Roberts wrote:
> Jun Koi wrote:
>> 1) how serious this problem is in your opinion? is it really true that
>> it is impossible to protect the binaries from reversing?
>
> Yes.  If this is an issue for you, then you should not be using an
> interpreted language at all.  You need to use something that is
> compiled, like C++.  Even compiled code can be reverse-engineered, but
> it's much harder.

IMHO not true. Professional decompilers for C++ are much better than
python decompilers. Example: hex-rays

Niki
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Harald Armin Massa[legacy]
...decompiling "protection"..
 
the correct answer is of course "put the code on a server"

BUT

there is code that cannot reside on a server. Especially client code in a client-server-environment. Example: the dropbox client. OnlineGameClients. 

As much as I learned Dropbox took a quite effective approach: reshuffle the Python bytecodes, compile your own Python.

Rises the costs of reengeneering quite a bit. 

Harald


--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
Using PostgreSQL is mostly about sleeping well at night.

_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Aahz
On Fri, Feb 10, 2012, Harald Armin Massa[legacy] wrote:
>
> As much as I learned Dropbox took a quite effective approach: reshuffle the
> Python bytecodes, compile your own Python.
>
> Rises the costs of reengeneering quite a bit.

Not enough to make a difference (speaking as someone who works for a
Dropbox competitor -- one of my coworkers spent some time poking through
the Dropbox code).  Also, Dropbox's goal is a bit different because you
can't run the client without Dropbox's server.

At my company, we don't even care enough to put a minimal bit of
protection in -- you need our servers, and our code isn't particularly
clever.
--
Aahz ([hidden email])           <*>         http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over."
--Remco Gerlich
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Kris Hardy
In reply to this post by Jun Koi
A few notes regarding intellectual property protection...

If I remember correctly, Microsoft's first Commerce Server was written
in Python by a company that they acquired, and Microsoft actually
shipped it as .pyc files.  (I may be wrong, but that's what I remember
hearing).

Whether or not to protect your code (and how to do it) depends on what
you are building.  If it has a large audience, especially a consumer
audience, and is high-value, it's an issue.  In that case, my suggestion
is to look at Cython.  Move the "special sauce" code into Cython
modules, and compile them down to .so/.dll files.

I know of a few companies that do this, one of which has a full desktop
app using Qt/PySide, and they're really happy with using a blend of
Python and Cython.

If your code has a limited customer base, especially if they are not
especially technical, you might be good enough just giving them the .py
files and enforcing your rights legally.  At a company I used to work
for, a large portion of our released application was in source files,
but the market was small and the users were non-technical, so there
really wasn't any reason to protect it other than enforce our license
agreement.

-Kris
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Dietmar Schwertberger-2
In reply to this post by Niki Spahiev-2
Am 10.02.2012 09:03, schrieb niki:
> On 9.02.2012 20:41, Tim Roberts wrote:
>> Yes. If this is an issue for you, then you should not be using an
>> interpreted language at all. You need to use something that is
>> compiled, like C++. Even compiled code can be reverse-engineered, but
>> it's much harder.
>
> IMHO not true. Professional decompilers for C++ are much better than
> python decompilers. Example: hex-rays

Might be.
But I would think that the most C[++] sources are still harder to
understand than Python bytecode...

To the OP:
Cross-posting is not nice. Posting to two lists without any indication
is even worse.


Regards,

Dietmar


_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Lincoln Yeoh
In reply to this post by Jun Koi
You can't protect any binary from being reversed either. The CPU has
to execute it. The antivirus and antimalware people reverse stuff all
the time[1].

There are only a few good reasons to obfuscate the python code:
1) Embarassing/bad/evil code/comments.
2) you're in the US or similar and want to also add DRM so you
qualify for DMCA protection (I personally am against the DMCA laws).

But what is your end objective? If it's to make money, most paying
customers aren't going to look. Competitors could learn stuff, but
they can't copy stuff exactly or they'd break copyright laws. They
could copy ideas, but cool ideas are a dime a dozen, the difficult
parts are elsewhere. Marketing, execution, polish. Even artwork and
design can be more important, customers are more likely to buy a
product that looks beautiful on the outside with ugly code inside,
than one with ugly artwork but beautiful code.

Apple weren't the first company to come up with a touchscreen phone
or tablet. McDonalds weren't the first company to sell burgers, nor
do they sell the best burgers, even in the "fast food burger" category.
Starbucks is one of the pioneers in overpriced coffee. I don't think
being first or not has anything to do with their success.

Regards,
Link.

[1] Easier nowadays with virtual machine technology. The difficulty
for them would be if a trojan contained innocuous code, but fetched
commands from a server that are OK but could one day be evil. That
said I wonder how well they'd do against polymorphic perl viruses ;).


At 02:51 PM 2/9/2012, Jun Koi wrote:

>1) how serious this problem is in your opinion? is it really true that
>it is impossible to protect the binaries from reversing?
>
>2) how efficient are the reversing tools on Python binaries now? would
>be great if somebody can share some experiences on using those tools.
>
>3) if it is true that it is quite trivial to reverse the Python
>binaries, how are you currently protecting your binaries? perhaps with
>some obfuscated tools, making it much harder to reverse?
>
>please share your ideas. thanks so much,
>Jun
>_______________________________________________
>python-win32 mailing list
>[hidden email]
>http://mail.python.org/mailman/listinfo/python-win32


_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Anti-reverse Python-based binaries?

Sturla Molden-2
In reply to this post by Jun Koi
On 09.02.2012 07:51, Jun Koi wrote:

> 1) how serious this problem is in your opinion? is it really true that
> it is impossible to protect the binaries from reversing?

You are probably aware that binary machine code from a C compiler can be
decompiled as well (e.g. to x86 assemby).

Decompiling Java bytecode or .NET bytecode is trivial. The .NET
framework even provides a decompiler.

Python bytecode are not any worse.

So if your bytecode is not safe enough, then I am not sure anything will
be. You might try to control the hardware, e.g. keep your dark secrets
hidden behind a web service and only provide a front-end for the
clients. That is what Google mostly does.

> 3) if it is true that it is quite trivial to reverse the Python
> binaries, how are you currently protecting your binaries?

Are you afraid someone will accidentally see your code? Is it that bad?

The main problem is managers confusing "obscurity" with "copy
protection". If you need to protect an invention, file a patent claim.
If you need protection against software piracy, remember that a program
can be copied without reverse-engineering.

But anyway, sure you can go for code obfuscation. I would have used
Cython with --embed instead of py2exe. Now you can provide your custom
module loader, and e.g keep the bytecode as encrypted text strings.
Since you can also build a custom Python interpreter from source, it is
also possible to make sure bytecode and attribute names are scrambled.
So you end up with an EXE and some DLLs that have strings of encrypted
bytecode only your custom built interpreter can make sence of. And I
would also link the custom Python interpreter statically, to make sure
it is not easily accessible for testing. It would still run with the
same speed as normal Python.

Sturla
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32