Python richtig kompilieren -> kein Dekompilieren

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Gast

Tja wie geht das eigentlich (technisch)? Ich hab keine Ahnung...

Oftmals will man ja was programmieren, ohne gleich zu verraten, wie man das angestellt hat. Manchmal meine ich damit auch eine Freeware, deren Quellcode ich aber nicht offen legen möchte. Vielleicht hat ja jemand interesse an einer kommerziellen Weiterentwicklung und kauft es mir ab?

Man kann seinen Python-Code kompilieren. Im Regelfall macht das der Interpreter schon selbst, richtig? Es entsteht eine .pyc Datei, die den Bytecode der .py Datei enthält. Dabei ist aber noch nicht viel passiert außer einer Textumwandlung in Bytecode, die trotzdem noch interpretiert (also kann man 'live compiliert' sagen?) werden muss.

Der Suche konnte ich entnehmen, dass man .pyc Dateien bis Python 2.3 mittlerweile dekompilieren kann. Es scheint also nur eine Frage der Zeit zu sein, bis auch die jüngeren Versionen nachrücken werden. Es kursierte dazu ein Direktlink zum Decompiler, der leider tot war. Hat vielleicht jemand den heißen Draht und postet den aktuellen Link nochmal?

Für mich ist es interessant, mein Python-Programm für UNIXe und Windows auszuliefern. Am liebsten würde ich deshalb meine Module und den Interpreter gleich zusammen 'freezen' (zu einer binären ausführbaren Datei zusammenstellen). Python bietet dafür das Modul freeze, welches allerdings noch ein paar Schwachstellen hat (Reihenfolge, was alles mit einbezogen wird etc.). Windows-Benutzer dürfen sich freuen: Dank py2exe bekommt man am Ende eine .exe Datei heraus.

Welchen Schutz bietet py2exe hinsichtlich dekompilieren? Bekommt man den Python-Quellcode wieder aus der .exe heraus?

Für UNIXe gibt es wohl auch Freezer analog zu py2exe, allerdings sind die wohl noch nicht so ausgereift. Es wäre ja cool, ein und dasselbe Programm (z.B. py2bin) für alle Plattformen zu haben. Durch eine interne Unterscheidung des Betriebssystems kann py2bin ja selbst entscheiden, ob eine .exe oder einfach eine binäre UNIX Datei rauskommt. Aber man hätte für alle Plattformen dieselbe setup.py (so heißt das bei py2exe) und dieselben Einstellungen.

Jedenfalls kann man sich auf UNIX Freezer noch nicht so verlassen, richtig? Sollte man da besser das .pyc rausgeben (noch unknackbar) und den Interpreter einfach voraussetzen? Auf den meisten UNIX-Systemen ist der sowieso vorhanden... nur vielleicht einige Module noch nicht. Kann ich die ebenfalls als .pyc mitliefern (z.B. Module wie 'xmlrpc', 'sys' oder 'os')? Checkt das der Python-Interpreter oder muss man ein .pyc noch über Python kompilieren (compile-Befehl)?

Edit (Leonidas): Thread gesplittet, der Rest ist unter "Mit Freier Software Geld verdienen" zu finden.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

