.NET-Verschleierungstools/Strategie [geschlossen]

https://stackoverflow.com/questions/2525

08-06-2019
|

Frage

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

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

Was ich bisher wissen sollte:

Serialisierung/Deserialisierung.In meiner aktuellen Lösung sage ich es einfach dem Tool nicht um alle Klassendatenmitglieder zu verschleiern, weil der Schmerz, Daten, die zuvor serialisiert wurden, nicht laden zu können, einfach zu groß ist.
Integration mit Build-Prozess
Arbeiten mit ASP.NET.In der Vergangenheit habe ich festgestellt, dass dies problematisch ist, weil sich die Namen der DLLs ändern (man hat oft einen pro Seite) – was nicht alle Tools gut handhaben.

Lösung

Zurück mit .Net 1.1 war Verschleierung unerlässlich:Das Dekompilieren des Codes war einfach, und man konnte vom Assembler über IL zum C#-Code wechseln und ihn mit sehr geringem Aufwand erneut kompilieren lassen.

Bei .Net 3.5 bin ich mir jetzt ü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 gehandhabt werden (das Neukompilieren ist ein Albtraum).Fügen Sie Lambda-Ausdrücke, Compiler-„Magie“ wie Linq-Syntax und hinzu var, und C#2 funktioniert wie yield (was zu neuen Klassen mit unlesbaren Namen führt).Ihr dekompilierter Code ist am Ende noch lange nicht kompilierbar.

Ein professionelles Team mit viel Zeit könnte es immer noch rückentwickeln, aber das Gleiche gilt für jeden verschleierten Code.Der daraus gewonnene Code wäre nicht wartbar und höchstwahrscheinlich sehr fehlerhaft.

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

Andere Tipps

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

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

Ehrlich gesagt bin ich davon überzeugt, dass die Verschleierung ein großer Trick ist.

Selbst die darin angesprochenen Probleme sind nicht unbedingt ein echtes Problem.Das Einzige, was Sie wirklich schützen müssen, sind Verbindungszeichenfolgen, Aktivierungscodes und ähnliche sicherheitsrelevante Dinge.Dieser Unsinn, dass ein anderes Unternehmen Ihre gesamte Codebasis zurückentwickeln und daraus ein Konkurrenzprodukt erstellen würde, ist der Albtraum eines paranoiden Managers und nicht die Realität.

Ich stecke derzeit tief in der Sache und versuche, eine gute Lösung zu finden.Hier sind meine bisherigen Eindrücke.

Xenocode - Ich habe eine alte Lizenz für Xenocode2005, die ich zum Verschleiern meiner .net 2.0-Assemblys verwendet habe.Es funktionierte gut unter XP und war eine anständige Lösung.Mein aktuelles Projekt ist .net 3.5 und ich verwende Vista. Der Support sagte mir, ich solle es versuchen, aber die Version von 2005 funktioniert nicht einmal unter Vista (stürzt ab), also muss ich und jetzt „PostBuild2008“ zu einem unglaublichen Preis kaufen von 1900 $.Das könnte ein gutes Werkzeug sein, aber ich werde es nicht herausfinden.Zu teuer.

Reactor.Net – Dies ist ein wesentlich attraktiverer Preis und hat auf meinem Standalone Executeable einwandfrei funktioniert.Das Lizenzierungsmodul war auch nett und hätte mir eine Menge Aufwand erspart.Leider fehlt eine wichtige Funktion, nämlich die Möglichkeit, Dinge von der Verschleierung auszuschließen.Dies macht es unmöglich, das gewünschte Ergebnis zu erzielen (mehrere Baugruppen zusammenführen, einige verschleiern, andere nicht verschleiern).

SmartAssembly - Ich habe das Eval 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 konnte auf der Website nicht gefunden werden.Derzeit in Gesprächen, um ein Angebot zu erhalten.Klingt bedrohlich.

Verwirrend - ein Open-Source-Projekt, das recht gut funktioniert (um die Leute zu verwirren, wie der Name schon sagt). https://confuser.codeplex.com/
(hinzugefügt von jgauffin)

Notiz:Berichten zufolge ist ConfuserEx „kaputt“. Ausgabe Nr. 498 auf ihrem GitHub-Repo.

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

Seit 29. Juni 2012, Eazfuscator.NET ist jetzt kommerziell.Die letzte kostenlos verfügbare Version ist 3.3.

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

Ich habe fast jeden Obfuscator 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 mich bei .net-Anwendungen viel besser ist.Es verschleiert, unterstützt Mono, führt Assemblys zusammen und verfügt außerdem über ein sehr schönes Lizenzierungsmodul, um eine Testversion zu erstellen oder die Lizenz mit einer bestimmten Maschine zu verknüpfen (sehr einfach zu implementieren).Auch der Preis ist sehr konkurrenzfähig und als ich Unterstützung brauchte, war sie schnell da.Eziriz

Um es klarzustellen: Ich bin nur ein Kunde, dem das Produkt gefällt und der in keiner Weise mit dem Unternehmen verbunden ist.

Die kurze Antwort lautet: Das geht nicht.

