renee+2008-05-07 21:08:09--

perlcc ist buggy und experimental. Würde ich nicht unbedingt einsetzen...

es ist noch nicht mal mehr experimentell, sondern aus perl 5.10 schon rausgeflogen.

Inferno+2008-05-06 19:18:36--

perlcc kommt leider nicht in frage, weil es extrem buggy ist und den source code irre aufbläht.

;-)

also perlcc wäre für mich sowieso nicht in frage gekommen. ich habe nur schlechte erfahrungen damit gemacht...leider :-(

Mit B::Deparse kann man sich ja jederzeit zur Laufzeit den Quelltext einer Subroutine ausgeben lassen. Weiss nicht, ob das nach perlcc immer noch geht, aber ich vermute es mal sehr stark. B::Deparse ist zwar seiterseits auch etwas buggy und es ist auch nicht gerade einfach, damit den Quelltext eines größeren Softwareprojekts auszugeben, daher kannst Du es vielleicht schwer machen, aber nicht unmöglich.

Inferno+2008-05-06 19:18:36--

ich möchte eine sehr umfangreiche/komplexe "software" in perl/cgi schreiben. da der entwicklungsaufwand ziemlich hoch ist und es vorraussichtlich über 1 jahr dauern wird, bis eine erste funktionsfähige version fertig ist, möchte ich natürlich um jeden preis meinen source code schützen.

Mag ja alles sein, aber streich lieber das "natürlich". Nicht jeder schützt seinen Quellcode, selbst wenn er 100 Jahre daran gearbeitet hat. Das sollte eigentlich jedem klar sein, der weiß, was perl ist. Wollt ich nur mal sagen. Ich will nun aber auch keine Diskussion lostreten, ob es ethisch vertretbar ist, Source Code zu schützen ;)


Was man wohl machen koennte: Alle Variablen, Subroutinen, Pakete und Dateinamen vor der Auslieferung in zufaellige Strings umbenennen. Wenn ich so einen Quelltext vorgesetzt bekaeme, wuerde ich ihn wohl lieber komplett neu schreiben, als daran Aenderungen vorzunehmen. Damit haettest Du dann wohl erreicht, was Du moechtest.
Dann allerdings viel Spass mit der Wartung und Fehlersuche ;)

betterworld+2008-05-08 03:14:54--

Was man wohl machen koennte: Alle Variablen, Subroutinen, Pakete und Dateinamen vor der Auslieferung in zufaellige Strings umbenennen. Wenn ich so einen Quelltext vorgesetzt bekaeme, wuerde ich ihn wohl lieber komplett neu schreiben, als daran Aenderungen vorzunehmen. Damit haettest Du dann wohl erreicht, was Du moechtest.
Dann allerdings viel Spass mit der Wartung und Fehlersuche ;)

gibts, siehe dazu http://forum.de.selfhtml.org/archiv/2008/4/t169263/#m1106951, dieses relative kurze Beispiel mit verschleierten Namen zu durchschauen kann dank perltidy recht schnell gehen...

Rauszukriegen WAS ein Programm macht ist nicht schwierig, schwierig ist das WIE und WARUM!

Wenn die komplette Doku, Repository und Testumgebung fehlt, wie soll ein anderer ein Mannjahr-Projekt als sein eigenes verkaufen können, selbst wenn die Namen sinnig sind???

Das fällt mir bei meinen ältesten eigenen Projekten ja selbst schwer... ;-(

Die Frage ist eher wie man schöpferische Ideen vor Nachahmern schützt, und da hilft keine Obfuscation und Verschlüsselung, man erinnere sich nur an Billy the Gates...

Und zum Thema verschlüsseltes PHP... offensichtlich sind PHPler einfach nur leichter zu beindrucken als Perler
http://forum.de.selfhtml.org/archiv/2008/3/t168045/#m1097121

KurtZ+2008-05-08 14:03:43--

betterworld+2008-05-08 03:14:54--

Was man wohl machen koennte: Alle Variablen, Subroutinen, Pakete und Dateinamen vor der Auslieferung in zufaellige Strings umbenennen. Wenn ich so einen Quelltext vorgesetzt bekaeme, wuerde ich ihn wohl lieber komplett neu schreiben, als daran Aenderungen vorzunehmen. Damit haettest Du dann wohl erreicht, was Du moechtest.
Dann allerdings viel Spass mit der Wartung und Fehlersuche ;)

gibts, siehe dazu http://forum.de.selfhtml.org/archiv/2008/4/t169263/#m1106951, dieses relative kurze Beispiel mit verschleierten Namen zu durchschauen hat mich dank perltidy aber keine Minute gekostet.

