Die bekannten Tools zu blockieren ist der einfache Teil beim Schutz von Desktop-Software. Ihre Prozessnamen und Fenstertitel sind bekannt, und fast jede Blacklist führt sie längst. Schwierig ist alles andere: ein bekanntes Tool unter neuem Namen, ein privates Werkzeug, das jemand gezielt für ein einziges Produkt gebaut hat, ein Tool, das letzte Woche erschienen ist. Eine Erkennung von Reverse-Engineering-Tools, die nur auf Namen schaut, übersieht sie alle.
Dieser Artikel zeigt, warum der Abgleich von Namen an Grenzen stößt und wie qPAnalyzer umbenannte und selbst entwickelte Tools daran erkennt, was sie sind, nicht wie sie heißen. Außerdem geht es darum, wie Sie Fehlalarme von zahlenden Kunden fernhalten und aus den Ergebnissen angemessene Maßnahmen ableiten.
Warum namensbasierte Erkennung umbenannte Tools übersieht
Eine statische Blacklist vergleicht, was gerade läuft, mit einer Liste: Prozessnamen, Fenstertitel, Fensterklassennamen. Bei öffentlichen, unveränderten Tools funktioniert das gut. Strukturell hat das Verfahren aber drei blinde Flecken.
- Umbenannte Tools. Eine Liste, die auf Namen basiert, kennt nur Namen. Ändert sich der Name, gibt es keinen Treffer mehr.
- Private Tools. Werkzeuge, die für ein einziges Ziel geschrieben wurden, tauchen auf keiner öffentlichen Liste auf.
- Neue Tools. Neue Releases und Forks erscheinen schneller, als sich eine Liste pflegen lässt.
Der umgekehrte Fehler wiegt genauso schwer. Wer jeden unbekannten Prozess als feindlich behandelt, beendet Ihre Anwendung bei Kunden, die zufällig ganz normale Software daneben laufen lassen. Gute Erkennung muss bei Analyse-Tools streng sein und bei allem anderen gelassen. Dafür braucht es Urteilsvermögen, nicht bloß eine längere Liste.
Eine längere Liste löst das Problem ohnehin nicht. Jeder Eintrag muss gefunden, geprüft und gepflegt werden, und breite Muster, die Varianten erfassen sollen, treffen bald auch legitime Software. Irgendwann muss die Frage nicht mehr lauten „Wie heißt das?“, sondern „Was ist das, und was tut es?“
Was ist qPAnalyzer?
qPAnalyzer ist die KI-gestützte Bedrohungserkennung von PapelShip für die Laufzeit. Sie läuft auf dem Rechner des Endnutzers direkt neben Ihrer Anwendung und erkennt Reverse-Engineering-Tools und verdächtige Aktivitäten, bevor diese Ihre Software erreichen. qPAnalyzer kam mit qPapel Auth v5.5 als eigene Analyseschicht innerhalb des bestehenden Schutzablaufs hinzu und wird wie die übrigen Schutzfunktionen in den Remote-Einstellungen aktiviert.
Das Prinzip ist einfach: auf dem Client erkennen, auf dem Server entscheiden, alles an einem Ort prüfen. qPAnalyzer analysiert dort, wo die Bedrohung entsteht. Ihre Entscheidungen über Lizenzen und Sperren bleiben auf den Servern von PapelShip. Die Ergebnisse erscheinen im selben Dashboard, in dem Sie auch Schlüssel und Verkäufe verwalten.
- Seite „Computer“: jeder Rechner mit seinen Scan-Ergebnissen, verdächtigen Aktivitäten und dem Bereich „Kürzlich gesperrt“.
- Threat Vault: alle Funde, filterbar nach Produkt, mit einer Ein-Klick-Aktion für Fehlalarme.
- Verdächtige Screenshots: eine eigene Seite für die Screenshots, die bei auffälligen Aktivitäten aufgenommen wurden.
- Sicherheits-Insights und Warnmeldungen: Erkennungen erscheinen in Echtzeit neben Ihren Lizenzen und Verkäufen.
Wie qPAnalyzer ein unbekanntes Tool erkennt
Statt einem Namen zu vertrauen, achtet qPAnalyzer auf Merkmale, die sich kosmetisch viel schwerer ändern lassen. Geprüft werden UI-Layoutmuster, Fenster-Handles und Speichersignaturen. So lässt sich ein Tool erkennen, ganz gleich, wie seine ausführbare Datei heißt.
- 01
Umgebungsprüfungen
Debugger- und Hypervisor-Signale
- 02
Prozess und Fenster
Layout, Handles, Signaturen
- 03
Screenshot-Analyse
Das markierte Fenster wird geprüft
- 04
Bedrohungs-Score
Kalibrierter Score von 0 bis 100 %
- 05
Aktion
Protokolliert, dann greift Ihre Regel
Umgebungsprüfungen
Während Ihre Software läuft, führt qPAnalyzer auf dem Rechner des Endnutzers Anti-Debug- und Anti-Tamper-Prüfungen durch. Dazu gehören Hypervisor-Signale, Hardware-Breakpoints, Debug-Flags des Prozesses und ein aktiver Kernel-Debugger. Jede Prüfung wird bestanden oder nicht, und jeder Fehlschlag fließt in den Score ein.
Screenshot-Analyse von Fenstern
Wirkt ein Fenster verdächtig, nimmt qPAnalyzer einen Screenshot davon auf, und die Analyse-Engine prüft die Benutzeroberfläche. Analyse-Tools sehen nun einmal aus wie Analyse-Tools, mit Speicheransichten, Disassembly-Bereichen und Registerlisten, egal wie ihr Prozess heißt. Die Screenshot-Analyse von Fenstern ist in jedem qPAnalyzer-Scan enthalten.
Ein kalibrierter Bedrohungs-Score
Die Engine vergibt einen Bedrohungs-Score von 0 bis 100 % und protokolliert die Belege in Ihrem Dashboard. Ein Score ist nützlicher als ein reines Ja oder Nein, weil Sie ein schwaches Signal anders behandeln können als ein starkes.
Erst die Kombination von Signalen macht den Score vertrauenswürdig. Jedes einzelne Indiz kann eine harmlose Erklärung haben: Ein Entwickler hat vielleicht für die eigene Arbeit einen Debugger installiert, oder ein Fenster ähnelt kurz etwas, das es gar nicht ist. Mehrere unabhängige Signale, die gleichzeitig und direkt neben Ihrer Anwendung in dieselbe Richtung weisen, lassen sich dagegen kaum wegerklären.
Fehlalarme gering halten: Whitelists und „Keine Bedrohung“
Ein Erkennungssystem, das die ganz normale Software Ihrer Kunden markiert, ist schlimmer als gar keines. Sie gewöhnen sich daran, es zu ignorieren, und Ihre Kunden gewöhnen sich daran, abzuwandern. qPAnalyzer gibt Ihnen drei Werkzeuge an die Hand, mit denen die Ergebnisse sauber bleiben.
| Werkzeug | Was es tut | Wann Sie es einsetzen |
|---|---|---|
| Produkt-Whitelist | Markiert Tools für ein Produkt als sicher, mit eigenen Anweisungen | Software, die Ihre Kunden legitim nutzen |
| Threat Vault | Listet Funde auf, filterbar nach Produkt | Ihre regelmäßige Durchsicht der markierten Funde |
| Keine Bedrohung | Entfernt einen Fehlalarm mit einem Klick | Ein Fund, der sich als harmlos herausstellt |
Die eigenen Anweisungen in der Whitelist sind wichtiger, als es scheint. Ein Tool für Streamer, ein Hardware-Dienstprogramm oder eine spezielle Branchensoftware kann für die Zielgruppe des einen Produkts völlig normal und für die eines anderen ungewöhnlich sein. Wenn Sie qPAnalyzer Ihre Zielgruppe beschreiben, bleibt die Erkennung dort streng, wo sie streng sein soll.
Von der Erkennung zur Aktion: Scores, Verzögerungen und Belege
Erkennung ist nur die halbe Arbeit. Was Sie mit einem Fund anfangen, entscheidet darüber, ob das System Ihren Umsatz schützt oder nur Rauschen erzeugt. Die Risiko-Engine von PapelShip fasst alle Signale zu einem Score zusammen, mit Schwellenwerten für Warnen, Einschränken, Schließen und Sperren, die Sie selbst festlegen.
- 01
Schwellenwerte pro Produkt festlegen
Bestimmen Sie, ab welchem Score gewarnt wird, ab wann Funktionen eingeschränkt werden, ab wann sich die Anwendung schließt und ab wann der Schlüssel gesperrt wird. Ein günstiges Tool und ein hochpreisiges Produkt können ganz unterschiedliche Richtlinien haben.
- 02
Verzögerte Aktionen nutzen
Im Modus für verzögerte Aktionen greifen Sanktionen erst nach einer zufälligen Verzögerung. Wer Ihren Schutz austestet, kann so kaum nachvollziehen, welcher Schritt die Reaktion ausgelöst hat.
- 03
Belege sichern
Suspicious Screenshot hält fest, was auf dem Bildschirm zu sehen war, als verdächtige Aktivität erkannt wurde. Die Screenshots sehen Sie auf einer eigenen Seite im Dashboard.
- 04
Beim Gerät ansetzen, nicht nur beim Schlüssel
Die Seite „Computer“ zeigt jeden Rechner, seine Scan-Ergebnisse und den Bereich „Kürzlich gesperrt“ mit genauen Sperrzeitpunkten. Wiederholungstäter fallen so schnell auf.
- 05
Routine automatisieren
Mit Auto Rules legen Sie eine Aktion einmal fest, danach läuft sie von selbst. Eindeutige Fälle müssen so nicht auf einen Menschen warten.
| Was Sie sehen | Eine sinnvolle Reaktion |
|---|---|
| Ein schwaches, einmaliges Signal | Protokollieren und später prüfen |
| Ein mittlerer Score | Warnen, protokollieren und Belege sichern |
| Ein hoher Score | Die Sitzung beenden |
| Hohe Scores für denselben Schlüssel oder dasselbe Gerät | Schlüssel und Gerät sperren |
Wie streng Sie sein sollten, hängt davon ab, was Sie verkaufen. Ein günstiges Tool mit breiter Zielgruppe kann mehr protokollieren und seltener eingreifen. Ein hochpreisiges Produkt, oder eines, bei dem Cheating anderen Kunden schadet, rechtfertigt strengere Schwellenwerte. So oder so liegt die Entscheidung bei Ihnen und lässt sich jederzeit im Dashboard ändern.
Weil Sperren auf dem Server entschieden werden, gelten sie bei der nächsten Prüfung überall. Sie müssen keinen Build ausliefern und auf kein Update warten. Dasselbe Prinzip steckt dahinter, serverseitige Geheimnisse aus dem Binary herauszuhalten: Der Client meldet, der Server entscheidet.
Wo qPAnalyzer neben Blacklists und Serverprüfungen steht
qPAnalyzer ersetzt Ihren übrigen Schutz nicht, sondern schließt die Lücke, die die anderen Schichten offen lassen. Prozess- und Fenster-Blacklists stoppen bekannte Tools weiterhin fast ohne Aufwand. qPapel Auth entscheidet weiterhin, wer Ihre Software auf welchem Gerät ausführen darf. qPAnalyzer achtet auf das, was keine der beiden Schichten sieht.
Statische Blacklist
- Gleicht Namen, Titel und Klassen ab
- Sofort und sehr günstig
- Übersieht umbenannte und private Tools
- Braucht eine Liste, die jemand pflegt
qPAnalyzer
- Prüft Layout, Handles, Signaturen
- Analysiert einen Screenshot des Fensters
- Bewertet Funde von 0 bis 100 %
- Pro Produkt per Whitelist abgestimmt
Am wirksamsten ist qPAnalyzer, wenn im Binary wenig zu holen ist. Bleiben Ihre wertvollen Strings und Dateien auf dem Server und werden nur an verifizierte Sitzungen ausgegeben, erhält eine markierte Sitzung sie einfach nicht mehr. Die Erkennung hat dann eine direkte, serverseitig durchgesetzte Folge, statt von einer Prüfung im Client abzuhängen.
Die grundsätzliche Argumentation finden Sie in Warum Anti-Reverse-Engineering über statische Blacklists hinausgehen muss. Alle Schichten in der richtigen Reihenfolge zeigt Ein Software-Schutz-Stack für C++ und C#.
qPAnalyzer in Ihrem Produkt einführen
- 01
Bibliothek aktualisieren
qPAnalyzer setzt qPapel Auth v5.5 oder neuer voraus. Verwenden Sie die aktuellen Lib- und Include-Dateien aus dem offiziellen Example-Projekt und die neueste
qPapelAuth64.dllvon der Downloads-Seite. - 02
In den Remote-Einstellungen aktivieren
Schalten Sie qPAnalyzer für das Produkt ein. Um die Einstellung später zu ändern, brauchen Sie keinen neuen Build.
- 03
Im Beobachtungsmodus starten
Protokollieren Sie Funde, ohne Sitzungen zu schließen oder Schlüssel zu sperren. Behalten Sie die Seite „Computer“ und den Threat Vault einige Tage lang im Blick.
- 04
Whitelist abstimmen
Nehmen Sie die legitimen Tools Ihrer Zielgruppe auf und beschreiben Sie sie in eigenen Anweisungen.
- 05
Aktionen einschalten
Legen Sie Ihre Schwellenwerte für Warnen, Einschränken, Schließen und Sperren fest, aktivieren Sie verzögerte Aktionen und prüfen Sie markierte Rechner regelmäßig.
qPAnalyzer ist in PapelShip+ für 14,99 € im Monat enthalten, zusammen mit 0 % Gebühren auf Krypto- und Kartenzahlungen. Die Produktseite von qPAnalyzer zeigt die Dashboard-Ansichten, und auf der Seite Preise vergleichen Sie die Tarife.
Häufig gestellte Fragen
Sehen, was eine statische Liste nicht sieht
Bekannte Tools zu blockieren ist die Grundlage. Am wichtigsten sind aber die Tools, die sich nicht zu erkennen geben: umbenannte, private oder schlicht neue. qPAnalyzer betrachtet, was diese Tools sind und wie sie sich verhalten, bewertet seine Funde und überlässt die endgültige Entscheidung Ihnen.
Aktivieren Sie qPAnalyzer im Beobachtungsmodus, stimmen Sie es auf Ihre Zielgruppe ab und lassen Sie dann den Score angemessene Maßnahmen steuern. So gewinnen Sie Einblicke, die Sie vorher nicht hatten, ohne Ihre zahlenden Kunden unter Generalverdacht zu stellen.
qPapel-Security-Team
Lizenzierung und Softwareschutz