Compilieren: Na klar! Decompilieren: (K)ein Problem ?!

[Bong-Jour]

Geplänkel, dass du nicht lesen musst:

Ich habe mir mal Gedanken über die Verwendung meiner Quelltexte von Dritten gemacht (unerlaubt ^^) und dazu ein bischen hier im Forum recherchiert. Beim decompilieren von pycs waren sich alle einig, dass es kaum eine Hürde darstellt. Aber bei exe.Dateien scheint jeder eine Andere Meinung zu haben.

Es kam auch oft das Argument zum Tragen, dass es sich wirtschaftlich gar nicht lohnen würde. Dies spielt aber für mich eine untergeordnete Rolle. Mir geht es ums Prinzip und ich möchte Jemanden "die Arbeit" so unschön wie möglich gestalten ^^


Eigentliche Frage:

Wie ist es den nun mit .exe Dateien ? Kann man sie tatsächlich decompilieren ? Und wenn Programmiersprache nur dazu dient Maschienencode zu erstellen, könnte man dann nicht aus einem Maschienencode den Quelltext zu jeder beliebigen Sprache erstellen lassen.. ?

[DasIch]

Ja.
Ja.

[sma]

Python ist die falsche Sprache, wenn da "exe"-Dateien erzeugt werden sollen, die möglichst schwer in Programmcode zurückverwandelt werden können sollen. Meines Wissens erzeugt nichts, was hier als py2exe und Co herumfliegt, Maschinencode, sondern packt nur einen Python-Interpreter zusammen mit dem Python-Bytecode in ein Programm, so das man nicht extra noch Python installieren muss.

Gäbe es einen Compiler, der Python-Programme in Maschinencode übersetzen kann, lässt sich aus solch generiertem Maschinencode in aller Regel auch wieder der Quelltext gewinnen, da ein einfacher Compiler bestimmte Muster erzeugt, die man erkennen und zurückverwandeln kann.

Eine bessere Chance hätte man mit stark optimierenden Compilern für ungewöhnliche Sprachen wie es sie z.B. für OCaml findet. Oder aber man verwürfelt noch mal den Assembler-Code, den ein Compiler wie der GCC erzeugt, wofür es meines Wissens auch spezielle Programme gibt. Das zerstört die Muster.

Weil diese Muster je nach Sprache unterschiedlich sind, kann man zwar theoretisch für jeden Maschinencode auch in jeder Sprache etwas äquivalentes finden, aber besser geht es, wenn man wieder die Originalsprache erzeugt.

Und es muss natürlich auch passende Sprachkonstrukture geben. Einen Sprung auszudrücken, ohne das man ein goto o.ä. in der Hochsprache hat, wird schwer.

Also: Ja, man kann exe-Dateien dekompilieren. Ja, theoretisch in jede Hochsprache, aber praktisch nicht.

Übrigens braucht man meinst nicht alles zurück zu übersetzen, sondern meist will man ja einen ganz bestimmten Test auf eine Lizenz o.ä. aushebeln. Dazu muss man bei weitem nicht alles verstehen. Ist der Test naiv implementiert, drehe ich einfach seine Bedingung und dann funktioniert mein Programm mit jeder ungültigen Lizenz - nur nicht mehr mit einer gültigen.

Und somit hast du dann auch den Weg gefunden, wie du jemandem Arbeit machen kannst: Lege Schicht um Schicht an Verwirrungen, Ablenkungen und Sackgassen über deinen Code und habe niemals nur eine einzige Stelle, wo etwas passiert. Sichere zudem alles mit cryptografisch sicheren Algorithmen ab, z.B. indem du an mehreren Stellen im Programm Prüfsummen über dein Programm sowohl auf der Platte als auch im Hauptspeicher berechnest, die du dann mit deinem privaten Schlüssel signiert hast.

Beachte, dass der Nutzer deines Programms es in einer VM (und damit aus deiner Sicht feindlichen Umgebung) laufen lassen könnte und somit sogar den Prozessor kontrollieren kann. Erkenne also die VM und verweigere kreativ den Dienst.

