Ich habe eine Baugruppe, die nicht von jeder anderen Anwendung als die angegebene ausführbare Datei verwendet werden sollte. Bitte geben Sie mir einige Anweisungen dazu.Wie kann ich verhindern, dass andere Benutzer meine .Net-Assembly verwenden?
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(...);
}
}
}
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. –
Ich konnte das nur nach der Umwandlung der Tokens in eine Zeichenfolge, z. BitConverter.ToString (typeof (NotForAnyoneElse) .Assembly.GetName(). GetPublicKeyToken()) – JohnZaj
Sie können dies möglicherweise in den Code Access Security-Richtlinien für die Assembly festlegen.
Sie sollten in der Lage sein, alles intern zu definieren, und dann das InternalsVisibleTo Attribut verwenden, um nur diesen einen Assembly Zugriff auf die internen Methoden zu gewähren.
kann es Reflexion zu schlagen? – cathy
In .Net 2.0 oder besser, alles intern machen, und dann verwenden Friend-Assemblys
http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx
Dies wird nicht Reflexion stoppen. Ich möchte einige der Informationen von unten einbeziehen. Wenn Sie unbedingt jemanden brauchen, um zu verhindern Aufruf, wahrscheinlich die beste Lösung ist:
Sie den Anruf auch prüfen könnte stack und holen Sie die Assembly für jeden Aufrufer und stellen Sie sicher, dass sie alle mit demselben Schlüssel wie die Assembly signiert sind.
wird diese Reflexion schlagen? – cathy
Nein, um die Reflexion zu übertreffen, muss man sie verschleiern. –
Wenn es sich bei der Assembly beispielsweise um einen Webdienst handelt, können Sie sicherstellen, dass die angegebene ausführbare Datei einen geheimen Wert in der SOAP-Nachricht übergibt.
Sie können die Verschleierung verwenden.
Das verwandelt:
int MySecretPrimeDetectionAlgorithm(int lastPrimeNumber);
In etwas unleserlich wie:
int Asdfasdfasdfasdfasdfasdfasdf(int qwerqwerqwerqwerqwerqwer);
Andere noch in der Lage sein wird, die Assembly zu verwenden, aber es wird schwierig sein, jede vernünftig zu machen.
100% völlig unmöglich ohne durch einige Reifen zu springen.
Einer der Vorteile 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 Ihr Code in einer verwalteten Assembly ist, bedeutet dies, dass jeder einen Verweis auf Ihren Code hinzufügen und seine öffentlichen Methoden aufrufen oder mit Reflektion laden und private Methoden aufrufen kann. 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 andere Benutzer ihn nicht ausführen können, 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.
Ich bin mir nicht sicher, wie das mir helfen wird. Ob es eine .net Assembly oder eine native Assembly ist, sollte jemand in der Lage sein, es richtig zu laden. – cathy
Ja, Sie können eine nicht verwaltete DLL dynamisch laden und das auch ausführen Dann müssen Sie wissen: die Speicheradresse des Codes, die Anzahl/Art der Parameter, wie man diese Parameter marshalliert usw. Unmanaged Code zu verwenden, um Dinge zu tun, ist praktisch unmöglich, ohne die Quelle zu haben. –
Der Zugang Sicherheits-Code-Attribut, das @Charles Graham ist erwähnt StrongNameIdentityPermissionAttribute
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. – cathy
Da einige Leute schon erwähnt haben, das Attribut InternalsVisibleTo verwenden und alles als internes markiert. Das wird natürlich nicht vor Nachdenken bewahren.
Eine Sache, die nicht erwähnt wurde, ist ilmerge Ihre Assemblies in Ihre Hauptdatei .exe/.dll/was auch immer, dies wird die Schranke für den Eintritt ein wenig (Menschen werden nicht in der Lage sein, Ihre Assemby sitzen allein zu sehen (wird gebeten, referenziert zu werden), aber stoppt die Reflektionsroute nicht.
UPDATE: IIRC, ilmerge verfügt auch über eine Funktion, mit der es die zusammengeführten Assemblys automatisch internalisieren kann, was bedeutet, dass Sie InternalsVisibleTo überhaupt nicht verwenden müssen
ironischerweise wird dieselbe Baugruppe bei Bedarf mit Reflektion geladen. Ich denke, es gibt keinen narrensicheren Weg, dies zu verhindern. – cathy
Sie können auch den ausführbaren Packer und Kompressor Netz 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.
Es klingt, als ob Sie ein Schutz- oder Verschleierungstool suchen. Es gibt zwar keine Wunderwaffe, aber das von mir empfohlene Schutzwerkzeug ist smartassembly. Einige Alternativen sind Salamander Obfuscator, dotfuscator und Xenocode.
Leider, wenn Sie Ihre Bytes jemandem zu lesen geben ... wenn sie genug Zeit und Mühe haben, können sie finden, laden und rufen Sie Ihren Code. 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. :)
Ich bin mir nicht sicher, ob dies eine verfügbare Möglichkeit für Sie ist, aber vielleicht können Sie die Assembly mit WCF oder ASP.NET-Webdiensten hosten und eine Art von Authentifizierungsschema verwenden (LDAP, public/rprivate-Schlüsselpaare usw.), um sicherzustellen, dass nur zugelassene Clients eine Verbindung herstellen können. 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.
Benötigen Sie einfach einen Zugangscode, der mit einem Funktionsaufruf gesendet wird, und wenn es nicht autorisiert wurde, dann funktioniert nichts, wie .setAuthorizeCode ('123456'), dann an jedem einzelnen Platz, den Sie verwenden können authorizeCode! = 123456 dann Fehler werfen oder einfach aus ... 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.
Überprüfen Sie mit [Assembly.GetEntryAssembly()] (http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly.aspx) –