.net-Strategie von Microsoft (?)

[sh17]

Mal ne Frage zur Investitionssicherheit: Wie sicher sind eigentlich Lösungen wie Dotfuscator, die .NET-Code verschleiern. Ich hab mal Beispielhaft einige Assemblys decompiliert. Sieht auf den ersten Blick ziemlich durcheinander aus. Kann mit entsprechenden Aufwand nicht aber doch lesbarer Code erzeugt werden?

Erschreckend finde ich, wie viele kommerzielle Produkte diesen Schutz nicht einsetzen. Ich kenne einige Programme/Bibliotheken, wo ich den kompletten Quellcode wiederherstellen kann, der ordentlich neu übersetzt werden kann und auch funktioniert.

Sven

[phXql]

Wie mein Prof schon zu java sagte: Hier ist der JAD, der Java Decompiler. Dann gibts hier gegen den JAD den Obfuscator, und dann hier gegen den Obfuscator den Deobfuscator.

Implementiert kritische Codeteile einfach als unmanaged code und ruft ihn über COM, PInvoke, Pipes, TCP/IP etc. auf. Is das sicherste.

Oder programmiert einfach open source. Mich stört es nicht wenn jemand meine Projekte dekompiliert, da eh fast alle unter der GPL

[Insider2004]

Ich benutze .net nicht, weil es einfach zu langsam ist. Siehe die Delphi 2007 IDE.

[Dax]

Zitat von sh17:

Mal ne Frage zur Investitionssicherheit: Wie sicher sind eigentlich Lösungen wie Dotfuscator, die .NET-Code verschleiern. Ich hab mal Beispielhaft einige Assemblys decompiliert. Sieht auf den ersten Blick ziemlich durcheinander aus. Kann mit entsprechenden Aufwand nicht aber doch lesbarer Code erzeugt werden?

Die Obfuskatoren sind so sicher, wie du sie arbeiten lässt. Manche Aktionen bringen sogar die Runtime durcheinander - sind aber trotzdem gültig. In der Regel aber bereiten sie keine Probleme und produzieren genau so lesbare Disassemblies wie Delphi auch - gut, man weiss, was eine Methode ist und was nicht, aber das kann mit guten Disassemblern auch von Delphi-Apps aus wieder herstellen. Generell kann man von *allem* ausgehend lesbaren Code erzeugen.

Zitat von sh17:

Erschreckend finde ich, wie viele kommerzielle Produkte diesen Schutz nicht einsetzen. Ich kenne einige Programme/Bibliotheken, wo ich den kompletten Quellcode wiederherstellen kann, der ordentlich neu übersetzt werden kann und auch funktioniert.

Ja, das mache ich auch nicht - warum auch? Wenn jemand deinen Code haben will, bekommt er ihn. Unter .NET geht das mit einem einfachen Disassembler, der IL-Code auswirft. Mit nativen Apps geht das mit komplexen Disassemblern (es gibt welche, die C-Code produzieren können), die Regeln sind die selben - nur macht .NET die Geschichte durch das Prinzip der Typsicherheit einfacher.

[jfheins]

Zitat von Insider2004:

Ich benutze .net nicht, weil es einfach zu langsam ist. Siehe die Delphi 2007 IDE.

Meinst du Delphi.NET oder .NET allgemein?

Was Delphi.NET angeht, kann man dir nur zustimmen (ist mehr so ne Portierung um der Portierug willen - was ich so gehört hab)
aber allgemein kannst du .NET nicht einfach als "lahm" geißeln. Mircrosoft hatte sicher nicht wenige Entwickler und sicher nicht wenig Geld da reingesteckt, so irre unoptimiert kann es fast nicht sein - es sei denn, die Programmierer haben von dem Geld Lustreisen gebucht

Mach doch mal ein Testprogramm, z.B. Quicksort in Delphi (TStringlist?), C++ (gibts bestimmt in der MFC), C# (Muss man da was programmieren?), Java und meinentwegen Delphi.NET

[Bernhard Geyer]

Zitat von Macci:

