.NET-Verschleierungstools / Strategie [geschlossen]

Mein Produkt besteht aus mehreren Komponenten: ASP.NET, Windows Forms App und Windows Service. Etwa 95% des Codes sind in VB.NET geschrieben.

Aus Gründen des geistigen Eigentums muss ich den Code verschleiern, und bis jetzt habe ich eine Version von dotfuscator verwendet, die jetzt über 5 Jahre alt ist. Ich denke, es ist Zeit, auf ein Tool der neuen Generation umzusteigen. Was ich suche, ist eine Liste von Anforderungen, die ich bei der Suche nach einem neuen Verschleierer berücksichtigen sollte.

Was ich weiß, sollte ich bisher suchen:

• Serialisierung / De-Serialisierung . In meiner aktuellen Lösung, sage ich einfach das Werkzeug nicht alle Klassendatenelemente zu verschleiernweil der Schmerz nichtder LageDaten zu ladendie zuvor serialisiert wurde einfach zu groß ist.
• Integration mit dem Build-Prozess
• Arbeiten mit ASP.NET . In der Vergangenheit habe ich dies als problematisch empfunden, weil ich DLL-Namen geändert habe (Sie haben oft einen pro Seite) - was nicht bei allen Tools gut funktioniert.

Zurück mit .Net 1.1 war die Verschleierung unerlässlich: Das Dekompilieren von Code war einfach, und Sie konnten von Assembly zu IL zu C # -Code wechseln und ihn mit sehr geringem Aufwand erneut kompilieren lassen.

Jetzt mit .Net 3.5 bin ich mir überhaupt nicht sicher. Versuchen Sie, eine 3.5-Assembly zu dekompilieren. Was Sie erhalten, ist weit vom Kompilieren entfernt.

Fügen Sie die Optimierungen von 3.5 (weitaus besser als 1.1) und die Art und Weise hinzu, wie anonyme Typen, Delegaten usw. durch Reflexion behandelt werden (sie sind ein Albtraum beim Neukompilieren). Fügen Sie Lambda-Ausdrücke, Compiler-Magie wie Linq-Syntax und varund C # 2-Funktionen wie hinzu yield(was zu neuen Klassen mit unlesbaren Namen führt). Ihr dekompilierter Code ist noch lange nicht kompilierbar.

Ein professionelles Team mit viel Zeit könnte es immer noch zurückentwickeln, aber das Gleiche gilt für jeden verschleierten Code. Welcher Code sie daraus erhalten haben, wäre nicht zu warten und höchstwahrscheinlich sehr fehlerhaft.

Ich würde empfehlen, Ihre Assemblys mit einem Schlüssel zu signieren (dh wenn Hacker eine neu kompilieren können, müssen sie alle neu kompilieren), aber ich denke nicht, dass sich die Verschleierung lohnt.

Wir haben eine Reihe von Verschleiern ausprobiert. Keiner von ihnen funktioniert auf einer großen Client / Server-App, die Remoting verwendet. Das Problem ist, dass Client und Server einige DLLs gemeinsam nutzen und wir keinen Verschleierer gefunden haben, der damit umgehen kann.

Wir haben DotFuscator Pro, SmartAssembly, XenoCode, Salamander und mehrere kleine Zeit-Apps ausprobiert, deren Namen mir entgehen.

Ehrlich gesagt bin ich überzeugt, dass Verschleierung ein großer Hack ist.

Selbst die darin angesprochenen Probleme sind kein wirkliches Problem. Das einzige, was Sie wirklich schützen müssen, sind Verbindungszeichenfolgen, Aktivierungscodes und solche sicherheitsrelevanten Dinge. Dieser Unsinn, dass ein anderes Unternehmen Ihre gesamte Codebasis zurückentwickeln und daraus ein konkurrierendes Produkt erstellen wird, ist etwas aus dem Albtraum eines paranoiden Managers, nicht aus der Realität.

Ich bin jetzt 'Knee Deep' und versuche eine gute Lösung zu finden. Hier sind meine bisherigen Eindrücke.

