Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]11764[/thread]

Perl source code schützen?

Leser: 2


<< |< 1 2 3 >| >> 22 Einträge, 3 Seiten
Inferno
 2008-05-06 21:18
#109300 #109300
User since
2007-06-29
19 Artikel
BenutzerIn
[default_avatar]
hallo!

möglicherweise ist dieses thema schon ziemlich abgedroschen, aber ich suche eine lösung für mein problem:

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. die software soll schließlich auch an den kunden verkauft werden.

der kunde wird das script auf seinem server einsetzen um den >kompletten< traffic seiner webseite(n) zu managen. dabei greift das script auf eine datenbank zu, in der eine vielzahl von seiten gespeichert sind, zu denen der kunde besucher schicken möchte, wenn bestimmte links/banner/bilder auf seiner website angeklickt werden. unter welchen umständen, wann/wie/wohin besucher nach einem klick geschickt werden hängt von einer vielzahl von faktoren ab. kurz gesagt es handelt sich um ein link exchange script, mit einer sehr hohen anzahl an extra features (gewissermaßen "künstliche intelligenz").

meine wahl für das projekt fiel auf Perl, da ich dort die meiste erfahrung habe und gegen php sowieso eine gewisse persönliche abneigung hege. das problem ist nur, dass es für php eine vielzahl an tools gibt um den source code relativ sicher zu machen. bei perl sieht das anders aus...
ich glaube nicht das ein perl obfuscator eine sicherheit darstellt. deshalb habe ich auch schon überlegt das ganze in C++ oder Java (native) zu implementieren. damit würde die entwicklungszeit allerdings nochmal um einiges länger sein. perlcc kommt leider nicht in frage, weil es extrem buggy ist und den source code irre aufbläht.

ich würde mich freuen, wenn mir jemand sagen könnte ob es eine chance gibt, den perl source code so zu schützen, dass der kunde ihn nicht manipulieren kann...oder im schlimmsten fall das produkt unter anderem namen weitervertreibt.

vielen dank schonmal im vorraus für konstruktive ideen :-)
moritz
 2008-05-06 21:29
#109301 #109301
User since
2007-05-11
923 Artikel
HausmeisterIn
[Homepage]
user image
Du kannst den Perl-Code nicht zuverlässig schützen. Das gleiche gilt übrigens für Java (hast du dir mal einen disassemblierten Bytecode angeschaut? IMHO ist der noch ziemlich gut lesbar).

Letztendlich ist Quellcode-Klau vor allem ein rechtliches Problem. Du kannst nur sinnvoll mit jemandem Geschäfte machen, gegen den du deine Ansprüche durchsetzen kannst - das ist mit Urheberrechten nicht anders als mit finanziellen Forderungen.
lichtkind
 2008-05-06 23:58
#109303 #109303
User since
2004-03-22
5697 Artikel
ModeratorIn + EditorIn
[Homepage]
user image
perltidy kenn einige optionen mit denen der code sehr kompakt wird :)


diverse B::* und Devel::* module können auch helfen aber moritz hat schon recht, vertrauen ist basis von allem.
Wiki:Tutorien in der Wiki, mein zeug:
kephra, baumhaus, garten, gezwitscher

Es beginnt immer mit einer Entscheidung.
Inferno
 2008-05-07 02:34
#109317 #109317
User since
2007-06-29
19 Artikel
BenutzerIn
[default_avatar]
moritz+2008-05-06 19:29:57--
Das gleiche gilt übrigens für Java (hast du dir mal einen disassemblierten Bytecode angeschaut? IMHO ist der noch ziemlich gut lesbar).


ok, ich dachte wenn ich schreibe "Java (Native)" weiß jeder was ich meine :-). natürlich ist der bytecode vom java compiler vollständig decompilierbar. deshalb würde ich ja auch einen native (maschinencode) compiler nehmen, wie z.b. GCJ, denn dann ist der java code so sicher wie compilierter C++ code. wäre sowieso ne zumutung dem kunde noch die JVM aufzudrücken...ganz zu schweigen von der miesen perfomance, die damit einhergeht.

ich habe schon befürchtet, dass solche antworten kommen. der code kann ja nicht verschlüsselt werden oder ähnlich, weil dann der perl parser nicht mehr klar kommt.

vertrauen ist hier ebenfalls eine schwierige sache. das script soll international angeboten werden (auf einer website). international lassen sich im prinzip kaum rechtliche forderungen durchsetzen. möglich ist es wohl, aber kaum für den privatmann. die bemühungen einen russen oder südamerikaner wegen nichteinhaltung des copyright zu verklagen, dürften allerhöchstens lächerlich sein.

wer noch ideen hat, kann sie gerne nennen :-)
KurtZ
 2008-05-07 05:34
#109320 #109320
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
dein Bestreben müsste sein, den Aufwand deinen Code zu entschlüsseln höher zu machen als den Aufwand die Ideen neuzuimplementieren. IMHO reicht per Perl meist schon die kompette Doku/Kommentare rauszuschmeißen und Namen zu verfremden um es unwartbar zu machen udn wer bringt schon ein unwartbares Produkt auf den Markt?

Ansonsten könntest du einige zentrale aber einfache Module nachträglich in C Implementieren, ...

Eine allgemeine Lösung für reines Perl kann es prinzipiell aber nicht geben, weil dann sofort jemand einen allgemeinen Gegenhack entwickeln würde.