.NET ist eine Konkurrenz zu Java. Als Microsoft damals J++ herausbrachte, war das so beliebt, dass Sun Microsoft promt verklagte, weil die mit J++ entwickelten Java-Anwendungen zu windowsähnlich waren.

Mein Stand ist das Sun Java verklagte da mit J++ entwickelte Programme nur noch auf Windows (teilweise nur noch im IE) lauffähig waren und damit ein Hauptaspekt/Zielrichtung von Java ad absurdum geführt hat. Nicht wenige Entwickler haben erst nach fertigstellung ihrer Anwendung gemerkt das sie sich das Anti-Pattern Vendor-Lockin eingebrockt haben

Zitat von Macci:

Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen. Deswegen bleibe ich bei Delphi und C++.

Das ist ein Hauptvorteil von managed Frameworks das die bei C++ so geliebten und oft für Probleme sorgenden Void-Pointer nicht mehr möglich sind. Zeiger in dem sind der wilden "Pointerrei" gibt es nicht mehr (und damit ist auch das beliebt "In's Knie schießen" von C++ viel schwerer möglich (fast unmöglich)). Zeiger gibt es, sind jedoch typisierte Referenzen und auch das wilde harte (und oft fehlerhafte Typcasting ist mehr möglich).

Zitat von sh17:

Mal ne Frage zur Investitionssicherheit: Wie sicher sind eigentlich Lösungen wie Dotfuscator, die .NET-Code verschleiern. Ich hab mal Beispielhaft einige Assemblys decompiliert. Sieht auf den ersten Blick ziemlich durcheinander aus. Kann mit entsprechenden Aufwand nicht aber doch lesbarer Code erzeugt werden?

Nö. Wie willst du ohne Infos was die Variable aacdgh eigentlich bedeutet hat auf den Namen kommen. Du mußt dann von den resten der ursprünglichen Namensgebung auf die Bedeutung kommen.

Zitat von sh17:

Erschreckend finde ich, wie viele kommerzielle Produkte diesen Schutz nicht einsetzen. Ich kenne einige Programme/Bibliotheken, wo ich den kompletten Quellcode wiederherstellen kann, der ordentlich neu übersetzt werden kann und auch funktioniert.

Wieso sollten sie? Im Bereich Delphi würde ich keine Komponente einsetzen bei der ich nicht den Quellcode habe. Für einen Komponentenhersteller gibt es genügend Ansatzpunkte konkurrente zu erkennen die Quellcode-Klau betreiben. Denn gute Komponentenhersteller implementieren oft eine gesamte aufeinander aufbauende Bibliothek und ein Konkurrent kann hier nicht ein paar Zeilen klauen ohne das drum herum. Und nimmt er alles, so fliegt er sehr schnell auf.

[delphirocks]

Probiert mal den Vergleich:

15 Sekunden in .NET vs 4 Sekunden in Delphi32 - die string.format Routine ist extrem langsam in .NET.
Genau wie das Zeichnen der Winforms Controls.

In Delphi sieht man die Anzeige sofort, in C# erst am Ende des Durchlaufes. Was wiederum heißt, daß ich in .NET Extra-Code schreiben muss, wenn ich will das das Ding sofort angezeigt wird.

Ich programmiere zur Zeit (leider) hauptsächlich C#. Was aber bringt die ganze Eleganz, wenn das Endergebnis nicht entspricht?

C#:
private void button1_Click(object sender, EventArgs e)
{
List<string> sl = new List<string>();
listBox1.Items.Add(DateTime.Now.ToLongTimeString() );
for (int i = 1; i <= 10000000; i++)
sl.Add(string.Format("hello{0}", i));
listBox1.Items.Add(DateTime.Now.ToLongTimeString() );
}

Delphi:
procedure TForm4.Button1Click(Sender: TObject);
var
sl:TStringList;
i:integer;
begin

memo1.Lines.Add(TimeToStr(now));
sl:=TStringList.Create;

for i:=1 to 10000000 do
sl.Add(Format('hello%d',[i]));

sl.Free;
memo1.Lines.Add(TimeToStr(now));
end;