Xenocode - Ich habe eine alte Lizenz für Xenocode2005, mit der ich meine .net 2.0-Assemblys verschleiert habe. Es funktionierte gut unter XP und war eine anständige Lösung. Mein aktuelles Projekt ist .net 3.5 und ich bin unter Vista. Der Support sagte mir, ich solle es versuchen, aber die Version 2005 funktioniert nicht einmal unter Vista (Abstürze). Deshalb muss ich und jetzt 'PostBuild2008' zu einem unglaublichen Preis kaufen von $ 1900. Dies könnte ein gutes Werkzeug sein, aber ich werde es nicht herausfinden. Zu teuer.

Reactor.Net - Dies ist ein viel attraktiverer Preis und es hat auf meinem Standalone Executeable gut funktioniert. Das Lizenzierungsmodul war auch nett und hätte mir eine Menge Mühe erspart. Leider fehlt eine Schlüsselfunktion, und das ist die Möglichkeit, Dinge von der Verschleierung auszuschließen. Dies macht es unmöglich, das von mir benötigte Ergebnis zu erzielen (mehrere Baugruppen zusammenführen, einige verschleiern, andere nicht verschleiern).

SmartAssembly - Ich habe das Eval dafür heruntergeladen und es hat einwandfrei funktioniert. Ich konnte alles erreichen, was ich wollte und das Interface war erstklassig. Der Preis ist immer noch etwas hoch.

Dotfuscator Pro - Preis auf Website nicht gefunden. Derzeit in Diskussionen, um ein Angebot zu erhalten. Klingt bedrohlich.

Confuser - ein Open-Source-Projekt, das recht gut funktioniert (um ppl zu verwirren, wie der Name schon sagt).

Hinweis: ConfuserEx ist Berichten zufolge gemäß Ausgabe 498 auf ihrem GitHub-Repo "kaputt" .

Wenn Sie nach einer kostenlosen Version suchen, können Sie die DotObfuscator Community Edition ausprobieren, die mit Visual Studio oder Eazfuscator.NET geliefert wird .

Seit dem 29. Juni 2012 ist Eazfuscator.NET nun kommerziell. Die letzte frei verfügbare Version ist 3.3.

Ich habe Smartassembly verwendet. Grundsätzlich wählen Sie eine DLL aus und sie wird verschleiert zurückgegeben. Es scheint gut zu funktionieren und ich hatte bisher keine Probleme. Sehr, sehr einfach zu bedienen.

Ich habe fast jeden Verschleierer auf dem Markt ausprobiert und SmartAssembly ist meiner Meinung nach der beste.

Ich habe auch SmartAssembly verwendet. Ich fand, dass Ezrinz .Net Reactor für .net-Anwendungen viel besser für mich ist. Es verschleiert, unterstützt Mono, führt Assemblys zusammen und verfügt über ein sehr schönes Lizenzierungsmodul zum Erstellen einer Testversion oder zum Verknüpfen der Lizenz mit einem bestimmten Computer (sehr einfach zu implementieren). Der Preis ist auch sehr wettbewerbsfähig und als ich Unterstützung brauchte, waren sie schnell. Eziriz

Um ganz klar zu sein, ich bin nur ein Kunde, der das Produkt mag und in keiner Weise mit dem Unternehmen verbunden ist.

Die kurze Antwort ist, dass Sie nicht können.

Es gibt verschiedene Tools, die es jemandem erschweren, Ihren Code zu lesen. Einige davon wurden in anderen Antworten erwähnt.

All dies erschwert jedoch das Lesen - sie erhöhen den Aufwand, das ist alles. Oft reicht dies aus, um Gelegenheitsleser abzuschrecken, aber jemand, der entschlossen ist, sich in Ihren Code zu vertiefen, wird dies immer tun können.

Wir haben eine mehrschichtige App mit einer asp.net- und winform-Oberfläche, die auch Remoting unterstützt. Ich hatte keine Probleme mit der Verwendung eines Obfuscators, mit Ausnahme des Verschlüsselungstyps, der einen Loader generiert, der auf alle möglichen unerwarteten Arten problematisch sein kann und meiner Meinung nach einfach nicht wert ist. Eigentlich würde mein Rat eher im Sinne von "Vermeiden Sie die Verschlüsselung von Verschleierern vom Typ Lader wie der Pest" sein. :) :)

