Reflection en .net - obsfuscation d'une assembly
Résolu
peug
Messages postés
232
Date d'inscription
mercredi 25 octobre 2000
Statut
Membre
Dernière intervention
5 octobre 2012
-
4 juil. 2008 à 10:08
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 - 5 juil. 2008 à 20:11
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 - 5 juil. 2008 à 20:11
5 réponses
Renfield
Messages postés
17287
Date d'inscription
mercredi 2 janvier 2002
Statut
Modérateur
Dernière intervention
27 septembre 2021
74
4 juil. 2008 à 10:50
4 juil. 2008 à 10:50
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. ..
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. ..
peug
Messages postés
232
Date d'inscription
mercredi 25 octobre 2000
Statut
Membre
Dernière intervention
5 octobre 2012
4 juil. 2008 à 11:22
4 juil. 2008 à 11:22
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
.. 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
jesusonline
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Membre
Dernière intervention
13 octobre 2010
29
5 juil. 2008 à 19:36
5 juil. 2008 à 19:36
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
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
jesusonline
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Membre
Dernière intervention
13 octobre 2010
29
5 juil. 2008 à 19:37
5 juil. 2008 à 19:37
(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
(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
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
cs_coq
Messages postés
6349
Date d'inscription
samedi 1 juin 2002
Statut
Membre
Dernière intervention
2 août 2014
101
5 juil. 2008 à 20:11
5 juil. 2008 à 20:11
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
*/
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
*/