Der IMHO zur Zeit sicherste Weg, ein Programm zu schützen ist, in das abgeschottete und "sichere" Audio- und Video-Subsystem von Windows Vista und Windows 7 aufnehmen zu lassen. Wie das geht, weiß ich nicht, aber da Musik und Filme ein wertvolles Gut sind, wird hier dem Benutzer eigentlich jedes Mitspracherecht aberkannt, egal, ob das nun sein eigener Computer ist oder nicht.

Stefan

[problembär]

Hallo,

erstmal:

http://de.wikipedia.org/wiki/Decompiler

Normalerweise ist "Obfuscation" ein ganz guter Schutz für Skriptcode. Für Perl gibt es z.B.

http://search.cpan.org/~smueller/PAR-Pa ... fuscate.pm

(Perls "PAR" ist sowas wie Pythons py2exe, dieses Modul schaltet automatisch (bei Perl) Obfuscation ein, sehr praktisch.)

Obfuscation klappt leider bei Python nicht , weil Python bekanntlich sehr strenge Vorgaben an die Syntax macht (, die unter anderem die gute Lesbarkeit des Codes sicherstellen).

Gruß

[DasIch]

Obfuscation klappt bei Python durchaus, allerdings ist dass bei weitem schwerer als bei Perl.

[jens]

Ein paar Info's gibt es dazu im Wiki: [wiki]FAQ#IchWillAberUnbedingtEinenCompiler[/wiki]

[problembär]

Vielleicht ganz interessant ist auch noch, daß wohl nach 8 Jahren Entwicklung nächste Woche "Parrot"

http://www.parrot.org/

fertig werden soll (1.0). Es ist eine VM, die in erster Linie für Perl6 geschrieben wurde, auf der aber auch Python-Code läuft. Es heißt in

http://docs.parrot.org/parrot/latest/ht ... w.pod.html

by resembling the underlying hardware to some extent, it's possible to compile down Parrot bytecode to efficient native machine language.

Könnte interessant werden ...

Gruß

[veers]

Lass es bleiben, es nützt nichts. Sieh dir an was Skype gemacht hat um ihre Applikation zu "schützen" und trotzdem hat es nichts gebracht: http://www.secdev.org/conf/skype_BHEU06.handout.pdf .

[Leonidas]

Wie ist es den nun mit .exe Dateien ? Kann man sie tatsächlich decompilieren ?

Ja, siehe diesen Thread wo Crackus ein "kompiliertes" Programm mit Salt online stellt und darauf hofft dass der Salt geheim bleibt. Trundle hat den Salt ausgelesen und sein Ergebnis selbst gehasht. Daraus ist dann exetractor entstanden. Somit ist die Sicherheit von kompilierten Skripten quasi noch geringer als die von Bytecode.

[snafu]

Ich persönlich verstehe den Sinn ohnehin nicht. Man lernt durch Open Source (davon gehe ich doch mal ganz stark aus), aber gibt seine Kenntnisse sozusagen als "Dankeschön" nicht an andere weiter. Für mich hat das sowas von: "Hihi, ich kann was, was du nicht kannst und das verrat' ich nicht." Und wenn Leute Quellcode übernehmen, machen sie daraus etwas besseres, etwas schlechteres oder etwas ganz anderes. Wenn das Programm am Ende gut ist, nutze ich es, ansonsten eben nicht.

Gut, manch einer opfert sehr viel Zeit für sein Projekt und möchte diese auch (für mich berechtigterweise) bezahlt bekommen. Aber muss es deshalb Closed Source werden? Von den potenziellen Qualitätsverbesserungen, die durch Fehlerbehebung vieler (weil sie eben den Code kennen) herrührt, wissen wir alle. So kann ich mir beispielsweise ein qualitativ hochwertiges Produkt mit besonderen Serviceleistungen bezahlen lassen, die eben über ein Hobby hinausgehen (dies kann der Zahlende wohl erwarten).

