[quote=vayu,05.07.2007, 10:56]der bedarfte wird aber einfach aus .exe ein .zip machen und diese zip datei entpacken ^^

zumindest geht das wenn man PAR benutzt. kA was perl2exe mit nem perlscript macht :)[/quote]
Der normale User muss erstmal wissen, dass es ein Perl-Prorgramm ist was dahinter steht. Dann muss er auf die Idee kommen, dass es mit PAR gepackt ist und wissen, dass PAR im Prinzip nur gepackte Dateien macht. Deswegen habe ich auch unbedarfte User gesagt...

So 100%ig kann man seinen Perl-Code nicht verstecken. Dann muss man C/C++ schreiben ;)\n\n

<!--EDIT|renee|1183627723-->

[quote=renee,05.07.2007, 11:27]....
So 100%ig kann man seinen Perl-Code nicht verstecken. Dann muss man C/C++ schreiben ;)[/quote]
und selbst da gibt es möglichkeiten ... :)

Du kannst das Script durch perlcc in Perl's Bytecode umwandeln, hier ein Beispiel

der Bytecode laesst sich dann ganz normal mit perl ausfuehren

Der Vorteil gegenueber einer .exe-Datei ist, dass der Bytecode weiterhin plattform-unabhaengig, vorallem wesentlich kleiner und schneller geladen ist.
Ein relativ alter Artikel ("Neues vom Perl-Compiler" von Michael Schilli) aus der iX beschreibt das Ganze.

perlcc ist buggy. Aus perlcc:

Quote

The code generated in this way is not guaranteed to work. The whole codegen suite (perlcc included) should be considered very experimental. Use for production purposes is strongly discouraged.

Außerdem ist perlcc aus blead verschwunden, d.h. perl 5.10 wird auch nicht mehr mti perlcc kommen. Eben weil es ziemlich buggy ist.

[quote=vayu,05.07.2007, 11:33][quote=renee,05.07.2007, 11:27]....
So 100%ig kann man seinen Perl-Code nicht verstecken. Dann muss man C/C++ schreiben ;)[/quote]
und selbst da gibt es möglichkeiten ... :)[/quote]
Das würde ich beides so nicht sagen.

Das Kompilieren in ein Binärprogramm ist niemals eine eindeutig umkehrbare Operation (das gilt auch für die Transformation von Perlquellcode in Parsebäume und die Anwendung von Deparse). Die eigentliche Schwierigkeit beim Dekompilieren ist nun aber nicht, das Kompilat in irgendeine gültige Quellcoderepräsentation zu transformieren, sondern vielmehr, eine Repräsentation zu erstellen, die leicht verständlich ist, bzw. einen meschlichen Leser den ursprünglichen Sinn des Programmes erkennen lässt!

In der Tat ist es wegen Laufzeittypinformationen, symbolischer Namen und enger an die Quellsprache angepasster Befehlssätze oft einfacher, Binärprogramme für virtuelle Maschinen verständlich in die Ausgangssprache zurück zu übersetzen. Das verdeutlicht aber nur die Richtigkeit der Annahme, dass es neben einer kanonischen Transformation der Befehlssequenzen auch Informationen über den Sinngehalt von Programmteilen bedarf, um lesbaren Quellcode zurückzuerhalten.

Damit folgt aber unmittelbar, dass man in jeder Sprache schlecht dekompilierbaren Code erstellen kann, indem man sich an einige einfache Regeln hält:

* Symbolische Namen sollten wenn möglich vermieden werden. Wo immer sie zwingend notwendig sind, sollte man sie völlig zufällig generieren.

* Klassen und Strukturierte Typen sollten nicht benutzt werden. Basisdatentypen sollten vorzugsweise so benutzt werden, dass sie nicht den eigentlichen Typ verarbeiteter Daten widerspiegeln.

* Alle Datenverarbeitungsschritte sollten in möglichst breiter Streuung über den gesamten Quelltext verteilt werden.

* Um die Analyse des Kontrollflusses zu erschweren, sind dynamisch berechnete Sprünge und dynamisch generierter Code nützlich. Besonders schön sind zufällig dynamisch ausgewählte Ausführungspfade, die mehrfach rekursiv durch eine ganze Hierarchie von zur Laufzeit generierten, unleserlich benannten Subroutinen springen, um schließlich doch ein verwendbares Endergebnis zu liefern.