^^ Das war kein Gast, sondern 'droptix'.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Machs einfach nicht. Codeklau geht auch mit compilierten Quellcode wunderbar. Also lass es einfach.
Lizensiers einfach unter GPL und erfreu dich dran.
TUFKAB – the user formerly known as blackbird
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Anonymous hat geschrieben:Tja wie geht das eigentlich (technisch)? Ich hab keine Ahnung...
Die Opcodes der Pythonbefehle kannst du dir mithilfe des dis-Modules mal ansehen.. dekompilieren zu Python-Code geht auch in die Richtung.
Anonymous hat geschrieben:Oftmals will man ja was programmieren, ohne gleich zu verraten, wie man das angestellt hat. Manchmal meine ich damit auch eine Freeware, deren Quellcode ich aber nicht offen legen möchte. Vielleicht hat ja jemand interesse an einer kommerziellen Weiterentwicklung und kauft es mir ab?
Ich habe irgendwie so das Gefühl, dass das ziemliches Wunschdenken ist. Außer du Programmierst etwas sehr aufwendiges sehr gut, aber so Projekte gibt es selten. Vor allem in Python ist es einfach ein Projekt von Grund auf neu zu machen.
Anonymous hat geschrieben:Man kann seinen Python-Code kompilieren. Im Regelfall macht das der Interpreter schon selbst, richtig? Es entsteht eine .pyc Datei, die den Bytecode der .py Datei enthält. Dabei ist aber noch nicht viel passiert außer einer Textumwandlung in Bytecode, die trotzdem noch interpretiert (also kann man 'live compiliert' sagen?) werden muss.
Naja, eine Umwandlung von .py zu .pyc oder .pyo ist eigentlich laut Wikipedia auch schon eine Kompilation (Quellsprache Python, Zielsprache Python Bytecode).
Anonymous hat geschrieben:Der Suche konnte ich entnehmen, dass man .pyc Dateien bis Python 2.3 mittlerweile dekompilieren kann. Es scheint also nur eine Frage der Zeit zu sein, bis auch die jüngeren Versionen nachrücken werden. Es kursierte dazu ein Direktlink zum Decompiler, der leider tot war. Hat vielleicht jemand den heißen Draht und postet den aktuellen Link nochmal?
Hier: Debian-Package decompyle.
Anonymous hat geschrieben:Für mich ist es interessant, mein Python-Programm für UNIXe und Windows auszuliefern. Am liebsten würde ich deshalb meine Module und den Interpreter gleich zusammen 'freezen' (zu einer binären ausführbaren Datei zusammenstellen). Python bietet dafür das Modul freeze, welches allerdings noch ein paar Schwachstellen hat (Reihenfolge, was alles mit einbezogen wird etc.). Windows-Benutzer dürfen sich freuen: Dank py2exe bekommt man am Ende eine .exe Datei heraus.
Freeze ist echt uralt, ich glaube nicht dass irgendjemand das noch nutzt.
Anonymous hat geschrieben:Welchen Schutz bietet py2exe hinsichtlich dekompilieren? Bekommt man den Python-Quellcode wieder aus der .exe heraus?
Schon möglich, wenn auch vielleicht etwas schwerer als aus einer .pyc-Datei. Jedoch ist die library.zip dafür voller .pyc/.pyos.
Anonymous hat geschrieben:Für UNIXe gibt es wohl auch Freezer analog zu py2exe, allerdings sind die wohl noch nicht so ausgereift. Es wäre ja cool, ein und dasselbe Programm (z.B. py2bin) für alle Plattformen zu haben. Durch eine interne Unterscheidung des Betriebssystems kann py2bin ja selbst entscheiden, ob eine .exe oder einfach eine binäre UNIX Datei rauskommt. Aber man hätte für alle Plattformen dieselbe setup.py (so heißt das bei py2exe) und dieselben Einstellungen.[/qoute]
Die Konvention der setup.py kommt von den distutils in die sich py2exe, ähnlich wie setuptools einklinkt. Aber sieh doch in die [wiki]FAQ[/wiki] dort steht vieles zum Thema Compiler schon drin.
Anonymous hat geschrieben:Jedenfalls kann man sich auf UNIX Freezer noch nicht so verlassen, richtig? Sollte man da besser das .pyc rausgeben (noch unknackbar) und den Interpreter einfach voraussetzen? Auf den meisten UNIX-Systemen ist der sowieso vorhanden... nur vielleicht einige Module noch nicht. Kann ich die ebenfalls als .pyc mitliefern (z.B. Module wie 'xmlrpc', 'sys' oder 'os')? Checkt das der Python-Interpreter oder muss man ein .pyc noch über Python kompilieren (compile-Befehl)?
Achtung! Die .pyc/.pyo-Dateien sind meist nur in einer Python-Generation verwendbar (z.B Python 2.2.x oder 2.3.x oder 2.4.x) da sie vom marshal-Modul hergestellt werden und keine Kompatibilität garantiert wird.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

Anonymous hat geschrieben:Man kann seinen Python-Code kompilieren. Im Regelfall macht das der Interpreter schon selbst, richtig? Es entsteht eine .pyc Datei, die den Bytecode der .py Datei enthält. Dabei ist aber noch nicht viel passiert außer einer Textumwandlung in Bytecode, die trotzdem noch interpretiert (also kann man 'live compiliert' sagen?) werden muss.
Ein C-Compiler macht auch nichts grundlegend anderes: Er erzeugt Bytecode der von einem Prozessor interpretiert wird. Bei vielen aktuellen Prozessoren steckt im Prozessor noch mal ein Übersetzer der den "externen" Maschinencode nochmal in einen interenen Microcode umwandelt, der dann auf der Hardware läuft.

