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

Sie können nicht verhindern, dass jemand Ihre Software knackt.

Sie können sie jedoch dazu bringen, Risse zu erzeugen, die Ihren Verkäufen weniger schaden. Schlüsselgeneratoren, die einen gültigen Registrierungscode für Ihre Software ausgeben können, sind viel schlimmer als einfache Patches, die Registrierungsanreize aus Ihrer Software entfernen. Das liegt daran, dass ein Crack nur für eine Softwareversion funktioniert und mit dem nächsten Software-Update, das Sie herausbringen, nicht mehr funktioniert. Der Schlüsselgenerator funktioniert so lange, bis Sie Ihren Registrierungsschlüssel-Algorithmus ändern, und das ist etwas, was Sie nicht oft tun wollen, weil es Ihre ehrlichen Kunden abschrecken wird.

Wenn Sie also nach einer Methode suchen, um illegale Schlüsselgeneratoren für Ihre Software zu bekämpfen, und Sie keine assymetrische Verschlüsselung wegen der langen Registrierungscodes, die dadurch erzeugt werden, verwenden möchten, sollten Sie sich die Partielle Schlüsselüberprüfung ansehen.

Die partielle Schlüsselüberprüfung stellt sicher, dass jeder illegale Schlüsselgenerator nur für eine bestimmte Version Ihrer Software funktioniert. Im Grunde genommen stellen Sie damit sicher, dass jede Version Ihrer Software nur mit dem Code zur Überprüfung EINIGER Ziffern des Registrierungscodes verknüpft ist. Welche Ziffern das genau sind, ist zufällig, so dass Cracker viele verschiedene Versionen Ihrer Software zurückentwickeln und all dies in einem Schlüsselgenerator kombinieren müssten, um einen Schlüsselgenerator zu veröffentlichen, der für alle Versionen Ihrer Software funktioniert.

Wenn Sie regelmäßig neue Softwareversionen herausgeben, führt dies zu zahlreichen Schlüsselgeneratoren, die in allen möglichen Softwarepiraterie-Archiven verbreitet werden und nicht mehr funktionieren. Potenzielle Softwarepiraten suchen in der Regel nach einem Crack oder Keygen für die neueste Version, also werden sie wahrscheinlich einige davon ausprobieren und schließlich aufgeben.

Ich habe die Partial Key Verification in meinen (C++) neueren Shareware-Spielen verwendet und sie hat sich als sehr effektiv erwiesen. Vorher hatten wir eine Menge Probleme mit Schlüsselgeneratoren, die wir nicht bekämpfen konnten. Danach gab es viele Cracks und einige wenige Key-Generatoren, die nur für die jeweilige Version des Spiels funktionierten, aber keinen Key-Generator, der mit allen Versionen funktioniert hätte. Wir haben regelmäßig sehr kleine Updates für das Spiel veröffentlicht, um alle bereits existierenden Cracks unbrauchbar zu machen.

Es scheint eine offene Quelle zu geben .NET-Framework für partielle Schlüsselüberprüfung obwohl ich es nicht ausprobiert habe.

Answer 2

• Verwenden Sie die Online-Aktualisierung, um diese nicht lizenzierten Kopien zu blockieren.

• Überprüfen Sie die Seriennummer von verschiedenen Modulen Ihrer Anwendung und verwenden Sie nicht eine einzelne Funktionsaufruf für die Überprüfung (damit Cracker die Überprüfung nicht einfach umgehen können).

• Prüfen Sie nicht nur die Seriennummer unter Start, sondern auch beim Speichern von beim Speichern von Daten, jeden Freitag abends, wenn der Benutzer im Leerlauf ist ...

• Überprüfung der Bewerbungsunterlagen Summe, speichern Sie Ihre Sicherheits-Checksumme an verschiedenen Orten.

• Gehen Sie nicht zu weit mit dieser Art von Tricks, stellen Sie sicher, dass Ihre Anwendung niemals abstürzt/zu einer Fehlfunktion führt während der Überprüfung des Registrierungscodes.

• Eine nützliche Anwendung für Benutzer zu erstellen ist viel wichtiger als die Herstellung einer
  unzerbrechliches Binärsystem für Cracker.

Answer 3

Sie können

Microsoft SLP-Dienste Das Software-Potenzial von InishTech bietet die Möglichkeit, den Code zu schützen, ohne die Funktionalität Ihrer Anwendungen zu beeinträchtigen.