* Zu guter letzt, sollte der Code niemals irgendein extern verwendbares Interface bereitstellen, damit jeder, der ihn wiederverwenden möchte, auch wirklich gezwungen ist, ihn komplett zu verstehen.

Kurzum: Misachte sämtliche Grundsätze sauberer Programmierung, ja verkehre sie komplett ins Gegenteil und niemand wird deinen Code lesen und weiterverwenden können (zumindest aber nicht wollen). Durch die Steigerung der Komplexität wird das Dekompilieren schlichtweg ineffektiv, denn nach der Dekompilation ist das Programm genauso unverständlich wie zuvor.

Natürlich könnte man die Transformation eines "ordentlichen" Programmes in ein solch übles Konstrukt auch automatisieren. Um wirklich effektiv zu sein, sollte der Transformationscode aber cleverer oder zumindest ausdauernder als ein möglicher Dekompilierer sein. Auf jeden Fall darf die Transformation nicht nur das Aussehen des Quellcodes entstellen, sie muss um effektiv zu sein auch seine Funktion so modifizieren, dass zwar das gleiche Resultat erreicht wird, das aber auf verschlungenen Pfaden.

Wer jetzt sagt, ich würde übertreiben, der kann sich ja gerne mal den Binärcode gewisser kommerzieller Software zu Gemüte führen -- ein populäres VoIP-Programm für Windows ist ein schönes Beispiel -- und wird feststellen, dass solche Techniken tatsächlich eingesetzt werden.

Ich bin aber der Meinung, dass solche Strategien weder der Programmstabilität noch dem Vertrauen der Benutzer in die korrekte Funktion der Software zuträglich sind.

[quote=murphy,05.07.2007, 17:22]Kurzum: Misachte sämtliche Grundsätze sauberer Programmierung, ja verkehre sie komplett ins Gegenteil und niemand wird deinen Code lesen und weiterverwenden können (zumindest aber nicht wollen).[/quote]
Auch der Programmierer selbst nicht ;)

Da das Thema doch immer wieder aufkommt, habe ich mal einen Artikel angefangen...

Ich hätte aber noch eine etwas besser umsetzbare Variante meiner Lösungsidee für das Ausliefern nicht lesbarer Perlquellen anzubieten:

Man kann ja sehr leicht mit der Perl-Embedding-API seinen eigenen "Perlinterpreter-Launcher" basteln. Es sollte mit moderatem Aufwand möglich sein, diesen so auszugestalten, dass er verschlüsselten Quellcode einlesen kann und einfache Versuche auf den internen Parsetree zuzugreifen blockiert.

Wenn man sich da etwas spielt, auf den PerlIO-Layer aufsetzt um den Code zu lesen, den entschlüsselten Quelltext nicht komplett im Speicher herumliegen lässt und vielleicht noch ein paar hässliche kleine Tricks wie unsortierte Datenströme, alternative, zufällig auswählbare Blöcke und größere Mengen Zufallsdaten als Padding einbaut sowie einen durch rohe Gewalt kaum zu knackenden Verschlüsselungsalgorithmus verwendet, dann ist es zwar immer noch möglich, mit einem guten C-Debugger und ein paar Kunstgriffen an den Quellcode zu kommen, denn der Schlüssel und der Algorithmus dazu müssen ja direkt im Ladeprogramm stecken, aber es sollte für die meisten Anwender wirklich abschreckend kompliziert sein.

Man hat halt den Vorteil, dass man nur das Ladeprogramm richtig schön nach den oben genannten Regeln vermurksen und gegen Debugger absichern muss, der Perlinterpreter und der eigentliche Code davon aber nicht betroffen sind.

Wieviel Mühe man sich geben muss, um Sicherheit zu erreichen, hängt aber natürlich auch davon ab, wen man als Gegner sieht. Der Durchschnittsanwender macht sich vielleicht nicht einmal die Mühe, ein PAR-Archiv zu entpacken, der durchschnittliche Perlprogrammierer schreckt vielleicht vor einem hässlich zu debuggenden C-Programm zurück, das den Code filtert. Aber wenn es jemand wirklich darauf abgesehen hat, deinen Code zu bekommen, dann hilft es eigentlich nur noch so zu programmieren, dass man beim ersten Blick auf den Code sofort einen Knoten ins Hirn bekommt. Die Obfuscation ist nur dann richtig gut, wenn man zum Verstehen der Funktionsweise des Programmes signifikant länger braucht als zur Neuentwicklung des gesamten Codes ;-)