Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #70078 > unrolled thread

python obfuscate

Back to article view | Back to comp.lang.python

Contents

  python obfuscate Wesley <nispray@gmail.com> - 2014-04-10 18:29 -0700
    Re: python obfuscate Tobiah <toby@tobiah.org> - 2014-04-10 18:48 -0700
      Re: python obfuscate Wesley <nispray@gmail.com> - 2014-04-10 19:14 -0700
      Re: python obfuscate Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-10 20:23 -0600
    Re: python obfuscate Ben Finney <ben+python@benfinney.id.au> - 2014-04-11 11:41 +1000
      Re: python obfuscate Wesley <nispray@gmail.com> - 2014-04-10 19:17 -0700
        Re: python obfuscate Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-10 20:28 -0600
          Re: python obfuscate Grant Edwards <invalid@invalid.invalid> - 2014-04-11 16:19 +0000
        Re: python obfuscate Ben Finney <ben+python@benfinney.id.au> - 2014-04-11 13:12 +1000
        Re: python obfuscate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-11 06:53 +0100
        Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 09:17 +0000
        Re: python obfuscate Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-11 04:22 -0600
          Re: python obfuscate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-11 11:44 +0000
        Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 12:42 +0000
    Re: python obfuscate Joshua Landau <joshua@landau.ws> - 2014-04-11 07:00 +0100
    Re: python obfuscate Chris Angelico <rosuav@gmail.com> - 2014-04-11 16:10 +1000
    Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 09:17 +0000
    Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 09:17 +0000
    Re: python obfuscate Chris Angelico <rosuav@gmail.com> - 2014-04-11 19:40 +1000
      Re: python obfuscate cl@isbd.net - 2014-04-11 13:32 +0100
        Re: python obfuscate Chris Angelico <rosuav@gmail.com> - 2014-04-11 22:47 +1000
        Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 13:06 +0000
        Re: python obfuscate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-11 14:10 +0100
      Re: python obfuscate Grant Edwards <invalid@invalid.invalid> - 2014-04-11 16:22 +0000
    Re: python obfuscate alister <alister.nospam.ware@ntlworld.com> - 2014-04-11 13:07 +0000
      Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 14:00 +0000
        Re: python obfuscate Grant Edwards <invalid@invalid.invalid> - 2014-04-11 16:27 +0000
          Re: python obfuscate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-12 00:49 +0000
            Re: python obfuscate Ben Finney <ben+python@benfinney.id.au> - 2014-04-12 14:52 +1000
    Re: python obfuscate Mark H Harris <harrismh777@gmail.com> - 2014-04-11 10:09 -0500
      Re: python obfuscate Chris Angelico <rosuav@gmail.com> - 2014-04-12 01:22 +1000
      Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 16:13 +0000
      Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-11 16:13 +0000
        Re: python obfuscate CM <cmpython@gmail.com> - 2014-04-11 22:01 -0700
          Re: python obfuscate Sturla Molden <sturla.molden@gmail.com> - 2014-04-12 12:07 +0000
            Re: python obfuscate CM <cmpython@gmail.com> - 2014-04-12 20:14 -0700
    Re: python obfuscate Michael Torrie <torriem@gmail.com> - 2014-04-11 09:19 -0600
    Re: python obfuscate Chris Angelico <rosuav@gmail.com> - 2014-04-12 01:30 +1000
    Re: python obfuscate Joshua Landau <joshua@landau.ws> - 2014-04-11 22:48 +0100
    Re: python obfuscate Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-12 07:48 +0000
    Re: python obfuscate Stefan Behnel <stefan_ml@behnel.de> - 2014-04-13 06:58 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#70133

On Fri, Apr 11, 2014 at 10:32 PM,  <cl@isbd.net> wrote:
> Chris Angelico <rosuav@gmail.com> wrote:
>> On Fri, Apr 11, 2014 at 7:17 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
>> > The only way to protect your code is never to ship anything.
>>
>> It's worth noting, as an aside, that this does NOT mean you don't
>> produce or sell anything. You can keep your code secure by running it
>> on a server and permitting users to access it; that's perfectly safe.
>>
> Perfectly?  :-)