[sh17]

Zitat von Bernhard Geyer:

Wieso sollten sie? Im Bereich Delphi würde ich keine Komponente einsetzen bei der ich nicht den Quellcode habe. Für einen Komponentenhersteller gibt es genügend Ansatzpunkte konkurrente zu erkennen die Quellcode-Klau betreiben. Denn gute Komponentenhersteller implementieren oft eine gesamte aufeinander aufbauende Bibliothek und ein Konkurrent kann hier nicht ein paar Zeilen klauen ohne das drum herum. Und nimmt er alles, so fliegt er sehr schnell auf.

Würde ich auch gar nicht wollen. Aber man kann eine ganze Menge über die Lösung lernen, da der erzeugte Quellcode wirklich sehr gut aussieht. Ich wüsste jetzt keinen Decompiler, der mir ein Win32-Programm so gut decompiliert. Und in Bereichen, wo man sich von der Konkurrenz durch Innovation abgrenzen muss, ist ungeschützter Code schon ein Risiko.

[Jelly]

Zitat von delphirocks:

15 Sekunden in .NET vs 4 Sekunden in Delphi32 - die string.format Routine ist extrem langsam in .NET.

Für grössere Stringmanipulationen gibts ja auch extra die StringBuilder Klasse.

Wer sucht, findet für beide Welten entsprechende Beispiele, um das andere schlecht zu machen... Aber was soll diese Diskussion überhaupt? Man soll einfach nur die Umgebung wählen, die für einen am geeignetesten ist.

Lege ich viel Wert auf Gui... nehm ich persönlich lieber Delphi. Wenn ich massiv mit Datenbanken arbeite, gerade mit dem MSSQL, bietet mit ADO.NET einfach mehr. Gerade auch, was das Databinding und auch andere Fähigkeiten betrifft. Das Konzept ist zwar nicht immer einfach zu verstehen, aber sehr performant. Es gibt noch viele Beispiele für Delphi und viele für .NET. Aber daraus einen Schluss zu ziehen, was denn nun besser sein soll ist doch gar nicht möglich.

Wenn ich grosse Anwendungen schreiben muss, mit vielen Schnittstellen unter einzelnen Programmmodulen und auch sogar über Netzwerkgrenzen hinweg... Da bevorzuge ich auch wieder .NET, da mittels den Webservices, Remoting, WCF sehr mächtige Werkzeuge zur Verfügung stehen, um miteinander zu kommunizieren. Diese Arbeit fällt unter Delphi imho wesentlich schwerfälliger aus.

Mich würde mal interessieren wieviele Leute, die hier in diesem Thread bislang gepostet haben, und die .NET nur schlecht machen wollen, auch wirklich schon ihre Erfahrung mit .NET gesammelt haben. Oder ob die meisten von ihnen nur was schreiben, weil sie .NET nicht kennen und deshalb pauschal Delphi besser ist.

[Macci]

Naja, also mit Pointern kann man so einiges machen- wenn man es richtig macht. Deswegen gefällt es mir nicht, dass es die in .NET nicht mehr gibt (was aber auf einer virtuellen Umgebung wohl nicht oder nur sehr schwer zu realisieren wäre). Wer sich mit Pointern nicht auskennt, sollte ohnehin darauf verzichten.

Das Problem an den ganzen platformunabhängingen System, wie eben Java oder .NET, ist einfach, dass die viel langsamer sind. Auch wenn manche was anderes behaupten, ist es nun mal so, dass ein Prozessor nativen Code VIEL schneller durchlaufen kann, als wenn er einen virtuellen Code erst mühsam über den Umweg einer virtuellen Maschine in nativen Code übersetzen muss. Und diese Übersetzung ist nunmal nötig. Ich wüsste auch nicht, dass es von Spielen wie z.B. Unreal oder Need for Speed Java Versionen gibt, die genauso gute Grafik haben. Obwohl man es theoretisch in Java nachprogrammieren könnte (auch das was die Grafikkarte tut, kann man ja in einer virtuellen Umgebung virtuell berechnen).