.NET ist dekompilierbar ?

Hallo Leute,

kann mir mal einer ganau sagen, was es mit diesen Gerüchten auf sich hat, das man Programme (oder auch Klassen-DLLs) die z.B. mit VB 2005.NET erstellt wurden, „leicht“ dekompilieren kann.

Ich möchte gerne mal genau wissen, was genau dabei „herauskommt“, wenn man sowas macht, und „wem“ das was nützen könnte ?

Wenn dem so ist, das das angeblich so einfach sein soll, sowas zu dekompilieren, warum hat Microsoft das denn überhaupt gemacht ??? Verstehe ich nicht :frowning:

Kann mir mal einer sagen, wo es einen Dekompiler gibt, dann würde ich das selber gerne mal an meinen Programmen und DLLs ausprobieren, um mir ein Bild machen zu können, welche „Gefahren“ für mich (geistiges Eigentum) entstehen.

Oder kann mir mal jemand einen Code schicken, der kompiliert wurde, und wie das dann hinterher aussieht, wenn so eine Dekompiler darauf losgelassen wurde.

Danke.

Jürgen

Auch hallo.

Kann mir mal einer sagen, wo es einen Dekompiler gibt, dann
würde ich das selber gerne mal an meinen Programmen und DLLs
ausprobieren, um mir ein Bild machen zu können, welche
„Gefahren“ für mich (geistiges Eigentum) entstehen.

Also wie die Umfrage des dotnet Magazins unter http://www.dotnet-magazin.de/itr/service/show.php3?i…
andeutet, ist das Problem bekannt und sollte sich mittels eines Obfuscators beheben lassen.

HTH
mfg M.L.

Hallo!

