Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
[Artikel] NET Reflector
egrath
myCSharp.de - Member

Avatar #avatar-2119.jpg


Dabei seit:
Beiträge: 937
Herkunft: Österreich / Steyr

Themenstarter:

[Artikel] NET Reflector

beantworten | zitieren | melden

Reflector

Dieser Artikel soll einen grundlegenden Überblick über das Tool "Reflector" ([1]) und dessen benutzung geben.

Überblick

Der Reflector ist ein Tool, welches von Lutz Roeder (Microsoft) entwickelt wurde. Es handelt sich dabei um einen Inspektor und Analyser für .NET Assemblies. Das hauptsächliche Einsatzgebiet für den Reflector ist, in bestehenden Assemblies für welche kein Quellcode verfügbar ist einen tieferen Einblick zu bekommen - beispielsweise um sich selbst weiterzubilden ("Wie machen andere das") oder um Bugs aufzuspüren und gegebenenfalls um diese "herum" zu programmieren.
Abb. 1: .NET Reflector

Zu den Basisfunktionalitäten gehören unter anderem:
  • Betrachten der kompletten Struktur der Assembly (Klassen, Methoden, Hierachien)
  • Dekompilieren von Klassen und Methoden in eine .NET Sprache (C#, VB.NET, MSIL, Delphi, MC++, Chrome)
Der Reflector wurde von anfang an mit einer offenen API ausgestattet, welche es ermöglicht eigene Plug-Ins dafür zu entwickeln. Dies haben auch schon etliche Entwickler gemacht, weshalb es eine relativ große auswahl an Plug-Ins für die verschiedensten Anwendungsbereiche gibt.

Laden und Analysieren von Assemblies

Beim ersten start des Reflectors besteht die Auswahlmöglichkeit welches .NET Framework verwendet werden soll. Dies hat aber im weiteren Betrieb keine besondere Auswirkung, da aufgrund dieser entscheidung nur ein Set von Initial-Assemblys geladen wird, welche zur direkten Betrachtung bereit stehen. Wird beispielsweise eine .NET 3.5 Assembly geladen, welche auf die 3.5er mscorlib referenziert so wird diese automatisch nachgeladen auch wenn Framework 2.0 ausgewählt wurde.

Der Reflector stützt sich selbst auf den Reflectionsmechanismus welcher von .NET zur Verfügung gestellt wird.

Nachdem nun eine Assembly geladen wurde, kann man sich tiefer in deren Struktur einarbeiten. Bei einem Doppelklick auf einen Node wird das Dekompilierungsfenster geöffnet und der Quellcode in der ausgewählten Sprache dargestellt. Falls der entsprechende Node im Quellcode mittels XML Dokumentation dokumentiert wurde, so wird dieser in formatierter Form dargestellt:
Abb. 2: Reflector mit nach C# dekompilierter Methode und deren Dokumentation

Im Quellcodefenster sind Klassen und Methoden Hypertextartig verlinkt, so dass eine schnelle Navigation möglich ist. Ein nachträgliches Umschalten der Dekompilierungssprache ist ebenso möglich, das Ergebnis wird sofort dargestellt. Um sich im Navigationsbaum besser und vor allem schneller orientieren zu können, sind die entsprechenden Nodes mit einem eindeutigen Icon gekennzeichnet, welche den Type des Nodes wiederspiegeln.

Plug-Ins

Wie schon eingangs erwähnt wurden schon eine Unzahl von Add-Ins für den Reflector entwickelt ([2]). Die Gebräuchlichsten werden untenstehend mit einer kurzen Funktionsbeschreibung gelistet:

FileGenerator Schreibt das Dekompilat in ein File
Reflexil Ermöglicht das modifizieren (ersetzen/hinzufügen) von IL Code von Assemblies direkt im Reflector
AutoDiagramer Erzeugt ein Klassendiagramm der Assembly

Die Installation von Plug-Ins läuft grundsätzlich immer nach dem gleichen Schema ab:
  • Downloaden des Plug-Ins
  • Entpacken in ein beliebiges Verzeichnis
  • Hinzufügen im Reflector unter "View->Add-Ins->Add"
Sollte der Installationsweg von diesem Standard abweichen, so stellt der Autor üblicherweise eine gesonderte Anleitung zur verfügung.

Hilfe gegen den Reflector

Wenn man sich zum ersten mal mit dem Reflector beschäftigt wird man feststellen dass dies ein sehr mächtiges, zur gleichen Zeit jedoch gefährliches Werkzeug sein kann, da man damit relativ einfach an interne Strukturen herankommt - was nicht immer gewünscht sein kann. Von diesem Problem sind im allgemeinen beinahe alle verwalteten Sprachen betroffen (so z.b. auch Java) da der Zwischencode (IL) in einer vom ursprünglichen Programmcode relativ unabstrahierten Form vorliegt, sowie zusätzlich noch viele Metadaten in den Assemblies enthalten sind (Dokumentationen, etc.)

Will man die Internas seiner Assemblies nicht preisgeben, so bleibt einem nur der Versuch diese zu verschleiern - für diesen Zweck gibt es Obfuskatoren, welche Klassennamen, Methodennamen und ähnliches so umbenennen dass eine Analyse mit dem Reflector erschwert wird. Einen absolut wasserdichten Schutz gibt es allerdings nicht - man kann nur versuchen die Aufwandsgrenze so weit in die Höhe zu treiben dass es sich nicht mehr lohnt die notwendige Zeit zu investieren.

Referenzen

[1] http://www.aisto.com/roeder/dotnet
[2] http://www.codeplex.com/reflectoraddins
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von egrath am .
private Nachricht | Beiträge des Benutzers
zero_x
myCSharp.de - Member

Avatar #avatar-2567.gif


Dabei seit:
Beiträge: 1069
Herkunft: Koblenz

beantworten | zitieren | melden

Hallo egrath,

einige weitere Informationen gibt es in der FAQ: [FAQ] .net Assembly vor Disassembling schützen (Obfuscator) . Ansonsten gibt es hier noch einige Informationen hier: http://www.hackerboard.de/thread.php?threadid=37963

zero_x
zero_x | myCSharp.de - gemeinsam mehr erreichen

Für längere Zeit inaktiv.
private Nachricht | Beiträge des Benutzers