Das deutsche Python-Forum

Zu dem `decompyle` *nochmal* das Argument: Es ist nicht unsicherer als Java. Eher noch sicherer weil es AFAIK nur dieses eine Programm gibt, dass kein aktuelles Python beherrscht. Python 2.3 ist da glaube ich der Stand. Wohingegen es bei Java sogar mehrere Decompiler-Projekte gibt.

Eine Firma die keine Probleme hat Java-`class`-Dateien an Kunden aus zu liefern, sollte auch mit `pyc`- bzw. `pyo`-Dateien keine Probleme haben. Wenn die Einstellung zu `class` und `pyo` nicht übereinstimmt, ist das etwas rein psychologisches. Da helfen keine technischen Massnahmen, sondern ein Arzt.

Mir ist ehrlich gesagt auch immer noch zu schwammig von was für tollem Wissen Du da redest, dass niemand sehen darf, das aber trotzdem zum Kunden auf die Platte darf. Ich würde mal sagen 99% an Anwendungsoftware-Quelltext ist absolut langweilig. GUI-Code, ein bisschen Daten hin und her schieben, alles nix wirklich Aufregendes.

Neue innovative Ideen sind oft, dass das Programm im ganzen etwas ermöglicht, was vorher noch niemand angedacht hat. Oder Bedienkonzepte. Das sind aber Sachen, die man von aussen sehen und entsprechend nach programmieren kann.

Und das eine Prozent wo wirklich ein Wissensvorsprung so bedeutend ist, dass er vor den Augen der Konkurrenz versteckt werden muss, sollte das einfach mal nicht auf der Festplatte von Kunden landen. Denn wenn die Konkurrenz da wirklich hinterher ist, werden die's "reverse engineeren", egal wie stark der Schutz ist. Wenn keiner es knacken will, ist es andererseits nicht ökonomisch Zeit in eine Verschlüsselung o.ä. zu investieren.

droptix hat geschrieben:Scriptschutz hat schon eine Relevanz, sonst würden Unternehmen kein Geld darin investieren.

Auch Unternehmen sind vor Fehlern nicht gefeigt. Die Leute, die das Geld für Technik verwalten bzw. ausgeben, sind nämlich in den seltensten Fälle auch Leute, die wirklich Ahnung von Technik haben.

Tatsache ist schlichtweg, dass Script"schutz" nicht existiert. Ein "geschütztes" Script ist nicht sicherer als ein ungeschütztes. Der einzige Schutz gegen Missbrauch des Quellcodes ist das Gesetz. Dekompilierung und Reverse Engineering sind in Deutschland Urheberrechtsverstöße. Auf diesem Wege gewonnenes Wissen ist für Firmen nicht zu gebrauchen, es sei denn, sie wollen sich dem Vorwurf der Urheberrechtsverletztung aussetzen.

Zudem stellt sich die Frage, ob Code in Programmen wirklich schützenswert ist. Ideen äußern sich nicht so sehr im Quellcode wie in der äußeren Erscheinung. Beispiel Aero: Es sieht toll aus, aber wen interessiert schon der Code? Eine Aero-ähnliche Oberfläche kann man leicht nachprogrammieren, egal ob der Code nun geschützt ist oder nicht.

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.

Security by obscurity funktioniert nicht. Die wenigen Firmen, die noch immer daran glauben (z.B. Microsoft), werden regelmäßig von katastrophalen Lücken heimgesucht. Das liegt daran, dass nur die wenigsten Lücken direkt aus dem Quelltext ersichtlich sind. Das sind vor allem Buffer-Fehler und ähnliches, was durch die unsichere Verwendung von C-Standardfunktionen verursacht wird.

Diese Sicherheitslücken sollten es bei einem entsprechend modernen Entwicklungsprozess aber eigentlich gar nicht mehr in die Öffentlichkeit schaffen, da entsprechende Security-Tools existieren, mit denen man derartiges aufspüren kann. Auch braucht man den Quelltext nicht, um diese Lücken von außen aufzuspüren. Da reicht es schon, wenn man verdächtigen Stellen (z.B. Nutzereingaben) einfach ein bisschen experimentiert. Dann sieht man meist recht schnell, ob dort eine Sicherheitslücke verborgen sein könnte.

Zudem sind Programme in High-Level-Sprachen wie Python oder Java davon sowieso nicht wirklich betroffen, da Speicherallokation und Manipulation im Interpreter bzw. Jit-Compiler geschieht. Problematisch sind nur Lücken in der Runtime, auf die man aber wenig Einfluss hat.

Richtig schlimm sind Sicherheitslücken, die durch logische Fehler im Programm auftreten. Ein Beispiel ist z.B. die WMF-Lücke, die es ermöglichte, Code aus Bilddateien heraus auszuführen. Solche Lücken erkennt man aber gerade in komplexen Systemen nicht aus dem Quellcode.