Heh. Well, as perfectly as anything ever is. All they can do is try to
find exploits (hi, Heartbleed!) and get at some of the code. It's not
like "hey look, here it is, I can just run it".

ChrisA

[toc] | [prev] | [next] | [standalone]

#70136

<cl@isbd.net> wrote:

>> It's worth noting, as an aside, that this does NOT mean you don't
>> produce or sell anything. You can keep your code secure by running it
>> on a server and permitting users to access it; that's perfectly safe.
>> 
> Perfectly?  :-)

Unless you have a heartbleed :)

Sturla

[toc] | [prev] | [next] | [standalone]

#70138

On 11/04/2014 14:06, Sturla Molden wrote:
> <cl@isbd.net> wrote:
>
>>> It's worth noting, as an aside, that this does NOT mean you don't
>>> produce or sell anything. You can keep your code secure by running it
>>> on a server and permitting users to access it; that's perfectly safe.
>>>
>> Perfectly?  :-)
>
> Unless you have a heartbleed :)
>
> Sturla
>

I was thinking more along the lines of Greek tragedies. :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#70160

On 2014-04-11, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Apr 11, 2014 at 7:17 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
>> The only way to protect your code is never to ship anything.
>
> It's worth noting, as an aside, that this does NOT mean you don't
> produce or sell anything. You can keep your code secure by running it
> on a server and permitting users to access it; that's perfectly safe.

You think a server that can be accessed by untrested people can be
perfectly safe?

Oh dear.

-- 
Grant Edwards               grant.b.edwards        Yow! If our behavior is
                                  at               strict, we do not need fun!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#70137

On Thu, 10 Apr 2014 18:29:21 -0700, Wesley wrote:

> Hi all,
>   Does python has any good obfuscate?
> 
> Currently our company wanna release one product developed by python to
> our customer. But dont's wanna others see the py code.
> 
> I googled for a while but mostly just say using pyc. Any better one?
> 
> Our product is deployed on Linux bed.
> 
> Thanks.
> Wesley

As already highlighted obfuscation is probably pointless, what do you 
expect it to achieve anyway? i can see a number of reasons all of which 
can be proved futile.

1) you want to stop the customer copying the program to other computers:-
obsfucation wont help here they already have the executable file & can 
just run it anyway Many copy protection schemes have been tried in the 
past none have been sucsesull

2) you don't want the customer to be able to modify your code & pass it 
of as their own:-

This is what Copyright is for. Also if they are that poor a programming 
shop that they are desperate to steel for your code they probably wont be 
in business long anyway.

3) to stop them modifying the code to suit their own requirements:-

What on earth is the problem here, that just makes the software more 
valuable to them. As long as they are paying for your software (assuming 
it is not freeware) then everyone wins. if they are not paying then it is 
another example of Copyright breach.

4) your software is a driver for some exotic piece of hardware & reading 
the code will help produce a competing product:-

A reasonable justification but in that case it is probably still worth 
the time & effort of fully decompiling the code & reverse engineering the 
hardware and the best you will do will be to slow them down


it is my opinion that attempting to obfuscate the code is akin to 
Microsoft's improvements to the BSOD in windows 8 (Adding a frowning 
emotion) the effort would have been better spent ensuring it wasn't 
displayed in the first place. 
Concentrate on making the product (even) better rather than trying to 
hide the unhideable.

-- 
It's easy to get on the internet and forget you have a life
	-- Topic on #LinuxGER

[toc] | [prev] | [next] | [standalone]

#70140

alister <alister.nospam.ware@ntlworld.com> wrote:

> Concentrate on making the product (even) better rather than trying to 
> hide the unhideable.

I think the number one reason for code obfuscation is an ignorant boss. 

Another reason might be to avoid the shame of showing crappy code to the
customer.


Sturla

[toc] | [prev] | [next] | [standalone]

