Clientseitiger Schutz oder serverseitige Geheimnisse: Wo Softwaresicherheit wirklich liegt

Jede Desktop-Anwendung läuft auf einem Rechner, den der Entwickler nicht kontrolliert. Die Person davor kann sie anhalten, den Arbeitsspeicher untersuchen und so oft erneut versuchen, wie sie will. Diese eine Tatsache prägt jedes ernsthafte Schutzkonzept. Deshalb ist die Wahl zwischen clientseitigem Schutz und serverseitigen Geheimnissen wichtiger als die Wahl eines einzelnen Tools.

Dieser Leitfaden erklärt, was clientseitiger Schutz tatsächlich leistet, wo er an seine Grenzen stößt und warum das Verlagern von Strings, Dateien, Variablen und Entscheidungen auf den Server die Kosten-Nutzen-Rechnung beim Cracken verändert. Am Ende steht eine praktische Aufteilung, die Sie diese Woche auf ein C++- oder C#-Produkt anwenden können.

Was ist clientseitiger Schutz?

Clientseitiger Schutz umfasst alles, was auf dem Rechner des Kunden läuft, um Ihre Anwendung schwerer analysierbar, schwerer veränderbar und in feindlicher Umgebung schwerer lauffähig zu machen. Er steckt im Binary, das Sie ausliefern, oder direkt daneben.

• –Obfuskation und Packing erschweren das Lesen von Code und Strings, wenn jemand die Datei öffnet.
• –Anti-Debug-Prüfungen erkennen, wenn ein Debugger an den Prozess angehängt ist.
• –Anti-VM-Prüfungen erkennen virtuelle Maschinen, die häufig genutzt werden, um Software isoliert zu analysieren.
• –Integritätsprüfungen vergleichen den Code im Speicher oder auf der Festplatte mit dem ausgelieferten Stand, sodass eine veränderte Version auffällt.
• –Prozess- und Fenster-Blacklists verweigern den Start, wenn bekannte Analysetools laufen.
• –Anti-Dumping und Speicherschutz erschweren es, ein sauberes Abbild des laufenden Programms zu kopieren.

Das sind echte Verteidigungsmaßnahmen, und sie lohnen sich. Zusammen stoppen sie Gelegenheitspiraterie, verlangsamen erfahrene Angreifer und scheitern an den meisten automatisierten Crack-Kits von der Stange. In qPapel Auth sind Anti-Dumping-Routinen, Speicherschutz und Anti-Tamper-Härtung eingebaut. Prüfungen wie Anti-VM, Integrität, CRC32 und Debugger-Sperren lassen sich über die Remote-Einstellungen aktivieren.

Was clientseitiger Schutz kann und was nicht

Am ehrlichsten betrachtet man clientseitigen Schutz als Kostenmultiplikator. Jede Technik erhöht den Zeit-, Know-how- und Frustrationsaufwand eines Angriffs. Keine davon ändert jedoch die grundlegende Tatsache: Der Code liegt auf dem Rechner des Angreifers, und Code, der läuft, kann irgendwann untersucht werden.

Produkte, die nur auf dem Client geschützt sind, verlaufen meist gleich. Der Schutz hält eine Weile, irgendwann taucht eine manipulierte Version auf, und diese läuft dann unbegrenzt weiter, weil ihr nichts fehlt, was sie braucht. Die Verteidigung hat das Ergebnis verzögert, aber nicht verändert.

Dazu kommt ein Ungleichgewicht beim Aufwand. Der Verteidiger muss jede Prüfung in jeder Version richtig umsetzen. Wer die Software analysiert, muss nur eine Lücke finden, kann offline in eigenem Tempo arbeiten und einen Versuch beliebig oft wiederholen, ohne dass es jemand bemerkt. Clientseitiger Schutz schließt Lücken, ändert aber nichts daran, wer die Maschine kontrolliert.

Warum serverseitige Geheimnisse die Rechnung beim Cracken verändern