UPDATE: (Offenlegung: Ich arbeite an Eazfuscator.NET) Was macht Microsoft SLP-Dienste Software-Potenzial Unterschied ist die Möglichkeit, den Code zu virtualisieren, so dass Sie definitiv kann . Es sind einige Jahre vergangen, seit die Frage ursprünglich gestellt wurde; heute gibt es mehr Produkte, die auf einer ähnlichen Grundlage funktionieren, wie z. B.:

• Agile.NET
• Eazfuscator.NET

Answer 4

Wenn Sie wollen, dass andere Ihren Code ausführen können (und wenn nicht, warum haben Sie ihn dann überhaupt geschrieben?), dann muss ihre CPU in der Lage sein, Ihren Code auszuführen. Um in der Lage zu sein ausführen. den Code, muss die CPU in der Lage sein verstehen. es.

Da CPUs stumm sind und Menschen nicht, bedeutet dies, dass auch Menschen den Code verstehen können.

Es gibt nur einen Weg, um sicherzustellen, dass Ihre Benutzer Ihren Code nicht bekommen: Geben Sie ihnen Ihren Code nicht.

Dies kann auf zwei Arten erreicht werden: Software als Dienstleistung (SaaS), d.h. Sie betreiben Ihre Software auf Ihr Server und lassen Sie Ihre Benutzer nur aus der Ferne darauf zugreifen. Dieses Modell verwendet zum Beispiel Stack Overflow. Ich bin mir ziemlich sicher, dass Stack Overflow seinen Code nicht verschlüsselt, aber man kann ihn nicht dekompilieren.

Die andere Möglichkeit ist das Gerätemodell: Statt den Nutzern Ihren Code zu geben, geben Sie ihnen einen Computer, der den Code enthält. Dies ist das Modell, das Spielekonsolen, die meisten Mobiltelefone und TiVo verwenden. Beachten Sie, dass dies nur funktioniert, wenn Sie den gesamten Ausführungspfad "besitzen": Sie müssen Ihre eigene CPU und Ihren eigenen Computer bauen, Ihr eigenes Betriebssystem schreiben und Ihre eigene CLI Umsetzung. Dann, und nur dann können Sie Ihren Code schützen. (Beachten Sie aber, dass auch die winzige Wenn Sie einen Fehler machen, sind alle Ihre Schutzmaßnahmen nutzlos. Microsoft, Apple, Sony, die Musikindustrie und die Filmindustrie können das bestätigen.)

Sie können aber auch einfach nichts tun, dann ist Ihr Code automatisch urheberrechtlich geschützt.

Answer 5

.NET-Reflektor kann nur "verwalteten Code" öffnen, was im Grunde ".NET-Code" bedeutet. Sie können es also nicht verwenden, um COM DLL-Dateien, natives C++ oder klassische C++-Dateien zu disassemblieren. Visual Basic 6.0 Code, etc. Die Struktur von kompiliertem .NET-Code macht ihn sehr bequem, portabel, auffindbar, überprüfbar usw. .NET Reflector nutzt dies, um einen Blick in kompilierte Assemblies zu werfen, aber Decompiler und Disassembler sind keineswegs spezifisch für .NET und gibt es schon so lange wie es Compiler gibt.

Sie können Obfuskatoren verwenden, um den Code schwerer lesbar zu machen, aber Sie können nicht verhindern, dass er dekompiliert wird, ohne ihn auch für .NET unlesbar zu machen. Es gibt eine Handvoll von Produkte Es gibt zahlreiche (in der Regel teure) Produkte, die behaupten, Ihre Managed-Code-Anwendung mit einer Native-Code-Anwendung zu "verknüpfen", aber selbst wenn diese tatsächlich funktionieren, wird ein entschlossener Mensch immer einen Weg finden.

Wenn es jedoch um Verschleierung geht, bekommt man das, wofür man bezahlt. Wenn Ihr Code also so geschützt ist, dass Sie sich so viel Mühe geben müssen, um ihn zu schützen, sollten Sie bereit sein, Geld in einen guten Obfuskator zu investieren.

In den rund 15 Jahren, in denen ich Code schreibe, habe ich jedoch festgestellt, dass ein übermäßiger Schutz des Quellcodes Zeitverschwendung ist und wenig Nutzen bringt. Allein der Versuch, Original-Quellcode ohne unterstützende Dokumentation, Kommentare usw. zu lesen, kann sehr schwer zu verstehen sein. Nimmt man noch die sinnlosen Variablennamen hinzu, die sich Decompiler ausdenken, und den Spaghetti-Code, den moderne Obfuscators erzeugen, braucht man sich wahrscheinlich nicht allzu viele Gedanken darüber zu machen, dass andere Ihr geistiges Eigentum stehlen.