#70161

On 2014-04-11, Sturla Molden <sturla.molden@gmail.com> wrote:
> alister <alister.nospam.ware@ntlworld.com> wrote:
>
>> Concentrate on making the product (even) better rather than trying to
>> hide the unhideable.
>
> I think the number one reason for code obfuscation is an ignorant
> boss. 
>
> Another reason might be to avoid the shame of showing crappy code to
> the customer.

Another reason I've heard of is to try to reduce support efforts.

If you distribute something that's easy to modify, then people will.

And when it doesn't work, they'll call tech support and waste
everybody's time trying to track down bugs that aren't actually _in_
the product you're shipping.

-- 
Grant Edwards               grant.b.edwards        Yow! In Newark the
                                  at               laundromats are open 24
                              gmail.com            hours a day!

[toc] | [prev] | [next] | [standalone]

#70171

On Fri, 11 Apr 2014 16:27:27 +0000, Grant Edwards wrote:

> Another reason I've heard of is to try to reduce support efforts.
> 
> If you distribute something that's easy to modify, then people will.

The majority of people will treat your app as a black box. Of course, a 
small minority (either out of actual competence, or sheer incompetence) 
will try to modify anything supplied as source code. (And who is to say 
that they shouldn't be permitted to, if they've bought your product?)

> And when it doesn't work, they'll call tech support and waste
> everybody's time trying to track down bugs that aren't actually _in_ the
> product you're shipping.

I wonder whether Red Hat and Ubuntu have this problem? Somehow I think 
that the magnitude of it is grossly exaggerated.

But in any case, this at least is trivially solved: take the md5 of your 
application, then before doing any support check whether the md5 of their 
copy has changed. A tiny Python script (small enough to visually inspect) 
can do this on systems without a md5sum utility.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#70176

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> On Fri, 11 Apr 2014 16:27:27 +0000, Grant Edwards wrote:
>
> > Another reason I've heard of is to try to reduce support efforts.
> > 
> > If you distribute something that's easy to modify, then people will.
>
> The majority of people will treat your app as a black box. Of course, a 
> small minority (either out of actual competence, or sheer incompetence) 
> will try to modify anything supplied as source code.

Further, those who are motivated to modify the product they receive from
you will often have motivations that remain even in the absence of
source code.

In many cases that motivation is strong enough they will *still* modify
the product in an attempt to get it to do what they want. So in those
cases, even the total absence of source code is not achieving the
putative goal of “stop the recipient from modifying the product”.

> (And who is to say that they shouldn't be permitted to, if they've
> bought your product?)

Indeed. People in the position of selling something to a customer need
to stop trying to have it both ways: Either the vendor owns the product,
or the customer does.

Either the customer is paying to own the product, and thereby has full
rights to use that product and modify it and sell it on to other people
without the vendor having any further say in the matter; or: The
vendor continues to own the product even while the customer possesses
it, and is responsible for controlling how it's used and is culpable for
any harmful effects of that use.

A third way is possible, but fans of obfuscation probably won't like it:
Software is inherently not amenable to the limits of scarce physical
property at all, and attempts to treat it as scarce and exclusive and
“owned” by one party are futile and counter to physical laws.

This is the position taken by Thomas Jefferson in 1813: “If nature has
made any one thing less susceptible than all others of exclusive
property, it is the action of the thinking power called an idea.”

<URL:http://questioncopyright.org/>

