Gibt es einen guten Obfuscater für Perl-Code?

Question

Kennt jemand einen guten Code Obsfucator für Perl? Ich werde gebeten, die Möglichkeit zu prüfen, Code zu verschleiern, bevor ich ihn an einen Client weiterleite. Ich weiß, dass obszierter Code immer noch reverse engineered sein kann, aber das ist nicht unser Hauptanliegen.

Einige Kunden machen kleine Änderungen am Quellcode, den wir ihnen geben, und es gibt uns Alpträume, wenn etwas schief geht und wir es reparieren müssen oder wenn wir einen Patch veröffentlichen, der nicht mit dem funktioniert, was sie haben geändert. Die Absicht ist nur, es so zu machen, dass es für sie schwierig ist, ihre eigenen Änderungen am Code vorzunehmen (sie sollen das sowieso nicht tun).

Answer 1

Ich bin diesen Weg schon einmal gegangen und es ist ein absoluter Alptraum, wenn man an "verschleiertem" Code arbeiten muss, weil er die Kosten enorm hochtreibt, um ein Problem auf dem Client-Server zu debuggen, wenn Sie, der Entwickler, ' t lese den Code. Sie landen mit "Deobfuscatoren" und kopieren den "echten Code" auf den Server des Kunden oder eines von vielen anderen Problemen, die nur mühsam zu verwalten sind.

Ich verstehe, woher Sie kommen, aber es hört sich an, als hätte das Management ein Problem und sie erwarten von Ihnen, dass Sie eine gewählte Lösung implementieren, anstatt herauszufinden, was die richtige Lösung ist.

In diesem Fall klingt es wie ein Lizenz- oder Vertragsproblem. Lassen Sie den Code Open Source haben, aber machen Sie ihn zu einem Teil der Lizenz, damit alle Änderungen, die er einreicht, zu Ihnen zurückkommen und genehmigt werden müssen. Wenn Sie Patches auswerfen, überprüfen Sie die MD5-Summe des gesamten Codes, und wenn es nicht dem entspricht, was erwartet wird, sind sie in Lizenzverletzung und werden dementsprechend berechnet (und es sollte eine weit, viel höhere Rate sein). (Ich erinnere mich an eine Firma, die uns den Code als Open Source zur Verfügung stellte, machte aber klar, dass wir, wenn wir etwas änderten, den Code für $ 25.000 "gekauft" haben und nicht mehr für Bugfixes oder Upgrades verantwortlich waren, außer wir kauften ein neue Lizenz).

Answer 2

Bitte tun Sie das nicht. Wenn Sie nicht möchten, dass Benutzer Ihren Perl-Code ändern, legen Sie ihn unter eine entsprechende Lizenz und erzwingen Sie diese Lizenz. Wenn Benutzer Ihren Code ändern, wenn Sie in der Lizenz angeben, dass dies nicht der Fall sein soll, liegt das Problem nicht darin, dass Ihre Updates nicht mehr mit ihrer Installation funktionieren.

Weitere Details finden Sie unter perlfaq3's answer to "How Can I hide the source for my Perl programs?.

Answer 3

Nicht. Tu es einfach nicht.

Schreiben Sie es in den Vertrag (oder revidieren Sie den Vertrag, wenn Sie müssen), dass Sie nicht für Änderungen verantwortlich sind, die sie an der Software vornehmen. Wenn sie Ihren Code aktualisieren und dann erwarten, dass Sie ihn reparieren, haben Sie Client-Probleme, die nicht gelöst werden, indem Sie den Code verschleiern. Und wenn Sie es verschleiern und sie auf ein tatsächliches Problem stoßen, viel Glück, wenn Sie sie dazu bringen, die Zeilennummer usw. im Fehlerbericht genau zu melden.

Answer 4

Es scheint, dass Ihr Hauptproblem darin besteht, dass Clients den Code ändern, was es dann schwierig macht, sie zu unterstützen. Ich würde vorschlagen, dass Sie nach Prüfsummen (md5, sha usw.) ihrer Dateien fragen, wenn sie zu Ihnen kommen, um Unterstützung zu erhalten, und ebenso die Prüfsummen von Dateien beim Patchen überprüfen. Beispielsweise können Sie den Client bitten, die Ausgabe eines bereitgestellten Programms bereitzustellen, das alle Dateien durch die Installation und die Prüfsummen führt.

Schließlich haben sie den Code, damit sie tun können, was sie wollen. Das Beste, was Sie tun können, ist, Ihre Lizenzen durchzusetzen und sicherzustellen, dass Sie nur unmodifizierten Code unterstützen.

Answer 5

In diesem Fall ist das Verschleiern der falsche Ansatz.

Wenn Sie den Code an den Client freigeben, sollten Sie eine Kopie des Codes behalten, den Sie senden (entweder auf der Festplatte oder vorzugsweise in Ihrer Versionskontrolle als Tag/Zweig).

Wenn Ihr Kunde dann Änderungen vornimmt, können Sie den Code, den er hat, mit dem Code vergleichen, den Sie ihm gesendet haben, und die Änderungen leicht erkennen. Schließlich, wenn sie das Bedürfnis haben, Änderungen vorzunehmen, gibt es ein Problem irgendwo und Sie sollten es in der Master-Codebasis beheben.

Answer 6

Eine Alternative zur Verschleierung ist die Konvertierung Ihres Skripts in eine Binärdatei mit etwas wie ActiveState's Perl Dev Kit.

