Verschlüsselung von Perl Scripten

[bchris]

Kennt jemand eine Möglichkeit Perl Scripte zu verschlüsseln so wie bei PHP SourceCop für den Fall das per Zufall doch jemand z.B.per FTP Datendiebstahl begehen sollte?

Die einzigste Möglichkeit was ich im Internet gefunden habe war Perlguardian, doch diese Firma ist nicht mehr im WEB verfügbar.

Kennt jemand noch so einen Hersteller?

[steckl]

Hi,

Kennt jemand eine Möglichkeit Perl Scripte zu verschlüsseln so wie bei PHP SourceCop für den Fall das per Zufall doch jemand z.B.per FTP Datendiebstahl begehen sollte?

Es gibt Programme die Perl compilieren und eine exe-Datei daraus machen. Ich hab das jedoch noch nie selber ausprobiert und weiß auch nicht sicher, ob man den erzeugten Code dann wieder decompilieren kann. Aber wenn das geht ist es wohl mit viel Aufwand verbunden.

Solche Compiler findest du z.B. mit einer Google-Suche nach perl2exe.

Ausserdem gibt es noch ein Perl-Modul, das verspricht (hab auch keine Erfahrung damit) Code zu verschlüsseln: Filter::decrypt (Doku dazu)

mfG,
steckl

[Mega]

man perlcc

[Patrick Andrieu]

Hallo Mega!

man perlcc

Tolle Antwort... Beherzige bitte folgenden Link:

Tipps für Antwortende

Viele Grüße aus Frankfurt/Main,
Patrick

[Alexander (HH)]

Moin Moin!

Verschlüsseln des Quelltextes bringt nichs. Spätestens, wenn der Computer das Script ausführen soll, braucht er den Entschlüsselungsalgorithmus und ggf. den passenden Key. Beides kann ein Angreifer absammeln.

Perl-FAQ Teil 3: How can I hide the source for my Perl program?

Du kannst es einem potenziellen Dieb vielleicht etwas schwerer machen, aber wer an Deinen Code ran will, wird rankommen. Auch compilieren hilft nichts, es gibt brauchbare Compiler für Flash, C++, C, VB und so ziemlich alle anderen gängigen Sprachen, den Rest analysiert man per Disassembler oder Debugger. Perl bringt übrigens gleich "ab Werk" ein passendes Tool mit. Egal wie gut Deine Verschlüsselung ist, und selbst wenn es der Top-Secret-Next-Next-Generation-Verschlüsseler der NSA ist, wird B::Deparse wieder brauchbaren Code ausspucken -- denn wie gesagt müssen Entschlüsselungsroutine und Schlüssel mitgeliefert werden.

Alexander

[Patrick Andrieu]

Hallo Alexander!

Ich nutze die Gelegenheit, um keinen Extra-Thread zu öffnen, dem der miese Geruch irgendwelcher Werbung anhaften könnte, hiermit mitzuteilen, dass 1&1 auf Perl 5.8.8 updatet (nebst Python 2.5 und was weiß ich noch), und dass wir also bald wieder Tainted Love spielen können ;)

Genauer gesagt für meine Domains ab 6.3. ... ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Alexander (HH)]

Moin Moin!

[...] dass wir also bald wieder Tainted Love spielen können ;)

OK, ich bereite schonmal die Consulting-Rechnung vor ... :-þ

Perl 5.8.8 alleine wird's nicht bringen, der Wrapper-Murks, der bei 1&1 abläuft, müßte mal gründlich beseitigt werden. Ich weiß jedenfalls, dass bei meinem aktuellen Großprojekt kein 1&1-Server im Spiel sein wird. :-(

Alexander

[Patrick Andrieu]

Hallo Alexander!

Perl 5.8.8 alleine wird's nicht bringen, der Wrapper-Murks, der bei 1&1 abläuft, müßte mal gründlich beseitigt werden. Ich weiß jedenfalls, dass bei meinem aktuellen Großprojekt kein 1&1-Server im Spiel sein wird. :-(