Nach meiner Erfahrung funktioniert jeder Obfuscator mit allen Aspekten von .net, einschließlich asp.net und Remoting. Sie müssen sich nur mit den Einstellungen vertraut machen und lernen, wie weit Sie ihn in welchen Bereichen Ihres Codes verschieben können. Nehmen Sie sich Zeit, um ein Reverse Engineering für das zu versuchen, was Sie erhalten, und sehen Sie, wie es mit den verschiedenen Einstellungen funktioniert.

Wir haben im Laufe der Jahre mehrere in unseren kommerziellen Apps verwendet und uns für Spices obfuscator von 9rays.net entschieden, weil der Preis stimmt, es funktioniert und sie gute Unterstützung haben, obwohl wir die Unterstützung seit Jahren wirklich nicht mehr gebraucht haben, aber um ehrlich zu sein Ich denke nicht, dass es wirklich wichtig ist, welchen Obfuscator Sie verwenden. Die Probleme und die Lernkurve sind alle gleich, wenn Sie möchten, dass es mit Remoting und asp.net ordnungsgemäß funktioniert.

Wie andere bereits erwähnt haben, ist alles, was Sie wirklich tun, das Äquivalent eines Vorhängeschlosses, das ansonsten ehrliche Leute fernhält und es schwieriger macht, eine App einfach neu zu kompilieren.

Die Lizenzierung ist normalerweise der Schlüsselbereich für die meisten Menschen, und Sie sollten auf jeden Fall ein digital signiertes Zertifikatsystem für die Lizenzierung verwenden. Ihr größter Verlust wird durch das gelegentliche Teilen von Lizenzen entstehen, wenn Sie kein intelligentes System haben. Die Leute, die das Lizenzsystem brechen, würden es niemals kaufen.

Es ist wirklich leicht, dies zu weit zu gehen und sich negativ auf Ihre Kunden und Ihr Unternehmen auszuwirken, das zu tun, was einfach und vernünftig ist, und sich dann keine Sorgen zu machen.

In den letzten zwei Tagen habe ich mit Dotfuscator Community Edition Advanced experimentiert (ein kostenloser Download nach der Registrierung des mit Visual Studio gelieferten Basis-CE).

Ich denke, der Grund, warum mehr Menschen die Verschleierung nicht als Standardoption verwenden, ist, dass dies im Vergleich zum Risiko ein ernsthafter Aufwand ist. Bei kleineren Testprojekten konnte ich den verschleierten Code mit viel Aufwand zum Laufen bringen. Das Bereitstellen eines einfachen Projekts über ClickOnce war mühsam, aber nach manuellem Signieren der Manifeste mit mage möglich. Das einzige Problem war, dass bei einem Fehler die Stapelverfolgung verschleiert zurückkam und im CE kein Deobfuscator oder Klärer verpackt war.

Ich habe versucht, ein reales Projekt zu verschleiern, das auf VSTO in Excel basiert, mit Virtual Earth-Integration, vielen Webservice-Aufrufen und einem IOC-Container und viel Reflexion. Es war unmöglich.

Wenn die Verschleierung wirklich eine wichtige Anforderung ist, sollten Sie Ihre Anwendung von Anfang an unter diesem Gesichtspunkt entwerfen und die verschleierten Builds im weiteren Verlauf testen. Andernfalls, wenn es sich um ein ziemlich komplexes Projekt handelt, werden Sie ernsthafte Schmerzen haben.

Crypto Obfuscator geht auf alle Ihre Bedenken und Szenarien ein. Es:

1. Schließt Typen / Mitglieder basierend auf Regeln automatisch von der Verschleierung aus. Serialisierte Typen / Felder sind einer davon.
2. Es kann mit MSBUild in den Erstellungsprozess integriert werden.
3. Unterstützt ASP.Net-Projekte.

Ich habe kürzlich versucht, die Ausgabe eines freien Obfuscators in einen anderen freien Obfuscator zu leiten - nämlich Dotfuscator CE und den neuen Babel-Obfuscator auf CodePlex. Weitere Details in meinem Blog .

Bei der Serialisierung habe ich diesen Code in eine andere DLL verschoben und in das Projekt aufgenommen. Ich kam zu dem Schluss, dass es dort keine Geheimnisse gab, die sowieso nicht im XML enthalten waren, sodass keine Verschleierung erforderlich war. Wenn diese Klassen ernsthaften Code enthalten, sollte die Verwendung von Teilklassen in der Hauptassembly diesen abdecken.