Und an sich kann jeder, der den Programmablauf verstanden hat, ihn (in welcher Sprache auch immer) nachbauen. Da in den meisten Fällen wohl kein Patent angemeldet wird, sollte dies auch rechtlich kein Problem darstellen. Jemand, der das geschafft hat, kennt sein Programm und hat die Möglichkei,t es zum Wohle aller (das mag jetzt etwas hippiehaft klingen) zu verbessern. Wer sich hingegen auf den Lorbeeren fremden Codes ausruht (ohne diesen wirklich verstanden zu haben), wird vermutlich nichts sinnvoll besseres herzaubern und damit auch nicht in ernsthafter Konkurrenz zum Original treten können. So sehe ich das zumindest.

[Mad-Marty]

Typische Linux mentalität mit alles soll/muss open source sein

Komisch das genau die gleichen leute meinen bei jedem server jedwede identifikationsstrings abschalten zu müssen.

Obfuscaten kann durchaus die Sicherheit erhöhen je nach Fall.

Ob sich das lohnt muss jeder selber wissen, mir reicht ein py2exe völlig aus.

[snafu]

Komisch das genau die gleichen leute meinen bei jedem server jedwede identifikationsstrings abschalten zu müssen.

Ich sehe ehrlich gesagt keinen Zusammenhang zwischen meiner Privatsphäre beim Surfen im Internet und der Bekanntmachung von Quellcode.

Nichts soll oder muss. Das ist eher eine moralische und pragmatische Angelegenheit. Vertreiber von Open Source Software zwingen dich ja nicht genrell dazu, auch Open Source zu entwickeln. Die Vor- und Nachteile sollte da jeder für sich selbst abwägen, aber ich persönlich kann's halt nicht so recht nachvollziehen. Das soll aber nicht heißen, dass ich beleidigt bin, wenn jemand das anders sieht.

[Leonidas]

Typische Linux mentalität mit alles soll/muss open source sein

Ist ja auch ok so.

Komisch das genau die gleichen leute meinen bei jedem server jedwede identifikationsstrings abschalten zu müssen.

Jein. Postfix zum Beispiel zeigt die Version Standardmäßig nicht an, wohingegen Exim das durchaus macht. An dieser Stelle kann es aber durchaus nützlich sein, dass man die Version nicht anzeigt, weil so der Angreifer nicht sofort weiß ob die Version verwundbar ist oder nicht. Bei automatisierten Scans hofft man darauf dass der Server nicht in den Fokus des Angreifers fällt. Als Schutz gegen einen Angreifer der genau meinen Server angreifen will hilft es natürlich keineswegs.

Wohingegen obfuskierter Quelltext keinem praktischen Ziel dient, außer allen betroffenen das Leben schwer zu machen.

Obfuscaten kann durchaus die Sicherheit erhöhen je nach Fall.

Ja? Bitte um Beispiele.

Eine obfuskierte SQL-Injection-Lücke ist nicht besser als eine offene SQL-Injection-Lücke. Die Lösung des Problemes ist nicht das Problem zu verstecken sondern die Lücke zu entfernen.

[snafu]

Gut, der wichtige Aspekt der Sicherheit durch Anonymität kommt natürlich auch noch hinzu. Den hatte ich gerade unterschlagen. Jedenfalls ist Open Source IMHO nicht unsicherer, nur weil es offen dargelegt wird. (Ich glaube, ich verstehe jetzt doch, worauf Mad-Marty hinaus wollte) Sowas hält ja wahrscheinlich gerade dazu an, seine Software so sicher wie möglich zu entwickeln. Das läuft jetzt aber wohl auf eine Grundsatzdiskussion hinaus...

[Bong-Jour]

@snafu: Ich finde es naiv anderen den Code offenzulegen.. Ich denke da an Viren, die in der Software platziert werden oder auch Wege um mit dem Client in den Server einzubrechen.

@veers: Mein technisches Verständnis reicht nicht aus für das Verstehen dieses Dokumentes ^^ Aber welchen Sinn sollte es haben den Skype-Client zu decompilieren ?

@sma: Wie erkenne ich denn, ob der User mein Programm in einem emulierten Betriebssystem "traktiert" .. ? Und wie ist das mit den mehreren Stellen an denen etwas passiert gemeint ? Soll ich hier sinnlose Threads paralell laufen lassen.. ?