Eigentlich bin ich alles andere als erfreut (never change a running system even if it's murks...) Mir graut's davor, da die »uns« (die Kunden) komplett umziehen (von irgendeiner Debian zu Debian Elch noch was), dass ich mich wieder auf die Suche nach evtl. anderslautenden Umgebungsvariablen machen muss, womit ich bei jeder anderen Umgebung die meisten Probleme habe...

Consulting Rechung...

Hm, kann ich das mit verrechnen mit Bordeaux-Wein? ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hallo Alexander!

Perl 5.8.8 alleine wird's nicht bringen, der Wrapper-Murks, der bei 1&1 abläuft, müßte mal gründlich beseitigt werden.

Woher wußtest Du, dass sie den Murks beibehalten würden? ;) Du hast recht, es wirft immer noch einen 500er mit der Endung .pl. Einziger Unterschied beim als .cgi gespeicherten Skript: ${^TAINT} ist nicht mehr undef, sondern 1. Das ist wohl das Einzige, was das Update zu Perl 5.8.8 gebracht hat ;)

Ich weiß jedenfalls, dass bei meinem aktuellen Großprojekt kein 1&1-Server im Spiel sein wird. :-(

Ach naja, am besten wäre, seinen eigenen Server laufen zu lassen. Bei all inkl (zumindest bei dem Paket, bei welchem ich schnüffeldürfeweise einen Zugang bekam), bekommt man noch nicht mal die aktuelle access_log zu sehen. Erst am Tag danach gibt es die Vortag-Log als .gz-Datei. Schlecht für die, die wie ich gerne gleich wissen, wer auf den Seiten gerade was sucht ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Alexander (HH)]

Moin Moin!

Hallo Alexander!

Perl 5.8.8 alleine wird's nicht bringen, der Wrapper-Murks, der bei 1&1 abläuft, müßte mal gründlich beseitigt werden.

Woher wußtest Du, dass sie den Murks beibehalten würden? ;)

Langjährige Erfahrung mit diversen organisch gewachsenen Systemen. Die größten Übel sind so tief im System, dass man sie nicht entfernen kann, ohne das halbe System neu zu schreiben.

Du hast recht, es wirft immer noch einen 500er mit der Endung .pl. Einziger Unterschied beim als .cgi gespeicherten Skript: ${^TAINT} ist nicht mehr undef, sondern 1. Das ist wohl das Einzige, was das Update zu Perl 5.8.8 gebracht hat ;)

Immerhin etwas.

Ich weiß jedenfalls, dass bei meinem aktuellen Großprojekt kein 1&1-Server im Spiel sein wird. :-(

Ach naja, am besten wäre, seinen eigenen Server laufen zu lassen. Bei all inkl (zumindest bei dem Paket, bei welchem ich schnüffeldürfeweise einen Zugang bekam), bekommt man noch nicht mal die aktuelle access_log zu sehen. Erst am Tag danach gibt es die Vortag-Log als .gz-Datei. Schlecht für die, die wie ich gerne gleich wissen, wer auf den Seiten gerade was sucht ;)

So sehe ich das auch. Ich werde mir also wohl einen Hoster suchen müssen, der mir gestattet, mich in Perl und mit Apache, mod_rewrite und FastCGI auf dem Webserver gründlich auszutoben, mir aber gleichzeitig einen gut administrierten Mailserver zur Verfügung stellt, an dem ich nicht schrauben muß.

Alexander

[Patrick Andrieu]

Hallo Alexander!

mir aber gleichzeitig einen gut administrierten Mailserver zur Verfügung stellt, an dem ich nicht schrauben muß.