Sie sollten das verwenden, was für Ihre Plattform am billigsten und bekanntesten ist, und es einen Tag nennen. Die Verschleierung von Hochsprachen ist ein schwieriges Problem, da VM-Opcode-Streams nicht unter den beiden größten Problemen leiden, die native Opcode-Streams haben: Funktions- / Methodenidentifikation und Register-Aliasing.

Was Sie über das Umkehren von Bytecodes wissen sollten, ist, dass es für Sicherheitstester bereits Standard ist, reinen X86-Code zu überprüfen und darin Schwachstellen zu finden. In Raw X86 können Sie nicht unbedingt gültige Funktionen finden, geschweige denn eine lokale Variable während eines Funktionsaufrufs verfolgen. Native Code-Umkehrer haben unter fast keinen Umständen Zugriff auf Funktions- und Variablennamen - es sei denn, sie überprüfen Microsoft-Code, für den MSFT diese Informationen der Öffentlichkeit hilfreich zur Verfügung stellt.

"Dotfuscation" funktioniert hauptsächlich durch Verwürfeln von Funktionen und Variablennamen. Es ist wahrscheinlich besser, dies zu tun, als Code mit Informationen auf Debug-Ebene zu veröffentlichen, bei denen der Reflektor Ihren Quellcode buchstäblich aufgibt. Aber alles, was Sie darüber hinaus tun, wird wahrscheinlich zu sinkenden Renditen führen.

Ich hatte keine Probleme mit Smartassembly.

Sie können "Dotfuscator Community Edition" verwenden - diese wird standardmäßig in Visual Studio 2008 Professional verwendet. Sie können darüber lesen unter:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

Die "Professional" -Version des Produkts kostet Geld, ist aber besser.

Brauchen Sie Ihren Code wirklich verschleiert? Normalerweise ist es sehr wenig falsch, wenn Ihre Anwendung dekompiliert wird, es sei denn, sie wird aus Sicherheitsgründen verwendet. Wenn Sie sich Sorgen machen, dass Leute Ihren Code "stehlen", seien Sie nicht; Die überwiegende Mehrheit der Personen, die sich Ihren Code ansehen, dient Lernzwecken. Auf jeden Fall gibt es für .NET keine vollständig effektive Verschleierungsstrategie - jemand mit ausreichenden Fähigkeiten kann Ihre Anwendung immer dekompilieren / ändern.

Reaktor vermeiden. Es ist völlig nutzlos (und ja, ich habe für eine Lizenz bezahlt). Xenocode war der beste, dem ich begegnet bin und für den ich auch eine Lizenz gekauft habe. Die Unterstützung war sehr gut, aber ich brauchte es nicht viel, da es einfach funktionierte. Ich habe jeden Verschleierer getestet, den ich finden konnte, und meine Schlussfolgerung ist, dass Xenocode bei weitem der robusteste war und die beste Arbeit geleistet hat (auch die Möglichkeit, Ihre .NET-Exe auf eine native Exe zu übertragen, die ich sonst nirgends gesehen habe).

Es gibt zwei Hauptunterschiede zwischen Reaktor und Xenocode. Der erste ist, dass Xenocode tatsächlich funktioniert. Das zweite ist, dass die Ausführungsgeschwindigkeit Ihrer Assemblys nicht anders ist. Mit dem Reaktor war es ungefähr 6 Millionen Mal langsamer. Ich hatte auch den Eindruck, dass der Reaktor ein Ein-Mann-Betrieb war.

Ich fand, dass das Agile.Net einen ziemlich guten Schutz für Ihre .Net-Assembly bietet, da es nicht nur Verschleierung, sondern auch Verschlüsselung bietet. Laden Sie einen kostenlosen Trail herunter.
http://secureteam.net/NET-Code-Protection.aspx http://secureteam.net/downloads.aspx