Ist Dein Quelltext wirklich sooo toll, wertvoll und revolutionär neu? Oder versuchst Du nur einen Kopierschutz zu "schützen"? In letzterem Fall braucht ein Angreifer kein Tool um den gesamten Bytecode wieder in Quelltext zu wandeln, es reicht auch aus nur den Schutzteil mit `dis` zu untersuchen. Das gilt genauso für C/C++ oder andere Sprachen deren Übersetzer Maschinencode erzeugen. Wenn Dein Programm "wertvoll" ist, wird es auch jemanden geben der es knackt. Wenn es nicht so "wertvoll" ist, das es jemand knacken würde, dann lohnt sich auch die Mühe nicht den Code zu schützen.
ProgChild
User
Beiträge: 210
Registriert: Samstag 9. April 2005, 10:58
Kontaktdaten:

BlackJack hat geschrieben:Ein C-Compiler macht auch nichts grundlegend anderes: Er erzeugt Bytecode der von einem Prozessor interpretiert wird. Bei vielen aktuellen Prozessoren steckt im Prozessor noch mal ein Übersetzer der den "externen" Maschinencode nochmal in einen interenen Microcode umwandelt, der dann auf der Hardware läuft.
Der Punkt ist aber, dass der C Compiler, den Code auf eine niedrigere komplexitäts Ebene bringt. Aus einem Stück C Code wird eine ganze Reihe an Maschienen befehlen generiert. Und aus diesen Maschienen befehlen wurden alle Variablennamen usw. entfehrnt, da sie für den Prozessor unwichtig sind.

Wenn ich jetzt den Maschienen Code hab, dann kann der gleiche Code von einer Menge an C Konstrukten hervorgerufen worden sein. Und Variablennamen existieren nicht mehr. Dazu kommt noch, dass der gleiche C Code auf verschiedenen Compilern mit verschiedenen Optimierungen unterschiedliche Ergebnisse hervorruft. Darum ist es quasi unmöglich, aus einer Executeable, den C Code zurück zu gewinnen.

Bei Python sieht das etwas anders aus. Der Bytecode Compiler schreibt das script quasi 1 zu 1 in Bytecode um. Alle Variablennamen bleiben erhalten. Es handelt sich quasie nur um eine Vereinfachung für den Python Interpreter, damit er keine Syntaxprüfung durchführen muss, sondern nur den Code ausführen kann.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

An dieser Stelle habe ich den Thread gesplittet, der Rest ist unter "Mit Freier Software Geld verdienen" zu finden.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
foxx
User
Beiträge: 18
Registriert: Montag 25. September 2006, 22:24
Kontaktdaten:

Anonymous hat geschrieben:Für UNIXe gibt es wohl auch Freezer analog zu py2exe, allerdings sind die wohl noch nicht so ausgereift. Es wäre ja cool, ein und dasselbe Programm (z.B. py2bin) für alle Plattformen zu haben. Durch eine interne Unterscheidung des Betriebssystems kann py2bin ja selbst entscheiden, ob eine .exe oder einfach eine binäre UNIX Datei rauskommt. Aber man hätte für alle Plattformen dieselbe setup.py (so heißt das bei py2exe) und dieselben Einstellungen.
Gibt es sowas nicht schon mit PyInstaller? Nach meinen Erfahrungen läuft der ziemlich stabil und ist auch nicht viel schwerer zu benutzen als py2exe. Außerdem kann er single-file-executables erstellen (okay, das ist manchmal noch ein ganz klein wenig buggy, aber das ist ja etwas, was py2exe garnicht erst beherscht).