Das PHP das Problem besser gelöst bekommen soll wundert mich, wäre für Infos zum "Wieso" dankbar.

Am ehesten könnte ich mir laut hörensagen eine compilierung zu native Code bei Python vorstellen.

Ich erinnere mich, dass M$ mal ein eingebautes encrypting für VB-Script propagierte, was aber ziemlich billig zu knacken war (BTW: per Perl-Script)
TMTOWTDYOG (there's more than one way to dig your own grave)
sid burn
 2008-05-07 14:00
#109347 #109347
User since
2006-03-29
1520 Artikel
BenutzerIn

user image
Quote
ich würde mich freuen, wenn mir jemand sagen könnte ob es eine chance gibt, den perl source code so zu schützen, dass der kunde ihn nicht manipulieren kann...oder im schlimmsten fall das produkt unter anderem namen weitervertreibt.


Wenn du keine OSS Lizenz nimmst dann darf er das nicht. Tut er es doch kannst du ihn verklagen. Das ist der einzige Schutz. Ob der Sourcecode nun letztendlich mitgelifert wird, oder nicht spielt wenig eine Rolle. Die Uhrheberrechte liegen trotzdem bei dir.

Und das etwas nicht manipuliert wird kannst du auch nicht mit einer Binary sicherstellen die du aus C++ code erzeugt hast.

Ich würde deswegen keine Zeit in sowas investieren... Mach/Nimm ene Lizenz und fertig. Das ist sowieso der einzige Schutz in diesem Sinne.
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
Inferno
 2008-05-07 16:51
#109391 #109391
User since
2007-06-29
19 Artikel
BenutzerIn
[default_avatar]
danke für die guten tipps :-). ich hätte vielleicht noch sagen sollen, dass es von dem produkt eine art FREE oder TRIAL version geben soll. mehr oder weniger soll die fast den gleichen funktionsumfang haben wie die vollversion, allerdings wird 1% des traffic vom kunden abgezweigt (traffic der mit dem script verwaltet wird).
ein fairer kunde weiß, dass dies ein sehr fairer deal ist, wenn er im prinzip eine vollversion nutzen kann und nur 1% seines traffic (also im prinzip 1 von 100 besuchern) abgezweigt/weitergeleitet wird. es gibt aber durchaus auch leute, die dann versuchen den source code zu manipulieren, damit sie überhaupt nichts zahlen müssen, obwohl sie mit dem script geld verdienen.

sowas möchte ich eben unterbinden, denn warum sollte ich mit wahnsinns aufwand eine software produzieren, wenn ich dafür nicht einen lausigen cent gewinn sehe. eine lizenz scheint mir hier eben nur eine moralische lösung zu sein. wie sollte man so eine softwarelizenz als privatmann weltweit durchsetzen (südamerika, russland, asien, usw...)? da hat man doch gar keine chance wenn jemand etwas verbotenes tut.

das sich C++ oder anderes auch decompilieren lässt ist mir klar, aber der aufwand den entstanden assembler code wieder verwertbar zu machen ist keinesfalls unerheblich und sicher auch extrem zeitraubend.

KurtZ+2008-05-07 03:34:07--
Das PHP das Problem besser gelöst bekommen soll wundert mich, wäre für Infos zum "Wieso" dankbar.


nunja, für php gibt es eine vielzahl and produkten wie zend, sourceguardian usw. mit denen man den code "weitgehend" sicher machen kann. aber auch das hat den nachteil, dass der php interpreter nicht mehr damit klar kommt und extra module "vorgeschalten" werden müssen. diese übersetzen dann den code wieder in für den interpreter verständlichen code. der kunde hat damit natürlich das problem, dass er diese programme/module auf seinem server installieren muss damit das script läuft. ok zend ist kein wirklicher schutz (falls das jetzt jemand sagen möchte), aber bietet dennoch genug schutz, damit der code nicht von laien oder fortgeschrittenen manipuliert werden kann. source guardian verschlüsselt sogar irgendwie den code...die meinen sogar reverse engineering wäre da nicht möglich (was ich nicht glaube). für perl sind mir solche programme auf anhieb jetzt leider nicht bekannt.
KurtZ
 2008-05-07 20:50
#109413 #109413
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
Inferno+2008-05-07 14:51:11--
KurtZ+2008-05-07 03:34:07--
Das PHP das Problem besser gelöst bekommen soll wundert mich, wäre für Infos zum "Wieso" dankbar.

nunja, für php gibt es eine vielzahl and produkten wie zend, sourceguardian usw. mit denen man den code "weitgehend" sicher machen kann.


Du das beantwortet das Wie aber nicht das Wieso! Die gleichen Prinzipien sollten IMHO auf Perl anwendbar sein und umgekehrt die gleichen Einschränkungen auch für PHP gelten.
TMTOWTDYOG (there's more than one way to dig your own grave)
topeg
 2008-05-07 22:52
#109417 #109417
User since
2006-07-10
2611 Artikel
BenutzerIn

user image
Wie wäre es mit perlcc? Mit "perlcc -B" wird der Bytecode ausgegeben.
renee
 2008-05-07 23:08
#109418 #109418
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
perlcc ist buggy und experimental. Würde ich nicht unbedingt einsetzen...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
<< |< 1 2 3 >| >> 22 Einträge, 3 Seiten



View all threads created 2008-05-06 21:18.