.NET Sprachen (C#, VB.NET, J#, …) zeichnen sich eben dadurch aus, dass sie zunächst in sog. IL (intermediate language) übersetzt werden (so eine Art „Hochassembler“) und diese IL dann von der Common Language Runtime (CLR) ausgeführt wird (das Vorgehen bei Java ist übrigens ähnlich).

Aus dieser IL lässt sich der Sourcecode recht gut wieder herstellen.
Schau’ mal auf http://www.aisto.com/roeder/dotnet/, dort findet sich ein Tool namens Reflector, das ist quasi DER Decompiler für .NET.

Mit Obfuscatoren wird meist versucht, den Leuten, die solche dekompilierten Assemblies zu verstehen versuchen, das Leben schwer zu machen, indem bspw. interne Methodennamen oder Properties in nicht bedeutungstragene Bezeichnungen geändert werden (wenn die Methoden „A“, „B“, „AA“ usw. heissen, tut man sich schon etwas schwerer, herauszufinden, was sie tun).
Aber bei öffentlichen Methoden oder Eigenschaften einer Klasse beissen sich solche Obfuscatoren i.d.R. die Zähne aus, weil man ja eben von außen auf eine Methode mit einem bestimmten Namen zugreift, und wenn die dann plötzlich anders heisst, dann kracht’s natürlich.
Also sind insgesamt solche Tools zwar ganz nett, aber das generelle Problem, dass etwas disassembliert/decompiliert werden kann, lösen sie nicht.

Gruß,
Martin

Hallo Martin, ich danke sehr für deine sehr lange Antwort, aber meine Kernfragen hast du nicht beantwortet :frowning:


Ich möchte gerne mal genau wissen, was genau dabei „herauskommt“, wenn man sowas macht, und „wem“ das was nützen könnte ?

Wenn dem so ist, das das angeblich so einfach sein soll, sowas zu dekompilieren, warum hat Microsoft das denn überhaupt gemacht ??? Verstehe ich nicht :frowning:

Danke auch dir, aber auch das hilft mir nicht weiter…:frowning:

Ich bräuchte Antworten auf meine Kernfragen.

Hallo Jürgen!
Da Du offenbar nicht gewillt bist, es mit den angegebenen Links selbst auszuprobieren :smile:, hier das „was“ ganz ausführlich:
Kleines C# Programm:

using System;

public class Testerle
{
 public static void Main(string[] args)
 {
 string gruss = "Hello ";
 if (args.GetLength(0) \> 0)
 Console.WriteLine(gruss + args[0]);
 else
 Console.WriteLine("Hello World");
 }
}

Das entstandene Executable mit dem (im Framework SDK enthaltenen) CLR Disassembler „ildasm“ betrachtet:

.method public hidebysig static void Main(string[] args) cil managed
{
 .entrypoint
 // Codegröße 43 (0x2b)
 .maxstack 3
 .locals init (string V\_0)
 IL\_0000: ldstr "Hello "
 IL\_0005: stloc.0
 IL\_0006: ldarg.0
 IL\_0007: ldc.i4.0
 IL\_0008: callvirt instance int32 [mscorlib]System.Array::GetLength(int32)
 IL\_000d: ldc.i4.0
 IL\_000e: ble.s IL\_0020
 IL\_0010: ldloc.0
 IL\_0011: ldarg.0
 IL\_0012: ldc.i4.0
 IL\_0013: ldelem.ref
 IL\_0014: call string [mscorlib]System.String::Concat(string,
 string)
 IL\_0019: call void [mscorlib]System.Console::WriteLine(string)
 IL\_001e: br.s IL\_002a
 IL\_0020: ldstr "Hello World"
 IL\_0025: call void [mscorlib]System.Console::WriteLine(string)
 IL\_002a: ret
} // end of method Testerle::Main

Und schließlich mit Reflector angeschaut:

public static void Main(string[] args)
{
 string text1 = "Hello ";
 if (args.GetLength(0) \> 0)
 {
 Console.WriteLine(text1 + args[0]);
 }
 else
 {
 Console.WriteLine("Hello World");
 }
}

Zum „wer“: Jeder, der sich fremden .NET-Code ansehen will.

Martin

Hallo Jürgen!
Da Du offenbar nicht gewillt bist, es mit den angegebenen
Links selbst auszuprobieren :smile:, hier das „was“ ganz
ausführlich:

Hallo Martin !

mittlerweile - schon vor deiner Antwort -habe ich mir auch so ein Programm runtergeladen, und meine mit VB.NET erstellt Klassenbibliothek DLL angeschaut. Es ist erschreckend :frowning:

Fragen bleiben dennoch offen; WARUM hat Microsoft so einen Mist gebaut ? Welcher ersthafte Programmierer wird sich nun noch mit .NET befassen, wenn er offensichtlich allerhöchste Anstrengungen unternehmen muss, um seinen Code mit speziellen Tools so zu verändern, das es in aller Regel dann mit solchen „Klau Programmen“ nicht mehr lesbar ist ?

Danke für alles.

Jürgen

Hallo an dieser Stelle.

Fragen bleiben dennoch offen; WARUM hat Microsoft so einen
Mist gebaut ? Welcher ersthafte Programmierer wird sich nun
noch mit .NET befassen, wenn er offensichtlich allerhöchste
Anstrengungen unternehmen muss, um seinen Code mit speziellen
Tools so zu verändern, das es in aller Regel dann mit solchen
„Klau Programmen“ nicht mehr lesbar ist ?

Tja, gute Frage…
Aber das neue dot.net Magazin 03/2006 nimmt sich des Themas Decompiler an: http://www.dotnet-magazin.de/itr/ausgaben/psecom,id,… (schade, kein Online Artikel…)

mfg M.L.

Hi,

da Java genauso decompilierbar ist, müßten ich fast keine „ernsthaften“ Entwickler mehr kennen.

Vielleicht steckt in Softwareentwicklung ja doch noch mehr als seinen Code zu verbergen.

Gruss
Quaser

Vielleicht steckt in Softwareentwicklung ja doch noch mehr als
seinen Code zu verbergen.

Hi,

ich will versuchen, das zu verstehen. Ich persönlich hätte ja (vielleicht) auch nicht viel zu verbergen. Was kann ich denn schon (programmieren). Und doch; es geht um eine komplette Warenwirtschaft, die ich von VB 6 auf VB.NET umstellen möchte. Egal wie viel oder wenig Geld ich damit verdiene (es ist wenig), so besteht doch die Gefahr (es sei denn, ich sehe das alles völlig falsch), das doch jemand auf die Idee kommt, und sagt; Mensch, das Programm ist gar nicht so schlecht, ich sehe mal, ob ich nicht irgendwie an den Code komme, dann verändert ich das ein wenig, und bringe es selber raus…

…wie gesagt, kann sein, das ich das alles total falsch sehe.

Aber wenn es wirklich so einfach ist, warum gibt z.B. Microsoft dann nicht auch den kompletten Code von Windows raus ? Warum geben andere grosse Softwarefirmen nicht den Code Ihrer (teuren) Programme raus ???

Und ich habe immer noch keine Antwort (ich zähle schon gar nicht mehr, wie oft ich hier schon gefragt habe), warum Microsoft so einen Mist überhaupt gemacht hat. Wenn das alles so toll wäre, und niemandem stören würde, müste es demnächst ja massenweise auf .Net umgestellte Programme geben…die man dann (vielleicht) alle gratis als Quellcode erhält.

Also wie gesagt, ich verstehe es nicht. Wahrscheinlich bin ich einfach nicht intelligent genug.

-(

Erklärst du es mir ?

Jürgen

Tja, gute Frage…
Aber das neue dot.net Magazin 03/2006 nimmt sich des Themas
Decompiler an:
http://www.dotnet-magazin.de/itr/ausgaben/psecom,id,…
(schade, kein Online Artikel…)

mfg M.L.

Hi, danke, ein guter Tipp. Die besorge ich mir, das will ich wissen.

Was du als „Mist“ interpretierst, ist nicht von Microsoft erdacht, sondern von Sun, und wurde erstmals mit Java realisiert. Die dahinter stehenden Prinzipien sind zu auslandend, um sie hier naeher zu erklaeren, jedenfalls ist es einfach ein anderer Ansatz zur Ausfuehrung von Code, eine Art Zwischenstufe zwischen Laufzeit-Interpretieren (zB php) und Kompilieren (zB C). Dass die Dateien so gut dekompilierbar sind ist „nur“ ein Nebeneffekt dieses Denkansatzes, der aber scheinbar immer mehr an Gueltigkeit gewinnt. In was fuer einer Welt leben wir denn, in der Firmen anderen Firmen, welche mehr am Gemeinwohl als am Profit interessiert sind, die Ideen klauen und damit Geld verdienen? Oh, moment… Microsoft… ich vergass…

Nunja, bei ausreichend groszen Applikationen ist aber das Verstehen und Aufarbeiten des Codes mit Kommentaren ausreichend zeitaufwaendig, um nichtmehr lohnend zu sein, also soo schlimm fuer proprietaeren Code ist es nicht :smile:

Hallo Valodim,

Was du als „Mist“ interpretierst, ist nicht von Microsoft
erdacht, sondern von Sun, und wurde erstmals mit Java
realisiert. Die dahinter stehenden Prinzipien sind zu
auslandend, um sie hier naeher zu erklaeren,

Ja, ist das sowas vielleicht, was Du meinst?
(http://de.wikipedia.org/wiki/Perl)

 Perl-Skripte werden in Textdateien mit beliebigem 
 Zeilentrennzeichen gespeichert. Beim Start eines Skripts 
 wird es vom Perl-Interpreter eingelesen, in **<u>Bytecode</u>** um-
 gewandelt und dieser dann ausgeführt. Der im Interpreter 
 integrierte Parser ist eine angepasste Version von GNU Bison.
 ...

Dass die Dateien so gut dekompilierbar sind ist „nur“ ein
Nebeneffekt dieses Denkansatzes, der aber scheinbar immer
mehr an Gueltigkeit gewinnt.

Dieser „Nebeneffekt“ ist imho so nicht existent,
denn wenn man den Quelltext schützen möchte,
kann man das auch. Tut man das nicht, bedeutet das
in den meisten Fällen, das man das auch nicht braucht.

In was fuer einer Welt leben wir denn, in der Firmen
anderen Firmen, welche mehr am Gemeinwohl als am Profit
interessiert sind, die Ideen klauen und damit Geld verdienen?

Ja klar. Gemeinwohl? Sun? Java?

LOL!

Oh, moment… Microsoft… ich vergass…

Alles war und ist letztlich Kampf um Marktmacht.
Was meinst Du, was VMware gerade macht? Oder
das gescholtene Microsoft? Siehe:
http://www.microsoft.com/germany/msdn/vstudio/expres…

oder (http://msdn.microsoft.com/vstudio/downloads/tools/jl…)

 The Java Language Conversion Assistant is a tool that automatically
 converts existing Java-language code into Microsoft Visual C# for 
 developers who want to move existing applications to the .NET 
 Framework.

oder: Der Sieg von ‚marketing over engineering‘
(http://www.galileocomputing.de/openbook/javainsel4/j…)

 Zunächst konnten sich nur wenige Anwender mit HotJava 
 anfreunden. So war es ein großes Glück, dass Netscape 
 sich entschied, die Java-Technologie zu lizenzieren.

Das ist sozusagen das legendäre „Microsoft-IBM-Event“
nochmal als Computersprache :wink:

Nunja, bei ausreichend groszen Applikationen ist aber das
Verstehen und Aufarbeiten des Codes mit Kommentaren
ausreichend zeitaufwaendig, um nichtmehr lohnend zu sein, also
soo schlimm fuer proprietaeren Code ist es nicht :smile:

Es gbit imho Technologien, .NET-code bei Bedarf
zu verschlüsseln.

Hehe - Wenn das schon bei simplem Perl kein Problem war:
(http://www.annocpan.org/~DCONWAY/Acme-Bleach-1.12/li…)

:wink:

Grüße

CMБ

> …was genau dabei „herauskommt“…
herauskommt tutet code :wink:

> „wem“ das was nützen könnte ?
nutzen: Reverseengeniering

> warum hat Microsoft das denn überhaupt gemacht ?
plattformunabhängigkeit, sprachinteroperabilität:
http://www.software-kompetenz.de/servlet/is/21842/
http://www.dotnetframework.de/dotnet/produkte/sprach…
gibt sicher noch andere gründe die mir grad nicht einfallen…

> „Gefahren“ für mich (geistiges Eigentum)
patente auf softwareimplementierte Erfindungen gibts in der eu doch noch garnicht… oder ?

falls du deinen code für so besonder schützenswert erachtest, kannst du natürlich auch direkt zu maschienencode compilieren anstatt zu IL.
das tool heisst „ngen.exe“ und ist beim .NET-Framework SDK mitdabei…
dann ist allerdings die plattformunabhängigkeit dachin… und man kann immer noch decompilieren… schlimmstenfalls zu assemblercode…

> …Code schicken…und wie das dann hinterher aussieht…
nein, googeln und decompilier musste schon selber :wink: