.NET Verständnisfrage

[Monger]

Ich hab heute nicht schlecht gestaunt, als mir ein Kollege gezeigt hat wie man sich diverse .NET DLLs - auch von Microsoft - in Klartext anschauen kann. Das war absolut astreiner Code, inklusive Methoden- und Variablennamen und schön strukturiertem Code.

Das hat mich verwirrt, und deshalb wollte ich mal hier nachfragen: was liegt denn in den Assemblies denn wirklich drin?

Bisher habe ich naiverweise angenommen, dass in den .NET DLLs nur der IL-Code liegt, und so ein disassemblieren zwar theoretisch möglich, aber äußerst unschön ist.
Mein Kollege meinte jetzt, dass man auf die DLLs üblicherweise noch einen Obfuscator loslässt, um den Code unkenntlich zu machen. Jetzt frage ich mich: warum ist das denn überhaupt nötig? Warum kann ich in den DLLs nicht einfach den Quellcode über Bord kippen, und nur den IL-Code behalten? Brauche ich die Quelle aus irgendeinem Grund noch zwingend?

[Gast]

http://code-inside.de/blog/2008/01/17/net-source-code-nun-verffentlicht/

[Demirug]

Da ist kein Quellcode drin. Nur der IL Code und Metadata. Die Metadaten beschreiben das Interface der Klassen also genau das was du auch mit Reflektion bekommen kannst. Wenn du dir den Reflector genau anschaust wirst du feststellen das er die für die gleiche DLL Code in unterschiedlichen Sprachen erzeugen kann. Er ist auch nicht wirklich ganz identisch mit dem ursprünglichen Code. Zum Beispiel fehlen bei allen lokalen Variablen die Namen.

[Monger]

Und das disassemblieren geht so gut?!? Ich bin beeindruckt. Ich mein... der IL Code ist ja ziemlich kryptisch. Kennt der denn überhaupt Schleifen o.ä.?


Okay, dann lass mich die Frage anders formulieren: wie schützt man denn dann sein Know How? So kann ja im Prinzip die Konkurrenz problemlos Teile meines Quellcode kopieren.

[Trap]

Okay, dann lass mich die Frage anders formulieren: wie schützt man denn dann sein Know How? So kann ja im Prinzip die Konkurrenz problemlos Teile meines Quellcode kopieren.
Wenn es um zeitkritische Algorithmen geht: kann man nicht. Auch in C oder Assembler nicht. Jemand der sich mit reverse engineering auskennt reicht.

Bei allem anderen kann man es mit Obfuscation beliebig kompliziert machen, aber unmöglich wird es nie.

[PatkIllA]

Und du bist sicher, dass das nicht der veröffentlichte Quellcode war?

[Trap]

Und du bist sicher, dass das nicht der veröffentlichte Quellcode war?
Decompiler für VM-Sprachen sind sehr gut wenn man keinen Obfuscator benutz.

Für Java kann man da ein paar Beispiele angucken: http://www.program-transformation.org/Transform/JavaDecompilerTests

[SGT.Hawk]

Ja,das mit der VM stimmt.Eclipse hatte mal unverständigerweise meine src verhunzt, waren alle nicht mehr zu lesen, aber der Byte Code war noch da, mit JAD war das kein Problem. Ich konnte mich an den source ein wenig erinnern.Der hatte es ganz genau hinbekommen.:eek:

[Gast]

Und das disassemblieren geht so gut?!?disassemblieren geht sogar sehr gut. Disassemblieren bedeutet nämlich, sich den Assembler-Code anzeigen zu lassen ;)
Das was du vermutlich meinst ist nicht Disassemblierung, sondern Decompilierung.

Jedenfalls heißt in Visual Studio das Fenster wo Assembler-Code angezeigt wird Disassemblierung. Macht auch Sinn: der Assembler assembliert den Assembler-Code. Will man aus dem Assemblat den Assembler-Code zurückgewinnen, muß man das umgekehrte machen, also disassemblieren.