Forensuche

Hallo meisteralex,

siehe [FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

Ich denke, das wurde hier schon oft genug besprochen...
[FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

Hallo Zusammen,

bin vor Kurzem mit meinem Lizenzgenerator fertig geworden und wollte einfach mal nachfragen was ihr davon haltet...

Info: Der Client zieht sich ein Tool in dem er seine Daten eintragen kann und welches ein Hardwareprofil des Rechners erstellt.

(1) Schlüsselpaar mit dem Strong Name Tool (sn.exe) erstellen
(Mit dem snk File werden die LizenzPrüfer.dll und das Programm signiert)
(2) Erstellen der Lizenz.xml -
(2.1) Lizenzdatei enthält eine Signatur
(2.2) Es wird ein Hash der Assembly in das Lizenzfile eingefügt.
(2.3) Das gesamte XML wird nochmal per Rijandael verschlüsselt und erneut als XML gespeichert (sozusagen XML in der XML) und die Signatur ist nur für die innere XML gültig.
(Info) Das Lizenz.xml enthält Persönliche Daten des Clients(Name Mail usw.) und HardwareInformationen (Mainboard Serial, Computername, ProzessorID usw.) und man kann wählen, welche in die Lizenz eingefügt werden.
Somit sollte die Lizenz auch wirklich nur auf dem Clientrechner funktionieren.
Weitergeben ausgeschlossen.
(3) Prüfen der Lizenz -
(3.1) Entschlüsseln der inneren XML mit Rijandael.
(3.2) Prüfen des Assembly Hashes.
(3.3) Prüfen der Signatur der XML indem aus der Signatur der Assembly der PublicKey gezogen wird.
(3.4) Hardwarekonfiguration prüfen.
Fertig!

Hoffe ich hab nichts vergessen.

Was haltet ihr davon? Bin neu auf dem Gebiet und erhoffe mir hier ein paar Ansätze ob das so Ok ist und vielleicht wie man es (noch)besser machen kann.

Wie/Wo würde man ansetzen wenn man sowas knacken wollen würde? Habe da leider nicht wirklich eine Idee, außer versuchen die dll zu tauschen und gegen eine eigene zu ersetzen. Aber das wird doch durch den Strong Name verhindert, oder nicht?
Vielleicht kommen ja ein paar Ansätze zusammen.

Hab auch vor Kurzem einen älteren Artikel auf MSDN gelesen(Decompiler und Obfuscator).
Ist das noch so aktuell? So fern ich es richtig verstanden habe bringt mir also ein Obfuscator doch nur einen sehr geringen Vorteil, oder hat sich da schon was getan?

Danke schonmal.

MfG
Rick

Hallo Innocentus,

sehr gute Setups lassen sich mit WiX erstellen: http://wix.sourceforge.net/
Man kann auch .NET Bootstrapper einbauen, etc.
Es lässt sich sogar in den Build-Prozess einbauen, sodass bei jedem Build ein Setup mit erstellt wird (sehr cool bei Continuous Integration und Build-Servern).

Bzgl. Obfuscator gibt es schon einige Posts hier, verwende die Suche.
Hier ist aber auch die Frage, ob dies wirklich nötig ist.

Viele Grüße,
NeuroCoder

Hallo Innocentus,

Der Benutzer sollte ein Setup erhalten, welches für ihn die Software installiert

• und einen Uninstaller bereithält, mit welchem er diese später wieder deinstallieren kann.
  -> Gibt es speziell von .NET- oder für .NET-Anwendungen einen Installer-Creator oder etwas Ähnliches?
  Hat Microsoft vielleicht selbst daran gedacht und einen solchen mitgegeben (ich habe noch keinen finden können)?
  Wie sieht es mit der manchmal nötigen Installation des .NET-Frameworks aus?
  Kann man das berücksichtigen?

Ja, sowas gibt es von im Visual Studio (AFAIK nicht in der Express).
Also du erstellst ein neues Projekt (vom Typ) Setup-Projekt.
Anschliessend kannst du dir dein Setup zusammenstellen.
Verwende es nie deshalb kann ich dir nicht viel dazu sagen, aber google hilft da bestimmt.

Zum Anderen habe ich gehört, das MSIL-Code leicht zu dekompilieren ist und von daher der abgefasste Quellcode leicht von Fremden ohne Erlaubnis eingesehen und ohne Wissen des Autors verwendet werden könnte.
Das möchte ich natürlich nicht.
-> Gibt es einen OpenSource-Obfuscator oder zumindestens einen Freeware-Obfuscator für .NET,
der auch für kommerzielle Anwendung ohne extra Lizenzgebühren etc. pp. verwendet werden darf?
Ich möchte jetzt keinen großartigen Schutz - aber einen gewissen Basisschutz würde ich schon gerne haben, damit nicht einfach jeder mit einem passenden Tool mal kurz den Quelltext einsehen kann.
-> Gibt es vielleicht auch Maßnahmen ohne die Verwendung eines Obfuscators, die auch alleine schon ausreichen, das Einsehen von Quelltext zu erschweren?

Ja da gibt es schon welche.
Ich haben den Phoenix Proetctor verwendet (nur für Private Projekte).
Aber ich glaube dass der auch kommerziell eingesetz ewrden darf (aber besser du schaust noch mal nach).
Es gibt auch noch weitere. Suche einfach nach obfuscator dann findest du bestimmt was

Und hat jemand von euch bereits so etwas derartiges (Deployment von .NET-Anwendungen) gemacht
und kann mir von daher ein paar Ratschläge geben bzw. worauf sollte man (unbedingt) achten?

Hm, ja da Fällt mir mal die Lizenz-geschichte ein. Weil du musst dein Programm irgendwie absichern dass es nicht jeder ohne Key und nix installieren kann.
Aber da ist jetzt wieder die Frage wie sicher das sein muss. Evtl könntest du das direkt in C# machen (achtung: unsicher) oder du machst es wie viele andere und lagerst es in eine C Bibliothek aus (was das ganze schon etwas sicherer macht).

Gruss
Michael

Ich habe eine .NET-Anwendung geschrieben.

• Nun möchte ich diese halbwegs seriös ausliefern.

Der Benutzer sollte ein Setup erhalten, welches für ihn die Software installiert

• und einen Uninstaller bereithält, mit welchem er diese später wieder deinstallieren kann.
  -> Gibt es speziell von .NET- oder für .NET-Anwendungen einen Installer-Creator oder etwas Ähnliches?
  Hat Microsoft vielleicht selbst daran gedacht und einen solchen mitgegeben (ich habe noch keinen finden können)?
  Wie sieht es mit der manchmal nötigen Installation des .NET-Frameworks aus?
  Kann man das berücksichtigen?

Zum Anderen habe ich gehört, das MSIL-Code leicht zu dekompilieren ist und von daher der abgefasste Quellcode leicht von Fremden ohne Erlaubnis eingesehen und ohne Wissen des Autors verwendet werden könnte.
Das möchte ich natürlich nicht.
-> Gibt es einen OpenSource-Obfuscator oder zumindestens einen Freeware-Obfuscator für .NET,
der auch für kommerzielle Anwendung ohne extra Lizenzgebühren etc. pp. verwendet werden darf?
Ich möchte jetzt keinen großartigen Schutz - aber einen gewissen Basisschutz würde ich schon gerne haben, damit nicht einfach jeder mit einem passenden Tool mal kurz den Quelltext einsehen kann.
-> Gibt es vielleicht auch Maßnahmen ohne die Verwendung eines Obfuscators, die auch alleine schon ausreichen, das Einsehen von Quelltext zu erschweren?

Und hat jemand von euch bereits so etwas derartiges (Deployment von .NET-Anwendungen) gemacht
und kann mir von daher ein paar Ratschläge geben bzw. worauf sollte man (unbedingt) achten?

Vielen Dank für eure Antworten im Voraus!
Mit freundlichen Grüßen
Innocentus

Hallo PC17,

das was du suchst ist ein Obfuscator
Siehe: [FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

Gruss
Michael

hallöchen!

also passwortgeschützt ist die ganze anwendung schon, habe einen XML-Keyring der verschlüsselt alle wichtigen passwörter enthält und der durch ein masterpasswort (einzugeben beim programmstart) geschützt ist (speicherung des masterpasswords als SHA-Hash im keyring).
nur dies ist ja alles erst wieder lokal möglich und hilft mir nicht die sachen online zu schützen... ARGH MS!!!

danke wegen dem phoenix-link, finde ich besser als den obfuscator von MS.

was den installer/updater angeht: so breite massen werden das projekt eh nicht zu gesicht bekommen, als das es extrem schützenswert wäre. es geht mir hier um das prinzip eine anwendung von vorne bis hinten gesichert publizieren zu können ohne mir vorher ein bein abzunagen ..

grüße

ist die URL einmal einem potentiellen angreifer bekannt, so kann dieser die software ohne probleme installieren & zur ausführung bringen, ohne das vorher eine authentifizierung notwendig wäre! natürlich kann man beim programmstart nach einem passwort fragen etc, aber das hindert einen angreifer nicht daran sich den code zu disassemblieren und darin nach daten etc zu suchen.

Ich denke, wenn du eine Anwendung der breiten Masse zur Verfügung stellst, und in deiner Anwendung einen hardcoded ConnectionString verwendest, wirst du keine Lösung zu deinem Problem finden. Als einfache Lösung würde ich z.B. sehen, dass der Anwender beim Start seinen Login und Passwort selbst eingibt (und dann für später z.B. lokal speichert). Ohne Login und Passwort kommt so also keiner in deine DB rein.

Zum Thema Disassemblieren: Google mal nach Obfuscator. Persönlich verwende ich den Phoenix Protector. Ich habe allerdings keine Ahnung, wie man den in Verbindung mit ClickOnce verwenden kann. Aber persönlich bin ich eh kein Freund von ClickOnce und distribuiere meine Anwendungen in der Regel selbst über ein Setup. Dein Updates kannst du z.B. mit dem KUpdater erzielen.

Hallo Levitas,

siehe [Artikel] .NET Reflector und [FAQ] .net Assembly vor Disassembling schützen (Obfuscator) .

zero_x

Ist es "hinreichend sicher" bei einem Projekt mit mehreren Mannjahren Entwicklungszeit?

Was verstehst Du darunter?

Du hast den rest von Nutzt ihr einen Obfuscator?
auch durchgelesen?

Hallo,

guck dir mal diese Seite an, da wurde schön über das Thema Obfuscator diskutiert.
Nutzt ihr einen Obfuscator?

Wobei dir ein Obfuscator ohnehin nie eine 100%tige Sicherheit bringt.
Denn wenn jemand wirklich interesse an deinem Code hat so wird er keine Mühen scheuen und das Ganz trotzdem wieder entschlüsseln.

Welcher von den genannten besser oder schlechter ist kann ich dir leider nicht sagen

PS: Mit der Suchfunktion findest du sehr viele Treffer zum Thema Obfuscator.

Grüsse
Michael

Also wenn es dir nur um Disassembling geht, dann nimm noch einen Obfuscator dazu. Das ist zwar auch nur eine weiter Hürde, aber doch eine recht große. Ich persönlich hab nur den Phoenix Protector ausprobiert, aber sonst benutz einfach mal die Suchfunktion.

Reflection braucht ein Object?!

Nein.

Geht das auch ohne? Direkt von der Klasse?

Ja.

Kann mir jemand ein Beispiel geben?

:rtfm: Type.FindMembers-Methode

Oder du schaust (sofern das nicht per Obfuscator verhindert wird) mit dem Reflector in die entsprechende Assembly hinein.

Jürgen

Ich hab jetzt mal die freien Obfuscator ausprobiert und mir ist folgendes aufgefallen.

Alle beherschen das Umbenennen der Methodennamen und Vaiablennamen

Komischer weise werden einige Methoden nicht umbenant. Zum Beispiel OnPaint() oder einzellne überschriebene Eventmethoden. Variablennamen in den Methoden werdern nicht alle überschrieben bzw. geändert.

Welche Gründe hat das?

Hallo rollerfreak2,

allgemein sei noch auf [FAQ] .net Assembly vor Disassembling schützen (Obfuscator) verwiesen.

herbivore

Hallo!

Kürzlich gab es hier im Forum einen Beitrag, wo zahlreiche - auch freie - Obfiskatoren vorgestellt wurden: Suche Freeware Obfuscator

meine güte...so eine schnelle antwort:-)

also das mit dem obfuscator wusste ich gar nicht..ich wäre mal der meinung gewesen, da was von komprimieren gelesen zu haben...ok, dann war es meine schuld.

garnicht. 1.5 mb ist schon klein und der obfuscator hat eine komplett andere funktion, die ncihts mit komprimieren zu tun hat.

Hallo,

wie der Titel schon sagt, wie kann ich meine .NET 3.5 Application komprimieren? Das Ding ist jetzt knappe 1,5 MB groß und ich wollte es eigentlich etwas schrumpfen. UPX unterstützt ja meines Wissens sowas nicht. Obfuscator hab ich auch nur in der "freeware" Version.

Unter http://www.csharp411.com/net-obfuscators/ und http://www.tjlug.org/2009/03/01/net-code-protection-and-obfuscators/ gibt's relativ aktuelle Auflistungen kostenloser und kommerzieller Obfuscatoren.

Ich finde Phoenix Protector ganz gut dafür dass er kostenlos ist; aber vielleicht kennt ja jemand einen besseren kostenlosen Obfuscator 😉

Am Besten ist wahrscheinlich wenn du einfach ein paar Funktionen in der DemoVersion sperrst. Und diese dann per generierten Aktivierungscode freigibst

so habe ich es momentan auch gelöst.
Und was die Trialversion angeht: ich glaube für meine Zwecke habe ich jetzt genug Sicherheitsmaßnahmen vorgenommen.

Eine Frage hätte ich trotzdem noch:

Ich habe eine Security Library in der die Funktionen zum überprüfen der Lizenzdatei drin stehen, wie bspw. der Public Key um die Lizenz zu testen. Wenn jetzt jemand die Library durch eine mit dem gleichen Interface, Funktionsnamen usw. ersetzt, hätte derjenige eine Vollversion, die überall läuft. Natürlich werden alle Libraries mit einem Obfuscator geschützt.

Ist es für einen Hacker schwerer, das Interface einer Klasse sowie die Funktionsnamen und Namespaces herauszufinden als diese zu dekompilieren und zu ändern?

Du kannst nichteinmal sicherstellen, dass dein Code zur überprüfung überhaupt ausgeführt wird. Die einzige Möglichkeit ist ein Obfuscator, aber der erhöt auch nur den Aufwand. Es ist unmöglich, das Hacken unmöglich zu machen. Am Ende musst du selbst sehen, wieviel Aufwand dir ein Schutz wert ist und wieviel Aufwand es für einen Hacker bedeutet ihn zu brechen.

[FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

Hallo prom,

programmtechnische Fragen gehören nicht nach Smalltalk. Deshalb nur in aller Kürze:

1.1. [FAQ] .net Assembly vor Disassembling schützen (Obfuscator)
1.2 Keygenerator und Key Generator

Zu den (lizenz-)rechtlichen Fragen:

2.1 Gar nichts. Eine Garantie ist eine freiwillige Zusicherung des Herstellers. Zwangsweise gilt nur die normale (gesetzliche) Gewährleistung (also Mangelfreiheit der Kaufsache). Und dann gibt es noch die Produzentenhaftung.
2.2 Grundsätzlich bist du im Rahmen der Gewährleistung verpflichtet, alle Mängel an der Kaufsache zu beseitigen. Darüber, welche Programmierfehler auch Mängel im Sinne der Gewährleistung darstellen, kann man aber trefflich streiten. Am besten fragst du einen spezialisierten Anwalt.

3 GPL-Bibliotheken kannst du in kommerziellen Projekten nicht benutzen, weil du dein eigenes Projekt auch unter GPL stellen musst, wenn du eine GPL-Bibliothek benutzt. LGPL-Bibliotheken kannst du dagegen benutzen, musst allerdings auf die Verwendung hinweisen. Die anderen Lizenzen musst du dir mal selbst angucken. In einer Lizenz steht ja gerade drin, was man darf und was nicht.

herbivore

Hallo prom,

zu 1. 1: Obfuscator, zb. Dotfuscator.

danke

und zur LGPL-Lizenz habe ich auch was gefunden. Bei mir handelt es sich auch um die ZedGraph-Library und laut zedgraph in projekt: verkauf möglich? darf man die veröffentlichen, wenn man sie nicht geändert hat.

Und zu allen anderen externen Libraries: Ich habe an keiner etwas geändert.

Hallo prom,

zu 1. 1: Obfuscator, zb. Dotfuscator.

Hallo!

Ich verwende für einige Projekte einen Obfuscator. Klar ist mir bewusst, dass man damit keinen 100%igen Schutz hat, aber zumindest ist die Schwelle schonmal für ein paar "Interessierte" etwas höher.

welchen verwendest du, wenn ich fragen darf?

Das Aktivierungen lästig sind ist mir bewust, aber verlorenes Geld für "ehrlich" erstellte SW ist auch lästig. Man muss halt bei Aktivierungen die entsprechende Infrastruktur und Ausweichoptionen liefern. Dann denke ich auch, dass die wenigsten Leute damit ernsthafte Probleme hätten...

ein obfuscator ist kein kopierschutz.

ich hab einmal den Dotfuscator an einer kleinen Anwendung ausprobiert...mein Eindruck bei der speziellen Anwendung: es war sicher schwerer die ganze Programmlogik zu verstehen, aber die Logik in den einzelnen Methoden war eigentlich recht leicht nachvollziehbar... ein Obfuscator würde -denke ich- das Aufspüren des Kopierschutzes nur verlangsamen

Hallo!

Ich verwende für einige Projekte einen Obfuscator. Klar ist mir bewusst, dass man damit keinen 100%igen Schutz hat, aber zumindest ist die Schwelle schonmal für ein paar "Interessierte" etwas höher.

Hi zusammen,

wir überlegen momentan im Unternehmen, ob wir uns
http://www.smartassembly.com/
anschaffen.

Wir hatten auch schon einmal über den Dotfuscator geredet, jedoch sind mit dem wieder ettliche Schulungen und Einarbeitungen verbunden. Noch dazu ist der Preis um ein vielfaches höher.

Smartassembly haben wir in der Testversion in einem Testprojekt ausprobiert und waren im prinzip vom Handling begeistert. Ok es ist sehr klick/bunt, aber im Prinzip kann es das, was man (wir) uns davon versprochen haben.

Frage wäre nun, ob jemand mit dieser Software bereits erfahrung gesammelt hat, bzw. ob jemand das Unternehmen "Cachupa" schon einmal gehört hatte. Mir sagt der Name nichts, und wir sind deshalb nicht so ganz sicher wie zukunftssicher (wenn man in der aktuellen Lage noch von sowas reden kann 😉) diese Investition ist.

Zur allgemeinen Diskussion noch kurz.
Ich bin noch relativ frisch von der Uni und somit fehlt ich sicher noch einiges an Berufserfahrung. Jedoch finde ich, hier werden einfach sehr unterschiedliche Dinge betrachtet. Software, die in Banken/Zentralrechnern etc. läuft müsste man ziemlich sicher nicht gegen Kopie sichern. Wenn die Leute idr. nicht an die DLL kommen, ist das auch verständlich.

Handelt es sich jedoch um Software, die zu einem Privatanwender wandert, sieht die Sache in meinen Augen anders aus. Hier wird sich die Zeit, die bis zum Erscheinen eines Cracks vergeht um einiges verlängern vermute ich. Ich meine es ist Fakt, dass es Leute gibt, die sich an das Schreiben solcher dinger machen. Je einfacher sowas ist, desto schneller macht man es zwischendurch. Kommt man eben über Standardmittel (Reflector/ILDA) nicht direkt an den Code und somit an die (if (authorized)) oder ähnliches, dann werden sich manche leute auch sagen.. naja das lohnt sich nicht.

Das sind wie gesagt, nur Vermutungen und Ansichten von mir. Aber so ganz an der Realität vorbei ist es glaube ich nicht. Mich stören nur etwas die Ansichten "Wer obfuscator nutzen will, der schreibt schlimmen Code". Ich bin der Meinung, mein Code ist ganz gut. Und gerade dadurch DAS er gut/strukturiert ist, hat ein Dritter es leichter, ihn zu verstehen. Benutzt man dinge wie Pattern, Modularisierung etc. nicht, Wird jede Anwendung in meinen Augen um ein vielfaches komplexer, als wenn das ganze ordentlich geplant und strukturiert wurde. Ich sehe das also genau andersrum. Guter Code muss geschützt werden, WEIL er leichter verständlich ist.

Für neue Ansichten bin ich jedoch immer offen! 😉

Grüße,
bernett

PS: Das Thema ist nicht aus der Luft gegriffen, wir besitzen bereits ein Produkt, welches nach kürzester Zeit gecrackt wurde und somit überlegen wir uns Alternativen. Auch eine Aktivierung über Web Services ist angedacht. Auch wenn das viele hier im Forum nicht gerne hören, aber die Realität ist einfach härter als die "Code ist für Jedermann" Einstellung. Irgendwer muss unsere Löhne ja auch bezahlen. 😉

Hallo Iceevil,

ließ dir mal die FAQ dazu durch [FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

Letztendlich aber kann man zusammenfassen, es bringt nichts, denn in dem Moment, wo das Programm gestartet wird, muss es auch entschlüsselt werden und schon ist die Verschlüsselung dahin. Ich hatte zum Beispiel auch an Anfang gedacht, dass .Net Reactor von http://www.eziriz.com ein Programm gut sichern kann, bis ich na ein wenig Recherche im Netz gesehen hab, wie schnell man diesen "Schutz" umgehen kann.

Grüße
Maik

Vielleich hilft dir ein Obfuscator weiter. Einfach mal die Forumssuche benutzen. Oder Google 👅

Gruß, Christian,

So etwas gab es schon. Nutzt ihr einen Obfuscator?

Gruß pdelvo

Hallo Zusammen,

momentan bin ich in der Firma auf der Suche nach einer für uns geeigneten Methode unsere Assemblies gegen das Disassemblieren zu schützen. Kostenlose Varianten gibt es ja nicht viele (kenne nur 2 oder 3), deshalb würde mich eure Meinung dazu mal interessieren. Anscheinnd gibt es wohl vier große Tools

• .NET Reactor
• Dotfuscator
• Salamander .NET Protector
• CodeVeil

mit denen sowas realisiert wird (vermutlich sogar noch mehr). Mich würde interessieren was ihr benutzt, warum ihr das benutzt (was war für euch DAS Kaufkriterium dafür? Preis? Ein tolles Feature?) und welche Erfahrung ihr mit dem Tool gemacht habt.

Jedes Produkt für sich hat ja schon irgendetwas, dass für sich spricht. Dotfuscator kann anscheinend den Obfuscatorbaum speichern und später wenn man z.B. einen Bug entdeckt und gefixt hat die Methodennamen merken, so das man am Ende nur eine Assembly updaten muss. Anscheinend muss man wohl sonst bei anderen Assemblies alles neu compilieren und durch den Obfuscator jagen damit es funktioniert oder warum wird das als Feature so angepriesen?

Was mich am .NET Reactor interessiert hat ist diese Native Code Wall. Wenn ich das richtig verstanden habe wird die .NET Assembly mit nativem Code umhüllt um zu verhindern, dass man Sie (z.B. mit .NET Reflector) disassemblieren kann. Wie gut funktioniert das? Hat man dadurch auch immernoch die Plattformunabhängigkeit?

Kennt ihr vielleicht noch andere Produkte die einen Blick wert sind?

Ich wollte hier keine neue Diskusion über das verschleiern von Assemblies breit treten sondern einfach Erfahrungen anderer Entwickler einholen, da wir auch mit dem Gedanken spielen uns solch ein Tool zu besorgen. Ich denke auch, dass dieses Thema viele Andere interessiert.

Vielen Dank und Grüße

Marco

Ich haue mal in die Kerbe.
Ich denke das ht weniger mit Angst zu tuen. Wenn Du z.B. im Bankenberecih arbeitest und Deine Software Funktionen der Bank, sowie Kontenzugriffe usw. erlaubt, dann wirst Du kaum völlig ungeschützen Code herausgeben wollen. In diesem Bereich ist der Schutz des Quellcodes oberste Priorität.

Also ich arbeite in der Bankenbranche bei einer der größten überhaupt.
Da wird keine Software mit Obfuscator verschlüsselt.
Da ist alles so weit geregelt/reglementiert, dass Du überhaupt keine Möglichkeit
hast, die entspr. Dinge anzuschauen.
Und ein Bankberater wird sich wohl kaum den Reflector runterladen um dann zu sehen,
wie seine Anwendung den Kontenzugriff technisch regelt.

Diese sicherheitsrelevanten Dinge werden über sichere Verbindungen, AppServer und Authentifierungs/Authorisierungsmechanismen geregelt.
Zudem laufen Kontenzugriffe über Subsysteme die in keinster Weise irgendwie .NET Code sind.

Es muss generell beim Schützen ein Verhältnis zw. Aufwand des Schützens und des "Wertes" des Quellcodes an sich.

Hallo,

.. ohne dokumentation ist man so auf verlorenem posten und da ist es billiger zu reimplementieren als zu analysieren und ggf. zu kopieren...

Wenn das wirklich der Fall wäre, dann hätten wir kein Problem mit Plagiaten in sämtlichen Sparten, sei es in der Software Entwicklung, sei es in der Textil oder Fahrzeug Industrie etc.

die reifenmischung ist die technologie und lässt sich ebensowenig verbergen, wie z.b. ob eine software das .netframework benötigt.

Das ist nicht ganz richtig. Die Technologie sind die Bestandteile eines Reifens, wie z.B. Kautschuk, Stahldrähte und andere Beigaben. Nun ist die Reifenmischung(Algorithmus) eine Zusammenstellung dieser Bestandteile (Funktionen aus dem .NET Framework).

der reflector ist nciht geschützt. er hat nur eingebaut, das man sein tool nciht mit seinem tool öffnen kann

Unabhängig davon, ob er nur eine Sperre fuer seinen eigenen Reflector eingebaut hat oder nicht. Letztendlich ist dann immer noch die Frage berechtigt, warum er das gemacht hat? Was gibt es da zu verstecken, wenn alles so einfach ist? (Die Frage ist gewollt ein wenig provokant gestellt)

Hast Du denn mal ausgetestet, ob man den Reflector mit anderen recht maechtigen Tools bspw. von RemoteSoftRemoteSoft so einfach zu decompilieren ist? Das ist nicht der Fall.

Ich denke nicht, dass wir hier auf einen Nenner kommen werden. Ich sehe alles ein wenig anders.
Zumindest ist in diesem im Poll ein Trend zu erkennen, dass die meisten keinen Obfuscator einsetzen.

Gruss, DaMoe

Wenn es um Firmeneigene Stacks geht, für bestimmte Protokolle, wird das alles in C++ geschrieben und ein Wrapper für .Net drum gelegt. Einfache Oberflächen oder sowas enthalten ja nicht gerade großes Knowhow.

.Net ist wie GPL 😉 Wer es verwendet muss auch den Code offen legen.

Wenn man ein Programm wirklich auslesen will, bringt ein Obfuscator auch nichts.

Ich hab mal mit Nein geantwortet.
Ein Obfuscator würde bei uns auch keinen Sinn machen, da unsere Software komplett mit Quellcode an den Kunden geht.

Gruß Jake

Hallo allerseits!

Ihr scheint das Thema ja auf die leichte Schulter zu nehmen. Ich finde es schon problematisch, daß man mit einer .NET-Anwendung seinen gesamten Quellcode mit verbreitet.

Ein Obfuscator erreicht zumindest, daß man sich einige Gedanken machen muß, um den Code nachzuvollziehen. Daß es gegen das Urhebergesetz verstößt, hält kaum jemanden davon ab, per Copy und Paste einzelne Funktionen oder ganze Klassen zu verwenden. Und wer sollte es nachprüfen?

Ich selbst bin relativ geübt darin, fremden Code zu lesen und zu verstehen, aber vor dem was ein Obfuscator produziert kapituliere ich bedingungslos. Es ist weniger Zeitaufwendig, die entsprechenden Routinen selbst zu schreiben, als in dem Code danach zu suchen...

Deshalb finde ich es schon wichtig, einen Obfuscator zu verwenden, wenn man halbwegs wichtigen Code für sich behalten möchte.

Schöne Grüße,
Christian

Hallo BAUHAUS,

das sind zwei ganz verschiedene Themen. Wer einen Obfuscator nutzt, ist das eine. Ob sich das lohnt das andere? Das mit dem lohnen wurde schon ausführlich besprochen. Siehe [FAQ] .net Assembly vor Disassembling schützen (Obfuscator).

herbivore

Das hängt zum Einen von der Zielgruppe ab, die das Produkt am Ende nutzt und zum Anderen muss man schauen wieviel Aufwand man betreiben will um das Produkt zu schützen.

Wir nutzen keinen Obfuscator.

Nutzt ihr einen Obfuscator? Das ist die Frage. So wirklich sagt mir diese Geschichte nicht zu.

Auf der einen Seite ist die Hürde zu hoch, kein einfacher Benutzer würde auf den Gedanken kommen nach dem IL-Code zu schauen um den Code für sich zu nutzen.
Auf der anderen Seite, diese speziellen Benutzer die danach schauen wird das bisschen Verschlüsselung kaum aufhalten. Irgendwann wäre auch das geknackt.

Was denkt ihr, lohnt sich ein Obfuscator. Nutzt ihr einen?

(Ich hätte zu diesem Thema auch gerne eine Umfrage erstellt, aber nicht jede Forensoftware unterstützt das.)

Hallo somebody, hallo zusammen,

hierzu kommen mir aber wiedereinmal einige (hier schon öfters dikutierte) fragen bezüglich der sicherheit meines quellcodes auf, wozu ich gerne mal euren rat einholen würde:

genau weil die Frage schon so oft diskutiert wurde und es daher auch schon in die FAQ geschafft hat ([FAQ] .net Assembly vor Disassembling schützen (Obfuscator)), sollten wir sie hier bitte nicht noch einmal grundsätzlich erörtern, sondern nur die spezifischen Fragen behandeln.

Das wäre hier eigentlich nur die Frage nach der SuppressIldasmAttribute-Klasse. Alles andere geht aus der FAQ hervor und sollte hier nicht wiederholt werden. Die Grundaussage der FAQ ist, es ist fast allen Fällen unnötig ist, den Codes zu schützen. Und dein Projekt wird da keine Ausnahme darstellen.

herbivore

Hallo Regenwurm,

das Zauberwort heisst Obfuscator.
Siehe: [FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

Gruss
Michael

Hallo Kinglouy,
beachte aber das ein Obfuscator, wie der Name bereits sagt, nur verschleiert - nicht "verschlüsselt". Der Obfuscator macht es schwerer, durch den Code zu steigen. Es werden vorhandene Klassen/Methoden/etc aufgeteilt und nach dem Alphabet umbenannt.

Sensitive Daten, wie beispielsweise Passwörter die im Klartext im Quellcode gespeichert sind zu 100% sichtbar. (Sollte man daher NIE! machen.)

Viele Grüße,
moq

Hallo Kinglouy,

zu 1. und 2.: Suche hier im Forum mal nach "obfuscator" (und poste die besten Treffer dazu). Ich glaub, das ist das, was du suchst.

Gruß
dN!3L

Ich glaube hier verhät es sich ähnlich wie mit kleinen Ratespielchen wie der "HelloWorld-Obfuscator". Die Sache lebt von der Spontaneität. Wenn sich jetzt jemand hinsetzt und da eine Webanwendung draus bastelt ist glaube ich ziemlich schnell der Witz weg...

Gruß,
Markus 😃

Jetzt noch eine Frage am Rande. In Managed Code, wie zum Beipsiel bei c# ist es ja möglich aus einem Assemblie den Code zurück zu bekommen, zwar ohne Variablennamen aber es ist Möglich (Reflector).

Gibt es irgendeine Möglichekit die IntermidateLanguage (IL) so zu verwursteln oder ein Progi über das Assemblie laufen zu lassen so das mann den Code nicht mehr zurück verfolgen kann?

THX

Da gibt es mehrere Programme, die das macht. Ich setze .NET Reactor ein. Es sind aber noch:

• Intellilock
• Dotfuscator (die light version ist im VS drin)
• Salamander .NET Obfuscator
• ... und vieles mehr

Hallo

Na ddl ist da schon eine gute Lösung. Das der Quellcode allerdings nicht eingesehen werden kann, kannst du eigentlich gleich vergessen.

[FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

chrische