Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Code vor unerlaubten Zugriff schützen
sugar76
myCSharp.de - Member



Dabei seit:
Beiträge: 69
Herkunft: Berlin

Themenstarter:

Code vor unerlaubten Zugriff schützen

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
sugar76
myCSharp.de - Member



Dabei seit:
Beiträge: 69
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Zitat von Abt
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.
Zitat von Abt
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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 996

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Torni
myCSharp.de - Member



Dabei seit:
Beiträge: 45

beantworten | zitieren | melden

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..
private Nachricht | Beiträge des Benutzers
sugar76
myCSharp.de - Member



Dabei seit:
Beiträge: 69
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 996

beantworten | zitieren | melden

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, ...)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Deaktiviertes Profil am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

beantworten | zitieren | melden

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!).
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 404
Herkunft: Germany

Leseschutz möglich ??

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
trib
myCSharp.de - Member



Dabei seit:
Beiträge: 693

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 404
Herkunft: Germany

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1918
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von T-Virus am .
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.
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 404
Herkunft: Germany

beantworten | zitieren | melden

Danke für die Info.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

beantworten | zitieren | melden

Zitat von T-Virus
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 :-)
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers