begin process at 2008 05 16 20:55:29
1 173 724 membres
533 nouveaux aujourd'hui
13 972 membres club

Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum.
Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

REFLECTOR : UN DÉCOMPILATEUR .NET


Information sur le tutorial

Catégorie :.NET Tutorial .NET ( DotNet ) Date de création : 05/05/2007 12:16:23 Vu : 8 705 fois

Note :
Aucune note

Commentaire sur cette source (20)
Ajouter un commentaire et/ou une note


Description

.

Tutorial

Reflector : un décompilateur .net

Beaucoup de développeur .net ne connaissent pas Reflector voici un rapide guide d’utilisation de cet outil.

Présentation de Reflector

Reflector est un programme gratuit permettant de décompiler des exécutable ou dll .net : des assemblies. Vous pouvez télécharger ce programme à cette adresse : http://www.aisto.com/roeder/dotnet/

Si vous ne connaissez pas le principe des « assemblies », je vous conseille la lecture de cette série d’article : http://msdn.microsoft.com/library/en-us/cpguide/html/cpconInsideNETFramework.asp

En bref :

  • Une assembly peut être un fichier .exe ou .dll, c’est le résultat d’une compilation d’un code .net ;
  • Une assembly est constitué d’une partie descriptive, et d’une partie code en MSIL (Microsoft Intermediate Language) ;
  • Le code MSIL est « human readable », c’est un mélange entre l’assembleur et .net .

Première décompilation

Lors du premier lancement, Reflector vous demande quelle version du Framework vous voulez analyser, vous obtenez ensuite cette fenêtre :

Par défaut, on voit que plusieurs assembly sont chargées. Si l’on clique sur l’une d’elles on voit dans la partie basse de la fenêtre différentes informations sur l’assembly tel que sa location, sa version etc…

Si l’on développe l’assembly System.Web, on peut voir 2 nœuds, on va tout d’abord voir l’utilité du nœud Resources puis on verra ensuite le second noeud.

Le nœud Resources

Ce nœud contient toutes les ressources contenues dans l’assembly, une ressource est un fichier stocké dans l’assembly, cela peut être des images, des fichiers de traductions, … dans le cas de l’assembly System.Web on voit les fichiers JavaScript servant aux différents contrôles ainsi que les images servant pour le designer des contrôles dans Visual Studio.

Pour voir le contenu des ressources il faut faire un clic droit sur la ressource puis View Resource.

Le nœud .dll ou .exe

Passons maintenant au premier nœud de tout à l’heure à savoir le nœud System.Web.dll

Ce nœud contient les différents namespace de l’assembly, développons le namespace System.Web.UI

On voit alors les différents types du namespace sélectionné, chaque sorte de type possède sa propre icône dont voici la signification :

Première décompilation

Commençons maintenant notre première décompilation. Pour cela nous allons nous intéresser au type System.Web.UI.WebControls.Label, développons alors ce type, les 2 premiers nœuds nous indique de quelle type dérive l’objet, et quel type dérive de lui :

On a aussi accès aux différentes méthodes, pour afficher le code de celle-ci il faut cliquer avec le bouton droit puis choisir « disassembler »

On a alors directement accès au code de la dll, ce code a été généré à partir du code MSIL, ce n’est pas le code qui a servi à compiler l’assembly, dans certains cas il se peut que le code ne soit pas parfait et comporte des erreurs. Pour naviguer dans le code, vous pouvez tout simplement cliquer sur les différents types et Reflector vous conduira à l’endroit souhaité. Vous pouvez afficher le code dans différents langages, tel que MSIL, VB, C#, Delphi, …

Enfin dernière fonctionnalité intéressante, il s’agit de la fonction « Analyzer » (disponible en cliquant avec le bouton droit sur la méthode). Cette fonctionnalité permet de connaitre qui appelle la méthode ou le type et vice-versa cette fonctionnalité est très pratique lors du debug ou de l’analyse de code !

Pour désassembler une autre assembly, on peut tout simplement faire un drag & drop du fichier .dll ou .exe dans Reflector ou encore utiliser le menu « File > Open ».

Conclusion

Reflector est un outil indispensable à toutes les personnes souhaitant comprendre le fonctionnement interne du Framework .net. Il permet aussi de résoudre très rapidement de nombreux problèmes, lorsque la documentation n’est pas assez complète. Cet outil est gratuit et remis à jour régulièrement de plus il existe de nombreux plug-ins permettant d’aller encore plus loin dans l’analyse d’une assembly.

Ressources


