Eine fremde Lizenzprüfung übernehmen, ohne das Plugin anzufassen

Ein gekauftes Serverpaket bringt ein Kernplugin mit, das beim Start eine Lizenz prüft. Diese Prüfung geht an einen Server des Herstellers. Wenn dieser Server nicht erreichbar ist, startet das Plugin nicht — und damit der halbe Server nicht.

Ich hatte eine schriftliche Freigabe des Herstellers, die Prüfung auf eigene Infrastruktur umzustellen. Was folgt, ist der technisch interessante Teil: wie man so etwas macht, ohne das Plugin selbst zu verändern.

Der Kniff: die Serveradresse ist Konfiguration

Bevor ich irgendetwas dekompiliert oder gepatcht habe, habe ich die mitgelieferten Konfigurationsdateien durchgesehen. Und dort stand sie: die Adresse des Lizenzservers, in einer Datei, die zur Laufzeit gelesen und über einen Befehl neu geladen werden kann.

Damit war die ganze Migration eine geänderte Zeile. Keine Dekompilierung, kein Patch, kein Neubau. Und der Rückweg ist ebenso einfach: Originaldatei zurückschreiben, neu laden.

Das ist die Lehre, die ich mir aus diesem Tag am stärksten gemerkt habe: Bevor man an einer Binärdatei arbeitet, alle Konfigurationsdateien lesen. Die aufwendige Lösung war nicht nötig, und ich hätte sie fast begonnen.

Das Altprotokoll verstehen

Was der Client erwartet, ließ sich aus dem beim Kauf mitgelieferten Teilquellcode ablesen:

• Ein Aufruf an einen festen Pfad, mit der Lizenz oder einem Token im Körper.
• Bei Erfolg eine Antwort mit zwei Werten: einem Token und einem Zusatzwert.
• Bei Fehler eine Antwort mit Fehlercode.
• Bei zu vielen Anfragen ein Hinweis, wie lange zu warten ist.

Der Pfad ist fest einkompiliert — nur Adresse und Port kommen aus der Konfiguration. Meine Anwendung musste ihn also unter genau diesem Pfad anbieten, was über eine Umschreibungsregel gelöst ist.

Der Zusatzwert wird nicht geprüft. Das war lange die einzige echte Unbekannte: Wird dieser Wert vom Client irgendwie verifiziert? Nein — er wird nur weitergereicht. Ein frischer Zufallswert genügt.

Der Sicherheitsteil, der ehrlich benannt gehört

Das Altprotokoll spricht unverschlüsselt und ohne Signaturprüfung. Der Client glaubt jeder Antwort, die zurückkommt.

Das bedeutet: Die Lizenzprüfung ist kryptografisch wertlos. Wer den Netzwerkverkehr beeinflussen kann, kann jede Antwort fälschen.

Meine Konsequenz war nicht, das Protokoll zu verbessern — das ginge nur mit einem Eingriff ins Plugin. Sie war, den Endpunkt so zu stellen, dass er ausschließlich aus dem internen Netz erreichbar ist. Die Netzabgrenzung ist hier die eigentliche Absicherung, nicht der Code.

Was auf der eigenen Seite dazukam

Zwei neue Modelle im Datenbestand: eines für das Produkt, eines für die Installationen pro Schlüssel. Die Kennung einer Installation ist bei diesem Altprotokoll die Absenderadresse, weil der Client nichts anderes mitschickt.

Dazu die Regeln, die ich aus meinem eigenen Lizenzsystem übernommen habe: eine begrenzte Zahl gleichzeitiger Installationen, ein Ablaufdatum, eine Prüfspur über jede Verwaltungsaktion.

Was ich nicht übernommen habe, ist der Offline-Betrieb. Bei meinem eigenen System gibt es eine Karenzzeit, damit ein Ausfall meines Servers die Software nicht sofort lahmlegt. Hier läuft die Prüfung im internen Netz zwischen zwei Diensten, die auf derselben Infrastruktur liegen — wenn der eine weg ist, ist der andere meistens auch betroffen.

Was nicht möglich war

Ein Neubau des Plugins. Der mitgelieferte Quellcode umfasst nur einen kleinen Teil der ausgelieferten Klassen — im Wesentlichen den Authentifizierungsteil. Das ganze Produkt fehlt.

Das war der Punkt, an dem klar wurde, dass der Weg über die Konfiguration nicht nur der elegantere, sondern der einzige ist.

Was ich vor dem Eingriff geklärt habe

Bevor irgendetwas passiert ist, standen zwei Fragen — und beide sind wichtiger als der technische Teil.

Darf ich das? Eine Lizenzprüfung umzuleiten, ist ein Eingriff in den Kopierschutz eines gekauften Produkts. Bei mir lag eine schriftliche Freigabe des Herstellers vor, dazu eine unabhängige Zusage einer beteiligten Person, die sich mit dem Autoreneintrag im Plugin deckte.

Ohne diese Freigabe hätte ich es nicht gemacht — nicht aus Vorsicht, sondern weil es dann schlicht nicht in Ordnung wäre.

Was ist der Rückweg? Die ursprüngliche Konfigurationsdatei liegt unverändert daneben. Zurück heißt: eine Datei kopieren, einen Befehl absetzen. Das ist die Art von Rückweg, die eine Änderung risikoarm macht.

Die Grenze, die ich mir aufgeschrieben habe

Es gibt eine Version dieser Geschichte, die ich nicht erzähle: die, in der ich das Plugin dekompiliert und den Prüfteil entfernt hätte.

Das wäre technisch möglich gewesen und war nie eine Option. Der Unterschied ist nicht die Schwierigkeit, sondern die Absicht: Eine Prüfung auf eigene Infrastruktur umzuleiten, weil der ursprüngliche Dienst nicht mehr existiert, ist etwas anderes, als eine Prüfung zu entfernen.

Im ersten Fall bleibt das System bestehen — es prüft weiterhin, nur gegen einen anderen Server, mit ausdrücklicher Erlaubnis. Im zweiten Fall wird es umgangen.

Diese Grenze habe ich mir aufgeschrieben, weil sie in der Praxis leicht verschwimmt. Wenn man ohnehin an einer Stelle arbeitet, ist der nächste Schritt technisch nur eine Kleinigkeit — und genau deshalb ist es besser, die Linie vorher zu ziehen als im Moment der Arbeit.

Was ich mitnehme

Zuerst lesen, dann eingreifen. Die aufwendige Lösung wäre technisch machbar gewesen und war unnötig.

Ein Rückweg gehört zum Umbau. Die Originaldatei liegt daneben. Eine Änderung, die man mit einem Kopierbefehl zurücknehmen kann, ist eine ganz andere Art von Änderung als eine, für die man einen Neubau braucht.

Fremde Protokolle bewertet man nach dem, was sie sind. Dieses hier war offensichtlich nie für feindliche Netze gedacht. Das ist keine Kritik am Autor — es ist eine Information darüber, wo man es betreiben darf.