A propos Mailserver... seit einigen Tagen, noch vor dem hier erwähnten Umzug auf Debian Elch mit Aktualisierung serverseitiger Sprachen, hat 1&1 irgendwas am Mailserver umkonfiguriert: früher war es so, dass ich bei jedem Eintrag in einem der Gästebücher eine Mail mit dem geposteten Inhalt erhielt. Das funktioniert immer noch, allerdings nicht, wenn der Besucher eine nicht nachvollziehbare E-Mail-Adresse eingibt, was leider bei der Testversion sehr oft der Fall ist.

Dabei wird, so weit ich das sehe, lediglich der Host geprüft, so dass:

[e-mail] durchgeht, während
existiertvielleicht@aot<-TIPPFEHLER->imc-eggs.com abgelehnt wird.

Nervig ist es vor allem, weil ich bisher nur dann die GB-Seiten besucht habe, nachdem die Mails ankamen. Aber auch sonst, soll es eine Art Spamschutz sein?

In der mail.log (schöne Sache bei 1&1, hatte ich bisher noch nie) stehen dann solche Einträge:

2008-03-06 10:22:45 mein_username 4AgE5q-1JXCJJ2GiU-0008GA WW transaction error after mail command: msmtp.kundenserver.de[172.19.35.7] 421 dns lookup failed for sender domain
2008-03-06 10:22:45 mein_username 4AgE5q-1JXCJJ2GiU-0008GA EE could not send mail

Viele Grüße aus Frankfurt/Main,
Patrick

[Alexander (HH)]

Moin Moin!

Hallo Alexander!

mir aber gleichzeitig einen gut administrierten Mailserver zur Verfügung stellt, an dem ich nicht schrauben muß.

A propos Mailserver... seit einigen Tagen, noch vor dem hier erwähnten Umzug auf Debian Elch mit Aktualisierung serverseitiger Sprachen, hat 1&1 irgendwas am Mailserver umkonfiguriert: früher war es so, dass ich bei jedem Eintrag in einem der Gästebücher eine Mail mit dem geposteten Inhalt erhielt. Das funktioniert immer noch, allerdings nicht, wenn der Besucher eine nicht nachvollziehbare E-Mail-Adresse eingibt, was leider bei der Testversion sehr oft der Fall ist.

Dabei wird, so weit ich das sehe, lediglich der Host geprüft, so dass:

[e-mail] durchgeht, während
existiertvielleicht@aot<-TIPPFEHLER->imc-eggs.com abgelehnt wird.

Nervig ist es vor allem, weil ich bisher nur dann die GB-Seiten besucht habe, nachdem die Mails ankamen. Aber auch sonst, soll es eine Art Spamschutz sein?

Ja, aber ein Schutz davor, dass 1&1 hilft, andere vollzuspammen.

In der mail.log (schöne Sache bei 1&1, hatte ich bisher noch nie) stehen dann solche Einträge:

2008-03-06 10:22:45 mein_username 4AgE5q-1JXCJJ2GiU-0008GA WW transaction error after mail command: msmtp.kundenserver.de[172.19.35.7] 421 dns lookup failed for sender domain
2008-03-06 10:22:45 mein_username 4AgE5q-1JXCJJ2GiU-0008GA EE could not send mail

Tja, die scheinen wirklich den Absender-Host zu prüfen, und verweigern das Senden, wenn es keinen DNS-Eintrag gibt. Sinnvoll.

Nimm nicht die vom Benutzer eingegebene Adresse als Absender. Richte einen Dummy-Mail-Account ein, z.B. [e-mail], benutze den als Absender (From), und wenn Du die eingegebene Adresse irgendwie verwerten willst, trage die als Reply-To ein. Den Absender-Account konfigurierst Du wahlweise auf Weiterleitung oder Annahme verweigern.

Alexander

[Patrick Andrieu]

Hallo Alexander!

Aber auch sonst, soll es eine Art Spamschutz sein?
Ja, aber ein Schutz davor, dass 1&1 hilft, andere vollzuspammen.

Diese Antwort verstehe ich nicht, wie meinen?