Was macht Microsoft eigentlich zum Schutz des Internet Explorers.. ? Es gibt doch seit Jahren den Rechtsstreit, dass Microsoft die Queltexte offenlegen soll. Anscheinend hat man hier deutliche Probleme mit der Dekompilation.

( Und wofür steht eigentlich die Abkürzung IMHO, die sma in jedem Post verwendet.. ? Bislang habe ich einfach die kopfinterne Funktion string.replace(Post["sma"], "IHMO", "") verwendet, damit ich weiterlesen konnte )

[BlackJack]

@Bong-Jour: Für Viren braucht man keinen Quelltext des Wirtsprogramms. Ein Merkmal von Viren ist ja gerade, dass sie sich in beliebige Wirtsprogramme "einnisten" können und nicht nur in spezielle, deren Quelltext der Virenprogrammierer kennen müsste.

Was Trojaner und ähnliches angeht: Bei offengelegtem Quelltext kann man so etwas einbauen, ja, aber man hat auch die Chance so etwas zu finden! Weisst Du bei ClosedSource Software was die hinter Deinem Rücken so alles tut!?

Wenn man mit Kenntnis des Quelltextes eines Clients in den Server einbrechen kann, dann sollte man nicht den Quelltext des Clients verstecken, sondern bitte den Server so absichern, dass man da nicht mehr so einfach einbrechen kann. Denn auch wenn man den Quelltext des Clients nicht einsehen kann, gibt's da ja dann offensichtlich eine Sicherheitslücke.

Bei Skype wäre es interessant den Client und das Protokoll zu analysieren um a) nicht von der Firma abhängig zu sein, weil man dann eigene Clients und Server schreiben könnte, die kompatibel sind, und b) um zu schauen welche Sicherheitslücken in dem Produkt (vielleicht sogar absichtlich) enthalten sind. Das Skype so beliebt ist und in Firmen eingesetzt wird, finde ich persönlich ja ein wenig bedenklich.

Ob ein Programm in einer "Sandbox" läuft ist nicht einfach heraus zu finden, falls die Sandbox etwas taugt. Zumal man heutzutage bei solchen Erkennungsroutinen auch Gefahr läuft den Dienst in Virtualisierungsumgebungen zu verweigern, weil man fälschlicherweise annimmt die Umgebung wird aus "böser" Absicht "emuliert".

Mit den mehreren Stellen war gemeint, so eine Überprüfung nicht an einem zentralen Punkt im Programm zu machen, sondern über das Programm zu verteilen. Weil man eine zentrale Stelle als Angreifer einfacher isolieren und deaktivieren kann.

Das Microsoft den Quelltext des Internet Explorers offenlegen soll, wäre mir neu. Jedenfalls nicht der Allgemeinheit. Es geht da auch nicht ums dekompilieren, sondern das Microsoft vor Gericht behauptet hat, es sei nicht möglich Windows ohne den IE auszuliefern, weil der zu sehr integraler Bestandteil des Betriebssystems sei. Und *diese* Behauptung sollten sie halt beweisen, zum Beispiel durch Herausgabe des Quelltextes an einen vom Gericht und den beiden Streitparteien anerkannten Experten.

IMHO = In My Humble Opionen

[snafu]

Was macht Microsoft eigentlich zum Schutz des Internet Explorers.. ?

Tja, das frag ich mich auch... *SCNR*

IMHO heißt soviel wie "Meiner Meinung nach". Im Zweifelsfall gibt es z.B. eine Wikipedia-Seite für solche Abkürzungen.

[Leonidas]

@veers: Mein technisches Verständnis reicht nicht aus für das Verstehen dieses Dokumentes ^^ Aber welchen Sinn sollte es haben den Skype-Client zu decompilieren ?

BlackJack hat schon einige Gründe angesprochen. Daneben gibt es aber auch die Möglichkeit Botnetze aufzubauen oder Firmenkommunikation abzuhören.

Was macht Microsoft eigentlich zum Schutz des Internet Explorers.. ? Es gibt doch seit Jahren den Rechtsstreit, dass Microsoft die Queltexte offenlegen soll. Anscheinend hat man hier deutliche Probleme mit der Dekompilation.

