.NET-Bibliotheken vor Missbrauch schuetzen
-
Hi,
folgendes: der Code einer .NET-DLL ist leicht zugaenglich. Leute, die selbst entwickeln, koennen die DLLs von einem Produkt ebenfalls nutzen, indem sie in ihrer IDE einen Verweis auf die DLL setzen. Danach ist der Code fuer ihr eigenes Projekt zugaenglich.
Wie kann man seine DLLs davor schuetzen? :xmas1:
-
-
Such mal im Netz nach code,protect,dotnet,obfuscator.
-
endline schrieb:
Hi,
folgendes: der Code einer .NET-DLL ist leicht zugaenglich. Leute, die selbst entwickeln, koennen die DLLs von einem Produkt ebenfalls nutzen, indem sie in ihrer IDE einen Verweis auf die DLL setzen. Danach ist der Code fuer ihr eigenes Projekt zugaenglich.
Wie kann man seine DLLs davor schuetzen? :xmas1:
100%-ige Sicherheit gibt's nicht. Es ist alles eine Frage des Vorwissens und des Aufwands, den jemand betreiben will, um eine DLL zu "knacken".
Obfuzsierte Assemblies sind etwas schwerer zu ändern, weil der Code zwar weiterhin klar für die Maschine aber für einen Menschen sehr verworren wirkt. Aber Du kannst die DLL dennoch disassamblieren (s. z.B. Lutz Roeder's Reflector) und herausfinden "was die Welt im Innersten zusammenhält".
Wenn Du verhindern willst, dass ein anderer, nicht authorisierter Entwickler Deine Komponente verwendet, kannst du die Standardlizenzierungs-Mechanismen des .NET Framework verwenden (s. Link von geeky) aber es muss Dir klar sein, dass diese Art der Authorisierung völlig separat von der Logik der Komponente abläuft. Selbst wenn die DLL digital signiert ist, so dass beim Laden ihre Integrität überprüft werden kann, heißt das noch lange nicht, dass der wirklich relevante IL-Code nicht ausgelesen werden kann.
Wenn Du die investierte "geistige Arbeit" (z.B. Formeln) schützen möchtest, wird es schwieriger. Es gibt eine Menge Tools da draußen, die .NET-Assemblies schützen: Durch Verschlüsselung von Strings, Ersetzen von Funktionen durch Offsets, Modifizieren des Kontrollflusses, Ersetzen von Variablennamen durch solche, die unter normalen Bedingungen eine Neukompilierung verhindern, Neuorganisierung von IL-Code in den Assemblies usw. Decompilierter Code sieht dann so aus:
private ᝓᙄ ᝳᙄ(string ᙂ)
{
ᝓᙄ ᝓᙄ2 = new ᝓᙄ(ᙂ);
ᝓᙄ2.Text = "0x00000001 (0)" + Strings.Space(160) + "!!!!";
ᝓᙄ2.BackColor = this.BackColor;
ᝓᙄ2.ForeColor = this.ForeColor;
ᝓᙄ2.Enabled = true;
ᝓᙄ2.Width = this.Width;
ᝓᙄ2.Height = this.Height;
ᝓᙄ2.Visible = true;
return ᝓᙄ2;
}Zugegeben, das erschwert etwas das Ausspionieren von Programm-Logik, aber nicht wirklich!
Kein Programm besteht nur aus Geistes-Blitzen, das meiste ist pure Wiederholung von Altbekanntem. Wenn es dem Angreifer gelingt, den Punkt im disassemblierten Code zu finden, wo das Neue liegt, wird er auch schnell herausfinden, wie's funktioniert. Vorausgesetzt der Angreifer versteht sein Handwerk.
Man sollte sich aber nicht verrückt machen und die Schutzwürdigkeit des Codes immer in Relation zur größten anzunehmenden Gefährdung betrachten. Manchmal reicht es, statt String einfach SecureString (quasi DPAPI-Shortcut) zusammen mit den Klassen aus System.Security.Cryptography zu verwenden...
Und nicht vergessen: Eine Innovation veraltert nicht so schnell wie das Medium das sie implementiert. Wenn man eine DLL ausliefert, gibt man sie aus der Hand. In zwei-drei-vier Jahren könnten da draußen Tools existieren, die das, was heute nicht möglich ist, in Bruchteilen von Sekunden schaffen. Also immer davon ausgehen, dass es diese Tools schon gibt.
Warnung:
Obfuscator-Tools können auch negative Wirkungen haben: Sie können die Ausführung von Code verhindern, das auf Reflektion beruht, sie können remoting unmöglich machen, sie können das Debuggen aushebeln und zusätzliche subtile Fehlerquellen einführen (keine Software ist perfekt).
Siehe auch:
-
Vielen Dank.
-
@maro158
Gefällt mir, dein Bericht.Gruss Simon