Tout développeur .Net sait que n'importe quel code managé peut être désassemblé et examiné. Par conséquent, n'importe quelle information stockée dans une application .Net est presque aussi visible que si les sources étaient fournies. En effet, le nom de toutes les variables et méthodes, ainsi que toutes les valeurs de constantes sont visibles pour quiconque possède un désassembleur. Or, les applications .Net nécessitent le framework pour fonctionner et comme chaque ordinateur sur lequel le framework est installé possède un désassembleur (Ildasm.exe), tout utilisateur est susceptible de désassembler du code .Net.
La
première chose à faire pour se protéger est de concevoir un algorithme qui
validera ou invalidera la licence d’utilisation. Mais pour rendre le code moins
limpide, il est conseillé de fragmenter et de disperser les données sensibles.
Ensuite, pour le rendre encore moins lisible, utilisez un obfuscateur
classique qui va convertir le nom des variables et les entêtes des méthodes en
caractères alphanumériques.
Cependant,
si vous stockez votre algorithme sur le disque local de l’utilisateur, vous ne
pouvez avoir aucune certitude que votre produit ne sera jamais piraté. En
effet, même l’obfuscation classique qui en rebutera
plus d’un, sans toutefois arrêter les plus déterminés ou ceux qui possèdent un
produit capable de générer du code c# à partir du code MSIL, et ce, même si le
code a été obfusqué. Dans ce dernier cas, il ne
faut que quelques minutes pour trouver les informations utiles,
ou même, toutes les informations voulues, puisque le corps des
méthodes est tout à fait lisible.
Ainsi, jusqu’à il y a peu, le seul moyen de protéger vos secrets commerciaux et données sensibles ou privées était de ne jamais les communiquer, ni les distribuer. Pour cela, le meilleur moyen était de les exposer au travers d’un service web : lorsque votre code nécessitait une opération sensible, comme le décryptage des données, ou la comparaison de hashages cryptés, vous pouviez déléguer cette tache à un service web et ainsi, conserver vos secrets commerciaux à l’abris, au travers d’un pare-feu d’entreprise.
Les
obfuscateurs transforment l’assembly
.Net en un assembly équivalent, mais difficile à
lire après désassemblage ou décompilation.
La
logique contenue dans les méthodes est inchangée. La modification des noms de
symboles peut empêcher l’assembly protégé de
fonctionner correctement (sérialisation, remoting,
réflexion)
Les
compilateurs transforment le code .Net en code natif par compilation native,
analogue à ce qui se produit lors de la compilation juste à temps.
Le
code généré est compilé pour une architecture donnée, ôtant les fonctionnalités
multi-plateformes de .Net.
Le
code généré ne nécessite plus le Framework pour
s’exécuter, mais ne bénéficie donc pas des améliorations apportées (service
packs).
Généralement,
un assembly .Net dépend de code émanant d’une
variété d’assemblies fournis par Microsoft. Ces
assemblies, connus sous le nom de .Net Framework,
constituent les fonctionnalités de base de .Net. En incorporant ces
assemblies directement dans les vôtres, un linker peut rendre votre
code plus difficile à comprendre. Attention ! Il se peut que l’usage d’un
éditeur de liens viole les droits de copyright détenus par Microsoft sur .Net.
Les
lanceurs (Hôtes) utilisent une stratégie en 2 phases pour protéger un
exécutable. D’abord, l’assembly est crypté,
ensuite, il est incorporé dans un exécutable natif chargé du lancement de la
runtime, de la décompression et du chargement des assemblies.
Avec cette technique, le code n’est plus vu comme du code .Net et ne peut donc
pas être attaqué par ILDASM et les outils de réflexion.
dotNet
Protector 5 protège Applications et composants grâce à une technologie inovante
de maquillage de bodies. Les assemblies ne sont plus transformés en application
native, mais restent des assemblies .Net. dotNet Protector 5 protège votre code
code grâce à un obfuscateur associé à un maquilleur de méthodes.
Les
assemblies sont obfusqués, et le corps des méthodes est remplacé par du code
corrompu; Les outils de décompilation ou désassemblage comme ILDASM ne pourront
pas désassembler ou décompiler les méthodes. dotNet Protector 5 prend en charge
la protection des composants et ASP.Net.
La runtime dotNet Protector 5 (5 dlls) doit être déployée avec les assemblies protégés. Il suffit de copier ces dlls dans le répertoire d'exécution. L'inscription de PvLogiciels.dotNetProtector.Runtime.dll dans le GAC est aussi possible.
dotNet Protector 5
Cette section introduit les méthodes de protections implémentées dans dotNet Protector et comment choisir un type de projet en fonction de l'assembly que l'on veut protéger.