Answer 7

Dies ist kein ernstzunehmender Vorschlag, aber werfen Sie einen Blick auf Acme::Buffy.

Es wird zumindest Ihren Tag erhellen!

Answer 8

Eine weitere Alternative zur Konvertierung Ihres Programms in eine Binärdatei ist das kostenlose PAR-Packer Werkzeug unter CPAN. Es gibt sogar Filter für Code-Verschleierung, obwohl andere gesagt haben, das ist möglicherweise mehr Mühe als es wert ist.

Answer 9

Wie einige Leute schon gesagt haben: nicht.

Es ist ziemlich implizit, angesichts der Natur des Perl-Interpreters, dass alles, was Sie tun, um die Perl zu verschleiern, rückgängig gemacht werden muss, bevor Perl es in die Hände bekommt, was bedeutet, dass Sie das De-Obfuscation-Skript/Binary liegen lassen müssen herum, wo der Dolmetscher (und damit Ihr Kunde) es finden kann :)

Fix das eigentliche Problem: Prüfsummen und/oder eine entsprechend formulierte Lizenz. Und Support-Mitarbeiter geschult, um zu sagen: "Sie haben es geändert? Wir rufen Klausel 34b unserer Lizenz auf, und das wird $ X, 000 sein, bevor wir sie berühren.

Lesen Sie auch why-should-i-use-obfuscation für eine allgemeinere Antwort.

Answer 10

Ich verwende ein Windows O/S und benutze perl2exe von IndigoSTAR. Die resultierende EXE-Datei wird wahrscheinlich nicht vor Ort geändert werden.

Wie andere gesagt haben, "wie ich es verschleiern" ist die falsche Frage. "Wie halte ich den Kunden davon ab den Code zu ändern" ist der richtige.

Answer 11

Ich stimme den vorherigen Vorschlägen zu.

Wenn Sie jedoch wirklich wollen, können Sie in PAR und/oder Filter::Crypto CPAN-Module suchen. Sie können sie auch zusammen verwenden.

Ich verwendete das letztere (Filter :: Crypto) als eine wirklich leichte Form des "Schutzes", als wir unser Produkt auf optischen Medien versandten. Es "schützt" Sie nicht, aber es stoppt 90% der Personen, die Ihre Quelldateien ändern möchten.

Answer 12

Die Prüfsummen- und Vertragsideen eignen sich gut, um die von Ihnen beschriebenen "Probleme" zu vermeiden. Wenn Sie jedoch Schwierigkeiten haben, Upgrades und Fehlerbehebungen vorzunehmen, machen Ihre Kunden Änderungen, die nicht bestanden werden die umfassende Testsuite? Wenn sie in der Lage sind, diese Änderungen vorzunehmen (oder zumindest eine Änderung vorzunehmen, die zeigt, was der Code tun soll), warum sollte es ihnen nicht einfach/automatisiert sein, ein Support-Ticket zu öffnen und den Patch hochzuladen? Der Kunde hat immer Recht über was der Kunde will (sie haben vielleicht keine Ahnung, wie es "der richtige Weg", aber das ist, warum sie dich bezahlen.)

Ein besserer Grund, einen Obfuscator zu wollen, wäre für den Desktop-Einsatz auf dem Massenmarkt, wo nicht jeder Kunde einen festen Vertrag hat. In diesem Fall, etwas wie PAR - alles, was die Verschlüsselung/Verschleierung Logik in eine kompilierte Binärdatei verpackt ist der Weg zu gehen.

Answer 13

Ich würde sie einfach in meinen SVN-Baum auf ihrem eigenen Zweig einladen, damit sie Änderungen bereitstellen können und ich sie sehen und ihre Änderungen in meinen Entwicklungsbaum integrieren kann.

Bekämpfen Sie es nicht, umarmen Sie es.

Answer 14

Wie Ovid sagt, es ist ein vertragliches, soziales Problem. Wenn sie den Code ändern, wird die Garantie ungültig. Lade ihnen viel auf, um das zu beheben, aber gib ihnen gleichzeitig einen Kanal, auf dem sie Änderungen vorschlagen können. Schauen Sie sich auch an, was sie ändern wollen und machen Sie diesen Teil der Konfiguration, wenn Sie können. Sie haben etwas, was sie tun wollen, und bis Sie das befriedigen, werden sie versuchen, sich um Sie zu kümmern.

In Mastering Perl, rede ich ein wenig über besiege obfucators. Auch wenn Sie Dinge wie Nonsense-Variablen Namen und dergleichen machen, Module wie B::Deparse und B::Deobfuscate, zusammen mit Perl-Tools wie Perl::Tidy, machen es ziemlich einfach für die kenntnisreiche und motivierte Person, Ihre Quelle zu bekommen. Sie müssen sich nicht so sehr um das Unerfahrene und Unmotivierte kümmern, weil sie ohnehin nicht wissen, was sie mit dem Code machen sollen.

Wenn ich mit Managern darüber spreche, gehen wir die normale Kosten-Nutzen-Analyse durch. Es gibt alle möglichen Sachen, die Sie könnten tun, aber nicht viel davon kostet weniger als den Nutzen, den Sie bekommen.

Viel Glück,

Answer 15

Ein weiterer nicht ernst Vorschlag ist Acme::Bleach zu verwenden, wird es Ihr Code sehr sauber machen ;-)