Wie kann ich verhindern, dass andere Benutzer meine .Net-Assembly verwenden?

Ich habe eine Assembly, die nicht von einer anderen Anwendung als der angegebenen ausführbaren Datei verwendet werden sollte. Bitte geben Sie mir einige Anweisungen dazu.

0
hinzugefügt bearbeitet
Ansichten: 2
Überprüfen Sie mit Assembly.GetEntryAssembly()
hinzugefügt der Autor Darren Kopp, Quelle

13 Antworten

100% völlig unmöglich ohne durch einige Reifen zu springen.

Einer der Vorteile bei der Verwendung von .NET ist die Fähigkeit, Reflektion zu verwenden, dh eine Assembly zu laden und zu inspizieren, Methoden dynamisch aufzurufen usw. Dies macht Interop zwischen VB.NET und F # möglich.

Da sich Ihr Code jedoch in einer verwalteten Assembly befindet, kann jeder einen Verweis auf Ihren Code hinzufügen und seine öffentlichen Methoden aufrufen oder ihn mithilfe der Reflektion laden und private Methoden aufrufen . Selbst wenn Sie Ihren Code "verschleiern", können die Benutzer dennoch Reflektionen verwenden und Ihren Code aufrufen. Da jedoch alle Namen maskiert werden, ist alles sehr schwierig.

Wenn Sie Ihren .NET-Code so versenden müssen, dass er von anderen Personen nicht ausgeführt werden kann, können Sie möglicherweise Ihre Binärdatei (kompilieren sie nach x86) und diese Binärdateien versenden.

Ich kenne die Einzelheiten Ihrer Situation nicht, aber die Verschleierung sollte gut genug sein.

0
hinzugefügt
Ja, Sie können eine nicht verwaltete DLL dynamisch laden und auch ausführen - aber dann müssen Sie wissen: die Speicheradresse des Codes, die Anzahl/Art der Parameter, wie man diese Parameter marshalliert usw. Aufruf in nicht verwalteten Code, um Dinge zu tun ist praktisch unmöglich ohne die Quelle zu haben.
hinzugefügt der Autor Chris Smith, Quelle
Ich bin mir nicht sicher, wie mir das helfen wird. Ob es eine .net-Assembly oder eine native Assembly ist, sollte jeder in der Lage sein, es richtig zu laden.
hinzugefügt der Autor cathy, Quelle

Erfordert nur einen Passcode, der mit einem Funktionsaufruf gesendet wird, und wenn er nicht autorisiert wurde, dann funktioniert nichts, wie .setAuthorizeCode ('123456'), dann muss er an jedem Ort, an dem er verwendet werden kann, prüfen, ob authorizeCode! = 123456 ist dann Fehler werfen oder einfach ausbrechen ... Es klingt nicht wie eine gute Antwort für die Wiederverwendbarkeit, aber das ist genau der Punkt.

Die einzige Zeit, die es verwendet werden könnte, ist von Ihnen und wenn Sie den Autorisierungscode fest in das Programm einprogrammieren.

Nur ein Gedanke, könnte was du suchst oder dich zu etwas Besserem inspirieren.

0
hinzugefügt

Ich bin mir nicht sicher, ob dies für Sie verfügbar ist, aber vielleicht können Sie die Assembly mithilfe von WCF- oder ASP.NET-Webdiensten hosten und eine Art von Authentifizierungsschema (LDAP, öffentliche/rprivate Schlüsselpaare usw.) verwenden, um sicherzustellen Nur erlaubte Clients verbinden. Dies würde Ihre Assembly physisch außerhalb der Hände anderer halten und Sie können kontrollieren, wer sich mit ihm verbindet. Nur ein Gedanke.

0
hinzugefügt

Sie können die Verschleierung verwenden.

Das wird sich drehen:

int MySecretPrimeDetectionAlgorithm(int lastPrimeNumber);

In etwas Unlesbares wie:

int Asdfasdfasdfasdfasdfasdfasdf(int qwerqwerqwerqwerqwerqwer);

Andere werden zwar weiterhin in der Lage sein, Ihre Baugruppe zu verwenden, aber es wird schwierig sein, sie sinnvoll zu machen.

0
hinzugefügt

Sie können die Assembly und die ausführbare Datei mit demselben Schlüssel signieren und anschließend den Konstruktor der Klassen, die Sie schützen möchten, markieren:

public class NotForAnyoneElse {
  public NotForAnyoneElse() {
    if (typeof(NotForAnyoneElse).Assembly.GetName().GetPublicKeyToken() != Assembly.GetEntryAssembly().GetName().GetPublicKeyToken()) {
      throw new SomeException(...);
    }
  }
}
0
hinzugefügt
Ich konnte dies nur nach der Konvertierung der Token zu einer Zeichenfolge, z. BitConverter.ToString (typeof (NotForAnyoneElse) .Assembly.GetN & zwnj; ame (). GetPublicKeyTo & zwnj; ken ())
hinzugefügt der Autor JohnZaj, Quelle
Ich denke, die unten erwähnte Option InternalsVisibleTo ist besser. Es ist das gleiche wie diese Antwort, ohne die Codierung. Sie müssen die Assemblys für InternalsVisibleTo signieren, um zu funktionieren. Mit beiden Techniken können andere Benutzer die Methoden sehen und sie durch Reflexion aufrufen; aber beide Techniken werden fehlschlagen, wenn die aufrufende Assembly nicht den gleichen Schlüssel hat.
hinzugefügt der Autor Rob Kraft, Quelle