Gruß,
foxx
[url=http://www.php4you.de/]PHP4You[/url]
[url=http://forum.php4you.de]PHP4You-Forum[/url]
[url=http://janek.php4you.de/]Mein Blog[/url]
[url=http://www.php4you.de/against_icq.html]Against ICQ[/url]
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

foxx hat geschrieben:Gibt es sowas nicht schon mit PyInstaller?
Ja. Sowohl PyInstaller als auch cx_Freeze laufen sowohl unter Windows als auch unter Linux. Von den bekannteren Freezern sind nur py2exe und py2app auf eine Platform beschränkt.

P.S.: py2exe beherrscht Single-File-Executables inzwischen (wenn ich mich nicht täusche schon seit Version 0.6.1).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
foxx
User
Beiträge: 18
Registriert: Montag 25. September 2006, 22:24
Kontaktdaten:

Leonidas hat geschrieben:P.S.: py2exe beherrscht Single-File-Executables inzwischen (wenn ich mich nicht täusche schon seit Version 0.6.1).
Achso? Bisher hab ich immer nur Lösungen mit NSIS oder Inno Setup gefunden... Wie auch immer, ich verwende trotzdem lieber PyInstaller, da ich da nicht für jedes System ein extra "Install Script" brauche.

Gruß,
foxx
[url=http://www.php4you.de/]PHP4You[/url]
[url=http://forum.php4you.de]PHP4You-Forum[/url]
[url=http://janek.php4you.de/]Mein Blog[/url]
[url=http://www.php4you.de/against_icq.html]Against ICQ[/url]
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Yeah. Alte Threads ausgraben.
TUFKAB – the user formerly known as blackbird
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

foxx hat geschrieben:Achso? Bisher hab ich immer nur Lösungen mit NSIS oder Inno Setup gefunden...
Voilá, eine Lösung die ohne externen Installer auskommt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
supersonic72
User
Beiträge: 17
Registriert: Freitag 15. September 2006, 15:45

Hallo alle zusammen.
Kann mir jemand sagen ob und wenn ja wie ich mit PyInstaller unter windows eine Linux executable erstellen kann? Die Standardmäßig erstellte Exe funktioniert nicht unter Linux.
Danke!
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

supersonic72 hat geschrieben:Kann mir jemand sagen ob und wenn ja wie ich mit PyInstaller unter windows eine Linux executable erstellen kann? Die Standardmäßig erstellte Exe funktioniert nicht unter Linux.
Soweit ich weiß unterstützt PyInstaller kein Crosscompiling. Das ist auch nicht verwunderlich, denn PyInstaller kocht auch nur mit Wasser und packt den Interpreter bei. Unter Windows ist in der Regel keine Linux-Version vom Interpreter verfügbar, die beigepackt werden könnte.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
supersonic72
User
Beiträge: 17
Registriert: Freitag 15. September 2006, 15:45

Soweit ich weiß unterstützt PyInstaller kein Crosscompiling. Das ist auch nicht verwunderlich, denn PyInstaller kocht auch nur mit Wasser und packt den Interpreter bei. Unter Windows ist in der Regel keine Linux-Version vom Interpreter verfügbar, die beigepackt werden könnte.
Gibt es eine andere Möglichkeit unter Windows eine Linux executable zu erstellen? py2exe, cxfreeze, mcmillan' installer? Wäre für jede Hilfe dankbar.
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:


Gibt es eine andere Möglichkeit unter Windows eine Linux executable zu erstellen? py2exe, cxfreeze, mcmillan' installer? Wäre für jede Hilfe dankbar.
So weit, wie ich weiß nein.
Unter Windows ist in der Regel keine Linux-Version vom Interpreter verfügbar, die beigepackt werden könnte.
Ich weiß ja nicht, aber selber basteln kann man sich so etwas nicht oder?


MfG EnTeQuAk
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

supersonic72 hat geschrieben:Gibt es eine andere Möglichkeit unter Windows eine Linux executable zu erstellen? py2exe, cxfreeze, mcmillan' installer?
Nein - VMWare, VirtualBox, VirtualPC.

Außerdem finden Linux-User soche Executables in der Regel eh ätzend. Ich lade mir auch nicht gerne irgendwelche BLOBs unter Linux runter.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
thorbytes
User
Beiträge: 37
Registriert: Samstag 24. Februar 2007, 17:38
Kontaktdaten:

Hallo,

ich bin gerade auf diesen Thread gestossen.

PyPy ist ja seit Ende März in der Version 1.0 erhältlich. Nach allem was ich bisher darüber gelesen habe, soll es damit möglich sein Python-Code in C-Code zu übersetzen. Diesen kann man dann ja wiederum sowohl für Linux als auch für Windows kompilieren.
Benutzeravatar
name
User
Beiträge: 254
Registriert: Dienstag 5. September 2006, 16:35
Wohnort: Wien
Kontaktdaten:

thorbytes hat geschrieben:Hallo,

ich bin gerade auf diesen Thread gestossen.

PyPy ist ja seit Ende März in der Version 1.0 erhältlich. Nach allem was ich bisher darüber gelesen habe, soll es damit möglich sein Python-Code in C-Code zu übersetzen. Diesen kann man dann ja wiederum sowohl für Linux als auch für Windows kompilieren.
Naja, cross-compiling is auch net so einfach, das isses einfacher sicher in einer VirtualBox oder VMware ein Linux aufzusetzen und da einfach pyinstaller zu machen.
Oder aber man nimmt wine um die .exe aufzumachen :P
Ohloh | Mein Blog | Jabber: segfaulthunter@swissjabber.eu | asynchia – asynchrone Netzwerkbibliothek

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

thorbytes hat geschrieben:PyPy ist ja seit Ende März in der Version 1.0 erhältlich.
Achtung, PyPys Version 1.0 heißt nicht: "man kann damit nun CPython ersetzen".
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten