Forensuche

Hallo luns,

ich selbst kenne mich mit dem Thema nur am Rande aus. Aber am 22.12.2004 schieb VizOne:

Ein obfuscator ist Dotfuscator, welches in der Community-Edition bei VS.NET2003 mitgeliefert wird. Für einen besseren obfuscator muss man allerdings oft tief in die Tasche greifen.

Nach dem du bisher keine Antworten bekommen hast, scheint sich an der Situation also nichts geändert zu haben.

herbivore

Ohne Obfuscation kann man den kompletten Quellcode per Reflector(z.B.) per Reverse Engineering sichtbar machen. Das geht so gut, das man den Reflector auf eine kompilierte Release-Version ansetzt, den Quellcode den man erhält in ein leeres VS-Projekt kopiert und dann ohne jegliche Änderung kompilieren kann.

Es sind lediglich kosmetische Fehler vorhanden, z. B. ist der Variablenname von lokalen Variablen nicht mehr enthalten und Schleifen werden zum Beispiel statt mit Foreach(...) mit For(...;Irgendwas.Enumerator;...) dargestellt.
Aber man erhält Quasi den kompletten Quellcode!

Meiner Meinung nach eines der größten Defizite von .Net.

(Wenn man das gerne hat, kann man aus der kompilierten C#-Datei natürlich auch Delphi oder VB.Net Quellcode erstellen).

Such mal im Forum nach Obfuscation/Obfuscator, da gibt es bereits mehrere Themen zu!

Grüße Christoph

Ich verfolge diesen Thread schon seit Anfang an und habe bis heute nicht verstanden, warum der Protector von Remotesoft nicht erwähnt wird. Dieser soll laut Remotesoft eine bessere Sicherheit bieten als Obfuscator.

Links:

.NET:
.NET Assembly vor Disassemblern schützen
Assembly Code schützen
ILDASM verhindern
Obfuscator gesucht / Suche Freeware Obfuscator
List of obfuscators for .NET

Umfrage: Nutzt ihr einen Obfuscator?

Schutz vor Deobfuscation

WinRT:
WinRT Codesicherheit: Kann der "Quellcode" wie bei .NET angesehen werden? Welche Obfuscatoren gibts?

Wird zwar nicht die Antwort sein, die du hören willst, aber im Prinzip gar nicht.
Alles was du machen kannst, is den Code unlesbar machen,
dazu gibts sogenannte Obfuscator:

Dotfuscator

also ich denk per obfuscator schützen ist schon recht gut, klappte ja bei ArenaWars auch, und da sieht man auch das man nix wiederfindet, selbt der coder nicht.

Naja, P-Code-Interpreter ist nicht der passende egriff (-> VB), aber du meinst sicher IL-JIT-Compiler 😁

Nun, mit solchem Zwischencode erhält man sich binäre Kompatibilität. Wenn man lediglich eine Bibliothek anbieten würde, die auf verschiedenen Plattformen erhältlich ist, ansonsten aber nativen Code erzeugt, muss man jedes mal das Programm neu kompilieren. IL-Code vereinfacht es zudem, neue Sprachen für .NET zu erschließen. Da IL-Code auf einem höheren Niveau arbeitet, muss man sich als Programmiersprachenanbieter nicht um Plattformdetails kümmern.

Schließlich und endlich kommen noch Argumente wie Laufzeitoptimierung hinzu. IL-Code hat das Potenzial, von der Laufzeit abhänig von der Plattform optimiert zu werden (z.B. für MMX, 3DNow!, SSE, SSE2, Multiprozessoren usw.).

Auf der anderen Seite zahlt man natürlich auch den Preis, dass IL-Code leichter dekompiliert werden kann. Wenn du mal nach "obfuscator" suchst, wirst du aber Mittel und Wege finden, die es erschweren.

MfG VizOne

Original von maxE
@LordK:

Da das Programm auf dem .NET Framework basiert, könntest du die Exe mal durch den Reflecor jagen (siehe Download Datenbank).
Damit sollte es recht einfach sein, heraus zu bekommen wie das Auslesen der Temperatur funktioniert 8)

