Reflection en .net - obsfuscation d'une assembly [Résolu]

Messages postés
234
Date d'inscription
mercredi 25 octobre 2000
Dernière intervention
5 octobre 2012
- - Dernière réponse : cs_coq
Messages postés
6366
Date d'inscription
samedi 1 juin 2002
Dernière intervention
2 août 2014
- 5 juil. 2008 à 20:11
Bonjour,

Je viens de lire l'article de Cyril DURAND ete Clément SERY sur Programmez http://www.programmez.com/magazine.php?num_magazine=hsnet12 concernant la Reflection et je me pose toujours la question depuis les début de .NET concernant la propriété intellectuel. Car si l'on peut si facilement décompiler un logiciel comment le protéger (j'ai aussi zieuté l'obfuscation... mais quizz...?)

Je ne travaille pas dans l'open source (faut bien que je gagne ma vie) et je pense ne pas être le seul d'ailleurs c'est pourquoi je continu toujours avec VS6 ... J'avoue que c'est seulement ça qui me bloque pour passe au .NET !

Je n'ai pas touvé comment écrire directement à Cyril DURAND mais d'après son blog il est très actif sur ce site alors... ;)

merci et good day
Afficher la suite 

Votre réponse

5 réponses

Meilleure réponse
Messages postés
17308
Date d'inscription
mercredi 2 janvier 2002
Dernière intervention
22 août 2018
3
Merci
Cyril DURAND, est connu sous le pseudo jesusonline sur le réseau CodeS-SourceS

l'obscfucation permet de rendre le code source (MSIL) telle une toile d'araignée. un dédale incompréhensensible pour l'humain. méthode, variables renommmées... code inutile ajouté, code relocalisé, déplacé, traffiqué...

au final, il sera toujours décompilable (reflector...) mais bon courage et bonne patience a qui voudra en comprendre la moindre chose...

maintenant, ce sont mes termes, je code pas en .Net, j'ai jamais lancé Reflector, donc. ..

Merci Renfield 3

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources a aidé 97 internautes ce mois-ci

Commenter la réponse de Renfield
Messages postés
234
Date d'inscription
mercredi 25 octobre 2000
Dernière intervention
5 octobre 2012
0
Merci
Merci !


.. en fait depuis des années je me dit que je dois me mettre au .NET, j'avais acheté le 2003, puis via le contrat MPower j'ai eu le 2005 et là le 2008 sort ! Bref ! j'aurai déjà du revoir mes source à chque release... On a pas le temps de comprendre 2003 que 15 jours après la framework change.


et VS6 comme tu le codes (car tes sources m'ont appris bcp j'avoue) me va parfaitement. Mais bon faut que je pense un peu à l'avenir
Commenter la réponse de peug
Messages postés
6827
Date d'inscription
dimanche 15 décembre 2002
Dernière intervention
13 octobre 2010
0
Merci
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 (http://www.mono-project.com/Cecil) 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 http://www.preemptive.com/dotfuscator.html. 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 ;-)

<hr />Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant
Commenter la réponse de jesusonline
Messages postés
6827
Date d'inscription
dimanche 15 décembre 2002
Dernière intervention
13 octobre 2010
0
Merci
(oups, je viens de voir que j'ai écrit une bonne tartine, j'aurais peut etre du me relire)

(PS : j'ai renommé ton sujet avec un titre que je trouve plus parlant :))

<hr />Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant
Commenter la réponse de jesusonline
Messages postés
6366
Date d'inscription
samedi 1 juin 2002
Dernière intervention
2 août 2014
0
Merci
Salut,

Pour l'obfuscation, faut voir suivant le contexte de réalisation du projet.
Obfusquer une solution développée pour un client spécifique n'est pas forcément cohérent, et ça reste une modification du code donc on ajoute un risque supplémentaire de bug.
Enfin après c'est pareil je n'ai pas non plus de grande expérience dans le domaine, donc je ne peux pas trop dire les impacts que ça peut avoir sur le debug et la résolution d'incidents.

Après ce côté autodescriptif n'est pas sans intérêt du point de vue des développeurs et architectes, vu que ça permet l'utilisation d'outils comme FxCop ou NDepend.

/*
coq
MVP Visual C#
CoqBlog
*/
Commenter la réponse de cs_coq

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.