Laden...

Code vor unerlaubten Zugriff schützen

Erstellt von sugar76 vor 6 Jahren Letzter Beitrag vor 4 Jahren 4.369 Views
S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 6 Jahren
Code vor unerlaubten Zugriff schützen

Hallo allerseits,

ich habe zwar schon viel entwickelt, aber wenig Erfahrungen damit, wie ich von mir entwickelte Software vor unerlaubtem Zugriff schützen kann. Das gilt insbesondere dann, wenn die Software beim Kunden installiert ist, also nicht auf einem von mir betriebenen Server läuft.

Das betrifft folgendes:
* Wie kann ich sicherstellen, dass der Code nicht per Reverse Engineering ausgelesen werden kann?
* Wie kann ich verhindern, dass sensible Daten, wie z.B. Connection-Strings für Datenbanken, nicht im Klartext in irgendwelchen Config-Dateien landen, sondern verschlüsselt werden?

Wie sind Eure Erfahrungen in diesem Bereich?

Grüße,

Abid

16.806 Beiträge seit 2008
vor 6 Jahren

Das Thema wurde ungefähr 42986423490324234 mal besprochen - und das vorsichtig geschätzt.

Bitte wenigstens 10 Sekunden die Forensuche oder Google verwenden. Wenigstens 10 Sekunden.
Beim Suchbegriff obfuscator hier im Forum findest Du über 150 Threads dazu.

Das Fazit ist: gar nicht.

Schutz vor Deobfuscation
[FAQ] DB-Password/Kennwort/Connection-String sicher speichern

Wenn Du ConnectionStrings brauchst, dann scheint es schon ein grundlegender Fehler bzgl. Architektur zu sein, dass die Anwendung direkt auf einen Datenbankserver zugreift und nicht über eine Server-Anwendung (zB ein REST-Service) dazwischen.
Eine solche Server-Anwendung wäre dann auch für eine individuelle Authentifizierung des Benutzers zuständig. Sowas sollte niemals die Datenbank übernehmen. Dafür ist sie nicht da; das kann sie auch nicht.

Das Prinzip dahinter ist eine ganz normale Client Server Architektur.
Nur, dass bei euch wohl der Server nur physikalisch und nicht als Anwendung vorhanden ist.

S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 6 Jahren

Das Thema wurde ungefähr 42986423490324234 mal besprochen - und das vorsichtig geschätzt.

Da hast Du Recht... ich wollte einfach eine Diskussion eröffnen, der Stand der Technik kann sich ja mit der Zeit ändern.

Wenn Du ConnectionStrings brauchst, dann scheint es schon ein grundlegender Fehler bzgl. Architektur zu sein, dass die Anwendung direkt auf einen Datenbankserver zugreift und nicht über einen Service (zB. REST) dazwischen.

Bzgl. Architektur gebe ich Dir nochmal Recht. Es gibt aber Szenarien, in denen die Software beim Kunden läuft und dann läuft beim Kunden auch der REST-Service. Egal, welche Architektur man verwendet, irgendeine Komponente hat den Zugriff zur Datenbank und dort steht dann ein Connection-String.

16.806 Beiträge seit 2008
vor 6 Jahren

Das sind völlig verschiedene Szenarien.

  • Szenario A: Verbindung zur Datenbank wird vom Client eröffnet, Benutzer hat direkten Zugriff auf die Verbindung - und hat potentiellen Zugriff auf die Credentials.
  • Szenario B: Verbindung zur Datenbank wird vom Server eröffnet, Benutzer hat keinen Zugriff auf die Verbindung - und auch nicht auf die potentiellen Credentials.

Einen vollständigen Schutz für alle Szenarien gibt es nicht.

D
985 Beiträge seit 2014
vor 6 Jahren

Wer Zugang zum Rechner hat (root Rechte) der kommt immer an alles dran, wo auch der Rechner selber dran kann, sonst käme auch der Rechner nicht dran.

Klingt logisch, ist aber anscheinend nicht immer offensichtlich.

So etwas lässt sich organisatorisch wesentlich sinnvoller und effektiver lösen als eine tolle Pseudoverschlüsselung.

T
50 Beiträge seit 2014
vor 6 Jahren

Abgesehen davon haben Reverse Engineers bisher immer "gewonnen".

Einen richtigen Schutz gibt es nicht wirklich.

Wir haben früher alles gecracked was auf dem Markt war, da gab es keine Hindernisse..
Heute bin ich genau auf den anderen Seite..aber auch da gewinnen die anderen..

S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 6 Jahren

Erstmal vielen Dank für alle Antworten.

Ich fasse mal zusammen:

  1. Code per obfuscation schützen bietet ein Plus an Sicherheit, aber mehr auch nicht.
  2. Zugangsdaten zu Datenbanken, etc. lassen sich am besten dadurch schützen, dass man den Rechner absichert, auf dem die Zugangsdaten liegen. Hier ist die Verwendung einer separaten Zugriffsschicht (REST Service o.ä.) auf einem eigenen Server und den Zugriff zur Datenbank bereitstellt, "sicherer" als wenn die Zugangsdaten direkt auf dem Client Rechner liegen.
D
985 Beiträge seit 2014
vor 6 Jahren

Die Zwischenschicht schützt nicht nur die Zugangsdaten, sondern auch den Zugriff insgesamt.

Die Datenbank lässt man exklusiv mit der Zwischenschicht kommunizieren, damit wirklich keiner dazwischenpfuschen kann.

