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

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

Is there a way to create a shared object file using PyInstaller?

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

Contents

  Is there a way to create a shared object file using PyInstaller? Swanand Pashankar <swanand.pashankar@gmail.com> - 2016-03-14 22:35 -0700
    Obfuscating Python code (was: Is there a way to create a shared object file using PyInstaller?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-15 16:45 +1100
      Re: Obfuscating Python code Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-15 19:59 +0100
        Re: Obfuscating Python code Chris Angelico <rosuav@gmail.com> - 2016-03-16 07:31 +1100
          Re: Obfuscating Python code Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-15 22:51 +0100
            Re: Obfuscating Python code Daniel Wilcox <dmw@yubasolutions.com> - 2016-03-15 23:40 -0700
        Re: Obfuscating Python code Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-16 18:04 +1100
          Re: Obfuscating Python code Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-16 07:55 -0400

#104918 — Is there a way to create a shared object file using PyInstaller?

Is there a way we can use PyInstaller to create .so file? I don't wish to fork (from my C code) just to call a function in a Python file. Embedding a Python file in C code works, but it exposes your Python script. Didn't find any free fool-proof way to obfuscate Python code either.

[toc] | [next] | [standalone]

#104919 — Obfuscating Python code (was: Is there a way to create a shared object file using PyInstaller?)

Swanand Pashankar <swanand.pashankar@gmail.com> writes:

> Embedding a Python file in C code works, but it exposes your Python
> script. Didn't find any free fool-proof way to obfuscate Python code
> either.

What exactly is it you want to prevent? Why do you think obfuscating the
code will achieve that?

-- 
 \       “The internet's completely over.… Anyway, all these computers |
  `\    and digital gadgets are no good. They just fill your head with |
_o__)     numbers and that can't be good for you.” —Prince, 2010-07-05 |
Ben Finney

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

#104952 — Re: Obfuscating Python code

Ben Finney wrote:

> Swanand Pashankar <swanand.pashankar@gmail.com> writes:
>> Embedding a Python file in C code works, but it exposes your Python
>> script. Didn't find any free fool-proof way to obfuscate Python code
>> either.
> 
> What exactly is it you want to prevent? Why do you think obfuscating the
> code will achieve that?

On a more constructive note, python(1) (CPython) creates a binary (byte-
code) “.pyc” file from “.py” files when it runs them.  ISTM that you can 
then run the “.pyc” file as if it were the “.py” file (if the “.pyc” file is 
given the executable flag, you can even execute it as a standalone command, 
but that might only work on my system).  So apparently you do not have to 
distribute the source code of a program written in Python if you do not want 
to.

If you want to distribute the “.pyc” file (perhaps under another name), then 
the “-O” and “-OO” optimization switches for python(1) could come in handy 
(see “python --help”).  [It is then perhaps not a coincidence that “-O” is 
documented to change the filename suffix from “.pyc” to “.pyo”; cf. “.so”]

(The Python manual should have more on this, I have not checked.)

That said, not distributing the source code of a program as well (or at 
least making it available to users in some way) strikes me as unpythonic 
since Python is at least Open Source software, and Python 2.0.1, 2.1.1 and 
newer are GPL-compatible Free Software.

<https://docs.python.org/3.5/license.html>
<http://www.gnu.org/licenses/license-list.html#Python>

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#104955 — Re: Obfuscating Python code

On Wed, Mar 16, 2016 at 5:59 AM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> That said, not distributing the source code of a program as well (or at
> least making it available to users in some way) strikes me as unpythonic
> since Python is at least Open Source software, and Python 2.0.1, 2.1.1 and
> newer are GPL-compatible Free Software.

gcc is also free software. Does that mean that all C programs should
be free software? No.

However, since all software can be reverse-compiled (particularly
byte-code like .pyc files), the only truly reliable way to make
completely closed software is to restrict access to it in all forms.
In today's world, that usually means providing it as a web service.
Otherwise, you have to assume that anyone can see your source. The
only difference between open-source and closed-source is the license,
not the ability to see stuff.

ChrisA

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

#104959 — Re: Obfuscating Python code

Chris Angelico wrote:

> On Wed, Mar 16, 2016 at 5:59 AM, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>> That said, not distributing the source code of a program as well (or at
>> least making it available to users in some way) strikes me as unpythonic
>> since Python is at least Open Source software, and Python 2.0.1, 2.1.1
>> and newer are GPL-compatible Free Software.
> 
> gcc is also free software. Does that mean that all C programs should
> be free software? No.

IMNSHO, yes.  At the very least because in using gcc you benefited from the 
free software community, so you should give back to the free software 
community accordingly.

> However, since all software can be reverse-compiled (particularly

You mean _decompiled_.

> byte-code like .pyc files),

Yes, it is easier with bytecode *if you know the VM*.

> the only truly reliable way to make completely closed software is to 
> restrict access to it in all forms.

ACK.

> In today's world, that usually means providing it as a web service.

ACK.  That’s why RMS calls it SaaSS, Service as a Software Substitute :)

> Otherwise, you have to assume that anyone can see your source. The
> only difference between open-source and closed-source is the license,
> not the ability to see stuff.

If that were the case and reverse engineering were an easy task that 
everyone could do, we would have a lot more free software variants of 
proprietary software.  Particularly, we would have a lot less proprietary 
device drivers.  ISTM that you do not know what you are talking about here.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#105009 — Re: Obfuscating Python code

If you really want to learn about obfuscating python bytecode so it can't
be reverse engineered (easily) -- there are people who are doing it.
Search for 'pyasm' on github as a starting point.  tldr; yes people are
patching .pyc files. yes you can make them a nightmare to disassemble. and
yes it slows down your code.

=D

also yes, you can be tricked into running a patched .pyc file that has
nothing to do with your .py file, you have been warned.  be careful out
there.

On Tue, Mar 15, 2016 at 2:51 PM, Thomas 'PointedEars' Lahn <
PointedEars@web.de> wrote:

> Chris Angelico wrote:
>
> > On Wed, Mar 16, 2016 at 5:59 AM, Thomas 'PointedEars' Lahn
> > <PointedEars@web.de> wrote:
> >> That said, not distributing the source code of a program as well (or at
> >> least making it available to users in some way) strikes me as unpythonic
> >> since Python is at least Open Source software, and Python 2.0.1, 2.1.1
> >> and newer are GPL-compatible Free Software.
> >
> > gcc is also free software. Does that mean that all C programs should
> > be free software? No.
>
> IMNSHO, yes.  At the very least because in using gcc you benefited from the
> free software community, so you should give back to the free software
> community accordingly.
>
> > However, since all software can be reverse-compiled (particularly
>
> You mean _decompiled_.
>
> > byte-code like .pyc files),
>
> Yes, it is easier with bytecode *if you know the VM*.
>
> > the only truly reliable way to make completely closed software is to
> > restrict access to it in all forms.
>
> ACK.
>
> > In today's world, that usually means providing it as a web service.
>
> ACK.  That’s why RMS calls it SaaSS, Service as a Software Substitute :)
>
> > Otherwise, you have to assume that anyone can see your source. The
> > only difference between open-source and closed-source is the license,
> > not the ability to see stuff.
>
> If that were the case and reverse engineering were an easy task that
> everyone could do, we would have a lot more free software variants of
> proprietary software.  Particularly, we would have a lot less proprietary
> device drivers.  ISTM that you do not know what you are talking about here.
>
> --
> PointedEars
>
> Twitter: @PointedEars2
> Please do not cc me. / Bitte keine Kopien per E-Mail.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#104991 — Re: Obfuscating Python code

On Wednesday 16 March 2016 05:59, Thomas 'PointedEars' Lahn wrote:

> On a more constructive note, python(1) (CPython) creates a binary (byte-
> code) “.pyc” file from “.py” files when it runs them.  

To be precise, it creates a .pyc file when the file is imported, not run. 
Just running a Python script doesn't save the byte-code into a file.


> ISTM that you can
> then run the “.pyc” file as if it were the “.py” file 

Correct. You can compile the file, delete or move the source code, then run 
the .pyc file:

steve@runes:~$ cat test.py 
print("Hello World!")
steve@runes:~$ python2.7 -m compileall test.py 
Compiling test.py ...
steve@runes:~$ mv test.py test~
steve@runes:~$ python2.7 test.pyc 
Hello World!


However byte-code is version-specific: you can only run the .pyc file with 
the same version of the interpreter as the one you compiled it with:

steve@runes:~$ python2.6 test.pyc 
RuntimeError: Bad magic number in .pyc file


> (if the “.pyc” file
> is given the executable flag, you can even execute it as a standalone
> command, but that might only work on my system).

There may be ways to get it to work, but it doesn't work here:

steve@runes:~$ chmod a+x test.pyc 
steve@runes:~$ ./test.pyc 
: command not found 
./test.pyc: line 2: syntax error near unexpected token `('
./test.pyc: line 2: `$�Vc
@s	dGHd
S(s
                                         Hello 
World!N((((stest.py<module>
s'



> So apparently you do not have to
> distribute the source code of a program written in Python if you do not
> want to.

Correct. This is a deliberate feature, intentionally supported by the Python 
interpreter.




-- 
Steve

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

#105007 — Re: Obfuscating Python code

On Wed, 16 Mar 2016 18:04:10 +1100, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:


>> (if the “.pyc” file
>> is given the executable flag, you can even execute it as a standalone
>> command, but that might only work on my system).
>
>There may be ways to get it to work, but it doesn't work here:
>
>steve@runes:~$ chmod a+x test.pyc 
>steve@runes:~$ ./test.pyc 
>: command not found 

>./test.pyc: line 2: syntax error near unexpected token `('
>./test.pyc: line 2: `$?Vc
@s	dGHd
S(
s
>                                         Hello 
>World!N((((stest.py<module>
s'
>

	It likely works on Windows, which uses the file extension and PATHEXT
environment to determine "executability" (though I see I don't have .pyc on
mine). UNIX/Linux shells looking for a "shebang" line OTOH...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

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

csiph-web