dns lookup failed for sender domain
Tja, die scheinen wirklich den Absender-Host zu prüfen, und verweigern das Senden, wenn es keinen DNS-Eintrag gibt. Sinnvoll.

Dachte ich auch schon. Schutzmechanismen seitens eines Providers sind eigentlich eher selten ;)

Nimm nicht die vom Benutzer eingegebene Adresse als Absender. Richte einen Dummy-Mail-Account ein, z.B. [e-mail], benutze den als Absender (From), und wenn Du die eingegebene Adresse irgendwie verwerten willst, trage die als Reply-To ein. Den Absender-Account konfigurierst Du wahlweise auf Weiterleitung oder Annahme verweigern.

Ah ok, Danke. Unter »Reply-to« hatte ich schon die GB-Benutzer-E-Mail (wenn angegeben, ist bei mir nicht Pflicht), nun habe ich unter From:

From: $paramName ($MyEmail)

wobei $paramName der Name des Besuchers, $MyEmail die von GB-Account, wo die vom GB gesendete Mails ja hingehen. Das geht durch, auch wenn in der »mail.log« - welche die einzige Logdatei, die bei 1&1 nicht sofort aktualisiert wird, sondern anscheinend nur ein Mal am Tag, so dass ich es erst morgen werde sehen können - sicher so was stehen wird wie:

invalid sender address: " Tester ([e-mail])"

Aber damit kann ich leben _und_ habe den Namen in der »von«-Zeile. Nur der Formmailer von SourceForge liefert seit dieser Umkonfigurierung eine Fehlermeldung, aber da bin ich angewiesen auf eine gültige - oder eben gar keine - E-Mail-Adresse, da passe ich die Fehlermeldung eben entsprechend ab, so dass der Absender sieht, was schief gelaufen ist. Bisher ist es auch schon so, dass wer mir über's Kontaktformular schreibt dies auch ohne Angabe einer E-Mail-Adresse tun kann, nur dann allerdings auf der Bestätigungsseite mit dem Hinweis, dass eine elektronische Beantwortung nicht möglich ist ;)

Die Freiwilligkeit der Angabe der E-Mail-Adresse will ich beibehalten.

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Fehlerfeuerwehr!

From: $paramName ($MyEmail)
invalid sender address: " Tester ([e-mail])"

Muss heißen:

invalid sender address: " Tester ([e-mail])"

$MyEmail existiert ja, ist doch meine ;) Das 1&1-Programm wird sich an die Klammer stören, naja, morgen weiß ich mehr!

Viele Grüße aus Frankfurt/Main,
Patrick

[Daniel Thoma]

Hallo Alexander,

Es bringt natürlich nichts, wenn man die Ausführung der Software verhindern will. Wenn man die Widerverwendung des Quelltextes verhindern will, bringt es durchaus etwas.
Ein größeres Stück Code mit zufällig benannten Variablen/Methoden, keinerlei Dokumentation und evtl. auch noch unübersichtlichem Kontrollfluss (weil die Jumps die der Compiler so generiert hatte evtl nicht genau so und nicht genau so verständlich zurück in Code übersetzt werden), ist für Wiederverwendung schon ziemlich unbrauchbar.
Meistens geht es ja nicht darum, irgend welche geheimen Algorithmen herauszufinden (das würde man natürlich schaffen mit entsprechendem Aufwand), sondern die eigenen Entwicklungskosten zu senken.
Wenn man aber eine disassemblierte Software warten muss, hat man dadurch wahrscheinlich höheren Aufwand, als etwas selbst zu entwickeln, vor allen Dingen, wenn es sich dabei um eine durchschnittliche Webanwendung handelt.

Ich halte nicht viel von solcher Sourcecode-"Verschlüsselung". Schon allein das entfernen von Kommentaren und andere Dokumentation dürfte eine Weiterverwendung schnell unrentabel machen und das Urheberrecht hat man dann ja auch noch. Aber so absolut formulieren, wie Du das tust, kann man das meines Erachtens nicht.

Grüße

Daniel