Erstens geht es nicht um die Offenlegung und zweitens selbst wenn man den Quelltext in sagen wir mal C++ dekompilieren könnte (ich gehe aus dass er in C++ geschrieben ist), dann dieser Quellcode dennoch illegal wäre, da man keine Rechte am Quelltext hat. Das ist eben auch der Unterschied zwischen Open Source und Freier Software. Nicht immer reicht es in den Code reinschauen zu können.

[problembär]

Hallo,

leider läuft diese Diskussion immer wieder falsch. Jedesmal wird gesagt:

1. Man kann Code nicht schützen, auch nicht durch Kompilieren.
2. Man soll Code nicht schützen.

Wenn man 2. folgt, kann man sein Urheberrecht aber praktisch kaum durchsetzen. Das heißt dann, man kann keine kommerziellen Programme zum Verkauf entwickeln. Das kann es ja irgendwie nicht sein.

Das Bedürfnis im professionellen Bereich, Programme zu schützen, ist recht groß. Deshalb sind kompilierte Sprachen wie C/C++ und Java auch so beliebt.
Denn auch oben 1. stimmt nicht: Der Output von C-Decompilern ist nur selten brauchbar. Oft kann der ausgegebene Code nicht wieder so kompiliert werden, daß er wieder läuft. Es wird auch in keiner Weise der Code so ausgegeben, wie er ursprünglich geschrieben wurde. Die C-Konstrukte des Decompiler-Outputs sind für Menschen kaum, d.h. praktisch gar nicht zu verstehen, schon gar nicht bei größeren Programmen.
Das ist auch der Grund, warum der Source-Code von MS Windows immer noch ein Geschäftsgeheimnis ist und eben nicht offenliegt.

Die einfachste Möglichkeit bei Python ist derzeit wohl die Weitergabe von pyc-Dateien. Diese laufen aber nur mit der Interpreter-Version, mit der sie erzeugt wurden. Außerdem ist hier Decompylen viel erfolgversprechender als bei C.

Mein Fazit ist jedenfalls: Es gibt für kommerzielle Entwickler ein Bedürfnis, Python-Code zu schützen. Es wäre auch möglich, eine Gelegenheit dafür zu schaffen, z.B. könnte vielleicht der Interpreter direkt verschlüsselten, aber lauffähigen Code ausgeben. (Vielleicht wird es mit Parrot gehen.) Derzeit bietet Python aber wenig Möglichkeiten zum Code-Schutz, deutlich weniger als andere Sprachen (einschließlich Perl). Ich betrachte das als verbesserungsbedürftig.

Gruß

[Hyperion]

Was genau ist denn der professionelle Bereich? Das ganze ist doch ein extrem heterogenes Gebilde. Natürlich kann ein 1-Mann Unternehmen seine Rechte schlechter durchsetzen, als eine Milliarden schwere Softwarefirma.

Letztere bieten oftmals eher komplexe und Spezialsoftware an - welcher Privatmann kauft sich schon eine PDM-Software, um mal ein Beispiel zu nennen! Daher setzen sie vor allem auf Gewinn durch Support und Wartung.

Für kleinere Softwareentwickler mag es durchaus ein Problem sein, seine Rechte an einer Software durchzusetzen - aber wird das denn wirklich imanent besser durch halbgare Ansätze wie hier diskutiert? Wer wirklich eine z.B. Serverabfrage verhindern will, der bekommt es auch hin.

Wer unbedingt dieses Tool benötigt, speziell für seine eigene erwerbliche Arbeit, der wird doch gerne dafür bezahlen, speziell wenn er dann Support und Wartung uvm erhält.

Wer das nicht tut und die Software lieber illegal nutzt, der wird versuchen den Schutz zu umgehen oder eine Alternative nutzen, die kostenlos ist oder bei der ein Crack funktioniert hat.

Eine für Entwickler durchaus interessante - von mir persönlich eher negativ gesehene - Alternative mag hier das Cloud-Computing sein. Allerdings müßte man dann ggf. dem Hoster einer solchen Lösung seinen Quellcode anvertrauen ...

Ich persönlich glaube nicht, dass man durch solch einen Schutz auch nur einen Euro mehr verdient!