Es gibt verschiedene Tools, die es jemandem erschweren, Ihren Code zu lesen – auf einige davon wurde in anderen Antworten hingewiesen.

Allerdings erschweren diese nur die Lesbarkeit – sie erhöhen den Aufwand, das ist alles.Oft reicht dies aus, um Gelegenheitsleser abzuschrecken, aber jemand, der entschlossen ist, sich in Ihren Code einzuarbeiten, wird dies immer tun können.

Wir haben eine mehrstufige App mit einer asp.net- und Winform-Schnittstelle, 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 unerwartete Weise problematisch sein kann und sich meiner Meinung nach einfach nicht lohnt.Eigentlich würde mein Rat eher lauten: „Vermeiden Sie die Verschlüsselung von Loader-Verschleierungsgeräten wie die Pest.“:) :)

Meiner Erfahrung nach funktioniert jeder Obfuscator gut 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 vorantreiben können.Und nehmen Sie sich die Zeit, ein Reverse Engineering an dem, was Sie erhalten, zu versuchen und zu sehen, wie es mit den verschiedenen Einstellungen funktioniert.

Wir haben im Laufe der Jahre mehrere davon in unseren kommerziellen Apps verwendet und uns für den Spices Obfuscator von 9rays.net entschieden, weil der Preis stimmt, er seinen Zweck erfüllt und einen guten Support bietet, obwohl wir den Support seit Jahren wirklich nicht mehr benötigt haben, aber um ehrlich zu sein Ich glaube 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 in Wirklichkeit tun, das Äquivalent eines Vorhängeschlosses, das ansonsten ehrliche Leute fernhält und/oder es schwieriger macht, eine App einfach neu zu kompilieren.

Die Lizenzierung ist für die meisten Menschen in der Regel der Schlüsselbereich und Sie sollten auf jeden Fall für die Lizenzierung eine Art digital signiertes Zertifikatssystem verwenden.Ihr größter Verlust wird durch die zufällige Weitergabe von Lizenzen entstehen, wenn Sie nicht über ein intelligentes System verfügen. Die Leute, die das Lizenzsystem brechen, würden von vornherein nie kaufen.

Es ist wirklich leicht, zu weit zu gehen und negative Auswirkungen auf Ihre Kunden und Ihr Unternehmen zu haben. Tun Sie das Einfache und Vernünftige und machen Sie sich darüber keine Sorgen.

In den letzten zwei Tagen habe ich mit Dotfuscator Community Edition Advanced experimentiert (ein kostenloser Download nach der Registrierung des Basis-CE, das im Lieferumfang von Visual Studio enthalten ist).

Ich denke, der Grund dafür, dass immer mehr Menschen die Verschleierung nicht als Standardoption verwenden, liegt darin, dass es im Vergleich zum Risiko ein großer Aufwand ist.Bei kleineren Testprojekten konnte ich mit viel Aufwand den verschleierten Code zum Laufen bringen.Die Bereitstellung eines einfachen Projekts über ClickOnce war mühsam, aber machbar, nachdem die Manifeste manuell mit Mage signiert wurden.Das einzige Problem bestand darin, dass der Stack-Trace aufgrund eines Fehlers verschleiert zurückkam und im CE kein Deobfuscator oder Clarifier enthalten war.

Ich habe versucht, ein echtes 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 Verschleierung wirklich eine entscheidende Anforderung ist, sollten Sie Ihre Anwendung von Anfang an unter diesem Gesichtspunkt entwerfen und die verschleierten Builds im weiteren Verlauf testen.Andernfalls werden Sie, wenn es sich um ein recht komplexes Projekt handelt, am Ende erhebliche Schmerzen haben.

Krypto-Verschleierer Gehen Sie auf alle Ihre Anliegen und Szenarien ein.Es :

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

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

Was die Serialisierung betrifft, 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 nicht sowieso im XML enthalten waren, sodass keine Verschleierung erforderlich war.Wenn in diesen Klassen schwerwiegender Code vorhanden ist, sollte dieser durch die Verwendung von Teilklassen in der Hauptassembly abgedeckt werden.

Sie sollten das nutzen, was für Ihre Plattform am günstigsten und bekanntesten ist, und Schluss damit machen.Die Verschleierung von Hochsprachen ist ein großes 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 die Bytecode-Umkehrung wissen sollten, ist, dass es für Sicherheitstester bereits gängige Praxis ist, reinen X86-Code zu überprüfen und darin Schwachstellen zu finden.In rohem X86 können Sie nicht unbedingt gültige Funktionen finden, geschweige denn eine lokale Variable während eines Funktionsaufrufs verfolgen.Unter fast keinen Umständen haben native Code-Umkehrer Zugriff auf Funktions- und Variablennamen – es sei denn, sie überprüfen Microsoft-Code, für den MSFT diese Informationen hilfreich der Öffentlichkeit zur Verfügung stellt.

„Dotfuscation“ funktioniert hauptsächlich durch das Verschlüsseln von Funktions- und Variablennamen.Es ist wahrscheinlich besser, dies zu tun, als Code mit Informationen auf Debug-Ebene zu veröffentlichen, bei dem der Reflector Ihren Quellcode buchstäblich preisgibt.Aber alles, was Sie darüber hinaus tun, führt wahrscheinlich zu sinkenden Erträgen.