Ich habe Code in derselben Anwendung seit .Net 1 verschleiert, und es war aus Wartungssicht ein großes Problem. Wie Sie bereits erwähnt haben, kann das Serialisierungsproblem vermieden werden, aber es ist wirklich einfach, einen Fehler zu machen und etwas zu verschleiern, das Sie nicht verschleiern wollten. Es ist einfach, den Build zu brechen oder das Verschleierungsmuster zu ändern und alte Dateien nicht zu öffnen. Außerdem kann es schwierig sein herauszufinden, was wo schief gelaufen ist.

Unsere Wahl war Xenocode, und wenn ich heute noch einmal die Wahl treffen würde, würde ich es vorziehen, den Code nicht zu verschleiern oder Dotfuscator zu verwenden.

Hier ist ein Dokument von Microsoft. Hoffe das hilft ..., es ist aus dem Jahr 2003, aber es könnte immer noch relevant sein.

Wir verwenden SmartAssembly auf unserem Windows-Client. Funktioniert gut.

Fügt auch einige zusätzliche Probleme hinzu. Das Ausdrucken Ihrer Klassennamen in Protokolldateien / Ausnahmen muss verschleiert werden. Und natürlich kann eine Klasse nicht aus ihrem Namen erstellt werden. Es ist daher eine gute Idee, einen Blick auf Ihren Kunden zu werfen und herauszufinden, welche Probleme durch Verschleierung auftreten können.

Es hängt alles von der Programmiersprache ab, die Sie verwenden. Lesen Sie den Artikel: Verschleierter Code

Der kostenlose Weg wäre, Dotfuscator aus Visual Studio heraus zu verwenden, andernfalls müsste man einen Obfuscator wie Postbuild kaufen ( http://www.xenocode.com/Landing/Obfuscation.aspx ).

Ich musste in meinem neuesten Projekt einen Verschleierungs- / Ressourcenschutz verwenden und fand Crypto Obfuscator als ein schönes und einfach zu verwendendes Werkzeug. Das Serialisierungsproblem ist nur eine Frage der Einstellungen in diesem Tool.

Es gibt eine gute Open-Source-Version namens Obfuscar. Scheint gut zu funktionieren. Typen, Eigenschaften, Felder und Methoden können ausgeschlossen werden. Das Original ist hier: https://code.google.com/p/obfuscar/ , aber da es nicht mehr aktualisiert zu werden scheint

Möglicherweise möchten Sie auch neue Codeschutztechnologien wie Metaforic und ViLabs sowie neue Software-Kopierschutztechnologien wie ByteShield kennenlernen . Offenlegung: Ich arbeite für ByteShield.

Ich benutze auch Smartassembly. Ich weiß jedoch nicht, wie es für eine Webanwendung funktioniert. Ich möchte jedoch darauf hinweisen, dass Ihre App, wenn sie den Shareware-Typschutz verwendet, keine Lizenz mit einer booleschen Rückgabe überprüft. Es ist zu einfach, Crack zu byten. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

SmartAssembly ist großartig, ich wurde in den meisten meiner Projekte verwendet

Ich habe die Eziriz-Demoversion ausprobiert ... es hat mir gefallen. Aber nie die Software gebracht.

Verschleierung ist kein wirklicher Schutz.

Wenn Sie eine .NET Exe-Datei haben, gibt es eine weitaus bessere Lösung.

Ich benutze Themida und kann sagen, dass es sehr gut funktioniert.

Der einzige Nachteil von Themida ist, dass es keine .NET-DLLs schützen kann. (Es schützt auch C ++ - Code in Exe und DLLs.)

Themida ist weitaus billiger als die hier genannten Verschleierer und der beste Schutz gegen Piraterie auf dem Markt. Es wird eine virtuelle Maschine erstellt, auf der wichtige Teile Ihres Codes ausgeführt werden, und es werden mehrere Threads ausgeführt, die von einem Cracker festgelegte Manipulationen oder Haltepunkte erkennen. Es konvertiert die .NET Exe in etwas, das Reflector nicht einmal mehr als .NET-Assembly erkennt.

Bitte lesen Sie die detaillierte Beschreibung auf ihrer Website: http://www.oreans.com/themida_features.php

Ich habe ein Produkt namens Rummage ausprobiert und es macht einen guten Job, um Ihnen etwas Kontrolle zu geben ... Obwohl es viele Dinge fehlt, die Eziriz anbietet, ist der Preis für Rummage zu gut ...