Ein Software-Schutz-Stack für C++- und C#-Produkte, Ebene für Ebene

Fragen Sie zehn Entwickler, wie sie ihre Software schützen, und Sie hören oft zehn Einzelantworten: einen Obfuskator, einen Packer, eine Lizenz-API, eine Anti-Debugging-Bibliothek. Jede hilft gegen eine Art von Angriff. Allein reicht keine davon, denn jede deckt nur einen Teil ab, wie Produkte tatsächlich angegriffen werden.

Die Alternative ist ein Software-Schutz-Stack: mehrere Ebenen, die jeweils eine andere Frage beantworten und so angeordnet sind, dass eine Ebene abdeckt, was die anderen nicht können. Dieser Leitfaden geht die sechs Ebenen durch, die wir für C++- und C#-Produkte empfehlen, zeigt, was jede einzelne abwehrt, wie sich die Gewichtung bei nativem und verwaltetem Code verschiebt und in welcher Reihenfolge Sie die Ebenen einführen sollten.

Warum ein einzelnes Schutzwerkzeug nie reicht

Jede Schutztechnik hat einen blinden Fleck. Ein Obfuskator macht Code schwerer lesbar, hilft aber nichts gegen einen geteilten Schlüssel. Eine Lizenzprüfung verhindert Weitergabe, kann aber gezielt angegriffen werden, wenn sie nur auf dem Client läuft. Eine Sperrliste stoppt bekannte Tools und übersieht alles andere. Angreifer müssen nicht alle diese Maßnahmen überwinden. Sie müssen nur die eine Lücke finden, die Sie offen gelassen haben.

Schichten funktionieren, weil die Lücken nicht übereinanderliegen. Wer eine Ebene überwindet, landet nur bei der nächsten. Und die wichtigsten Ebenen, nämlich die auf dem Server, liegen gar nicht auf dem Rechner des Angreifers.

Ein guter Stack gibt außerdem jeder Ebene eine einzige, klare Aufgabe. Beantwortet jede Ebene genau eine Frage, sieht man leicht, welche Frage für Ihr Produkt noch offen ist, und kann einem Kunden leicht erklären, warum eine bestimmte Prüfung existiert.

Die sechs Ebenen eines Software-Schutz-Stacks

1. Lizenzierung und HWID-Bindung

Die Frage: Wer darf diese Software ausführen, und auf welchem Rechner? Lizenzschlüssel werden pro Bestellung ausgestellt, auf dem Server geprüft und bei der ersten Aktivierung an eine Hardware-ID gebunden. Schlüssel lassen sich erzeugen, pausieren, sperren und in Echtzeit prüfen. Auf der Seite Computers sehen Sie, welche Geräte welche Schlüssel nutzen. Diese Ebene verhindert die beiläufige Weitergabe von Schlüsseln und gibt Ihnen einen Hebel, um Missbrauch ohne neues Release zu unterbinden. Was ist HWID-Locking? erklärt die Mechanik.

Was sie nicht abdeckt: einen lizenzierten Kunden, der seine eigene Kopie untersucht oder verändert. Ein gültiger Schlüssel auf dem richtigen Rechner besteht diese Ebene, deshalb gibt es die folgenden Ebenen.

2. Integritätsprüfungen

Die Frage: Ist das der Build, den Sie ausgeliefert haben? In qPapel Auth prüft auth.CheckMemoryIntegrity(), ob der Speicher des Programms zur Laufzeit verändert wurde, etwa durch Patchen von Instruktionen. auth.CheckTextIntegrity() ergänzt CRC-, sitzungsbasierte und Patch-Prüfungen. Eine CRC32-Prüfung lässt sich in den Remote-Einstellungen aktivieren. Build Control verhindert, dass Ihre Datei von nicht autorisierten Tools verändert, gepatcht oder geöffnet wird.

Was sie nicht abdeckt: Untersuchung, die nichts verändert. Jemand kann ein Programm beobachten, ohne es zu verändern. Integritätsprüfungen werden deshalb mit Anti-Debugging und Laufzeiterkennung kombiniert.

3. Anti-Debugging und Anti-VM

Die Frage: Untersucht gerade jemand das Programm, während es läuft? qPapel Auth erkennt einen angehängten Debugger und kann die betreffende Lizenz sperren. Die Anti-VM-Erkennung bemerkt virtuelle Maschinen, die häufig für Analysen genutzt werden. Anti-Dumping-Routinen, Speicherschutz und Anti-Tamper-Härtung sind unabhängig von Ihren Einstellungen eingebaut.