Angreifer wägen Aufwand gegen Ertrag ab. Clientseitiger Schutz wirkt auf der Aufwandsseite dieser Gleichung. Serverseitige Geheimnisse wirken auf der Ertragsseite. Wenn ein wesentlicher Teil Ihrer Anwendung nie im Binary ausgeliefert wird, ist eine veränderte Kopie kein funktionierendes Produkt mehr. Sie ist eine Hülle, die trotzdem eine gültige, authentifizierte Sitzung braucht, um nützlich zu werden.

Deshalb ist auch das Teilen einer geknackten Version weniger attraktiv. Jede Kopie muss weiterhin mit Ihrem Server sprechen, jede Sitzung kann abgelehnt und jeder beteiligte Schlüssel und jedes Gerät zentral gesperrt werden. Der Aufwand des Angreifers lässt sich nicht so vervielfachen wie dann, wenn alles in der Datei liegt.

• –Die Arbeit lässt sich nicht übertragen. Das Entfernen einer lokalen Prüfung ergibt kein funktionierendes Produkt mehr, weil die fehlenden Daten weiterhin vom Server kommen müssen.
• –Jede Kopie ist sichtbar. Jede Sitzung meldet sich an, sodass ungewöhnliche Nutzung eines Schlüssels im Dashboard auftaucht, statt unbemerkt zu passieren.
• –Sie reagieren ohne neuen Release. Eine Sperre oder die Änderung eines Serverwerts greift bei der nächsten Prüfung, für alle Kopien gleichzeitig.

Was auf den Server gehört: Strings, Dateien, Variablen und Entscheidungen

Nicht alles lässt sich verlagern, und nicht alles sollte es. Der Test ist einfach: Würde eine veränderte Version nützlicher, wenn ein Wert oder eine Datei durchsickert? Wenn ja, ist es ein Kandidat für den Server.

qPapel Auth deckt alle vier ab. SS Strings halten sensible Werte auf den Servern von PapelShip und liefern sie nur an authentifizierte Sitzungen aus. SS Files stellen Dateien authentifizierten Clients bereit, statt sie mit Ihrer Anwendung zu bündeln. Mit Remote Settings ändern Sie Einstellungen und Variablen Ihrer App ohne neuen Build. Und die Lizenzentscheidung selbst, einschließlich der HWID-Bindung, fällt auf dem Server und nicht durch Logik in Ihrem Binary.

Wie ein serverseitiges Geheimnis Ihre Anwendung erreicht

Serverseitige Daten sind nur so stark wie der Weg, auf dem sie reisen. Wenn der Kanal gelesen, wiederholt oder gefälscht werden kann, liegt das Geheimnis nur an einem anderen Ort. Ein vertrauenswürdiger Auslieferungsweg hat einige nicht verhandelbare Eigenschaften.

• –Jedes Mal eine neue Sitzung. Jede Sitzung beginnt mit einem Schlüsselaustausch, daher ist mitgeschnittener Verkehr einer alten Sitzung später nutzlos. qPapel Auth rotiert für jede aktive Sitzung die AES-256-Kommunikationsschlüssel.
• –Verschlüsselte und signierte Nachrichten. Ein Beobachter kann den Inhalt nicht lesen, und eine gefälschte Antwort wird nicht als echt akzeptiert.
• –Prüfungen vor der Freigabe. Der Server bestätigt Schlüssel, Gerät und Build, bevor er etwas freigibt. qPapel Auth ist so konzipiert, dass manipulierte lokale Dateien keine Serverdaten lesen können.
• –Kurze Lebensdauer im Arbeitsspeicher. Geschützte Strings lassen sich ohne Spuren auf der Festplatte direkt in den Arbeitsspeicher streamen. Halten Sie sie nur so lange dort, wie Sie sie brauchen.

Bei größeren Assets gilt dieselbe Idee auch für den Code selbst. Laden im Arbeitsspeicher streamt verschlüsselte DLLs in den Arbeitsspeicher, ohne sie auf die Festplatte zu schreiben. So liegt der Premium-Teil Ihres Produkts nie als Datei auf dem Laufwerk des Kunden.

Die Nachteile serverseitigen Schutzes