Und schon ist nur noch das möglich, was die Zwischenschicht erlaubt.

Ein weiteres Schmankerl: Ich brauche mir keine Gedanken mehr über irgendwelche Datenbank-Treiber auf dem Client machen (ist der Treiber installiert, passt die Version, ...)

16.806 Beiträge seit 2008
vor 6 Jahren
  1. Code-Verschleierung macht es nur komplizierter an den Quellcode zu kommen; von Sicherheit kann man hier trotzdem nicht sprechen.
    Ein Entwickler, der weiß, was ILCode ist, weiß auch, wie man daraus C#/VB.NET Code bekommt. Laien können auch mit dem Quellcode direkt nichts anfangen.

  2. Es geht darum, dass kein physikalischer Zugriff auf eine Datenbank erfolgen kann. Weder lokal noch über das Netzwerk.
    Jeder Datenbankserver, der direkt erreichbar ist, ist eine potentielle Lücke.
    In Azure zB. ist jeder Datenbankserver von Haus aus nicht erreichbar; nicht mal für andere Azure Dienste. Das muss alles einzeln freigegeben werden. Bewusst.

Ein ordentliches Authentifizierungssystem geht nur über eine eigene Server-Anwendung.
Ein Datenbankserver ist dafür nicht gemacht und es ist auch nicht seine Aufgabe (nein, die Benutzerverwaltung im SQL Server ist nicht dafür da!).

O
461 Beiträge seit 2009
vor 4 Jahren
Leseschutz möglich ??

Hallo, sorry dass ich da auch nochmal nachfrage. Bei uns in der Firma ist es auch so, das wir entwickeln und bestimmte Berechnugsprogramme nach aussen geben.
Könnte es aber auch so funktioneren, dass der Code auf einem Speichermedium lin Form von USB iegt (als DLL), der Stick aber nicht kopiert werden kann ... ??
Oder kann der IL-Code dann aus dem Speicher ausgelesen werden?
Gäbe es so eine Möglichkeit in diese Richtung etwas zu machen, damit es jedenfalls nicht ganz so leicht ist?

T
708 Beiträge seit 2008
vor 4 Jahren

Hallo oehrle,

ein Schreibschutz wird Dich nicht davor schützen, dass das Programm ausgelesen wird.

Um das dekompilieren zu umgehen: Verwende eine Programmiersprache, die keinen IL Code generiert. C, C++, etc.

Zwar gibt es auch einige Tools für z.B. C++ Anwendungen, die Hürde ist aber um ein vielfaches höher!

PS: Ja, man kann USB-Sticks schreibschützen. Hilft an dieser Stelle aber nicht.

16.806 Beiträge seit 2008
vor 4 Jahren

Wie in meinem vorherigen Beitrag bereits geschrieben hast Du da keine allgemeine Chance.
Meinen Maschinenbaukunden, die oft auch Algorithmen haben, die Wettbewerbsvorteile darstellen, empfehle ich den Berechnungskern in zB C++ auszulagern und den dann von C# aufzurufen.

In .NET Native hast Du mittlerweile auch die Möglichkeit C# Code auf nativ zu kompilieren; aber vermutlich wird das aufgrund der Einschränkungen für Deinen Zweck nicht anwendbar sein.

O
461 Beiträge seit 2009
vor 4 Jahren

Hallo, aber C++ ist doch dann auch in .Net? Oder hat dass dann wieder mit der Umsetzung in IL zu tun, dass bei C++ so nicht gemacht wird?

T
2.219 Beiträge seit 2008
vor 4 Jahren

Du solltest dich dringend in C++ einlesen.
Reines C++ (Unmanged) hat nichts mit .NET zu tun.
Das wird nativ kompiliert, da hast du keine .NET Runtime sondern ein "echtes" Programm spezifisch für die Rechnerarchitektur und Betriebssystem!
Dies kann man dann, da es keinen IL Code sondern nur den fertigen Maschinenlesbaren Code für den spezifischen CPU Typen gibt, auch nicht einfach dekompilieren bzw. durch einen Zwischencode (IL Code) auslesen.

Anders sieht es bei Manged C++ aus, was dann auf .NET läuft.
Da hast du dann IL Code, den man eben durch ILSpy einfach auslesen kann.
Das sind aber Grundlagen der .NET Architektur.
Das solltest du dir dringend mal durchlesen!

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

O
461 Beiträge seit 2009
vor 4 Jahren

Danke für die Info.

16.806 Beiträge seit 2008
vor 4 Jahren

Dies kann man dann, da es keinen IL Code sondern nur den fertigen Maschinenlesbaren Code für den spezifischen CPU Typen gibt, auch nicht einfach dekompilieren bzw. durch einen Zwischencode (IL Code) auslesen.

Muss das kurz korrigieren, denn so formuliert stimmt das nicht.

Am Ende von unmanaged C++ kommt (meist) einfacher Binärcode raus.
Aber auch C++ kann man decompilen - einer der bekanntesten ist Hex Rays.
Anders als bei den meisten .NET Decompilern werden da aber Random Namen für Methoden und Variablen generiert, da die ursprünglichen Informationen beim Compile Prozess verloren gehen. Auch fehlt die gesamte Struktur.

Der Aufwand aus C++ etwas wieder nutzbares herzustellen ist immens größer als bei .NET; aber auch nicht unmöglich - wie bei allem mit Nullen und Einsen.
Das sind aber die Grundlagen der PC Architektur 😃