Schutz von .NET-Code vor Reverse Engineering?

Question

Die Verschleierung ist eine Möglichkeit, aber sie kann nicht davor schützen, die Sicherheit der Anwendung gegen Piraterie zu verletzen. Wie stelle ich sicher, dass die Anwendung nicht manipuliert wird, und wie stelle ich sicher, dass der Registrierungsmechanismus nicht zurückentwickelt werden kann?

Es ist auch möglich, eine C#-Anwendung in nativen Code zu konvertieren, und Xenocode zu kostspielig ist.

C# bietet viele Funktionen und ist die ideale Sprache für meinen Code, so dass es nicht in Frage kommt, die gesamte Codebasis erneut in C++ zu schreiben.

Sichere Zertifikate können leicht aus den signierten Assemblies in .NET entfernt werden.

Answer 1

Ist es das wirklich wert? Jeder Schutzmechanismus kann mit genügend Entschlossenheit durchbrochen werden. Berücksichtigen Sie Ihren Markt, den Preis des Produkts, die Anzahl der Kunden usw.

Wenn Sie etwas Zuverlässigeres wollen, sollten Sie den Weg der Hardware-Schlüssel einschlagen, aber das ist (für den Benutzer) ziemlich umständlich und teurer. Softwarelösungen wären wahrscheinlich eine Verschwendung von Zeit und Ressourcen, und das Einzige, was sie Ihnen geben würden, ist ein falsches Gefühl von "Sicherheit".

Einige weitere Ideen (keine ist perfekt, denn es gibt keine perfekte Idee).

• AntiDuplikat
• Ändern Sie die Sprache, nutzen Sie die netten Tricks, die die Autoren von Skype gebraucht
• Lizenz-Server

Und verschwenden Sie nicht zu viel Zeit damit, denn die Cracker haben viel Erfahrung mit den typischen Techniken und sind Ihnen einige Schritte voraus. Wenn Sie nicht viele Ressourcen verbrauchen wollen, sollten Sie vielleicht die Programmiersprache wechseln (machen Sie es auf die Skype-Art).

Answer 2

Es gibt ein detailliertes Vergleichsblatt für verschiedene .Net-Verschleierungswerkzeuge.

Bildschirmfoto entnommen aus obfuscators.io

Answer 3

Abgesehen vom Kauf eines Schutzes können Sie (oder Ihre Entwickler) lernen, einen Kopierschutz zu erstellen.

Dies sind Ideen:

Versuchen Sie zunächst, ein Programm zu schreiben, das sich selbst auf die Konsole schreibt. Das ist ein bekanntes Problem. Der Hauptzweck dieser Aufgabe besteht darin, das Schreiben von selbstreferenzierendem Code zu üben.

Zweitens müssen Sie eine Technologie entwickeln, die einen Teil des Codes so umschreibt, dass verlässlich auf andere Methoden CIL .

Sie können eine virtuelle Maschine schreiben (noch in .NET ). Und fügen Sie dort etwas Code ein. Letztendlich führt die virtuelle Maschine eine andere virtuelle Maschine aus, die den Code ausführt. Das ist für einen Teil der selten aufgerufenen Funktionen, um die Leistung nicht zu sehr zu verlangsamen.

Schreiben Sie einen Teil der Logik in C++/CLI um, und mischen Sie verwalteten Code mit nicht verwaltetem. Dies wird die Disassemblierung erschweren. Vergessen Sie in diesem Fall nicht, die x64 auch Binärdateien.

Answer 4

Ja, es stimmt, .NET-Code ist extrem leicht zurückzuentwickeln, wenn der Code nicht verschleiert ist.

Die Verschleierung ist ein zusätzliches Ärgernis für Leute, die versuchen, Ihre Software zurückzuentwickeln. Je nachdem, welche Version Sie erwerben, erhalten Sie unterschiedliche Schutzniveaus.

Visual Studio enthält eine Version von Dotfuscator . Da es sich um eine gebündelte Version handelt, erhalten Sie definitiv nicht die stärkstmögliche Verschleierung. Wenn Sie sich die Funktionslisten ansehen, werden Sie genau sehen, was Sie vermissen (und was genau die Anwendung tun wird, um Ihren Code sicherer zu machen).

Es gibt eine Reihe anderer freier oder quelloffener .NET-Verschleierungsprogramme (ich kann jedoch nichts über die Qualität oder die verschiedenen Methoden sagen, die sie verwenden):

• Obfuscar
• Babel.NET

Letztendlich ist nichts perfekt. Wenn jemand wirklich sehen will, wie Ihre Software funktioniert, wird er das tun.

Answer 5

Leider werden Sie nicht davor weglaufen können. Am besten ist es, wenn Sie Ihren Code in C schreiben und P/Aufruf es.

Es gibt einen kleinen Haken: Jemand könnte Ihre Anwendung einfach dekompilieren, um CIL und beenden Sie jeglichen Verifizierungs-/Aktivierungscode (z. B. den Aufruf Ihrer C-Bibliothek). Denken Sie daran, dass in C geschriebene Anwendungen auch von hartnäckigeren Hackern zurückentwickelt werden (sehen Sie sich nur an, wie schnell Spiele heutzutage geknackt werden). Nichts wird Ihre Anwendung schützen.

Letztendlich funktioniert es ähnlich wie bei Ihrem Haus: Schützen Sie es so gut, dass es zu viel Aufwand ist (Spaghetti-Code würde hier helfen) und dass der Angreifer einfach zu Ihrem Nachbarn weiterzieht (Konkurrenz :) ). Sehen Sie sich Windows Vista an, es gibt bestimmt 10 verschiedene Möglichkeiten, es zu knacken.

Es gibt Pakete, die Ihre EXE-Datei verschlüsseln und entschlüsseln, wenn der Benutzer die Erlaubnis hat, sie zu benutzen, aber auch hier handelt es sich um eine generische Lösung, die zweifellos geknackt worden ist.

Die Aktivierungs- und Registrierungsmechanismen richten sich an den "Otto Normalverbraucher": Menschen, die nicht über genügend technisches Wissen verfügen, um sie zu umgehen (oder die wissen, dass sie sie umgehen können). Kümmern Sie sich nicht um Cracker, die haben viel zu viel Zeit für sich.