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

Donnerstag 31. Januar 2008, 10:45

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

Donnerstag 31. Januar 2008, 13:27

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

Donnerstag 31. Januar 2008, 13:44

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 31. Januar 2008, 14:09

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

Donnerstag 31. Januar 2008, 14:23

@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: 4871
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

Donnerstag 31. Januar 2008, 14:24

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

Donnerstag 31. Januar 2008, 14:34

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

Donnerstag 31. Januar 2008, 14:47

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

Donnerstag 31. Januar 2008, 15:36

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

Donnerstag 31. Januar 2008, 16:27

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

Donnerstag 31. Januar 2008, 18:32

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

Donnerstag 31. Januar 2008, 21:12

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

Donnerstag 31. Januar 2008, 23:13

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 31. Januar 2008, 23:50

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

Freitag 1. Februar 2008, 00:02

@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.
Antworten