Sie sollten in der Lage sein, alles intern zu definieren und dann die InternalsVisibleTo Attribut, um nur dieser einen Baugruppe Zugriff auf die internen Methoden zu gewähren.

0
hinzugefügt
Kann es Reflexion besiegen?
hinzugefügt der Autor cathy, Quelle

The Code Access Security attribute that @Charles Graham mentions is StrongNameIdentityPermissionAttribute

0
hinzugefügt
Von diesem Link - In der .NET Framework-Version 2.0 und höher sind Anforderungen für Identitätsberechtigungen nicht wirksam, wenn die aufrufende Assembly vollständig vertrauenswürdig ist.
hinzugefügt der Autor cathy, Quelle

In .Net 2.0 oder besser, machen Sie alles intern und verwenden Sie dann Friend Assemblies

http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

Das wird die Reflexion nicht aufhalten. Ich möchte einige der Informationen von unten einbeziehen. Wenn Sie unbedingt jemanden davon abhalten müssen, anzurufen, ist wahrscheinlich die beste Lösung:

  1. ILMergetieren Sie die .exe und .dll
  2. verschleiern die letzte .exe

Sie können auch den Aufruf-Stack überprüfen und die Assembly für jeden Aufrufer abrufen und sicherstellen, dass alle mit demselben Schlüssel wie die Assembly signiert sind.

0
hinzugefügt
Wird das die Reflektion schlagen?
hinzugefügt der Autor cathy, Quelle
Nein, um die Reflexion zu besiegen, muss man sie verschleiern.
hinzugefügt der Autor Rick Minerich, Quelle

Sie können dies möglicherweise in den Code Access Security-Richtlinien für die Assembly festlegen.

0
hinzugefügt

Wie einige Leute erwähnt haben, verwenden Sie das Attribut InternalsVisibleTo und markieren Sie alles als intern. Das wird natürlich nicht vor Nachdenken bewahren.

One thing that hasnt been mentioned is to ilmerge your assemblies into your main .exe/.dll/whatever, this will up the barrier for entry a bit (people won't be able to see your assemby sitting on its own asking to be referenced), but wont stop the reflection route..

UPDATE: IIRC, ilmerge verfügt außerdem über eine Funktion, mit der die zusammengeführten Assemblys automatisch internalisiert werden können. Dies bedeutet, dass Sie InternalsVisibleTo überhaupt nicht verwenden müssen

0
hinzugefügt
Ironischerweise wird dieselbe Baugruppe bei Bedarf durch Reflexion geladen. Ich denke, es gibt keinen narrensicheren Weg, dies zu verhindern.
hinzugefügt der Autor cathy, Quelle

Sie können auch den Netz ausführbaren Packer und Compressor verwenden.

Dies nimmt Ihre Assemblys und Ihre EXE-Datei und packt sie in eine einzige ausführbare Datei, so dass sie für die Außenwelt nicht sichtbar sind, ohne ein bisschen herumzukramen.

Meine Vermutung ist, dass dies ausreicht, um den Zugriff für die meisten .net-Programmierer zu verhindern.

Ein großer Vorteil des .netz-Ansatzes ist, dass Sie Ihren Code nicht ändern müssen. Ein weiterer Vorteil ist, dass es Ihren Installationsprozess wirklich vereinfacht.

0
hinzugefügt

Wenn die Assembly beispielsweise ein Webdienst ist, können Sie sicherstellen, dass die angegebene ausführbare Datei einen geheimen Wert in der SOAP-Nachricht übergibt.

0
hinzugefügt

Es klingt, als ob Sie nach einem Schutz- oder Verschleierungstool suchen. Es gibt zwar keine Wunderwaffe, aber das Schutzwerkzeug, das ich empfehle, ist smartassembly . Einige Alternativen sind Salamander Obfuscator , dotfuscator und Xenocode .

Leider, wenn Sie Ihre Bytes jemandem zum Lesen geben ... wenn sie genug Zeit und Mühe haben, können sie Wege finden, Ihren Code zu laden und aufzurufen. Um einen Kommentar präventiv zu beantworten, sehe ich, dass Sie häufig fragen: Salamander wird verhindern, dass Ihr Code direkt in das Reflector-Tool geladen wird, aber ich hatte bessere (dh zuverlässigere) Erfahrungen mit Smart-Assembly.

Hoffe das hilft. :)

0
hinzugefügt