Bonjour,
Oui il est relativement "simple" de connaitre le code sous jacent d'une assemblie .net. Mais attention via la Reflection ce n'est pas directement possible et ce n'est pas le but! La reflection permet principalement d'avoir du code "dynamique" et d'obtenir des informations sur l'assemblie. D'ailleurs pour des meilleures performances et plus de fonctionnalités sur l'analyse via le code d'une assembly, je te conseille Cecil (
[ Lien ]) qui est plus rapide pour la lecture d'une assembly (pas pour l'execution dynamique).
Pour récuperer le code d'une assemblie via la Reflection c'est un poil compliqué. Avant toute chose il faut savoir qu'une assembly est constitué de MSIL sous forme compilé (si on ouvre un exe on ne lit pas directement du MSIL ;)). La reflection nous permet à partir d'un MethodInfo obtenir le tableau des OpCode de la méthode, ceci s'effectue via la méthode
GetMethodBody, ensuite à partir de ce tableau de Byte on peut obtenir le code MSIL via une table de correspondance des opcode et des instructions MSIL fournit dans la spec de la CLR.
A partir de là, pour obtenir du code C#, VB (oups, j'avais oublié VB, je suis sur vbfrance, je vais me faire tapper ! :p) , il faut analyser le code MSIL ce qui est plutt compliqué, mais ce que fais très bien reflector.
En aucun cas il s'agit du code original.Reflector permet rarement (sauf dans les petites assemblies) d'obtenir du code directement compilable (à part en prenant via le MSIL, mais peu de gens code le MSIL) il est donc rare qu'on puisse modifier intégralement ton programme (à part via
Reflexil (qui utilise Cecil) qui va directement modifier le MSIL dans le .exe/.dll), tu as donc peu de chances que ton programme soit modifié, mais c'est possible :) Par contre tu as plus de chance que l'on te pique une classe ou quelque chose du genre.
Pour éviter cela il faut passer par de l'obfuscation, le maitre en la matière est dotfuscator
[ Lien ]. Le principe de cet outil est de modifier l'IL d'une assembly, pour cela voici quelques une des possibilités :
- modification des noms de méthodes en utilisant toute la gamme des caractères unicode
- surcharge des méthodes pour qu'elles aient toutes le même nom, en IL il est possible d'avoir des méthodes avec le même nom, mêmes arguments mais types de retour différent (ce qui n'est pas possible en C# (ni meme en VB))
- etc ... (je viens de perdre une autre méthode que j'avais en tête)
Il est également possible d'avoir un .exe classique (non .net) qui contiendra en ressource l'assembly à executer. l'exe classique ne fera que lancer l'exe caché. Bien sur cette technique est toute simple à contourner, encore faut-il savoir que l'application contien une assembly .net à l'interieur ;-)
Bref il y a des solutions, mais elles sont rarement utilisés car pas toujours nécessaire.
La plupart des frameworks (même payant) laisse leur code non obfusqué (à part le code de vérification de licence ;)), pour ma part Reflector est souvent ma plus grande documentation :-)
Dans le cas d'une application client/serveur, niveau sécurité ce n'est pas en cachant le code qu'on va protéger le serveur d'une attaque par le client. Certes cela va surement l'empecher de comprendre rapidement le code mais même via l'obfuscation il est possible de comrpendre la logique (d'ailleurs pour vraiment embeter le pirate, je te déconseille la version community de dotfuscator qui est beaucoup trop laxiste, seule la version pro doit être utilisé s'il y a besoin d'obfuscation)
Faisant principalement des applications web, je n'ai pas trop d'experience sur l'obfuscation, si d'autres ont des experiences sur le sujet ... ;-)
En ce qui concerne les différentes version du framework .net, je suis d'accord qu'il y a des nouvelles versions assez souvent, mais pas tous les 15 jours ;-)
En fait il y a principalement 2 versions de .net. .net 1.0 et .net 2.0, quand je parle .net je parle de la CLR : la machine virtuelle qui execute ton code. Toutes les autres versions sont simplement des rajouts au framework (toutes les classes qui permettent de faire pleins de choses).
La différence fondamental entre les versions 1.0 et 1.1 et l'ajout de quelques assemblies (et un nouveau compilo VB mais passons). La différence entre 2.0 et 3.0 est principalement l'ajout de WPF, WCF et WF, pour beaucoup ces nouvelels assemblies n'auraient jamais du s'appeller .net 3.0 mais .net 2.x pour 3.5 on a encore de nouvelles assemblies (linq & co) et un nouveau compilo C#3 et VB9 mais cela tourne toujours sur la CLR2.0.
une appli fonctionnant sur .net 2.0, fonctionnera aussi sur .net 3.5, mais tu auras surement codé des trucs inutiles disponibles dans les nouvelles assemblies.
Quand a me contacter, il y a la page contact sur
mon blog ou mon
site perso, mais le forum reste le mode de contact privilégié ca permet de partager la réponse avec tous le monde ;-)
Cyril -
MVP ASP.net -
MCPD ASP.net & MCTS SQL - Consultant indépendant