Existe-t-il un bon obscurcisseur pour le code Perl?

Question

Quelqu'un connaît-il un bon observateur de code pour Perl? On me demande d’examiner la possibilité d’observer le code avant de le remettre à un client. Je sais que le code obsfucated peut encore être désossé, mais ce n’est pas notre principale préoccupation.

Certains clients apportent de petites modifications au code source que nous leur attribuons et qui nous causent des cauchemars lorsque quelque chose ne va pas et que nous devons le réparer, ou lorsque nous publions un correctif qui ne fonctionne pas avec ce qu'ils ont changé. . L’intention est donc simplement de faire en sorte qu’il soit difficile pour eux d’apporter leurs propres modifications au code (ils ne sont pas censés le faire de toute façon).

Answer 1

Je suis déjà allé dans cette voie et c’est un cauchemar absolu de travailler sur " obfuscated " code, car il augmente considérablement les coûts en essayant de résoudre un problème sur le serveur du client lorsque vous, le développeur, ne pouvez pas lire le code. Vous vous retrouvez avec "désobfuscateurs", copie du "code réel". sur le serveur du client ou sur un certain nombre d'autres problèmes qui deviennent un véritable problème à gérer.

Je comprends votre point de vue, mais il semble que la direction ait un problème et elle compte sur vous pour mettre en œuvre la solution choisie plutôt que de déterminer quelle est la solution correcte.

Dans ce cas, il semble que ce soit vraiment un problème de licence ou de contrat. Donnez-leur le code open source, mais intégrez-le dans la licence pour que toute modification apportée par ce dernier vous revienne et soit approuvée. Lorsque vous déposez des correctifs, vérifiez les sommes de md5 de tout le code et si elles ne correspondent pas à celles attendues, elles sont en violation de licence et seront facturées en conséquence (et le taux devrait être beaucoup plus élevé). (Je me souviens d'une entreprise qui nous a laissé le code open source, mais a précisé que si nous changions quoi que ce soit, nous avons "acheté" le code pour 25 000 $ et ils n'étaient plus responsables des corrections de bogues ou des mises à niveau, sauf si nous achetions une nouvelle licence).

Answer 2

Ne pas. Ne le faites pas.

Ecrivez-le dans le contrat (ou révisez-le si nécessaire), pour indiquer que vous n'êtes pas responsable des modifications apportées au logiciel. S'ils analysent votre code et s'attendent à ce qu'il soit corrigé, vous rencontrez des problèmes client qui ne seront pas résolus en obscurcissant le code . Et si vous le dissimulez et qu’ils rencontrent un problème réel, bonne chance pour leur permettre de rapporter avec précision le numéro de ligne, etc., dans le rapport de bogue.

Answer 3

S'il vous plaît, ne faites pas ça. Si vous ne voulez pas que les gens modifient votre code Perl, soumettez-le sous une licence appropriée et appliquez cette licence. Si des personnes modifient votre code lorsque votre licence indique qu’elles ne devraient pas le faire, le problème ne se pose pas lorsque vos mises à jour ne fonctionnent plus avec leur installation.

Voir Réponse de perlfaq3 à " Comment masquer le code source de mes programmes Perl? pour plus de détails.

Answer 4

Il semblerait que votre problème principal concerne les clients qui modifient le code, ce qui complique leur prise en charge. Je vous suggérerais de demander des sommes de contrôle (md5, sha, etc.) de leurs fichiers lorsqu'ils vous contacteront, et de même de vérifier les sommes de contrôle des fichiers lors de l'application de correctifs. Par exemple, vous pouvez demander au client de fournir le résultat d’un programme fourni qui passe par leur installation et la somme de contrôle de tous les fichiers.

Finalement, ils ont le code, ils peuvent donc faire ce qu’ils veulent. Le mieux que vous puissiez faire est d'appliquer vos licences et de vous assurer que vous ne supportez que du code non modifié.

Answer 5

Dans ce cas, masquer est une mauvaise approche.

Lorsque vous transmettez le code au client, vous devez conserver une copie du code que vous lui avez envoyé (sur disque ou de préférence dans votre contrôle de version sous forme de balise / branche).

Ensuite, si votre client apporte des modifications, vous pouvez comparer le code qu’il a avec le code que vous lui avez envoyé et repérer facilement les modifications. Après tout, s’ils ressentent le besoin d’apporter des modifications, il existe un problème quelque part et vous devez le régler dans la base de code principale.

Answer 6

Une autre alternative pour convertir votre programme en fichier binaire est le gratuit de PAR gratuit outil sur le CPAN . Il existe même des filtres pour l’obscurcissement du code, bien que, comme d’autres l'ont déjà dit, cela pose peut-être plus de problèmes que ça ne vaut la peine.