Der umgekehrte Schluss, dass offener Code die Sicherheit erhöht, ist der richtige. Zum einen macht man damit professionellen Experten die Arbeit leichter, was die Chance erhöht, dass Lücken von der "guten" Seite gefunden und beseitigt werden, bevor sie von der "bösen" ausgenützt werden können. Zum anderen überträgt man damit das bewährte Kerckhoffs-Prinzip aus der Kryptographie auf Software: Sicherheit muss selbst dann garantiert werden, wenn dem Angreifer alles bekannt ist!

BlackJack hat geschrieben:Zu dem `decompyle` *nochmal* das Argument: Es ist nicht unsicherer als Java. Eher noch sicherer weil es AFAIK nur dieses eine Programm gibt, dass kein aktuelles Python beherrscht. Python 2.3 ist da glaube ich der Stand. Wohingegen es bei Java sogar mehrere Decompiler-Projekte gibt.

Meines Wissens nach geht mittlerweile auch Python 2.5:

decompyle hat geschrieben:The 'decompyle' service converts Python byte-code back into equivalent Python source. It accepts byte-code from any Python version starting with 1.5 up to 2.5

BlackJack hat geschrieben:Mir ist ehrlich gesagt auch immer noch zu schwammig von was für tollem Wissen Du da redest, dass niemand sehen darf, das aber trotzdem zum Kunden auf die Platte darf.

Hum, hab ich das so schlecht dargestellt? Ich konstruiere hier nur Zusammenhänge und erzähle keine konkreten Geschichten…

Was du z.B. in dein Python-Programm steckst ist dein Wissen. Sicher könnte das auch jemand anders haben, aber dein Programm löst vielleicht ein spezielles Problem, welches bislang unbedient blieb. Weil du dein Wissen mit einer neuartigen Idee auf besondere Weise gebündelt hast, entsteht so vielleicht ein Programm mit einem Alleinstellungsmerkmal. Genau so ergeht es StartUp-Unternehmen: Ihr einziges Verkaufspotenzial ist ein Technologievorsprung durch irgend eine noch nie dagewesene Idee, die vorhandenes Wissen neuartig zusammensetzt.

Also stimme ich dir zu: ich spreche wohl eher von neuen Ideen. Das Wissen dafür ist meistens schon lange da. Ich denk da immer an die IBM-Werbung mit dem geschnitten Brot…

BlackJack hat geschrieben:Und das eine Prozent wo wirklich ein Wissensvorsprung so bedeutend ist, dass er vor den Augen der Konkurrenz versteckt werden muss, sollte das einfach mal nicht auf der Festplatte von Kunden landen.

Wie sollte man denn das umgehen? Da fällt mir nur ein Webservice ein. Ansonsten landet die Idee bzw. das gebündelte Wissen auf der Festplatte des Kunden, nur eben nicht lesbar.

droptix hat geschrieben:Ansonsten landet die Idee bzw. das gebündelte Wissen auf der Festplatte des Kunden, nur eben nicht lesbar.

Ein "nicht lesbares" Programm gibt es nicht. Jedes Programm, welches auf der Platte des Users liegt, muss lesbar sein. Sonst wäre es ja nicht ausführbar.

Deswegen gilt: Alles, was auf der Platte des Kunden landet, ist potentiell lesbar. Dagegen hilft kein Scriptschutz, dagegen hilft noch nicht mal der Allmächtige selbst

Folglich musst du abwägen: Ist der Code wirklich so wertvoll (was ich mich nicht vorstellen kann)? Dann muss du das Programm eben als Webservice ausführen, und nur dumme GUI-Clients für die Kundenrechner ausliefern. Fraglich ist dann allerdings wieder, ob die Firmen dieses Programm dann überhaupt kaufen werden. Die IT-Sicherheit einer Firma ist nämlich sicherlich nicht begeistert davon, geschäftskritische Daten auf fremden Servern zu verarbeiten.

lunar hat geschrieben:Der umgekehrte Schluss, dass offener Code die Sicherheit erhöht, ist der richtige. Zum einen macht man damit professionellen Experten die Arbeit leichter, was die Chance erhöht, dass Lücken von der "guten" Seite gefunden und beseitigt werden, bevor sie von der "bösen" ausgenützt werden können. Zum anderen überträgt man damit das bewährte Kerckhoffs-Prinzip aus der Kryptographie auf Software: Sicherheit muss selbst dann garantiert werden, wenn dem Angreifer alles bekannt ist!

Das regt zum Nachdenken an

@droptix: Ah, `decompyle` kostet dann aber etwas. Ist auch eine gewisse Hürde. Und wenn man es als Webservice nutzt, kommt noch dazu, dass dann eventuell ein Dritter, nämlich der Anbieter von `decompyle` vor Gericht als Zeuge gegen einen auftreten kann, wenn man unberechtigt fremden Code in Quelltext verwandelt hat.

