Ich möchte hier nicht die Diskussion aufkochen, bei der es um die Gründe für Closed-Source-Projekte geht. Vielmehr soll dieses Thema Antworten liefern, ob Python als Scriptsprache für bestimmte Interessensgruppen geeignet ist. Ich bitte daher nochmal darum, den Fakt als gegeben zu nehmen, dass es Closed-Source-Projekte gibt und Anbieter darauf bedacht sind, Ihren Quellcode schützen zu müssen.
Gibt es eine Möglichkeit, Python-Scripts "sicher" auszuliefern, so dass sie nicht mehr mit einfachen Mitteln (wie z.B. decompyle) in den Python-Quellcode zurück gewandelt werden können?
Mir fällt da der Zend Guard ein, der PHP-Scripts in ein Binärformat verschlüsselt. Es gibt eine kostenlose Entschlüsselungs-Engine für Endanwender, die verschlüsselte PHP-Scripts zur Laufzeit entschlüsselt.
Gibt es solche oder ähnliche Ansätze auch für Python, um Scriptsicherheit für kommerzielle Entwickler zu gewährleisten?
Scriptsicherheit
IMHO ist das keine Sicherheit, sondern nur ein zusätzlicher Umstand. Wenn Code ausgeführt werden muss, dann muss er dazu in einer verarbeitbaren Form vorliegen. Diese wird man an der einen oder anderen Stelle abgreifen und wieder zu Programmcode machen können.
Als wertvoll betrachte ich gerade die Dinge, die nicht direkt Teil von ausgeführtem Code sind, nämlich Dokumentation, Kommentare, Bezeichner. Darüber wird dem Leser meist erst klar, was das ganze soll, was es tut und warum es das tut.
Im Falle von Python werden bei optimiertem Bytecode (.pyo) die Docstrings entfernt, die Kommentarzeilen sowieso. Inwieweit das für Bezeichner zutrifft, weiß ich so nicht. Wenn ja würde ich das aber als im Verhältnis zum Aufwand effizienteste und letztlich ausreichende Verschleierung ansehen, sofern es bei jenen Closed-Source-Projekten nicht gerade um Steuerungssoftware für Lenkraketen oder ähnliches geht.
Als wertvoll betrachte ich gerade die Dinge, die nicht direkt Teil von ausgeführtem Code sind, nämlich Dokumentation, Kommentare, Bezeichner. Darüber wird dem Leser meist erst klar, was das ganze soll, was es tut und warum es das tut.
Im Falle von Python werden bei optimiertem Bytecode (.pyo) die Docstrings entfernt, die Kommentarzeilen sowieso. Inwieweit das für Bezeichner zutrifft, weiß ich so nicht. Wenn ja würde ich das aber als im Verhältnis zum Aufwand effizienteste und letztlich ausreichende Verschleierung ansehen, sofern es bei jenen Closed-Source-Projekten nicht gerade um Steuerungssoftware für Lenkraketen oder ähnliches geht.
Python-bytecode dürfte eine ähnliche "Sicherheit" wie Java gegen reverse Engineering haben, da beide zu VM-Bytecode kompiliert werden, dabei aber die Identifier (z.b. Funktionsnamen) sichtbar lassen.
Bei java scheint das nicht als Problem gesehen zu werden...
Bei java scheint das nicht als Problem gesehen zu werden...
Zuletzt geändert von keppla am Donnerstag 31. Januar 2008, 14:12, insgesamt 1-mal geändert.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich werde alt und entwickle gegenüber non-Free-Software immer weniger Toleranzdroptix hat geschrieben:Ich bitte daher nochmal darum, den Fakt als gegeben zu nehmen, dass es Closed-Source-Projekte gibt und Anbieter darauf bedacht sind, Ihren Quellcode schützen zu müssen.
Nein. Das liegt in der Natur des Bytecodes (übrigens auch dem von Java oder .NET). Auch wenn decompyle nicht immer mit dem aktuellen Bytecode zurecht kommt, ist es recht einfach den anzupassen, wenn man ausreichend motiviert ist.droptix hat geschrieben:Gibt es eine Möglichkeit, Python-Scripts "sicher" auszuliefern, so dass sie nicht mehr mit einfachen Mitteln (wie z.B. decompyle) in den Python-Quellcode zurück gewandelt werden können?
Der Zend Guard gewährleistet doch gar nichts. Das Skript muss so oder so entschlüsselt werden, da eine CPU keinen verschlüsselten Code ausführen kann. Also muss der Schlüssel entweder in der Entschlüsselungs-Engine stecken oder im Binary.droptix hat geschrieben:Mir fällt da der Zend Guard ein, der PHP-Scripts in ein Binärformat verschlüsselt. Es gibt eine kostenlose Entschlüsselungs-Engine für Endanwender, die verschlüsselte PHP-Scripts zur Laufzeit entschlüsselt.
Gibt es solche oder ähnliche Ansätze auch für Python, um Scriptsicherheit für kommerzielle Entwickler zu gewährleisten?
Sowas ähnliches kannst du dir auch basteln: GnuPG nehmen, den Code symmetrisch verschlüsseln, durch ein C-Programm aufrufen lassen, welches das Passwort enthält und das alles in eine Binärdatei packen lassen. Wenn es den Aufwand wert wäre, gäbe es sowas schon.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@keppla: Bei Java gibt's für die Namen sogenannte "Obfuscator"-Programme, die alle Namen durch kryptisches Zeug austauschen.
Es gibt wohl auch so ein Programm für Python, aber das ist etwas unsicher, weil es in Python nicht unüblich ist Namen erst zur Laufzeit zusammen zu setzen, und so etwas wie ``getattr(self, 'do_' + command)(data)`` natürlich in die Hose geht, wenn die `do_*`-Methoden umbenannt wurden.
@droptix: Wie Y0Gi schon gesagt hat, irgendwo muss der Bytecode in unverschlüsselter Form an den Interpreter verfüttert werden und spätestens da kann man ihn abgreifen.
Man könnte einen eigenen Python-Interpreter compilieren und verwenden, bei dem die Bytecodes andere Werte haben.
Oder bestimmte, kritische Teile in (Pyrex|Cython) programmieren, oder in C und dann per `ctypes` einbinden.
Das Python-Bytecode ansonsten in etwa so sicher ist, wie Java's `class`-Dateien wurde ja schon gesagt. Aber auch kompiliertes C oder Assembler ist in der Regel nicht besonders sicher gegen bestimmte Angriffe. Ich habe früher als Schüler ein paar Spiele für den C64 und den PC (DOS) gecrackt und mit Trainern versehen.
Das einzig wirklich sichere ist, die zu schützenden Code-Teile nicht aus zu liefern, sondern als Internetdienst zur Verfügung zu stellen.
Was ist überhaupt das Angriffsszenario? Wogegen soll der Schutz greifen? Denn letztendlich bieten die meisten Methoden nur begrenzt Schutz und sind trotzdem aufwändig.
@Leonidas: Da würde mir spontan ein import-hook einfallen um verschlüsselte Module zu laden.
Es gibt wohl auch so ein Programm für Python, aber das ist etwas unsicher, weil es in Python nicht unüblich ist Namen erst zur Laufzeit zusammen zu setzen, und so etwas wie ``getattr(self, 'do_' + command)(data)`` natürlich in die Hose geht, wenn die `do_*`-Methoden umbenannt wurden.
@droptix: Wie Y0Gi schon gesagt hat, irgendwo muss der Bytecode in unverschlüsselter Form an den Interpreter verfüttert werden und spätestens da kann man ihn abgreifen.
Man könnte einen eigenen Python-Interpreter compilieren und verwenden, bei dem die Bytecodes andere Werte haben.
Oder bestimmte, kritische Teile in (Pyrex|Cython) programmieren, oder in C und dann per `ctypes` einbinden.
Das Python-Bytecode ansonsten in etwa so sicher ist, wie Java's `class`-Dateien wurde ja schon gesagt. Aber auch kompiliertes C oder Assembler ist in der Regel nicht besonders sicher gegen bestimmte Angriffe. Ich habe früher als Schüler ein paar Spiele für den C64 und den PC (DOS) gecrackt und mit Trainern versehen.
Das einzig wirklich sichere ist, die zu schützenden Code-Teile nicht aus zu liefern, sondern als Internetdienst zur Verfügung zu stellen.
Was ist überhaupt das Angriffsszenario? Wogegen soll der Schutz greifen? Denn letztendlich bieten die meisten Methoden nur begrenzt Schutz und sind trotzdem aufwändig.
@Leonidas: Da würde mir spontan ein import-hook einfallen um verschlüsselte Module zu laden.
Das kann man so nicht sagen: Ein Programm welches in Python-Bytecode vorliegt lässt sich viel leichter analysieren, da der Bytecode aus "Hochsprachen-Anweisungen" besteht. Bei Java hingegen wird nahezu "echter" Maschinencode erzeugt. Dort sind Zusammenhänge viel schlechter zu erkennen.Leonidas hat geschrieben:Nein. Das liegt in der Natur des Bytecodes (übrigens auch dem von Java oder .NET). Auch wenn decompyle nicht immer mit dem aktuellen Bytecode zurecht kommt, ist es recht einfach den anzupassen, wenn man ausreichend motiviert ist.
Das erschwert es vielleicht zusätzlich etwas: http://www.lysator.liu.se/~astrand/proj ... obfuscate/
MfG
HWK
Edit: Oh, ich sehe gerade: BlackJack war schneller.
MfG
HWK
Edit: Oh, ich sehe gerade: BlackJack war schneller.
Wie gesagt das ist nicht der DiskussionsstandpunktLeonidas hat geschrieben:Ich werde alt und entwickle gegenüber non-Free-Software immer weniger Toleranz
Der Gedanke kam mir auch. D.h. es ist eigentlich sehr einfach knackbar, oder?Leonidas hat geschrieben:Der Zend Guard gewährleistet doch gar nichts. Das Skript muss so oder so entschlüsselt werden, da eine CPU keinen verschlüsselten Code ausführen kann. Also muss der Schlüssel entweder in der Entschlüsselungs-Engine stecken oder im Binary.
Gäbe es decompyle nicht, wäre das Ausliefern von Python-Bytecode (.pyc) meiner Meinung nach ausreichend. Das Vorhandensein von decompyle stellt aber geradezu eine Einladung dar.
Die Frage, die sich mir stellt: Was für ein superheftigkrasses Programm muss das sein, dass sich jemand die Mühe macht, den Code entschlüsseln zu wollen? Wenn da so ein toller Algorithmus dahinter steckt, kann man den wohl noch patentieren lassen.
Auch kann ich mir vorstellen, dass man Code-Module durchaus verwenden kann, ohne sie zu "entschlüsseln", wenn man die API herausfinden kann und die selbst nicht "verschlüsselt" ist.
Auch kann ich mir vorstellen, dass man Code-Module durchaus verwenden kann, ohne sie zu "entschlüsseln", wenn man die API herausfinden kann und die selbst nicht "verschlüsselt" ist.
@droptix: Wozu stellt decompyle eine Einladung dar? Und was ist so schlimm daran?
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Nein, Javas Bytecode kennt sogar Objekte. Ich habe vor Jahren mit, ich glaube es war JAD wunderbar Java-Dateien aus Class-Dateien herausbekommen können. Wesentlich angenehmer als das Assembler, was mir diverse Disassembler für C liefern.EyDu hat geschrieben:Das kann man so nicht sagen: Ein Programm welches in Python-Bytecode vorliegt lässt sich viel leichter analysieren, da der Bytecode aus "Hochsprachen-Anweisungen" besteht. Bei Java hingegen wird nahezu "echter" Maschinencode erzeugt. Dort sind Zusammenhänge viel schlechter zu erkennen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Nein. Softwarepatente sind in Deutschland i.d.R. nicht möglich, es sei denn sie haben einen "technischen Charakter". Das ist z.B. dann der Fall, wenn eine spezielle Software Messdaten auswertet oder sowas… unmittelbar in Zusammenhang steht aber ein Gerät oder eine Maschine, ohne die die Software sinnlos wäre.Y0Gi hat geschrieben:Die Frage, die sich mir stellt: Was für ein superheftigkrasses Programm muss das sein, dass sich jemand die Mühe macht, den Code entschlüsseln zu wollen? Wenn da so ein toller Algorithmus dahinter steckt, kann man den wohl noch patentieren lassen.
Wozu: Zum decompilieren, also zum Aufdecken von Programmroutinen oder Ideen bzw. Ansätzen, auf die andere Leute wohl nicht so schnell gekommen wären. Man kann somit sein Wissen nicht vor Nachahmung schützen.BlackJack hat geschrieben:@droptix: Wozu stellt decompyle eine Einladung dar? Und was ist so schlimm daran?
Schlimm: Kommerzielle Unternehmen haben durch diese extrem einfache Möglichkeit, nahezu den ursprünglichen Code wiederherstellen zu können, kein Interesse Python zur Entwicklung von Programmen einzusetzen… ich sehe zumindest eine deutliche Tendenz dorthin.
Gerade als StartUp-Unternehmen ist das eigene Wissen der einzige Vorteil gegenüber der Konkurrenz. Wenn die aber problemlos in die eigenen Karten schauen kann, verschwindet der Wissensvorsprung.
Betrachtet diese Diskussion nicht auf mich bezogen. Ich untersuche nur, wie sich dieser Umstand auf das Denken kommerzieller Unternehmen gegenüber Python auswirkt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wo ist das schlimm? Außerdem glaube ich, dass du die falschen Schlüsse ziehst - in java, und ich wiederhole mich, ist das noch _wesentlich_ einfacher möglich (da die Tools sogar kostenlos erhältlich sind und in größerer Menge). Gibt es zu wenige Java-Jobs? Gibt es wenige Java-Firmen? Ich wollte schon immer ex falso quodlibet sagendroptix hat geschrieben:Schlimm: Kommerzielle Unternehmen haben durch diese extrem einfache Möglichkeit, nahezu den ursprünglichen Code wiederherstellen zu können, kein Interesse Python zur Entwicklung von Programmen einzusetzen… ich sehe zumindest eine deutliche Tendenz dorthin.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@droptix: Das trifft genau so auf Java zu. Und gibt's da grössere Bedenken?
Du kannst das Wissen auch ohne dekompilieren nicht vor Nachahmung schützen. Ideen und Ansätze sind in der Regel bei weitem nicht so toll wie die Programmierer, die's unbedingt schützen wollen, glauben. Wenn man von aussen sieht was ein Programm macht, kann man es in der Regel auch ohne den Quelltext zu kennen nach programmieren. Oft ist es sogar einfacher etwas "from scratch" nach zu bauen, als das Original zu "reverse engineeren".
Wenn es auf der anderen Seite wirklich etwas interessantes ist, dann wird sich auch bei stark geschütztem Binärcode jemand finden, der sich SoftICE schnappt und es komplett auseinander nimmt.
Du kannst das Wissen auch ohne dekompilieren nicht vor Nachahmung schützen. Ideen und Ansätze sind in der Regel bei weitem nicht so toll wie die Programmierer, die's unbedingt schützen wollen, glauben. Wenn man von aussen sieht was ein Programm macht, kann man es in der Regel auch ohne den Quelltext zu kennen nach programmieren. Oft ist es sogar einfacher etwas "from scratch" nach zu bauen, als das Original zu "reverse engineeren".
Wenn es auf der anderen Seite wirklich etwas interessantes ist, dann wird sich auch bei stark geschütztem Binärcode jemand finden, der sich SoftICE schnappt und es komplett auseinander nimmt.
Software bzw. deren Funktion ist immer duplizier- und reproduzierbar. Das sollte jeder Entwickler wissen und daher erübrigt sich meiner Meinung nach auch die Idee, Code vor fremden Augen schützen zu wollen.
Bonusfrage: Nenne mir einen Kopierschutz, der nicht geknackt oder ausreichend umgangen wurde.
Bonusfrage: Nenne mir einen Kopierschutz, der nicht geknackt oder ausreichend umgangen wurde.
Miese Qualität! Schlechte Programme will niemand haben, ergo werden sie auch nicht kopiert. Beispiel: VistaY0Gi hat geschrieben:Bonusfrage: Nenne mir einen Kopierschutz, der nicht geknackt oder ausreichend umgangen wurde.
scnr
lunar
Okay, damit sind wir nun endgültig doch vom eigentlichen Thema abgedriftet… Es ist zwar interessant, aber in der Praxis dann doch wieder egal, ob ihr einen Schutz als unnötig betrachtet. Fakt ist, dass es Unternehmen gibt, die das als nötig erachten.
Scriptschutz hat schon eine Relevanz, sonst würden Unternehmen kein Geld darin investieren. Und dass sie das tun, sieht man z.B. am Zend Guard (1. Posting). Ohne das Interesse am Schutz des geistigen Eigentums könnte ja jeder Open-Source entwickeln.
Der Schutz hat zudem auch noch eine weitere positive Eigenschaft: das Einschränken von Risiko. Die Hürde, um eine Sicherheitslücke im Programm zu finden, ist weitaus niedriger, wenn der Quellcode verfügbar ist. Das heißt zwar nicht, dass Closed-Source vom Ansatz her sicherer ist, jedoch gibt es andere Vorteile durch Unwissenheit. (Klar, bei Open-Source könnten mehr mitarbeiten und Sicherheitslücken im Vorhinein schließen.)
Fassen wir zusammen:
Scriptschutz hat schon eine Relevanz, sonst würden Unternehmen kein Geld darin investieren. Und dass sie das tun, sieht man z.B. am Zend Guard (1. Posting). Ohne das Interesse am Schutz des geistigen Eigentums könnte ja jeder Open-Source entwickeln.
Der Schutz hat zudem auch noch eine weitere positive Eigenschaft: das Einschränken von Risiko. Die Hürde, um eine Sicherheitslücke im Programm zu finden, ist weitaus niedriger, wenn der Quellcode verfügbar ist. Das heißt zwar nicht, dass Closed-Source vom Ansatz her sicherer ist, jedoch gibt es andere Vorteile durch Unwissenheit. (Klar, bei Open-Source könnten mehr mitarbeiten und Sicherheitslücken im Vorhinein schließen.)
Fassen wir zusammen:
- Für Python gibt es keine derartige Scriptschutzfunktion, abgesehen von pyobfuscate, was aber noch buggy ist.
Knackbar ist nichts.
Ich vermute das man noch viel tiefer gehen müsste.
Ein Skript (so verschlüsselt es auch ist) muss ja in letzter Konsequenz dem Interpreter zum verarbeiten vorgelegt werden. Und genau da liegt dann die Chance für die (ach so Böswilligen) Neugierigen zuzuschlagen.
IMHO wäre es nötig seine Programme mit einem eigenen PythonInterpreter auszuliefern, welcher bestimmte Entschlüsselungsarbeiten im Kern vornimmt.
Damit schneidet man sich zwar noch aggresiver von der Außenwelt ab. Aber bitte, sollen se doch
Ein letzter Schwenk auf die Grundsatzdiskusion:
Firmen wollen kostenfrei das Wissen und die Arbeit anderer(hier in Form von Python) nutzen. Sind dann aber nicht bereit ihr Wissen im gegenzug mit anderen zu teilen. Das finde ich moralisch doch sehr verwerflich.
Wenn es im firmeninterne Daten geht die wirklich nicht nach außen dürfen dann sollte man darüber nachdenken was die beim Kunden auf dem Rechner zu suchen haben.
Der einzige Anwendungsfall den ich akzeptabel finde sind Lizensierungen von Software. Aber dafür gibt es kryptographische Algorithmen unter Verwendung von Private und Public Keys, welche meines Wissens nach heutigem Stand ausreichend sicher sind.
Ein Skript (so verschlüsselt es auch ist) muss ja in letzter Konsequenz dem Interpreter zum verarbeiten vorgelegt werden. Und genau da liegt dann die Chance für die (ach so Böswilligen) Neugierigen zuzuschlagen.
IMHO wäre es nötig seine Programme mit einem eigenen PythonInterpreter auszuliefern, welcher bestimmte Entschlüsselungsarbeiten im Kern vornimmt.
Damit schneidet man sich zwar noch aggresiver von der Außenwelt ab. Aber bitte, sollen se doch
Ein letzter Schwenk auf die Grundsatzdiskusion:
Firmen wollen kostenfrei das Wissen und die Arbeit anderer(hier in Form von Python) nutzen. Sind dann aber nicht bereit ihr Wissen im gegenzug mit anderen zu teilen. Das finde ich moralisch doch sehr verwerflich.
Wenn es im firmeninterne Daten geht die wirklich nicht nach außen dürfen dann sollte man darüber nachdenken was die beim Kunden auf dem Rechner zu suchen haben.
Der einzige Anwendungsfall den ich akzeptabel finde sind Lizensierungen von Software. Aber dafür gibt es kryptographische Algorithmen unter Verwendung von Private und Public Keys, welche meines Wissens nach heutigem Stand ausreichend sicher sind.
Nichts ist unknackbar, soweit waren wir schon. Wer wirklich will, macht sich die Mühe. Kommt drauf an wie einfach es einem "Angreifer" gemacht wird. Wenn es schwer genug war und trotzdem geknackt wurde, dann hat sich der Angreifer den Quellcode auch verdient Nur wenn es durch decompyle quasi in Sekunden möglich ist, den Ursprungsquellcode wieder herzustellen, dann liegt die Messlatte sicher für viele zu niedrig.Zap hat geschrieben:Ich vermute das man noch viel tiefer gehen müsste.
Ein Skript (so verschlüsselt es auch ist) muss ja in letzter Konsequenz dem Interpreter zum verarbeiten vorgelegt werden. Und genau da liegt dann die Chance für die (ach so Böswilligen) Neugierigen zuzuschlagen.
Macht ihr das nicht ständig auch? Nicht unbedingt im Python-Forum, aber in anderen Bereichen…Zap hat geschrieben:Firmen wollen kostenfrei das Wissen und die Arbeit anderer(hier in Form von Python) nutzen.
Das sehe ich nicht so. Ich bin der Meinung dass viele ihr Wissen wieder anbieten, in welcher Form auch immer. Ich fände es ebenfalls verwerflich, wenn es so wäre. Wenn es um die Entwicklung neuartiger Dinge geht, kann man sein Wissen nicht immer teilen, allein schon nicht im Interesse des Auftraggebers/Arbeitgebers. Letztlich sind es meistens Angestellte, die programmieren und im Python-Forum auch mal nachfragen.Zap hat geschrieben:Sind dann aber nicht bereit ihr Wissen im gegenzug mit anderen zu teilen.
Wenn man sein Wissen in ein Programm packt, dass einem Kunden Vorteile und Erfolg bringt, dann liegt das Wissen nun mal beim Kunden auf der Platte. Wenn ich den Quellcode als "firmeninterne Daten" bezeichne, ist dieser Umstand von Haus aus bereits erfüllt.Zap hat geschrieben:Wenn es im firmeninterne Daten geht die wirklich nicht nach außen dürfen dann sollte man darüber nachdenken was die beim Kunden auf dem Rechner zu suchen haben.