Was sie nicht abdeckt: Werkzeuge, die von außerhalb des Prozesses beobachten. Dafür sind Sperrlisten und qPAnalyzer zuständig.

4. Prozess- und Fenstersperrlisten

Die Frage: Läuft ein bekanntes Analysewerkzeug? Über die Remote-Einstellungen blockieren Sie Fenstertitel, Klassennamen, aktive Prozesse und Debugging-Werkzeuge, ohne einen neuen Build zu kompilieren. Regeln lassen sich gezielt nach App-Version, Land oder Nutzergruppe ausrichten. Sperrlisten sind schnell und günstig, erfassen aber nur Tools, die bereits bekannt sind.

Was sie nicht abdeckt: umbenannte, private und neu erschienene Tools. Eine Liste kann nur benennen, was jemand bereits hinzugefügt hat.

5. Serverseitige Daten

Die Frage: Was bekommt ein verändertes Build tatsächlich? 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 mitzuliefern, und verschlüsselte DLLs lassen sich in den Speicher streamen, ohne auf die Festplatte geschrieben zu werden. Ein Build, das so verändert wurde, dass es die früheren Ebenen überspringt, bekommt davon nichts und bleibt daher unvollständig. Genau diese Ebene verschiebt die Rechnung für Angreifer, wie Clientseitiger Schutz im Vergleich mit serverseitigen Geheimnissen erklärt.

Was sie nicht abdeckt: einen Wert, nachdem er an eine gültige Sitzung ausgeliefert wurde. Halten Sie die Lebensdauer im Speicher kurz und lassen Sie die Laufzeit-Ebenen die Sitzung überwachen, solange sie besteht.

6. qPAnalyzer-Erkennung zur Laufzeit

Die Frage: Läuft ein unbekanntes Tool? qPAnalyzer ist eine KI-gestützte Erkennung von Bedrohungen zur Laufzeit. Sie prüft Muster im UI-Layout, Fenster-Handles und Speichersignaturen, analysiert einen Screenshot des markierten Fensters und vergibt einen Bedrohungswert von 0 bis 100 %. Eine Whitelist je Produkt und die Aktion „Keine Bedrohung“ halten Fehlalarme gering. Lesen Sie, wie qPAnalyzer umbenannte und eigene Tools erkennt.

Was sie nicht abdeckt: die Entscheidung, was danach geschieht. qPAnalyzer liefert Belege und eine Bewertung. Ihre Schwellenwerte in der Risiko-Engine und die Sperre auf dem Server entscheiden über das Ergebnis.

Wie die Ebenen beim Start Ihrer App zusammenarbeiten

Die Ebenen sind keine getrennten Produkte, die nachträglich zusammengeschraubt wurden. Bei einem einzigen Start übergeben sie einander die Kontrolle, und der Server steht im Zentrum jeder Entscheidung.

Beachten Sie, was das für eine veränderte Kopie bedeutet. Überspringt sie die lokalen Prüfungen, muss sie trotzdem die Lizenz- und Geräteprüfungen des Servers bestehen, bevor sie irgendetwas erhält. Besteht sie diese mit einem gültigen Schlüssel, erreichen ihre Laufzeitbefunde weiterhin den Server. Eine Sperre stoppt den Schlüssel dann überall bei der nächsten Prüfung.

Was jede Ebene abwehrt

Wenn Sie gängige Bedrohungen der Ebene zuordnen, die sie abwehrt, wird die Überschneidung deutlich. Die meisten Bedrohungen werden von mehr als einer Ebene abgedeckt, und genau darauf kommt es an.

C++ und C#: derselbe Stack, andere Schwerpunkte

Die sechs Ebenen gelten für nativen und verwalteten Code gleichermaßen. Was sich ändert, ist der Punkt, an dem der Druck liegt.

• –C# wird in eine Zwischensprache kompiliert, die sich verhältnismäßig leicht wieder in lesbaren Code zurückübersetzen lässt. Das gewichtet serverseitige Daten stärker: Legen Sie keine Geheimnisse in die Assembly, halten Sie sensible Werte in SS Strings und behandeln Sie alles, was im Binary bleibt, als lesbar. Der Leitfaden zur C#-Lizenzierung ohne fest einprogrammierte Geheimnisse geht ins Detail.
• –C++ ist schwerer zu lesen, doch ein kompiliertes Binary lässt sich trotzdem auf Befehlsebene verändern. Integritätsprüfungen und serverseitige Entscheidungen sorgen dafür, dass ein einzelner geänderter Sprung das Produkt nicht preisgibt. Siehe C++-Authentifizierung und Lizenzierung.