Serverseitige Geheimnisse sind nicht kostenlos. Wenn Sie die Kosten klar benennen, können Sie sie einplanen, statt sie erst im Betrieb zu entdecken.

• –Konnektivität. Hängt eine Funktion von Serverdaten ab, braucht sie eine Verbindung. Legen Sie bewusst fest, welche Funktionen offline laufen können und wie lange.
• –Entwurfsaufwand. Jemand muss entscheiden, was wertvoll ist, und den Code so umbauen, dass er diesen Wert anfordert, statt ihn zu enthalten.
• –Speicherexposition. Ein gelieferter Wert liegt während der Nutzung im Prozessspeicher. Laufzeitüberwachung und kurze Lebensdauern verkleinern dieses Zeitfenster.
• –Betriebliche Sorgfalt. Ein serverseitiges Asset ist eine laufende Abhängigkeit. Behandeln Sie Änderungen daran wie einen Release: erst testen, dann ausrollen.

Das sind lösbare Probleme, und sie sind der Preis für einen Schutz, der tatsächlich hält. Die Alternative ist ein Produkt, dessen wertvollste Teile in einer Datei auf der Festplatte jedes Kunden liegen.

Eine brauchbare Faustregel zur Konnektivität: Der Kern Ihres Produkts verträgt kurze Unterbrechungen, die Teile, die es wertvoll machen, sollten dagegen bei jeder Nutzung beim Server nachfragen. So bleibt das Kundenerlebnis reibungslos, und eine Kopie, die sich nie meldet, bekommt nie die Teile, auf die es ankommt.

Eine praktische Aufteilung: Was auf welche Seite gehört

Die meisten Produkte landen bei einer ähnlichen Arbeitsteilung. Der Client übernimmt, was dort geschehen muss, wo die Bedrohung ist. Der Server hält alles, was sich zu stehlen lohnt, und trifft jede Entscheidung, auf die es ankommt.

1. 01

   Lizenzentscheidung verlagern

   Prüfen Sie Schlüssel, Ablauf, Sperren und die Gerätebindung auf dem Server. Lassen Sie das Binary niemals allein entscheiden.

2. 02

   Ihre wichtigsten Geheimnisse verlagern

   Legen Sie API-Schlüssel, Endpunkte und Konstanten in serverseitige Strings. Die Schritt-für-Schritt-Anleitung für .NET finden Sie unter C#-Lizenzierung ohne fest hinterlegte Geheimnisse.

3. 03

   Premium-Teile verlagern

   Stellen Sie Module und Datenpakete als serverseitige Dateien bereit oder laden Sie sie im Arbeitsspeicher, damit eine veränderte Version unvollständig bleibt.

4. 04

   Den Rest härten

   Aktivieren Sie Anti-Debug, Anti-VM, Integritätsprüfungen und Blacklists, um die Analyse des lokal verbleibenden Codes zu verlangsamen.

5. 05

   Zur Laufzeit überwachen

   Ergänzen Sie eine Erkennung für unbekannte Tools, denn statische Blacklists erfassen nur bekannte Tools.

Das vollständige Bild mit allen Schichten in der richtigen Reihenfolge finden Sie in unserem Leitfaden zu einem Software-Schutz-Stack für C++ und C#. Da die Remote-Einstellungen ohne Neuaufbau funktionieren, können Sie den Schutz außerdem aus der Ferne aktualisieren, sobald Sie wissen, was Ihr Produkt braucht.

Schützen Sie, was zählt, wo es sich schützen lässt

Clientseitiger Schutz macht Angriffe teuer. Serverseitige Geheimnisse machen sie unlohnend. Nutzen Sie den ersten, um jeden zu bremsen, der Ihr Binary studiert, und den zweiten, damit selbst eine erfolgreiche Manipulation nur ein unvollständiges Produkt hinterlässt.

Fangen Sie klein an: Verlagern Sie diese Woche die Lizenzentscheidung und Ihre drei wertvollsten Werte, und ergänzen Sie den Rest Schritt für Schritt. Jeder Schritt nimmt etwas, das ein Angreifer will, von seinem Rechner und stellt es wieder unter Ihre Kontrolle.