Perl 用の優れたコード難読化ツールを知っている人はいますか? クライアントにリリースする前に、コードを難読化するオプションを検討するよう求められています。難読化されたコードがリバース エンジニアリングされる可能性があることは知っていますが、それは私たちの主な関心事ではありません。
一部のクライアントは、私たちが提供したソース コードに小さな変更を加えており、何か問題が発生して修正しなければならない場合や、変更内容で機能しないパッチをリリースした場合に悪夢に見舞われます。したがって、意図は、彼らがコードに独自の変更を加えることを困難にすることです(とにかくそれを行うことは想定されていません)。
私は以前にこの道を進んできましたが、「難読化された」コードで作業する必要がある場合、開発者であるあなたがコードを読み取れないときにクライアントのサーバーで問題をデバッグしようとするとコストが大幅に増加するため、これは絶対的な悪夢です。 。結局、「難読化解除機能」、「実際のコード」をクライアントのサーバーにコピーすること、または維持するのが非常に面倒になる他の多くの問題のいずれかになります。
あなたがどこから来たのかはわかりますが、経営陣に問題があり、正しい解決策を理解するのではなく、選択した解決策を実装することを求めているようです。
この場合、それは実際にはライセンスまたは契約上の問題のように聞こえます。コードをオープンソースにしますが、提出した変更はすべてあなたに戻って承認される必要があることをライセンスの一部にします。パッチをプッシュするときは、すべてのコードのmd5の合計を確認してください。予想と一致しない場合は、ライセンス違反であり、それに応じて課金されます（はるかに高いレートになるはずです）。（コードをオープンソースにしたある会社を覚えていますが、何かを変更した場合、コードを25,000ドルで「購入」し、購入しない限り、バグ修正やアップグレードの責任を負わないことを明確にしました。新しいライセンス）。
しないでください。しないでください。
契約書にそれを書いてください（または、必要に応じて契約書を改訂してください）。ソフトウェアに加えられた変更については、あなたが責任を負わないことを確認してください。彼らがあなたのコードを修正していて、あなたがそれを修正することを期待しているなら、あなたはコードを難読化することによって解決されないであろうクライアントの問題を抱えています。また、難読化して実際に問題が発生した場合は、バグレポートで行番号などを正確に報告してもらうようにしてください。
お願い、それはやめて。他の人にPerlコードを変更させたくない場合は、適切なライセンスの下に置き、そのライセンスを適用します。あなたがライセンスを取得したときに人々があなたのコードを変更するべきではないと言った場合、あなたのアップデートが彼らのインストールで機能しなくなったとしてもあなたの問題ではありません。
詳細については、「Perlプログラムのソースを非表示にするにはどうすればよいですか？」に対するperlfaq3の回答を参照してください。
あなたの主な問題は、クライアントがコードを変更することであり、それがあなたのサポートを困難にしているように思われます。サポートが必要な場合は、ファイルのチェックサム（md5、shaなど）を要求し、パッチを適用する場合も同様にファイルのチェックサムを確認することをお勧めします。たとえば、クライアントに、インストールを実行してすべてのファイルをチェックサムする、提供されたプログラムの出力を提供するように依頼できます。
最終的に彼らはコードを持っているので、彼らはやりたいことを何でもすることができます。最善の方法は、ライセンスを適用し、変更されていないコードのみをサポートするようにすることです。
この場合、難読化は間違ったアプローチです。
コードをクライアントにリリースするときは、送信するコードのコピーを（ディスク上に、またはできればタグ/ブランチとしてバージョン管理に）保持する必要があります。
次に、クライアントが変更を加えた場合、クライアントが持っているコードを送信したコードと比較して、変更を簡単に見つけることができます。結局のところ、変更を加える必要があると感じた場合は、どこかに問題があるため、マスターコードベースで修正する必要があります。
プログラムをバイナリに変換するもう 1 つの方法は、CPANの無料のPAR-Packerツールです。他の人が言ったように、コードの難読化のためのフィルターさえありますが、それは価値があるよりもおそらく面倒です.
以前の提案に同意します。
ただし、本当に必要な場合は、PARおよび/またはFilter::Crypto CPAN モジュールを調べることができます。それらを一緒に使用することもできます。
後者 (Filter::Crypto) は、光メディアで製品を出荷する際の「保護」の非常に軽量な形式として使用しました。あなたを「保護」するわけではありませんが、あなたのソースファイルを変更しようとする人々の 90% を止めることができます。
これは深刻な提案ではありませんが、Acme::Buffyを見てください。
それは少なくともあなたの一日を明るくします！
An alternative to obfuscation is converting your script to a binary using something like ActiveState's Perl Dev Kit.
チェックサムと契約のアイデアは、あなたが説明する「問題」を防ぐのに役立ちますが、アップグレードとバグ修正の展開の難しさがコストである場合、クライアントは包括的なテストスイートに合格しない変更をどのように行っていますか？彼らがこれらの変更を行うことができる場合（または少なくとも、コードに実行させたいことを表す変更を加えることができる場合）、サポートチケットを開いてパッチをアップロードするのを簡単/自動化してみませんか？顧客は顧客が何を望んでいるかについて常に正しいです（彼らはそれを「正しい方法」で行う方法の手がかりを持っていないかもしれませんが、それが彼らがあなたに支払っている理由です）。
難読化ツールが必要なより良い理由は、すべての顧客が永続的な契約を結んでいないマスマーケットのデスクトップ展開のためです。その場合、 PARのようなもの（暗号化/難読化ロジックをコンパイル済みのバイナリにパックするもの）が最適です。
何人かの人々がすでに言っているように：しないでください。
Perl インタープリターの性質を考えると、Perl を難読化するために行うことはすべて、Perl がそれを手に入れる前に元に戻すことができなければならないということは、ほとんど暗黙の了解です。 （したがって、あなたの顧客）はそれを見つけることができます:)
実際の問題を修正します: チェックサムおよび/または適切な言葉遣いのライセンス。サポート スタッフは、「変更しましたか?」と言うように訓練されています。私たちはライセンスの条項 34b を発動しており、それに触れる前にそれは $X,000 になるでしょう....
また、より一般的な回答については、難読化を使用する必要がある理由をお読みください。
Windows O/S を実行しており、IndigoSTAR の perl2exe を使用しています。結果の .EXE ファイルは、オンサイトで変更される可能性はほとんどありません。
他の人が言ったように、「難読化する方法」は間違った質問です。「顧客がコードを変更できないようにするにはどうすればよいですか」が正しいものです。
Ovidが言うように、それは契約上の、社会的な問題です。コードを変更すると、保証が無効になります。それを修正するために彼らにたくさん請求しますが、同時に、彼らが変更を提案できるチャネルを彼らに与えます。また、彼らが何を変更したいかを見て、可能であれば構成のその部分を作成します。彼らにはやりたいことがあり、あなたがそれを満足するまで、彼らはあなたを回避しようとし続けます。
Perlのマスターでは、難読化ツールを打ち負かすことについて少し話します。意味のない変数名などを作成する場合でも、B::DeparseやB:: Deobfuscateなどのモジュールと、 Perl :: TidyなどのPerlツールを使用すると、知識が豊富で意欲的な人が簡単に取得できます。あなたのソース。彼らはとにかくコードをどうするかを知らないので、あなたは知識がなく、やる気がないことをそれほど心配する必要はありません。
これについてマネージャーと話すときは、通常の費用便益分析を行います。あなたができることはいろいろありますが、その多くはあなたが得る利益よりも安くはありません。
幸運を、
私は彼らを自分のブランチの SVN ツリーに招待するだけで、彼らが変更を提供できるようになり、私はそれらを見て、彼らの変更を私の開発ツリーに統合することができます。
戦わないで、受け入れてください。
別の深刻ではない提案は、Acme::Bleachを使用することです。これにより、コードが非常にきれいになります ;-)