qPapel Auth stellt native SDKs für beide Sprachen bereit. Die EasyAuth-Bibliothek hat mit Version 7.0 C#-Unterstützung erhalten, und die Default Library bleibt für bestehende C++-Projekte verfügbar.

In welcher Reihenfolge sollten Sie die Ebenen einführen?

Sie brauchen nicht am ersten Tag alle Ebenen. Führen Sie sie in der Reihenfolge ein, die den meisten Schutz für den geringsten Aufwand bringt.

1. 01

   Lizenzierung und HWID

   Sofortiger Umsatzschutz. Jeder Verkauf wird zu einem Schlüssel, der an ein Gerät gebunden und auf dem Server geprüft wird.

2. 02

   Serverseitige Daten

   Der größte Ertrag für den Aufwand. Verlagern Sie zuerst Ihre drei wertvollsten Strings oder Dateien auf den Server.

3. 03

   Integritätsprüfungen

   Rufen Sie die Integritätsfunktionen an den Stellen auf, die zählen, nicht nur beim Start, und aktivieren Sie die CRC32-Prüfung.

4. 04

   Anti-Debugging, Anti-VM und Sperrlisten

   Aktivieren Sie sie in den Remote-Einstellungen. Das dauert nur Minuten und filtert Versuche mit geringem Aufwand heraus.

5. 05

   qPAnalyzer

   Schalten Sie es ein, sobald die Basis steht, starten Sie im Beobachtungsmodus, passen Sie die Whitelist an und aktivieren Sie dann die Aktionen.

Den Stack nach dem Release betreiben

Ein Schutz-Stack ist nichts, was man installiert und dann vergisst. Einige feste Routinen halten ihn wirksam.

• –Prüfen Sie die Befunde wöchentlich. Sehen Sie sich die Seite Computers und den Threat Vault an, setzen Sie legitime Tools auf die Whitelist und markieren Sie Fehlalarme als „Keine Bedrohung“.
• –Achten Sie auf Muster bei Resets und Sperren. Häufige HWID-Resets bei einem einzelnen Schlüssel deuten meist auf Weitergabe hin.
• –Ändern Sie Werte aus der Ferne. Rotieren Sie serverseitige Strings und passen Sie die Remote-Einstellungen an, sobald Sie eine Offenlegung vermuten, und zwar ohne neuen Build.
• –Legen Sie Schwellenwerte fest. Die Schwellen für Warnung, Einschränkung, Beenden und Sperre in der Risiko-Engine sollten zum Wert jedes Produkts passen.
• –Halten Sie Verkauf und Lizenzierung verbunden. Wenn Shop und qPapel Auth ein Dashboard teilen, bleiben Erstattungen, Sperren und Resets synchron.
• –Geben Sie dem Team nur die Rechte, die es braucht. Team-Panels erlauben dem Support, Resets und Schlüsselfragen zu bearbeiten, ohne das Inhaberkonto zu nutzen.

Wenn etwas schiefgeht, etwa wenn ein Build dort auftaucht, wo es nicht sein sollte, tragen dieselben Werkzeuge die Reaktion. Durchgesickerte Builds mit Binary Trace erkennen beschreibt einen Plan Schritt für Schritt.

Die Produktseite von qPapel Auth zeigt, wie Lizenzierung, Remote-Einstellungen und serverseitige Daten in einem Dashboard zusammenspielen.

Schützen Sie Ihr Produkt in Ebenen

Einzelne Schutzwerkzeuge scheitern auf vorhersehbare Weise. Ein Stack, in dem jede Ebene ihre eigene Frage beantwortet und in dem die wichtigsten Entscheidungen und Daten auf dem Server bleiben, hält auch dann stand, wenn sich Angreifer anpassen.

Beginnen Sie diese Woche mit der Lizenzierung und Ihren wertvollsten serverseitigen Daten und ergänzen Sie dann die übrigen Ebenen nacheinander. Jede schließt eine Lücke, die die anderen offen lassen.