Answer 7

Je suis d'accord avec les suggestions précédentes.

Toutefois, si vous le souhaitez vraiment, vous pouvez consulter PAR et / ou Filtre :: Crypto Modules CPAN. Vous pouvez également les utiliser ensemble.

J'ai utilisé ce dernier (Filter :: Crypto) comme une forme très légère de " protection " lorsque nous expédions notre produit sur des supports optiques. Cela ne "protège" pas. vous empêcherez 90% des personnes qui souhaitent modifier vos fichiers source.

Answer 8

Ce n’est pas une suggestion sérieuse, mais jetez un coup d’œil à Acme :: Buffy .

Cela éclairera au moins votre journée!

Answer 9

Une alternative à l'obscurcissement consiste à convertir votre script en fichier binaire en utilisant quelque chose comme Perl Dev d'ActiveState Kit .

Answer 10

J'utilise un système d'exploitation Windows et utilise perl2exe d'IndigoSTAR. Le fichier .EXE résultant ne sera probablement pas modifié sur place.

Comme d’autres l’ont dit, "comment puis-je l’obscurcir" est la mauvaise question. "Comment puis-je empêcher le client de modifier le code" est le bon.

Answer 11

Les idées de contrôle et de contrat permettent de prévenir les "problèmes". vous décrivez, mais si le coût pour vous est la difficulté de déployer des mises à niveau et des corrections de bugs, comment vos clients apportent-ils des modifications qui ne passent pas la suite de tests complète ? S'ils sont capables d'effectuer ces modifications (ou du moins, en apportant une modification qui exprime ce qu'ils veulent que le code fasse), pourquoi ne pas simplement leur simplifier la tâche pour qu'ils ouvrent un ticket de support et téléchargent le correctif? Le client a toujours raison sur ce qu'il souhaite (il se peut qu'il ne sache pas comment le faire "de la bonne manière", mais c'est pourquoi il vous paye.)

Une meilleure raison de vouloir un obfuscateur serait pour le déploiement de postes de travail grand public où tous les clients ne sont pas sous contrat. Dans ce cas, quelque chose comme PAR - tout ce qui contient la logique de cryptage / obfuscation dans un fichier binaire compilé est le chemin à parcourir.

Answer 12

Comme plusieurs personnes l'ont déjà dit: ne le faites pas.

Il est à peu près implicite, étant donné la nature de l'interpréteur Perl, que tout ce que vous faites pour masquer Perl doit être irréversible avant que Perl ne le récupère, ce qui signifie que vous devez laisser le script / binaire de désobscurcation traîner où l’interprète (et donc votre client) peut le trouver:)

Corrigez le vrai problème: les sommes de contrôle et / ou une licence libellée de manière appropriée. Et le personnel de soutien formé pour dire «vous l'avez changé? nous invoquons l'article 34b de notre licence, et cela nous coûtera X 000 $ avant que nous ne le touchions '....

Lisez également pourquoi-devrais-je-utiliser-obfuscation pour plus de détails réponse générale.

Answer 13

Je les inviterais simplement dans mon arbre SVN sur leur propre branche afin qu'ils puissent apporter des modifications et que je puisse les voir et les intégrer à mon arbre de développement.

Ne le combat pas, embrasse-le.

Answer 14

Comme le dit Ovid, c’est un problème social et contractuel. S'ils changent le code, ils annulent la garantie. Chargez-les beaucoup pour résoudre ce problème, mais en même temps, donnez-leur un canal où ils peuvent suggérer des modifications. En outre, regardez ce qu'ils veulent changer et faites-en une partie de la configuration si vous le pouvez. Ils veulent faire quelque chose et, tant que vous n'y serez pas satisfait, ils continueront d'essayer de vous contourner.

Dans Maîtriser Perl , je parle un peu des moyens de vaincre les obfucateurs. Même si vous créez des noms de variables sans signification, par exemple, des modules tels que B :: Deparse et B :: Deobfuscate , ainsi que des outils Perl tels que Perl :: Tidy , facilitez la tâche de la personne avertie et motivée pour obtenir votre source. Vous n'avez pas à vous soucier de l'inconnaissable et de la non-motivation, car ils ne savent pas quoi faire avec le code de toute façon.

Lorsque je discute de cette question avec les responsables, nous analysons l’analyse coûts-avantages normale. Il y a toutes sortes de choses que vous pouviez faire, mais cela ne coûte pas beaucoup moins cher que l'avantage que vous obtenez.

Bonne chance,

Answer 15

Une autre suggestion peu sérieuse consiste à utiliser Acme :: Bleach , ce qui rendra votre code très propre ;-)