Du "konstruierst Zusammenhänge", nichts konkretes, das ist es was ich mit "schwammig" meine. Und dagegen kann man fast nichts tun. Wenn man sich gegen etwas schützen möchte, muss man schon *genau* wissen, wogegen und wie stark. Gegen dieses allgemeine "Kunde darf Implementierung von Idee nicht sehen" hilft wirklich nur der Webservice. Wie das zum Beispiel bei `decompyle` gemacht wird.

Bei dem beschriebenen Szenario ist die Kombination der Ideen das Wesentliche und nicht der Quelltext. Die Kombination bekommt man auch ohne den Quelltext heraus, in dem man sich anschaut was das Programm bekommt und was es daraus macht. Auf die IBM-Werbung bezogen: Wenn ich vorher das Brot sehe, und nachher die geniale Idee mit den Scheiben, werde ich auch ohne gesehen zu haben wie jemand ein Brotmesser benutzt, einen Weg finden können Brot in Scheiben zu zerteilen.

Wenn man ausführbaren Code rausgibt, kann man nur gewisse Hürden aufbauen, die das "reverse engineering" erschweren. `pyo`-Dateien sollten für den Anfang genügen. Schau Dir mal die Preise vom `decompyle`-Webservice an. Die sind nicht ohne. Entweder eine Beschränkung auf 5 Dateien pro Monat mit mindestens 10€ pro Datei (10€ pro angefangene 5 KiB/Datei), oder mindestens 500€ für bis zu 5 Dateien und für jede weitere Datei nochmal 100€.

Man kann sich einen eigenen Python-Interpreter bauen, bei dem die Werte der Bytecodes anders sind. Dann funktioniert `decompyle` nicht mehr so einfach, bis der Angreifer herausgefunden hat, wie die neuen Werte zu den alten stehen.

Und man kann Teile des Programms in Pyrex/Cython oder C schreiben und zwingt damit den Angreifer zu einem Disassembler zu greifen. Ist aber letztendlich auch ein recht schwacher Schutz, der nur ein wenig aufhält. Wenn überhaupt. "Reverse engineering" von `pyo`-Dateien ist relativ exotisch, für x86-Maschinencode gibt's wesentlich mehr Werkzeuge und sicher auch erfahrene (Cr|H)acker.

decompyle für Python 2.5 ist komerziell, die freie Version die von einigen Debian-Leuten maintaint wird ist auf dem Stand von 2.3. Somit kann man neuen Python Bytecode zumindest nicht umsonst disassemblieren. Java-Bytecode schon.

Ich glaube, dass größte Problem für den OP ist...

Ich mach'n Programm und verkauf's. Einer kauft's, kopiert den Quelltext, ändert 2 Zeilen und verkauft es für 10 € weniger oder macht's frei.

(Natürlich ist es im Endeffekt nicht so leicht.... Aber ich denke halt, dass dies seine Bedenken sind.)

BlackVivi hat geschrieben:Ich glaube, dass größte Problem für den OP ist...

Ich mach'n Programm und verkauf's. Einer kauft's, kopiert den Quelltext, ändert 2 Zeilen und verkauft es für 10 € weniger oder macht's frei.

Dekompilieren und Reverse Engineering ist - bis auf wenige Ausnahmen - durch das Urheberrecht untersagt! In dem Moment, in dem eine Firma geklauten Code in ihr Programm einbaut, begeht sie eine Urheberrechtsverletzung. Folglich wird keine seriöse Firma ihr Programm auf solchem Code aufbauen!

Die unseriösen Firmen/Personen dagegen würde sowieso mehr oder weniger alles tun, um die Code zu erhalten, da schützt auch kein Obfuscator.

Geheimhaltung des Codes und bessere Sicherheit sind keine Argumente für verschlüsselten Code. Ersteres lässt sich damit nicht erreichen, letztere wird durch Verschlüsselung eher noch verringt als erhöht.

Warum also sollte eine Firma Geld in Dinge investieren, die entweder nichts bringen oder sogar schädlich sind? Hinter einem solchen Vorhaben steht keine kluge Geschäftsführung.

Wäre sich eine Firma die Quelltext klaut würde ich den geklauten Code auch verschlüsseln.

BlackVivi hat geschrieben:Ich mach'n Programm und verkauf's. Einer kauft's, kopiert den Quelltext, ändert 2 Zeilen und verkauft es für 10 € weniger oder macht's frei.

(Natürlich ist es im Endeffekt nicht so leicht.... Aber ich denke halt, dass dies seine Bedenken sind.)

Das sind im übrigen nicht meine Bedenken, sondern bekannte Dinge, über die sich Programmierer und Unternehmen im Alltag Gedanken machen.