Geht leider nicht, da wurde wohl ein Obfuscator benutzt...

Hab mir den Aspose.Obfuscator mal angeschaut. Nunja, das übliche 🙂 Mit einer kleiner Assembly hats funktioniert, aber bei einer größeren Anwendung mit diversen Abhängigkeit läuft der Obfuscator auf Fehler. Auf das Freeware-Zeugs ist eben weniger verlass. Ich bin immer noch für selbstschreiben, aber allein hab ich da keinen Nerv drauf g

Eine einigermaßen gut funktionierende kostenlose Variante habe ich jetzt gefunden:
Aspose.Obfuscator
Hier fehlt nur die Option ILDASM ganz zu verhindern, welche in Dotfuscator und Spikes angeboten wird (soll wohl durch das Hinzufügen von Meta-Tags in der Assembly funktionieren).

Original von NewYoda
Danke, hab' auch noch ein weiteres Programm gefunden:
Spices
Leider sind diese Programme ziemlich teuer.

Deshalb hatte ich auch mal vorgeschlagen das man so einen Obfuscator vielleicht mal hier in der Community entwickeln könnte. Kostenlos gibts ja sonst scheinbar nichts vernünftiges.

Es gibt Programme (obfuscators), die den IL Code so verschleiern, dass es schwierig wird, etwas sinnvolles daraus zu interpretieren. Ein obfuscator ist Dotfuscator, welches in der Community-Edition bei VS.NET2003 mitgeliefert wird. Für einen besseren obfuscator muss man allerdings oft tief in die Tasche greifen.

MfG VizOne

Obwohl die genannten Lösungen natürlich die empfehlenswerteren Varianten sind, möchte ich trotzdem - der Vollständigkeit halber - darauf hinweisen, dass du auch einzelne .cs-Dateien als Referenz zufügen kannst.

Dazu klickst du im Projekt-Explorer auf den Ordner, der die Verweise später enthalten soll, "Vorhandenes Element hinzufügen" und wählst die entsprechenden Dateien aus. Würdest du jetzt auf Öffnen klicken, würden die Datein kopiert werden. Wenn du aber auf den kleinen Pfeil rechts beim Öffnen-Button klickst und "Datei verknüpfen" wählst, wird lediglich eine Referenz zu dieser/n Datei(en) zum Projekt zugefügt. Sie sind an dem kleinen Pfeil unten links zu erkennen (wie normale Windows-Verknüpfungen). Wenn du dir den Projektordner im Explorer anschaust, wirst du sehen, dass keine Datei in das Projekt kopiert wurde. Wann und wo auch immer die verknüpften Dateien verändert werden (auch außerhalb von Visual Studio), dein Projekt enthält immer die aktuellste Version.

Du musst allerdings bedenken, dass jede Änderung, die du an den Dateien vornimmst, für alle Projekte gelten, die diese Dateien referenzieren. Also bitte aufpassen!

Warum würde man solche Verknüpfungen überhaupt wollen? Zum Beispiel um den Overhead einer weiteren DLL zu sparen (bei Embedded Device ist das durchaus ein Thema) oder um einem Obfuscator den Code besser schützen zu lassen (nicht öffentlich gemachter Code kann durch einen Obfuscator in der Regel besser verschleiert werden, da keine Abhängigkeiten bei Namen bestehen etc.).

MfG VizOne

Wobei ja bei Webprojekten der Zugriff auf die DLL eher recht schwer wird 🙂

Wenn du allerdings PHP Seiten für Intranet-Lösungen an den Kunden weiter gibst, dann kann er diesen genauso lesen ...

Wie Viz schon sagte, Obfuscator zum verschleiern, nicht verschlüsseln und an sonsten COM!

Ich sehe da zwei Möglichkeiten:
nicht-öffentliche Teile durch nen Obfuscator jagen und/oder "kritische" Teile in Native DLLs auslagern.

MfG VizOne

Man kann die Codebehind Dateien ganz normal compilieren, sodass man auf dem Server nur noch DLLs und aspx/asmx Dateien hat. Allerdings sind die DLLs genauso leicht zu dekompilieren wir andere .NET assemblies. Und einen Obfuscator kann man bei ASP.NET nur bedingt einsetzen.

