Certains langages comme Java et .NET peuvent être facilement décompilés en code source lisible. L'obscurcissement du code est un processus qui rend les fichiers binaires de votre application plus difficiles à lire avec un décompilateur. C’est un outil important pour protéger la propriété intellectuelle de votre entreprise.
Pourquoi obscurcir le code?
Les langages compilés comme C ++ sont convertis directement en bytecode. La seule façon de faire de l'ingénierie inverse sur leur fonctionnement consiste à utiliser un désassembleur, ce qui est un processus ardu et compliqué. Ce n’est pas impossible, mais essayer de déduire une logique d’application de haut niveau à partir d’un flux de langage assembleur est difficile.
D'un autre côté, les langages comme C # et Java ne sont pas compilés pour un système d'exploitation particulier. Ils sont plutôt compilés dans un langage intermédiaire, comme MSIL de .NET. Le langage intermédiaire est similaire à l'assembly, mais il peut être facilement reconverti dans le code source. Cela signifie que si vous avez une DLL ou un exécutable public que votre entreprise distribue, toute personne disposant d'une copie de votre exécutable peut l'ouvrir dans un Décompilateur .NET comme dotPeek, et directement lire (et copier) votre code source.
L'obscurcissement du code ne peut pas empêcher ce processus: toute DLL .NET peut être connectée à un décompilateur. Ce que fait l'obfuscation est d'utiliser un certain nombre d'astuces pour créer le code source ennuyeux comme l'enfer pour lire et déboguer.
La forme la plus simple de ceci est le changement de nom d'entité. Il est courant de nommer correctement les variables, méthodes, classes et paramètres en fonction de ce qu’ils font. Mais vous n’êtes pas obligé de le faire, et techniquement, rien ne vous empêche de les nommer avec une série de L et un I minuscules, ou des combinaisons aléatoires de caractères chinois unicode. Pour l'ordinateur, il n'y a pas de problème, mais il est complètement illisible pour un humain:
IlIIIIlIIIllIIIllIIll lIIIllIIllIlIIIIlIIIl
Un obfuscateur de base gérera automatiquement ce processus, en prenant la sortie de la compilation et en la convertissant en quelque chose qui est beaucoup plus difficile à lire. Il y a pas de performance par rapport au code non obscurci
Des obfuscateurs plus avancés peuvent aller plus loin et modifier en fait la structure de votre code source. Cela inclut le remplacement des structures de contrôle par une syntaxe plus compliquée mais sémantiquement identique. Ils peuvent également insérer du code factice qui ne fait rien d'autre que de confondre le décompilateur. Cela a pour effet que votre source ressemble à du code spaghetti, ce qui la rend plus ennuyeuse à lire.
Un autre objectif commun est de masquer les chaînes des décompilateurs. Dans les exécutables gérés, vous pouvez rechercher des chaînes telles que des messages d'erreur pour localiser des sections de code. L'obscurcissement des chaînes remplace les chaînes par des messages codés, qui sont décryptés au moment de l'exécution, ce qui rend impossible leur recherche à partir d'un décompilateur. Cela s'accompagne généralement d'une pénalité de performance.
Il existe de nombreuses options pour les obfuscateurs, bien que cela dépende de la langue que vous obscurcissez. Pour .NET, il y a Obfuscar. Pour Java, il y a ProGuard. Pour JavaScript, il y a javascript-obfuscator.
Autres options: convertir en un langage compilé
La conversion d'un langage de programmation en un autre n'est pas une idée complètement folle – Unity utilise IL2CPP, un convertisseur qui transforme le code .NET en bytecode C ++ compilé. Il est beaucoup plus performant, mais il permet également de sécuriser les jeux contre le craquage facile, ce qui est crucial pour un environnement en proie au piratage et aux tricheurs.
Microsoft a CoreRT, un environnement d'exécution expérimental .NET Core utilisant la compilation Ahead-Of-Time, bien qu'il ne soit pas prêt pour une utilisation en production.
Devriez-vous obscurcir?
Si vous déployez du code dans des environnements non approuvés où vous souhaitez protéger votre code source, vous devez presque toujours utiliser au moins un obfuscateur de base pour renommer les fonctions, les méthodes et les propriétés afin que la décompilation demande un peu plus d'efforts.
Si vous vraiment Personne n'a besoin de pouvoir décompiler votre application, vous pouvez utiliser un obfuscateur plus intrusif, mais vous devriez vraiment vous demander si le problème serait mieux résolu en passant à un langage qui n'a pas ce problème, tel que C ++ ou Rust.