-- 
 \      “By instructing students how to learn, unlearn, and relearn, a |
  `\         powerful new dimension can be added to education.” —Alvin |
_o__)                                    Toffler, _Future Shock_, 1970 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#70143

On 4/10/14 8:29 PM, Wesley wrote:

>    Does python has any good obfuscate?

    Others have answered this well, but I thought I would give you 
another opinion, perhaps more direct.

    Obfuscation (hiding) of your source is *bad*,  usually done for one 
of the following reasons:
    1) Boss is paranoid and fears loss of revenues due to intellectual 
property theft.
    2) Boss is ignorant of reverse engineering strategies available to 
folks who want to get to the heart of the matter.
    3) Boss and|or coders are embarrassed for clients (or other coders) 
to see their art, or lack thereof. Sometimes this is also wanting to 
hide the fact that the product really isn't "worth" the price being 
charged for it?!?

    There really is no good reason to obfuscate your code.

> Currently our company wanna release one product developed by
 > python to our customer. But dont's wanna others see the py code.

    This is the age of open source in computer science.

    It is far better to develop a strategy and culture of openness. 
Everyone benefits; especially your customers. I recommend the GPLv3 
license. I also advocate for copyleft. How to leverage openness for 
capital gain, you might ask? Answer: provide a value add. Its not just 
about your code, or your "product". It should also be about your 
service, maintenance, support, packing, manuals, news letters, &c.

    Deliberately obfuscating your code is a negative; please consider an 
alternative strategy.

marcus

[toc] | [prev] | [next] | [standalone]

#70145

On Sat, Apr 12, 2014 at 1:09 AM, Mark H Harris <harrismh777@gmail.com> wrote:
>    This is the age of open source in computer science.
>
>    It is far better to develop a strategy and culture of openness. Everyone
> benefits; especially your customers. I recommend the GPLv3 license.

While I wholeheartedly agree with the ideal of open source, I don't
like the GPL (any version), because of the annoying restrictions that
end up running through projects. All sorts of projects can't go GPL,
ergo can't use readline. Why? Because readline went for a policy of
"force it to be GPL or nothing". Thank you so much, now I have to faff
around with PostgreSQL to get decent editing keys (and the legality of
that is apparently dubious, but IANAL and it's not my problem anyway).
Postgres is open source, but not GPL, and it's linked to some other
library (I disremember which) that's under a license incompatible with
the GPL.

For my code, I use the MIT license. Do what you like, only don't sue
me. Okay, that's not something everyone will want to use, but it does
make things easier on anyone who wants to distribute it. You want to
release a third-party build of my program? Or even just package up my
code into an installer? No problem; you aren't responsible to host the
code. With GPL software, you *are*, as I found out when I tried to
make a simple GTK updater; I'm legally required to make it clear that
the source code is available from the same web site as the binaries
are (even though I didn't build it, all I did was download the
binaries from their site and download the corresponding source
archives), and I'm also obliged from the perspective of practicality
to make it clear that the source code is not necessary, lest my users
be thoroughly confused. Completely unnecessary hassle; it's red tape
applied to those who're keeping everything open, in order to have a
weapon to wield against those who close things up.

I'm aware that the GPL has its place. I'm fully aware that GPL
violations, being pursued legally, help to ensure openness; and the
borderline cases of "we could go proprietary or we could go open
source" are sometimes tipped in favour of open source by an argument
of "we could use this if we go open"; but for most people, please,
pick a simpler license that puts less restrictions on usage.

ChrisA

[toc] | [prev] | [next] | [standalone]

#70155

Mark H Harris <harrismh777@gmail.com> wrote:

>     This is the age of open source in computer science.
> 
>     It is far better to develop a strategy and culture of openness. 
> Everyone benefits; especially your customers. I recommend the GPLv3 
> license. I also advocate for copyleft. 

I would not use GPL in a commercial product, but "Open Source" might still
be beneficial. E.g. one can get better feedback and even bug fixes or code
improvements from customers and other interested parties. It is a win-win
situation. If I ran a software business (I don't currently do), I would
gladly discount customers or pay anyone who help to improve my software.
Open Source does not mean that software has to be free, that copyright is
lost, or that copyleft is implied.

Sturla

[toc] | [prev] | [next] | [standalone]

#70156

Mark H Harris <harrismh777@gmail.com> wrote:

>     Obfuscation (hiding) of your source is *bad*,  usually done for one 
> of the following reasons:
>     1) Boss is paranoid and fears loss of revenues due to intellectual 
> property theft.
>     2) Boss is ignorant of reverse engineering strategies available to 
> folks who want to get to the heart of the matter.
>     3) Boss and|or coders are embarrassed for clients (or other coders) 
> to see their art, or lack thereof. Sometimes this is also wanting to 
> hide the fact that the product really isn't "worth" the price being 
> charged for it?!?

You can also add fear of patent trolls to this list. Particularly if you
are in a startup and cannot afford a long battle in court. You can quickly
go bankrupt on attorney fees.

Sturla

[toc] | [prev] | [next] | [standalone]

#70177

On Friday, April 11, 2014 12:13:47 PM UTC-4, Sturla Molden wrote:
> Mark H Harris <harrismh777@gmail.com> wrote:
> 
> >     Obfuscation (hiding) of your source is *bad*,  usually done for one 
> > of the following reasons:
> 
> >     1) Boss is paranoid and fears loss of revenues due to intellectual 
> > property theft.
> >     2) Boss is ignorant of reverse engineering strategies available to 
> > folks who want to get to the heart of the matter.
> >     3) Boss and|or coders are embarrassed for clients (or other coders) 
> > to see their art, or lack thereof. Sometimes this is also wanting to 
> > hide the fact that the product really isn't "worth" the price being 
> > charged for it?!?
> 
> You can also add fear of patent trolls to this list. Particularly if you
> are in a startup and cannot afford a long battle in court. You can quickly
> go bankrupt on attorney fees.
> 
> Sturla

You're saying that fear of patent trolls is yet another bad reason to 
obfuscate your code?  But then it almost sounds like you think it is a 
justifiable reason. So I don't think I understand your point.  Whether a 
patent troll has your original code or not has no bearing on the patent
infringement.  

[toc] | [prev] | [next] | [standalone]

#70181

CM <cmpython@gmail.com> wrote:

> You're saying that fear of patent trolls is yet another bad reason to 
> obfuscate your code?  But then it almost sounds like you think it is a 
> justifiable reason. So I don't think I understand your point.  Whether a 
> patent troll has your original code or not has no bearing on the patent
> infringement.

There might be no infringment. Patent trolls usually possess invalid
patents, as they constitute no real invention. These are usually not
engineers who have invented something, but lawyers who have been granted
patent on vague thoughts for the purpose of "selling protection". The US
patent office has allowed this to happen, by believing that any invalid
patent can be challenged in court, so their review process is close to
non-existent. If patent trolls have your code they are in a better position
to blackmail. They can use your code to generate bogus "legal documents" in
the thousands, and thereby turn up your legal expenses. 

Sturla

[toc] | [prev] | [next] | [standalone]

#70185

On Saturday, April 12, 2014 8:07:57 AM UTC-4, Sturla Molden wrote:
> CM <cmpython@gmail.com> wrote:
> 
> 
> 
> > You're saying that fear of patent trolls is yet another bad reason to 
> 
> > obfuscate your code?  But then it almost sounds like you think it is a 
> 
> > justifiable reason. So I don't think I understand your point.  Whether a 
> 
> > patent troll has your original code or not has no bearing on the patent
> 
> > infringement.
> 
> 
> 
> There might be no infringment. Patent trolls usually possess invalid
> patents, as they constitute no real invention. These are usually not
> engineers who have invented something, but lawyers who have been granted
> patent on vague thoughts for the purpose of "selling protection". The US
> patent office has allowed this to happen, by believing that any invalid
> patent can be challenged in court, so their review process is close to
> non-existent. If patent trolls have your code they are in a better position
> to blackmail. They can use your code to generate bogus "legal documents" in
> the thousands, and thereby turn up your legal expenses. 
> 
> Sturla

Ahh, I see.  I suppose such an entity might try that.  But I would hope it would not result in additional legal expenses, in that anyone with the smallest amount of legal understanding of patents knows that in doesn't matter in what way the invention is brought about in specific code, just that the *resulting invention* is similar enough to the claims of the patent.  That is, the invention could be written in Python, or C, or COMAL, in whatever spaghetti the author wants, and none of that is pertinent to the issue of patent infringement (whereas it might very well be to the issue of copyright infringement).  I would hope the defense lawyer(s) and judge struck that from the proceedings, but I am probably hoping for too rational an outcome.

[toc] | [prev] | [next] | [standalone]

#70144

On 04/10/2014 07:29 PM, Wesley wrote:
> Hi all, Does python has any good obfuscate?
> 
> Currently our company wanna release one product developed by python
> to our customer. But dont's wanna others see the py code.
> 
> I googled for a while but mostly just say using pyc. Any better one?
> 
> Our product is deployed on Linux bed.

I guess it all depends on what you are really trying to do.

If you're trying to prevent people from making and using unauthorized
copies of your software then even obfuscating the code certainly won't
help that at all.

If you're trying to prevent people from learning trade secrets, then
simply don't put that part of your product in the hands of customers.
And on this point the language doesn't matter.  Could be a binary
compiled from C++.  Someone could, in theory, reverse-engineer and trace
the code and uncover your secret algorithm.  The question is, is it
worth it for the mythical, theoretical, bad guy to do this?  Is it worth
it for you to go to lengths to prevent this theoretical possibility?

If you have IP you truly need to keep secret, separate it out from your
application and stick it on a server and talk to it over some form of RPC.

If you're simply trying to keep the boss happy, simply wrapping up your
python scripts into a self-contained executable format (say py2exe or a
similar tool) is probably good enough.

Most end users will never know or care what you build the app with, even
if you have a directory full of open .py files.  99% of the users of a
popular ebook app called Calibre never know or care that it's made of
python and that you could go in and see the code.  All they care about
is they can click an icon and the program launches and runs.

[toc] | [prev] | [next] | [standalone]

#70146

On Sat, Apr 12, 2014 at 1:19 AM, Michael Torrie <torriem@gmail.com> wrote:
> Most end users will never know or care what you build the app with, even
> if you have a directory full of open .py files.  99% of the users of a
> popular ebook app called Calibre never know or care that it's made of
> python and that you could go in and see the code.  All they care about
> is they can click an icon and the program launches and runs.

Absolutely. When you run "hg something_or_other", you would expect
that it's all written in Python, but some of it might not be, for all
you know. Certainly with git there are several languages used (some
are compiled binaries, some are shell scripts, some are Perl, gitk is
TCL...), and it doesn't matter at all. Who cares? I type a command and
it runs. If upstream decides to rewrite bash in Lua, I won't much
care, and probably wouldn't even know (although somehow I suspect
performance would drop... slightly...).

Adding to your list, though:

If you're trying to hide your source code for security, absolutely DO
NOT! This is one of the most common reasons I've heard of; either
because the "cryptographic" algorithms are hand-rolled and easy to
reverse-engineer if you have the source, or because the keys are
hard-coded in the program. Either way, you can't. It just won't work.
People can get at your crypto, and if it's broken as soon as someone
sees the source code, it's weak crypto to start with.

ChrisA

[toc] | [prev] | [next] | [standalone]

#70169

On 11 April 2014 10:17, Sturla Molden <sturla.molden@gmail.com> wrote:
> Joshua Landau <joshua@landau.ws> wrote:
>
>> However, if this really is your major blocker to using Python, I
>> suggest compiling with Cython.
>
> Cython restains all the code as text, e.g. to readable generate exceptions.
> Users can also still steal the extension modules and use them in their own
> code. In general, Cython is not useful as an obfuscation tool.

Ah, thanks for the info. I imagine it's perfectly easy to get around
that, though, through basic removal at the C phase. I doubt it's
worthwhile doing so, but deobfuscation will still be harder than a
.pyc.

[toc] | [prev] | [next] | [standalone]

#70179

On Thu, 10 Apr 2014 18:29:21 -0700, Wesley wrote:

> Currently our company wanna release one product developed by python to
> our customer. But dont's wanna others see the py code.

Your business model is fucked.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web