Sagen wir es mal so: für nen Otto-Normal-Kunden ist das vollkommen in Ordnung. Er weiß höchst wahrscheinlich nicht mal, dass er die DLLs wieder dekompilieren kann.

MFG VizOne

Hallo,

ich habe da eine wichtige grundlegende Frage bezüglich ASP.NET:

Angenommen man will ein in PHP geschriebenes Software-Produkt verkaufen, so bleibt einem zum Schutz des geistigen Eigentums ja nur ein Obfuscator oder der teure Zend-Compiler. Wie ist das in ASP.NET? Kann man die Programme hier vorher ohne teure Zusatzsoftware etc. kompilieren und so ausliefern? Wie handhabt Ihr das?

Danke für Eure Antworten!

Gruß,
Sarky

Zu 2.:
Korrekt ist die 2. Variante von zovax, da sich deine Klasse mit den verschiedensten Funktionalitäten vom logischen Ablauf her nicht um die Ausgabe der Fehler kümmert, sondern dies sollte immer in der Endanwendung geschehen. Beispielsweise möchtest du das ein Fehler später in einer Anwendung unter den Tisch fällt und nicht angezeigt wird usw. Du solltest dir dann übrigens auch eine eigene Excpetion-Klasse erstellen die von ApplicationException ableitet und diese werfen.

Zu 3.:
Du meinst sogenannte Obfuscator. Sie verschlüßeln nicht, sondern sie machen das Klassengerüst schwer bzw. unlesbar. Größter Nachteil: Bei Bibliotheken, die Funktionen nach außen zur Verfügung stellen sollen, ist es nur für private Member einsetztbar, es sei den du möchtest in deinem Aufruf-Code Zeilen wie

A.b1(4711, "irgendein string");

schreiben. Das Problem ist außerdem bei den Obfuscator das die kostenlosen Versionen meist auch nicht viel taugen bzw. zu viele Einschränkungen haben. Korrigier mich jemand, wenn ich damit falsch liege 🙂

Richtiges Verschlüßeln ist ansonsten nicht möglich, da letztendlich immer MSIL-Code in den Executables und Libraries vorliegen muß und dieser lässt sich nunmal dekompilieren. Es gibt aber noch Ansätzte den MSIL-Code so umzustrukturieren, das es die Dekompiler schwerer haben, bestimmte Code-Konstrukte zu erkennen.

Schon beim aktuellen VS ist ein Obfuscator dabei ... (allerdings nur als "community edition", also wohl mit ein par deaktivierten features) ... wie auch immer, ich hoffe ich werde nie gezwungen sowas hässliches wie nen obfuscator einzusetzen...

es gibt verscheiden möglichkeiten den code zu schützen

zb http://www.remotesoft.com/salamander/obfuscator.html

wenn ich mich nicht irre ist bei der nächsten version der Framework oder VS ein Obfuscator sogar dabei.

Original von Code-Hacker

• Visionierungssystem für Entwickler

Hmm, ich wollte auch schon immer mal meine Visionen festhalten 😉 Ne, Versionierungssystem ist schon ne interessante und auch nützliche Sache. Visual Source Safe ist ja das abschreckende Beispiel 🙂

Okay, dann mach ich auch nochmal einen Vorschlag. Sowas fänd ich zumindest ganz interessant: Also eine dotnet Decompiler, der eben aus dem IL-Code wieder C#-Quellcode erstellt. Dazu passend wäre auch so eine Obfuscating-Funktionalität. Könnte man auch etwas weiter treiben und direkt den IL-Asm-Code ändern, damit das dekompilieren schwieriger wird. Und nett wäre vielleicht auch ein Debugging Tool für Assemblys die im Release also ohne Debug-Code kompiliert wurden. Zusammenfassend:
*IL Disassembler *Decompiler zu C# *Obfuscator *IL-Code verändern um decompiling zu erschweren *Debugging/Changing Tool für released Assemblys

Ist aber nicht so kompliziert, wies jetzt vielleicht aussieht 🙂 Auf jeden Fall wär ein Decompiler was schönes...