Alternative zur Verschleierung in der .NET-Welt

8

Gibt es Alternativen zur Verschleierung, um Ihren Code vor Diebstahl zu schützen?

    
Rookian 26.08.2011, 11:38
quelle

4 Antworten

22

Ein ultimativer Schutz ist das SaaS-Modell. Alles andere wird deine wertvollen Geheimnisse auf die eine oder andere Weise enthüllen.

Siehe: Ссылка

    
SK-logic 26.08.2011, 12:18
quelle
4

Eine kurze Antwort ist:

  • Verschleierung hat nichts mit Diebstahlschutz zu tun.
  • Der einzige Zweck von Obfuscation besteht darin, das Lesen und Verstehen Ihres Codes zu erschweren, so dass Reverse Engineering im besten Fall wirtschaftlich unattraktiv ist.

Es ist immer noch möglich, dass jemand Ihren Quellcode stiehlt. Selbst wenn Sie die beste verfügbare Verschleierungstechnologie verwenden oder wenn Sie an SaaS-Szenarien denken.

Normalerweise haben Sie Ihren Quellcode mindestens an zwei Stellen zusammen mit allen Meta-Dateien, die Sie zum Erstellen des Projekts benötigen:

  1. Ihr Entwicklungscomputer
  2. Ihr Code-Repository

Wenn Sie Ihren Code vor Diebstahl schützen möchten, sind dies die ersten Orte, an denen aktiv sein muss. Selbst die größten Marktteilnehmer wie Adobe, Microsoft Corporation, Symantec haben aufgrund eines Diebstahls zwar Quellcode verloren, aber nicht durch Reverse Engineering. Und in größeren Unternehmen braucht es keinen externen Angreifer - ein abwesender Mitarbeiter genügt manchmal.

Sie könnten also interessiert sein an:

  • Starke Maschinenverschlüsselung
  • Antivirus, Anti-Rootkit, Anti-Malware
  • Firewall und Angriffserkennung
  • Schutz digitaler Objekte
  • Begrenzter Internetzugang auf Entwicklungscomputern
  • Verwaltete ferne Entwicklungsumgebungen, sodass die Quelle niemals gesicherte Server und Infrastruktur verlässt
  • usw. pp.
  • Klare Prozesse und konsistente Rechteverwaltung

Heutzutage ist es in vielen Fällen ein größeres Risiko, dass ein schlechter Typ Zugang zu Ihrem Repository oder Entwicklungssystem erhält oder dass ein ausscheidender Mitarbeiter eine "Sicherungskopie" Ihres Codes hat, als ein Unternehmen Zeit in das Reverse Engineering investiert bestehende Anwendungen, um eine 1: 1-Kopie zu erstellen oder Änderungen vorzunehmen (beides ist in den meisten Ländern illegal und kann zu großen Reputationsschäden und teuren Sätzen führen und sie haben auch keine Möglichkeit, professionelle Unterstützung für solche gehackte und modifizierte Software zu erhalten)

Verschleierung bedeutet auch nicht, dass Ihr geistiges Eigentum gegen Diebstahl oder Kopieren geschützt ist. Abhängig vom verwendeten Obfuscator ist es immer noch möglich, Logik zu analysieren.

Wenn Sie die Analyselogik schwieriger machen möchten, benötigen Sie eine Art Kontrollflussverschleierung. Aber cfo kann viele lustige und schwer zu debuggende Probleme produzieren. Ich bin sicher, das ist in den meisten Fällen eher ein zusätzliches Problem als eine Lösung.

Die schlechte Realität ist, dass die Verschleierung nicht das Problem des Reverse Engineering löst. Es löst das Problem von 1: 1 (oder fast 1: 1) Code-Kopien. Das liegt daran, dass die meisten Software eine erkennbare Benutzeroberfläche oder Verhalten hat und in fast allen Fällen ist es möglich, Benutzeroberflächen und Verhaltensweisen zu reproduzieren (oder um genauer zu sein: Die Ergebnisse) und es gibt kein Werkzeug, um Software davor zu schützen.

Wenn Sie möchten, dass Gelegenheits-Programmierer Ihren Code verstehen, können Open-Source-Tools wie obfuscar gut genug sein. Aber ich wette, dass Sie auf Probleme stoßen, wenn Sie Technologien wie Reflektion, Remoting, Plugins, dynamisches Laden und Bauen von Baugruppen usw. verwenden. Pp.

Aus meiner Sicht - und das ist auch meine Erfahrung - ist Verschleierung in den meisten Fällen entbehrlich.

Wenn Sie anderen den Zugriff auf Ihren Code wirklich schwer machen wollen (während "wirklich schwer" relativ ist), haben Sie im Allgemeinen zwei Möglichkeiten:

  1. Eine Art kryptographischer Container mit einer virtuellen Ausführungsumgebung und einem virtuellen Dateisystem, das nicht nur Ihren Code, sondern auch die gesamte Anwendung und ihre Struktur schützt. Der Angriffsvektor ist z.B. der Speicher zur Laufzeit oder der Container selbst.

  2. Denken Sie über SaaS nach, was bedeutet, dass Sie den Zugang zu Ihrer Software, aber nicht die Software selbst liefern. Bedenken Sie jedoch, dass SaaS-Lösungen je nach Service-Level, Sicherheit und Vertrauen, die Sie benötigen oder bereitstellen müssen, schwer zu entwickeln und teuer sein können. Der Angriffsvektor ist z.B. die Serverinfrastruktur.

Diese ultimative 100% kugelsichere Lösung existiert tatsächlich nicht auf diesem Planeten.

Zu guter Letzt könnte es notwendig sein, den Kunden in einigen Situationen vollständigen Quellcode zur Verfügung zu stellen. Z.B. wenn Sie individuelle Software entwickeln und Code liefern, ist das ein Teil Ihres Vertrages oder wenn Sie in kritischen Segmenten wie Luft- und Raumfahrt, Militärindustrie, Regierungssystemen usw. tätig sein wollen. pp.

    
Axel Napolitano 18.04.2014 23:59
quelle
3

Sie könnten auch die sensitiven Funktionen / Komponenten in natives C ++ codieren, sie in C ++ / CLI umwandeln und mit .NET verwenden.

Natürlich kann es immer noch reverse engineered sein, aber es ist trotzdem eine Alternative.

    
Seth 06.09.2011 04:03
quelle
-1

Es gibt keinen Obfuscator, der jemals sicher genug ist, um eine in .NET geschriebene Anwendung zu schützen. Vergiss es! Verschleierung ist kein wirklicher Schutz.

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

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

Themida ist bei weitem billiger als die meisten Obfuscatoren und ist der beste Anti-Piraterie-Schutz auf dem Markt. Es erstellt eine virtuelle Maschine, in der kritische Teile Ihres Codes ausgeführt werden und mehrere Threads ausführt, die Manipulationen oder Breakpoints erkennen, die von einem Cracker gesetzt werden. 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: Ссылка

Der einzige Nachteil von Themida ist, dass .NET Dlls nicht geschützt werden können. (Seine Stärke ist der Schutz von C ++ - Code in Exe und DLLs)

    
Elmue 06.03.2014 03:25
quelle

Tags und Links