05 mai 2007 13:27:13 :
modification d'une image
  • signaler à un administrateur
    Commentaire de Rawheadrex le 05/05/2007 15:46:53

    Je ne sais pas si c'est moi, mais j'ai essayé de télécharger Reflector, et le zip est toujours invalide. Suis-je le seul à avoir ce problème? Pour ma part, j'utilise 7-Zip pour la décompression. Merci!

  • signaler à un administrateur
    Commentaire de jesusonline le 05/05/2007 16:14:57 administrateur CS

    J'utilise Winrar et je n'ai pas de problème particulier. Mais tu n'es pas le premier que j'entend dire que le zip de Reflector est invalide :-/

  • signaler à un administrateur
    Commentaire de coq le 05/05/2007 18:31:13 administrateur CS

    Pas de problème non plus de mon côté.

  • signaler à un administrateur
    Commentaire de romagny13 le 05/05/2007 23:37:06

    Joli article et bien fait :)
    moi ce qui m'aurait bien plu c'est savoir quels add-ins existent pour Reflector (disponibles sur Codeplex il me semble), qu'est ce que chacun apporte et lesquels sont vraiment indispensables

  • signaler à un administrateur
    Commentaire de Rawheadrex le 06/05/2007 02:41:13

    Merci, je vais donc essayer avec un autre logiciel! Bon travail en passant.

  • signaler à un administrateur
    Commentaire de hilairenicolas le 15/06/2007 14:05:48

    j'vais ptete dire une connerie, mais j'essaie cet outil, je charge System.dll
    je déplie, System.IO et il me manque plein de classes, genre StreamReader il est ou ?
    Meme une méthode statique, genre File.Copy.

    Comment faire pour voir l'implémentation du code ?
    Merci

  • signaler à un administrateur
    Commentaire de jesusonline le 15/06/2007 14:55:28 administrateur CS

    les classes que tu décrit sont dans mscorlib qui est vraiment le poumon de .net. mscorlib est chargé par défaut dans reflector.

  • signaler à un administrateur
    Commentaire de hilairenicolas le 15/06/2007 15:13:51

    ah oué, youpi, c'est ca :)

    Merci

  • signaler à un administrateur
    Commentaire de alvinp le 02/08/2007 22:12:19

    Super bien fait!! Par contre, je ne pense pas que sa me servira ^^

    Du moins pas pour le moment...

  • signaler à un administrateur
    Commentaire de loussaille le 17/08/2007 09:21:35

    Grace à ton tutoriel
    Prise en main de Reflector en moins de 10 min alors que je ne connaissais pas du tout cet outil "indispensable"
    Merci beaucoup

  • signaler à un administrateur
    Commentaire de tkd1984 le 01/09/2007 22:57:26

    bonjour
    c'est un tres beau sujet avec une traitement professionnele,je vous demande si il ya de decompilateur pour virus-trojan ,rien que pour comprendre et apprendre comment les virus travail,je suis debutant en programmation C/C++.
    merci de votre reponce

  • signaler à un administrateur
    Commentaire de coq le 01/09/2007 23:04:18 administrateur CS

    Et le site courant est dédié au C#, un langage de la plateforme .NET, relativement éloigné du natif => http://www.cppfrance.com/

  • signaler à un administrateur
    Commentaire de Rocco123 le 25/12/2007 18:11:26

    Je suis justement en train d'essayer d'écrire un obfuscateur .NET (par curiosité plutôt qu'un but commercial), j'ai déjà réussi à pouvoir changer tous les noms de méthodes et membres par des "?" (facile, possible même avec un simple éditeur hexa). Maintenant, j'aimerais savoir comment font certains obfuscateurs à faire planter Reflector pour qu'il affiche par exemple "Ce code a été obfusqué", si quelqu'un a une idée... Là c'est déjà une option avancée qui nécessite d'aller fouiller dans le code IL mais ça doit être possible. Peu de documentation vraiment sur les possibilités qu'offre .NET en la matière.

    Je sais que les obfuscateurs ne servent parfois pas à grand chose (par exemple un hacker qui veut à tout prix craquer une licence le fera) mais je suis vraiment surpris de la qualité du code que Reflector est capable d'obtenir, comment se fait-il que Microsoft n'ait pas pensé à plus de protections au niveau du framework .NET lui-même? Apparement, il y a une astuce avec NGEN, mais qui dépend de la machine, ou bien créer un lanceur natif qui déchiffre le code .NET à la volée, bref, ces outils auraient dû se trouver déjà d'origine dans le SDK...

  • signaler à un administrateur
    Commentaire de jesusonline le 26/12/2007 13:40:27 administrateur CS

    ngen te permet de compiler une assembly vers un code natif en fonction de la machine, je ne l'ai jamais utilisé et je n'en sais pas plus sur ce qu'il fait exactement en interne. Coq en sait surement plus que moi =)

    Pour la doc : j'ai commencé à lire : http://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463 qui est vraiment très complet et que je conseil si tu t'interesse à l'IL

  • signaler à un administrateur
    Commentaire de coq le 26/12/2007 14:23:22 administrateur CS

    Pour simplifier on peut voir ngen comme un outil effectuant la compilation JIT (Just In Time) habituelle une et une seule fois en la stockant dans une image native (dans %windir%\assembly\NativeImages*), le runtime se servira ensuite directement de cette image au lieu de charger et compiler le MSIL.
    On gagne donc du temps sur certains points, par contre il y a d'autres aspects à prendre en compte avant de s'en servir, ce qui est un sujet assez pointu en fin de compte, et je n'en maitrise pas encore tous les aspects non plus : http://msdn2.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx
    Un exemple assez connu de programme utilisant ngen est Paint.NET.

    Mais je ne vois pas en quoi ngen pourrait servir à la non divulgation du code MSIL, car à ma connaissance il n'y a pas moyen de se passer de l'assembly d'origine une fois que l'image native est générée (notamment pour les éléments que ngen n'a pu traiter et pour lesquels on rebascule en mode standard).

    Ensuite compter sur un plantage de Reflector est illusoire : un bug, ça se corrige, et ça n'arrêtera personne, surtout s'il se produit lors de la génération du code C# à partir de l'IL : il "suffit" de lire l'IL, et donc d'utiliser directement des jouets comme ildasm.

    Concernant l'absence de mesures de protection fournies par MS, ça ne m'étonnes/ne me choque pas plus que ça : un outil fourni est un outil à tester/maintenir, ce qui a un coût, et je ne pense pas que les developpeurs désireux d'obfusquer leur code représentent une majorité de la masse.
    De plus utiliser un obfuscateur présente un risque supplémentaire de bugs, et doit compliquer assez fortement le déboguage.

    Bref, cet aspect de .NET est à prendre en compte au moment du choix de la technologie de développement de la solution.

  • signaler à un administrateur
    Commentaire de jesusonline le 26/12/2007 16:25:10 administrateur CS

    Je rajoute que l'obfuscation ruine tous les programmes utilisant la reflection. Pour info en web (je connais pas assez le win), de nombreux contrôles utilisent la Reflection ... il faut donc faire très attention à ce point en utilisant un obfuscateur => http://www.vbfrance.com/tutoriaux/OBFUSCATION-NET_304.aspx

  • signaler à un administrateur
    Commentaire de Rocco123 le 26/12/2007 23:57:50

    Reflector (comme d'autres décompilateurs) se base sur des structures de code IL pour
    représenter un code de plus haut niveau (C# par exemple). Certains obfuscateurs
    modifient de manière subtile le code IL pour enlever toute structure qui pourrait
    laisser penser à un algorithme : des sauts, des conditions toujours vraies, des
    boucles factices... Reflector y perdra vite son latin. L'obfuscation n'est pas
    la meilleure sécurité, elle permet juste de rendre un programme plus difficile
    à comprendre... Une fonction utile aurait été de laisser le choix au programmeur
    s'il souhaite que certaines méthodes soient "masquées" et non utilisables par
    reflexion, tout comme cette option, qu'il faut ajouter à un assembly pour stopper
    ILDASM :

    [assembly: System.Runtime.CompilerServices.SuppressIldasm()]

    (Mais qui ne s'applique qu'à ILDASM).

    En tout cas, si le sujet des obfuscateurs vous interesse, je pourrais faire un
    tutorial pour expliquer un peu ma méthode (qui pour l'instant est surtout
    manuelle et qui fonctionne assez bien à mon goût).

  • signaler à un administrateur
    Commentaire de coq le 27/12/2007 00:47:16 administrateur CS

    Tiens, je ne le connaissais pas celui là, et j'avoue que j'ai du mal à comprendre son intérêt profond vu qu'apparemment c'est ildasm qui le traite pour déterminer s'il doit afficher ou non le code.

    Pour le tuto vas y si ça te tente, c'est toujours intéressant d'avoir des informations :-)

  • signaler à un administrateur
    Commentaire de jesusonline le 27/12/2007 01:38:58 administrateur CS

    J'avais déjà vu cet attribut : j'ai chercher à comprendre et ma conclusion est que cet attribut ne sert à rien ...

    Rocco123 : un tuto de qualité est toujours le bienvenue ;)

  • signaler à un administrateur
    Commentaire de Rocco123 le 27/12/2007 17:57:39

    Il ne sert à rien en effet, cet attribut date du temps de la première béta de .NET et a été abandonné là. Mais il est la preuve qu'il aurait été possible de créer des attributs empêchant par exemple la reflexion. Après avoir fouiné dans le code IL et la structure des fichiers .exe compilés par .NET, il apparaît que de nombreuses choses sont totalement inutiles comme le nom des classes (sauf pour la reflexion cela va de soi), jusqu'à présent, les nombreuses bidouilles que j'ai pu faire n'ont eu aucune incidence sur la stabilité du code, mais c'est vrai que cela peut conduire à des bugs si on obfusque n'importe comment (ex: les membres publics ne devraient pas être obfusqués).

    Ce qui m'a poussé à m'interesser à l'obfuscation est justement tous ces obfuscateurs payants qui soit-disant protègent une application. Pour moi, c'est simple, toute fonctionnalité que l'on veut protéger au maximum, il ne faut pas la mettre sur le poste du client... .NET est d'ailleurs prévu pour ça, les web services.

Ajouter un commentaire

Appels d'offres

Pub



CalendriCode

Mai 2008
LMMJVSD
   1234
567891011
12131415161718
19202122232425
262728293031 

Boutique

Boutique de goodies CodeS-SourceS