Hallo meine treuen Blogleser

Auf bitten einer Person hab ich mir Intercafe 2011 bzw 2013 nochmal angeschaut. Über Intercafe habe mir bereits vor 2 Jahren den Kopf zerbrochen, die damals entstanden Artikel sind in der Serie unten verlinkt. Mit mehr Lebensweisheit und vorallem Erfahrung habe ich also einen weiteren Versuch gestartet, das tückische System zu überlisten.

Wie immer geht es zunächst um die Registrierung des Programms. Dabei ist der Mechanismus bei 2013 genau der selbe wie der bei 2011. Wie in den vorherigen Posts nach zu lesen ist, wird ein Name, ein Softwarecode und ein Softwarekey verlangt. Diese Daten werden nach durchlaufen eines Offline-Checks über eine verschlüsselte Verbindung zum Server übertragen. Wenn diese Daten passen, so ist man registriert. Wenn nicht, so sendet der Server die Anzahl der Tage, die die Testversion schon abgelaufen ist. Da ich auf dem selben PC vor 2 Jahren gearbeitet hab, ist auch das Testdatum das vor 2 Jahren. Somit ist meine Software bereits seid 684 Tagen abgelaufen.

Im letzten Post habe ich von einem Base64-String erzählt, der wohl die Lizenzdaten bereitstellt. Mit dieser Erkenntnis bewaffnet, schaute ich mir diese Lizenzklasse weiter an. Da diese inzwischen in eine ziemlich lesbare, exterene Lib ausgelagert wurde, konnte man sie auch dementsprechend gut analysieren. Aber zunächst etwas Code, der die Server-Response auf eine Login/Registrationsmessage darstellt.

public static void A(string DKSStateString, string st, string string_0, string DKSStateString, string st, string st, string st, string st, string DKSStateString, string st)
{
	try
	{
		e9.C = Convert.ToBoolean(st);
	}
	catch
	{
		e9.C = false;
	}
	e9.E = CLConvertFunctions.ConvertObjectToBool(st);
	e9.A = (E.A(DKSStateString) as CLRegistrationEntry);
	if (string.IsNullOrEmpty(e9.A.RegistrationCode))
	{
		e9.f = "DEMOVERSION";
	}
	e9.G = string_0;

Ziemlich unleserlicher Salat, nicht? Diese Funktion schaltet das Programm frei, oder auch nicht. Denn in dem ersten Parameter wird eine Base64-Serilisierte Klasse übergeben, die im Anschluss als “CLRegistrationEntry” (9te Zeile) gelesen/deserialisiert wird. Wenn nun der Registrations-Code in dieser Struktur “NullOrEmpty” ist, so handelt es sich um eine Demoversion.

Die Lösung bestand nun darin, die CLRegistrationEntry-Struktur in einem eigenen Projekt zu verwenden, mit irgendwelchen validen Lizenzdaten zu füllen und in das Programm einzuschleusen. Das Ergebnis war ebenfalls ein Base64-Codierter String, der per Reflexil fest eingepatched wurde. Nun wurde jedes mal meine valide Lizenz eingelesen und zur Lizenzstruktur geparst.

Lösung? Nein… Das Programm startete normal, es war ja aktiviert, der Server meckert aber immer noch. Denn jede Request, die von dem Internet Cafe Server ausgeht, gelangt zum (in Hintergrund laufenden) Verwaltungsservice “ICService.exe”. Das bedeutet, dass allte Daten vom Service angefordert werden müssen. Und wenn der Service uns nicht mag, gibts auch keine Daten. Wem die Tragweite dieser Technik noch nicht einleuchtet, dem sei ein Stück Server-Client-Log präsentiert, nachdem ich auf “Statistik -> Bilanzstatistik” gedrückt habe:

[SENT] REQUESTRECEIPTLISTDIALOG
[RECV] DEMOVERSIONNOTRIALTIMELEFT 684

Eigentlich müsste die Antwort ein “RESPONSERECEIPTLISTDIALOG” sein, mit Strukturen wie “CLReceiptListDialog” gefüllt. Dagegen sagt der Server einfach “nein, mach ich nicht. Demozeit abgelaufen”.

Nunja, die Erkenntnis von ICService.exe bringt uns verdammt viel. Denn diese regelt demnach wohl Registration, als auch alles andere in Verbindung mit dem Intercafe Server. Ich rede von nun an von “Server”. wenn ich den lokalen Internetcafe Server meine, sonst wird von “Service” gesprochen, also der Dienst der die Daten an den Server bereitstellt.

Schnell wurde die Registrationsroutine im Service gefunden. Diese lief wohl über eine XML-Datei, die mit verschlüsselten Daten gefüllt war. Die erste Idee war es also, diese XML-Datei zu erstellen, zu füllen und Erfolg zu haben. Das Problem ist, dass diese XML-Lizenzdatei mit einem RSA2048 Bit Public Key gesichert ist. Wenn die Signatur der XML-Datei, die nur mit dem Private Key zu erstellen ist, nicht passt, so findet auch kein Auslesen statt. Das hätte mal zwar Patchen können, aber ist ebenfalls viel zu viel Aufwand.

Der nächste Ansatz war wieder die Registration, dieses mal allerdings im Service. Denn der Softwarecode gelangt nach Eingabe am Server zum Service und von dort an über eine weitere verschlüsselte Verbindung zum großen Internet-Cafe-Online-Server, der uns bei gültigem Key ein “OK” liefert. In der nächsten Request würde die Lizenzstruktur, ein bisschen codiert aber machbar, sowie die Anzahl der Tage bis Ablauf zurückgeliefert werden. Wenn nicht, so wird die Lizenz-Struktur im Service mit “Demoversion-Werten” gefüllt. Aufmerksame Blogleser ahnen bereits was kommt. Denn im Service war eine ähnliche “Deserialize”-Funktion zu finden, wie bereits im Server. Anstatt bei einem Fehlschlag der Registration eine “Demoversion-Lizenz” einzufügen, patchen wir unsere erstellte Lizenz rein. Das Ergebnis kann sich sehen lassen:

Damit haben wir jegliche RSA-Checks, Verschlüsselungsalgorithmen und Demochecks umgangen. Das Programm kann nun normal genutzt werden und meckert nicht mehr, wenn man irgend einen Dialog öffnen möchte. In der Lizenz können natürlich die einzelnen Module (de)aktiviert werden, genau wie alles andere in der Lizenzklasse.

Damit ist mein so ziemlich schwerstes .NET RE abgeschlossen und ich bin auch irgendwie etwas Stolz. Denn InterCafe war zwar mit seinen vielen Funktionen, Klassen, Managern und Parsern richtig unübersichtlich und auf jeden Fall eine echte Herrausforderung!

Grez

10 people like this post.

Like

Unlike