perltidy kann doch nur die Formatierung korrigieren, aber nicht wieder sinnvolle Namen fuer die Variablen etc. herstellen. Bei einem paar-Zeilen-Programm braucht man das vielleicht nicht, um es schnell zu verstehen. Aber wenn Du ein größeres Programm hast, das aus 100 Dateien und ein paar MB besteht, willst Du es nicht wirklich durchlesen, wenn die Sachen alle keine richtigen Namen haben, oder? Da hilft auch kein perltidy.

betterworld+2008-05-08 14:32:40--

Bei einem paar-Zeilen-Programm braucht man das vielleicht nicht, um es schnell zu verstehen. Aber wenn Du ein größeres Programm hast, das aus 100 Dateien und ein paar MB besteht, willst Du es nicht wirklich durchlesen, wenn die Sachen alle keine richtigen Namen haben, oder? Da hilft auch kein perltidy.

Naja bei einem auf Wartbarkeit ausgelegten Projekt haben die meisten Variablen alle einen begrenzten Scope, der nicht viel größer ist als in diesem Beispiel.

... man erkennt Filehandels, Strings, Indizes ...

betterworld+2008-05-08 14:32:40--

Aber wenn Du ein größeres Programm hast, das aus 100 Dateien und ein paar MB besteht, willst Du es nicht wirklich durchlesen, wenn die Sachen alle keine richtigen Namen haben, oder? Da hilft auch kein perltidy.

Ich will's so oder so nicht durchlesen, wenn keine Doku, Konzepte und Testsuite vorliegen. Meine Aussage ist das die Verschlüsselung der Namen nicht den entscheidenden Mehrwert bringen.

Und wenn eine der mir bekannten Scriptsprache gute Chancen hat absichtlich unlesbar codiert zu werden, dann ist es Perl + TIMTOWTDI + Magie. Da reicht es IMHO die Kommentare zu löschen...

KurtZ+2008-05-08 14:51:40--

Und wenn eine der mir bekannten Scriptsprache gute Chancen hat absichtlich unlesbar codiert zu werden, dann ist es Perl + TIMTOWTDI + Magie. Da reicht es IMHO die Kommentare zu löschen...

da muss ich dir rechtgeben. perl ist von grund auf kein hübsches kind...wenn man dann noch für grobe verwirrung sorgt könnte das vielleicht sogar ausreichen. falls jemand doch extrem hartnäckig sein sollte um irgendetwas mit dem code anzustellen, kann man es eben nicht ändern. es gibt im prinzip keinen sicheren code...sogar C++ lässt sich decompilieren, wenn man anschließend lust und laune hat sich mit assembler rumzuschlagen. ab diesem punkt werden es aber dann 99% der leute sein lassen ;-)

was zu hoffen bleibt, dass Perl programmierer die ehrlicheren und reiferen menschen sind (im gegensatz zu PHP).

wenn wir einmal beim thema sind...kennt sich bereits jemand mit guten Perl obfuscators aus? würde mich mal interessieren womit ihr vielleicht schon gute erfahrungen gemacht habt :-)

KurtZ+2008-05-08 14:51:40--

Naja bei einem auf Wartbarkeit ausgelegten Projekt haben die meisten Variablen alle einen begrenzten Scope, der nicht viel größer ist als in diesem Beispiel.

... man erkennt Filehandels, Strings, Indizes ...

Ne kleine Fundsache zum Thema "lesbare" Variablennamen zurückgewinnen: B::Deobfuscate

wenn es um webserver geht, dann vielleicht ein paar wesentliche komponenten auf deinem webserver betreiben lassen und die per RPC (vermutlich XML oder AJAX) einbetten?

dann brauchst du wenigstens nicht den vollen code rausgehen, musst aber im Gegenzug für hohe Verfügbarkeit des Servers sorgen...

Strat+2008-05-16 15:34:43--

wenn es um webserver geht, dann vielleicht ein paar wesentliche komponenten auf deinem webserver betreiben lassen und die per RPC (vermutlich XML oder AJAX) einbetten?

dann brauchst du wenigstens nicht den vollen code rausgehen, musst aber im Gegenzug für hohe Verfügbarkeit des Servers sorgen...

das ist schon alles richtig, aber eine serverseitige bereitstellung von irgendwelchen komponenten meinerseits ist undenkbar. die kunden verwalten mit dem script eventuell seiten die im bereich von 1k-500k besucher täglich liegen. weder die enormen traffic-kosten noch die dann erforderliche 100%ige verfügbarkeit meines servers lassen sich realisieren.