Ich hatte keine Probleme mit Smartassembly.

Sie könnten „Dotfuscator Community Edition“ verwenden – es ist standardmäßig in Visual Studio 2008 Professional enthalten.Sie können darüber nachlesen 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.

Muss Ihr Code wirklich verschleiert werden?Normalerweise gibt es kaum etwas Falsches daran, Ihre Anwendung zu dekompilieren, es sei denn, sie wird aus Sicherheitsgründen verwendet.Wenn Sie befürchten, dass jemand Ihren Code „stiehlt“, ist das kein Grund zur Sorge.Die überwiegende Mehrheit der Leute, die sich Ihren Code ansehen, wird zu Lernzwecken dienen.Auf jeden Fall gibt es keine völlig wirksame Verschleierungsstrategie für .NET – jemand mit ausreichenden Kenntnissen wird immer in der Lage sein, Ihre Anwendung zu dekompilieren/ändern.

Vermeiden Sie Reaktor.Es ist völlig nutzlos (und ja, ich habe für eine Lizenz bezahlt).Xenocode war das Beste, das mir begegnet ist, und habe auch eine Lizenz dafür gekauft.Der Support war sehr gut, aber ich brauchte ihn nicht sehr, da er einfach funktionierte.Ich habe jeden Obfuscator getestet, den ich finden konnte, und bin zu dem Schluss gekommen, dass Xenocode bei weitem der robusteste war und die beste Arbeit leistete (auch die Möglichkeit, Ihre .NET-Exe in eine native Exe zu überführen, die ich sonst nirgends gesehen habe).

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

Meiner Meinung nach bietet Agile.Net einen ziemlich guten Schutz für Ihre .Net-Assembly, 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 verschleiere seit .Net 1 Code in derselben Anwendung, und das bereitet mir aus Wartungssicht große Kopfschmerzen.Wie Sie bereits erwähnt haben, kann das Serialisierungsproblem vermieden werden, aber es ist wirklich leicht, einen Fehler zu machen und etwas zu verschleiern, das nicht verschleiert werden soll.Es ist leicht, den Build zu unterbrechen oder das Verschleierungsmuster zu ändern und alte Dateien nicht öffnen zu können.Außerdem kann es schwierig sein herauszufinden, was wo schief gelaufen ist.

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

Hier ist ein Dokument von Microsoft selbst. Ich 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 einfach gut.

Fügt auch einige zusätzliche Probleme hinzu.Das Ausdrucken Ihrer Klassennamen in Protokolldateien/Ausnahmen muss entschlüsselt werden.Und natürlich kann man aus seinem Namen keine Klasse erstellen.Daher ist es eine gute Idee, einen Blick auf Ihren Kunden zu werfen und zu sehen, welche Probleme Sie durch die Verschleierung bekommen 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üssten Sie rausgehen und einen Obfuscator wie Postbuild kaufen (http://www.xenocode.com/Landing/Obfuscation.aspx)

Ich musste in meinem neuesten Projekt einen Verschleierungs-/Ressourcenschutz verwenden und habe Folgendes gefunden Krypto-Verschleierer als schönes und einfach zu bedienendes 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, Methoden können ausgeschlossen werden.Das Original gibt es hier: https://code.google.com/p/obfuscar/, aber da es anscheinend nicht mehr aktualisiert wird, hat es jemand hierher geforkt: https://obfuscar.codeplex.com/

Möglicherweise möchten Sie sich auch mit neuen Codeschutztechnologien befassen, z Metaforisch Und V.i.Labs und neue Software-Kopierschutztechnologien wie z ByteShield.Offenlegung:Ich arbeite für ByteShield.

Ich verwende auch Smartassembly.Ich weiß jedoch nicht, wie es für eine Webanwendung funktioniert.Ich möchte jedoch darauf hinweisen, dass, wenn Ihre App einen Shareware-Typ-Schutz verwendet, Sie darauf achten sollten, dass keine Lizenz mit einem booleschen Rückgabewert überprüft wird.Es ist zu einfach, Bytes zu knacken.http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

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

Ich habe die Eziriz-Demoversion ausprobiert ... es hat mir gefallen.Habe die Software aber nie mitgebracht.

Verschleierung ist kein wirklicher Schutz.

Wenn Sie eine .NET Exe-Datei haben, gibt es eine Weit besser Lösung.

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

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

Themida ist bei weitem günstiger als die hier genannten Obfuskatoren und der Beste auf dem Markt Anti Piraterie Schutz auf dem Markt.Es erstellt eine virtuelle Maschine, in der kritische Teile Ihres Codes ausgeführt werden, und führt mehrere Threads aus, die Manipulationen oder von einem Cracker gesetzte Haltepunkte erkennen.Es konvertiert die .NET-Exe-Datei 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 leistet gute Arbeit und gibt Ihnen etwas Kontrolle ...Es fehlen zwar viele Dinge, die Eziriz bietet, aber der Preis für Rummage ist zu gut ...

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow