Scriptsicherheit

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.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

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?
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

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.
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

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...
Zuletzt geändert von keppla am Donnerstag 31. Januar 2008, 14:12, insgesamt 1-mal geändert.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

droptix 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.
Ich werde alt und entwickle gegenüber non-Free-Software immer weniger Toleranz :P
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?
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: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?
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.

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
BlackJack

@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.
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

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 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.
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

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.
BlackJack

Ich hatte mir aber nicht die Mühe gemacht den Link heraus zu suchen. :-)
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Leonidas hat geschrieben:Ich werde alt und entwickle gegenüber non-Free-Software immer weniger Toleranz :P
Wie gesagt das ist nicht der Diskussionsstandpunkt :twisted:
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.
Der Gedanke kam mir auch. D.h. es ist eigentlich sehr einfach knackbar, oder?

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.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

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.
BlackJack

@droptix: Wozu stellt decompyle eine Einladung dar? Und was ist so schlimm daran?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

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.
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.
BlackJack hat geschrieben:@droptix: Wozu stellt decompyle eine Einladung dar? Und was ist so schlimm daran?
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.

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.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

droptix 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.
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 sagen ;)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

@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.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

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.
lunar

Y0Gi hat geschrieben: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: Vista

scnr
lunar
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

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:
  • Für Python gibt es keine derartige Scriptschutzfunktion, abgesehen von pyobfuscate, was aber noch buggy ist.
    Knackbar ist nichts.
Wöllte man so etwas im Eigenbau basteln, müsste der Scriptschutz während dem `import` Befehl greifen. Kann man den denn so erweitern, dass nach dem Einlesen der .py Datei ein Decrypt-Verfahren über den Dateiinhalt läuft?
Zap
User
Beiträge: 533
Registriert: Freitag 13. Oktober 2006, 10:56

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. :roll:

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.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

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.
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 :twisted: 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:Firmen wollen kostenfrei das Wissen und die Arbeit anderer(hier in Form von Python) nutzen.
Macht ihr das nicht ständig auch? Nicht unbedingt im Python-Forum, aber in anderen Bereichen…
Zap hat geschrieben:Sind dann aber nicht bereit ihr Wissen im gegenzug mit anderen zu teilen.
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: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.
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.
Antworten