En y réfléchissant, il existe plusieurs types d'obscurcissement. Commençons par l'obscurcissement du code source, ce qui est une perte de temps complète; c'est déjà assez difficile à comprendre sans ça! Alors concentrons-nous plutôt sur l'obscurcissement du package de livraison, sur la façon dont le code est remis à l'utilisateur.
Obfuscation mineure
Un brouillage mineur existe pour empêcher l'utilisateur occasionnel de fourrer ses doigts et de casser des objets facilement. Cela n'empêche pas le pirate informatique déterminé, mais cela a de la valeur pour aider à garantir que les choses que vous êtes invité à soutenir sont ce que vous avez réellement livré. Le niveau de protection requis pour ce genre de chose est vraiment assez faible; le paquet de livraison doit simplement ne pas être lisible et modifiable (sans outils spécialisés) et c'est assez bien.
La minification de Javascript en est un exemple, bien qu'elle ne soit pas commercialisée comme telle. Personne sensé ne voudrait lire et éditer un fichier JS minifié, même s'il est techniquement possible de le faire si vous êtes déterminé / assez persistant.
De même avec la livraison d'applications Java. Le simple fait d'emballer le code dans un fichier JAR exécutable arrêtera la majorité de la folie, même s'il a toute la force d'un panneau poli «S'il vous plaît, évitez l'herbe» dans un parc de la ville.
Même lors de la livraison de code C ++, la suppression des symboles inutiles de l'exécutable sera suffisante pour être qualifiée d'obscurcissement mineur. La clé est qu'il est difficile de lire le résultat en tant qu'utilisateur, mais pas un problème pour l'exécuter en tant qu'ordinateur.
Obscurcissement majeur
L'obscurcissement majeur empêche l'utilisateur déterminé et bien informé . C'est aussi une partie perdante totale; si un ordinateur peut l'exécuter, une personne peut le séparer et déterminer ce qu'il fait. Le plus proche que vous pourriez obtenir serait de faire en sorte que le programme se décrypte continuellement, transformant ce qu'il fait à un moment donné en une chose complètement différente qu'il fait à un autre moment. La création d'une telle chose serait plutôt difficile et ne garderait toujours pas un très bon pirate informatique (bien qu'ils seraient vraiment assez croisés avec vous à la fin de celui-ci à la quantité d'effort requise pour décrypter tout ce code auto-modifiant).
Il vaut mieux penser en termes d'autres solutions. Par exemple, vous pouvez conserver les «joyaux de la couronne» du code sur les serveurs que vous contrôlez et n'autoriser que les appels de service, ce qui fait du client un cadeau essentiellement gratuit qui est un frontal pour les bits de valeur. Ou vous pouvez emprunter la voie la plus contractuelle / légale et ne remettre les exécutables qu'aux organisations qui acceptent formellement de ne pas fouiller dans votre code ou de vous indemniser si elles le font (ce serait donc une sorte de NDA). L'objectif serait de créer une forte incitation pour le pirate à ne pas pirater, et pour les utilisateurs de garder le code à l'écart de tout pirate non lié par l'accord.
Mais vous ne devez pas supposer que votre code ne peut jamais être fissuré. Avec la virtualisation, tout état de programme d'une exécution peut être examiné et suivi, et tout ce qui tente de le vaincre (par exemple, le suivi de l'horloge vers une source de temps externe) sera beaucoup plus susceptible de causer des problèmes aux utilisateurs légitimes qu'aux pirates. (Consultez l'historique de DRM pour savoir comment même des éditeurs d'informations très déterminés ne peuvent pas sécuriser leurs systèmes une fois que le code est entre les mains de leurs adversaires.) Il est préférable de se concentrer sur la satisfaction des utilisateurs légitimes. Les pertes occasionnées par la fissure occasionnelle ne seront rien comparées à l'argent supplémentaire apporté par la satisfaction satisfaisante des clients.