Wie wir ein vergessenes Strip Poker Spiel wieder hergestellt haben

Die zusätzlichen Teams aus Strip Poker Professional Volume I und Volume II waren nicht von den ursprünglichen CD-ROMs verschwunden. Die Dateien waren weiterhin vollständig vorhanden, jedoch verschlüsselt und an ein telefonisches Freischaltungssystem gebunden, das seit Jahrzehnten nicht mehr existiert.

Es reichte daher nicht aus, lediglich die ausführbare Datei des Spiels zu patchen. Die eigentlichen Bilder, Animationen, Menüressourcen und Spieldaten mussten entschlüsselt, rekonstruiert und anschließend wieder korrekt in die Spiele eingebunden werden.

Dieser Artikel erklärt, wie wir das Schutzsystem rekonstruierten, worin sich die beiden Volumes technisch unterscheiden und wie wir aus den verschlüsselten Inhalten der Originaldatenträger wieder vollständige lokale Installationen erstellen konnten.

Ein Freischaltungssystem aus der Zeit vor dem Internet

Artworx veröffentlichte in den 1990er-Jahren zwei CD-ROM-Ausgaben von Strip Poker Professional. Die Datenträger enthielten mehrere zusätzliche Gegnerteams, beim Kauf des Spiels war jedoch nur ein Teil der Inhalte unmittelbar verfügbar.

Weitere Teams konnten über eine Telefonhotline erworben werden. Der Kunde übermittelte eine Seriennummer oder eine vom System erzeugte Kennung und erhielt dafür einen Freischaltcode.

Bei der Aktivierung wurden verschlüsselte Produktdatensätze auf dem Computer gespeichert. Der mitgelieferte VendorSystem-Loader wertete diese Datensätze aus und entschlüsselte die erworbenen Inhalte während des Lesens von der CD.

Dieses System funktionierte nur, solange der Hersteller oder der Aktivierungsdienst erreichbar war. Nachdem die Hotline eingestellt worden war, blieben die zusätzlichen Inhalte zwar weiterhin vollständig auf den Originaldatenträgern vorhanden, konnten bei einer neuen Installation aber nicht mehr auf dem vorgesehenen Weg freigeschaltet werden.

Selbst Besitzer der Original-CD-ROMs konnten daher auf einen erheblichen Teil der Inhalte, die sich auf ihren Datenträgern befanden, nicht mehr zugreifen.

Das eigentliche Problem war nicht lediglich ein gesperrter Menüpunkt. Die Mediendateien selbst waren verschlüsselt. Das Umgehen einer einzelnen Schutzabfrage hätte daher keine funktionierenden zusätzlichen Teams hervorgebracht.

Aufbauend auf früherer Preservation-Forschung

Unsere Arbeit begann nicht bei null. Frühere Forschungen von -=CHE@TER=-, auch bekannt als CTPAX-X, hatten bereits wichtige Teile der VendorSystem- und VEND-Technologie dokumentiert.

Diese Vorarbeiten lieferten wesentliche Informationen über die Dateiformate, die verschlüsselten Produktdatensätze und die allgemeine Architektur des ursprünglichen Loaders.

Besonderer Dank gilt außerdem ELDRICUS, der uns die für die technische Analyse benötigten Original-ISO-Abbilder zur Verfügung stellte.

Teile der Community nahmen auch Kontakt mit dem früheren Artworx-Programmierer Arthur Welsh auf. Die ursprünglichen Entwicklungsdateien und Aktivierungswerkzeuge waren jedoch nicht mehr vorhanden. Uns blieb daher nur die Möglichkeit, das System anhand der tatsächlich an die Kunden ausgelieferten Software und Daten zu rekonstruieren.

Die abschließende Rekonstruktion und Entwicklung der Unlocker erfolgte durch DOSGAME.AT mit Unterstützung von OpenAI.

Die gemeinsame technische Grundlage

Beide Volumes verwenden proprietäre Containerdateien und einen eigens entwickelten symmetrischen Verschlüsselungsalgorithmus. Die Teamdaten sind in Dateien mit der Endung VCL gespeichert.

Dabei handelt es sich um Archivcontainer, die mit dem Genus-System erstellt wurden. Intern enthalten sie ein Verzeichnis mit DOS-Dateinamen, Dateioffsets, Dateigrößen und den dazugehörigen Daten.

Ein korrekt entschlüsseltes VCL-Archiv beginnt mit einer charakteristischen Signatur:

01 CA  Copyright (c) Genus Microprogramming, Inc. 1988-90

Diese Signatur war für die Analyse besonders wertvoll. Sie stellte einen verlässlichen bekannten Klartext dar. Wurde ein Block mit dem richtigen Schlüssel entschlüsselt, musste die resultierende Datei mit genau diesem Header beginnen.

Falsche Schlüssel konnten dadurch sofort ausgeschlossen werden, anstatt scheinbar plausible, tatsächlich aber beschädigte Ausgabedateien zu erzeugen.

Der proprietäre Blockalgorithmus

Die Verschlüsselung verarbeitet die Daten in Blöcken zu jeweils acht Bytes. Es handelt sich somit um einen 64-Bit-Blockalgorithmus.

Für die Teamarchive wird ein 32-Bit-Schlüssel in zwei 16-Bit-Hälften aufgeteilt und zu vier Initialisierungswörtern erweitert:

LOW16(KEY), HIGH16(KEY), LOW16(KEY), HIGH16(KEY)

Aus diesen acht Initialisierungsbytes erzeugt der Algorithmus einen 32 Byte großen Arbeitsvektor. Jeder verschlüsselte Acht-Byte-Block durchläuft anschließend:

1. eine einleitende XOR-Verknüpfung mit einem Teil des Arbeitsvektors,
2. acht Runden aus Wortvertauschungen, XOR-Verknüpfungen und Byte-Substitutionen,
3. eine abschließende XOR-Verknüpfung mit einem weiteren Vektorteil.

Die Substitutionsstufe verwendet eine speziell angeordnete Lookup-Tabelle mit 256 Bytes. Es handelt sich weder um DES noch um IDEA oder einen anderen bekannten Standardalgorithmus, sondern um ein proprietäres VendorSystem-Verfahren.

Für unsere Werkzeuge mussten wir sowohl den Entschlüsselungsweg als auch den umgekehrten Verschlüsselungsweg rekonstruieren. Das Lesen der Archive war lediglich ein Teil der Aufgabe. Zusätzlich mussten gültige verschlüsselte Aktivierungsdatensätze exakt in dem Format erzeugt werden, das die Originalsoftware erwartete.

Volume I: Verschlüsselte Teamarchive in VEND0251

In Strip Poker Professional Volume I befinden sich die geschützten Zusatzarchive innerhalb der großen Datei VEND0251.

Die sechs Teamarchive liegen an festen Rohdatenoffsets. Jedes Archiv besitzt eine bekannte Originalgröße und einen eigenen 32-Bit-Inhaltsschlüssel. Die physische Reihenfolge im Container entspricht dabei nicht der numerischen Reihenfolge der Teams.

Archiv      Offset in VEND0251     Größe              32-Bit-Schlüssel
-------------------------------------------------------------------------
TEAM1.VCL   0x00122C00             10.725.178 Bytes   0x27B450D2
TEAM2.VCL   0x00B5D600              9.820.060 Bytes   0xF2174D30
TEAM3.VCL   0x03132200             11.552.060 Bytes   0xE29EAEA4
TEAM4.VCL   0x028C9A00              8.815.556 Bytes   0x681169CF
TEAM5.VCL   0x01E71000             10.847.236 Bytes   0x723B2B53
TEAM6.VCL   0x014BB200             10.181.066 Bytes   0xEC8963CF

Schritt 1: Extraktion der verschlüsselten Datenbereiche

Der Volume-I-Unlocker liest das Original-ISO unmittelbar als ISO-9660-Dateisystem und kopiert die normalen Spieldateien in ein lokales Zielverzeichnis.

VEND0251 wird gesondert als Rohdatenquelle behandelt. Für jedes Team springt das Werkzeug zum bekannten Offset und liest exakt den verschlüsselten Archivbereich aus.

Da der Algorithmus ausschließlich vollständige Acht-Byte-Blöcke verarbeitet, wird die interne Arbeitslänge auf das nächste Vielfache von acht aufgerundet. In die endgültige Ausgabedatei werden jedoch nur jene Bytes geschrieben, die zur tatsächlichen Originalgröße des jeweiligen Archivs gehören.

Schritt 2: Entschlüsselung und Validierung der Archive

Jeder verschlüsselte Bereich wird mit dem jeweiligen Teamschlüssel Block für Block entschlüsselt.

Die ersten entschlüsselten Bytes müssen den erwarteten Genus-VCL-Header enthalten. Fehlt diese Signatur, bricht das Werkzeug ab. Dadurch wird verhindert, dass ein nicht unterstütztes ISO oder ein falscher Schlüssel unbemerkt beschädigte Dateien erzeugt.

Die sechs großen Archive können parallel verarbeitet werden. Der Algorithmus selbst verändert sich dadurch nicht, die Bearbeitungszeit auf modernen Computern wird jedoch deutlich verkürzt.

Schritt 3: Neuaufbau von TEAM0.VCL

Nach der Entschlüsselung liegen TEAM1.VCL bis TEAM6.VCL wieder als lesbare Archive vor. Das allein reicht allerdings noch nicht aus.

Das Spiel erwartet seine Hauptinhalte innerhalb von TEAM0.VCL und greift normalerweise über den ursprünglichen Aktivierungspfad auf zusätzliche Teams zu. Daher mussten wir auch die interne VCL-Struktur analysieren.

• Der Containerheader ist 0x80 Bytes groß.
• Jeder Verzeichniseintrag umfasst 26 Bytes.
• Ein Eintrag enthält einen DOS-Dateinamen, einen Datenoffset, eine Dateigröße und einen zusätzlichen Statuswert.
• Die eigentlichen Archivdaten beginnen unmittelbar nach dem letzten Verzeichniseintrag.

Der Unlocker liest sämtliche Einträge aus TEAM0.VCL bis TEAM6.VCL, prüft auf doppelte Dateinamen, berechnet die neuen Offsets und erzeugt daraus einen einzigen vollständigen lokalen Container.

Zusätzlich werden die Menüressourcen TEAM1INF.VXC bis TEAM6INF.VXC eingebunden.

Bestimmte Auswahlgrafiken erwartet das Spiel als separate Dateien. Der Unlocker extrahiert daher außerdem:

TEAM1.VXC  bis TEAM6.VXC
TEAM1B.BXL bis TEAM6B.BXL

Schritt 4: Anpassung von SPROG.EXE an die lokale Installation

Die ausführbare Datei SPROG.EXE enthielt weiterhin Verweise auf die ursprünglichen Teamcontainer, CD-Pfade und Aktivierungszustände.

Der Unlocker nimmt daher mehrere bytegenau geprüfte Änderungen vor:

• Das Laden der Teams wird auf die neu aufgebaute lokale TEAM0.VCL umgeleitet.
• Lokale CD-Pfadprüfungen und Fehlerroutinen für vermeintlich falsche Datenträger werden umgangen.
• Die Gegnerauswahl behandelt die vorhandenen Teams als lokal aktivierte Inhalte.
• Der vorgesehene lokale Speicherpfad wird aktiviert.
• Zusätzlich wird ein Fehler korrigiert, der beim Start eines neuen Spiels Pot-, Runden- und Angebotswerte beeinträchtigte.

Vor jeder Änderung prüft das Werkzeug die erwarteten Originalbytes. Eine nicht unterstützte Programmversion wird abgelehnt, anstatt unkontrolliert gepatcht zu werden.

Schritt 5: Rekonstruktion der Produktdatensätze

Volume I speichert die Aktivierungsinformationen in SETUP\PREFS.PRF. Die relevanten Datensätze sind acht Bytes lang und enthalten in entschlüsselter Form eine Slotnummer, Statusflags und einen 32-Bit-Inhaltsschlüssel:

[Slot: 16 Bit] [Flags: 16 Bit] [Schlüssel: 32 Bit]

Für die Verschlüsselung dieser Datensätze wird die Produkt-ID 0x000532 verwendet. Die zusätzlichen Teams sind versteckten Produktslots zugeordnet:

Versteckter Slot     Team      Schlüssel
------------------------------------------
0x12                 TEAM4     0x681169CF
0x13                 TEAM3     0xE29EAEA4
0x14                 TEAM6     0xEC8963CF
0x15                 TEAM5     0x723B2B53
0x17                 TEAM2     0xF2174D30
0x18                 TEAM1     0x27B450D2

Der Unlocker erzeugt diese Datensätze in dem verschlüsselten Format, das vom ursprünglichen System erwartet wird. Er aktiviert somit nicht lediglich einen sichtbaren Menüeintrag, sondern rekonstruiert den lokalen Zustand einer vollständig aktivierten Installation.

Die erhaltene Volume-I-Implementierung dokumentiert die endgültigen Schlüssel, die Archivstruktur, den Entschlüsselungsweg und die Validierungsmethode. Der genaue ursprüngliche Forschungsweg, über den jeder einzelne Volume-I-Schlüssel erstmals ermittelt wurde, ist weniger vollständig dokumentiert als die entsprechende Analyse von Volume II.

Die Schlüssel selbst werden jedoch durch die resultierenden Aktivierungsdatensätze und die eindeutige Genus-VCL-Struktur zweifelsfrei bestätigt.

Volume II: Zwei voneinander unabhängige Verschlüsselungsebenen

Volume II verwendet ein weiterentwickeltes und erheblich komplexeres System. Die geschützten Dateien befinden sich innerhalb von VEND0278.

Diese Datei ist nicht lediglich eine Aneinanderreihung verschlüsselter VCL-Archive. Sie bildet zunächst einen eigenen verschlüsselten, HFS-ähnlichen Container beziehungsweise eine Dateisystemebene.

Für Volume II mussten daher zwei getrennte Schutzschichten rekonstruiert werden:

1. Äußere Ebene: Entschlüsselung und Interpretation des Containers VEND0278.
2. Innere Ebene: separate Entschlüsselung der darin gespeicherten TEAM?.VCL-Archive.

Der ursprüngliche VendorSystem-Loader entschlüsselte die äußere Ebene während des Lesevorgangs.

Im Zuge der Analyse ließ sich dieser Pfad bis in die interne VENDRUN-Verarbeitung zurückverfolgen, einschließlich des als b035 bezeichneten Lese- und Dekodierpfads.

Um eine dauerhafte lokale Installation zu ermöglichen, musste dieses Verhalten außerhalb des nicht mehr vorhandenen Aktivierungssystems nachgebildet werden.

Die entscheidende Schwachstelle: Der Schlüssel bestätigte sich selbst

Der wichtigste Durchbruch bei Volume II ergab sich aus den versteckten Produktdatensätzen.

Ein korrekt entschlüsselter Acht-Byte-Datensatz enthielt nicht nur den Produktslot, sondern auch denselben 32-Bit-Schlüssel, mit dem der Datensatz entschlüsselt worden war. Vereinfacht dargestellt hatte er folgende Struktur:

00 00 00 [SLOT] [KEY0] [KEY1] [KEY2] [KEY3]

Die letzten vier Bytes enthalten den Schlüssel in Little-Endian-Reihenfolge. Dadurch konnte jeder mögliche Kandidat unmittelbar überprüft werden.

Nach der Entschlüsselung mussten sowohl der erwartete versteckte Slot als auch der verwendete Kandidatenschlüssel selbst im Klartext erscheinen.

Ein konkretes Beispiel:

Verschlüsselter Datensatz:
A0 C8 19 9C C8 57 36 93

Schlüsselkandidat:
0x68647DC3

Entschlüsseltes Ergebnis:
00 00 00 18 C3 7D 64 68

Das Ergebnis enthält den Slot 0x18, gefolgt von C3 7D 64 68. Dies entspricht exakt 0x68647DC3 in Little-Endian-Darstellung.

Der Schlüssel war damit nicht lediglich plausibel, sondern wurde durch die Struktur des entschlüsselten Datensatzes selbst bestätigt.

Es handelte sich daher nicht um blindes Ausprobieren über die Benutzeroberfläche. Die bekannte Datensatzstruktur lieferte für jeden Kandidaten einen eindeutigen kryptografischen Test.

Nach der Entschlüsselung eines Teamarchivs bot die Genus-VCL-Signatur eine zweite, unabhängige Bestätigung.

Die internen Schlüssel von Volume II

Team      Interner Inhaltsschlüssel
-------------------------------------
TEAM1     0x68647DC3
TEAM2     0x0DE45369
TEAM3     0xEAD77ECE
TEAM4     0x6D270A21
TEAM5     0x80E57A2D
TEAM6     0x91EB784B

IMPORT.DAT stellte die Verbindung zwischen den versteckten Produktslots und den tatsächlichen Teamdateien her. Dadurch ließ sich bestimmen, welcher bestätigte Produktdatensatz welchem verschlüsselten Archiv zugeordnet war.

Von VEND0278 zur lokalen Installation

Nachdem die Entschlüsselung des äußeren Containers rekonstruiert worden war, konnten die internen Dateien aus VEND0278 gelesen werden.

Zu diesem Zeitpunkt waren die Teamarchive allerdings weiterhin unbrauchbar, weil jedes von ihnen zusätzlich mit einem eigenen Inhaltsschlüssel geschützt war.

Der vollständige Ablauf für Volume II bestand daher aus:

1. dem Einlesen der Original-CD oder des ISO-Abbilds,
2. der Dekodierung der äußeren VEND0278-Struktur,
3. der Zuordnung der internen Produktdatensätze zu den Teamdateien über IMPORT.DAT,
4. der blockweisen Entschlüsselung jedes einzelnen Teamarchivs,
5. der Validierung der entschlüsselten VCL-Struktur,
6. der lokalen Extraktion und anschließenden Einbindung der entschlüsselten Spieldaten.

Erst die Kombination beider Ebenen ergab nutzbare Inhalte. Weder das bloße Öffnen des äußeren Containers noch eine einfache Änderung der ausführbaren Datei hätte dafür ausgereicht.

Die wichtigsten Unterschiede zwischen Volume I und Volume II

Merkmal               Volume I                         Volume II
--------------------------------------------------------------------------------
Hauptcontainer        VEND0251                         VEND0278

Schutzebenen          Teamarchive an festen            Verschlüsselter äußerer
                      Rohdatenoffsets                   Container und zusätzlich
                                                       verschlüsselte Teamarchive

Schlüsselprüfung      Aktivierungsdatensätze und       Self-Key-Signatur im
                      eindeutiger VCL-Header            Produktdatensatz sowie
                                                       VCL-Header

Dateizuordnung        Bekannte Offsets und Größen      Containerdateisystem und
                                                       Zuordnung über IMPORT.DAT

Lokale Rekonstruktion Neuaufbau von TEAM0.VCL und      Entschlüsselung des äußeren
                      Anpassung von SPROG.EXE           Containers und lokale
                                                       Extraktion der Archive

Warum ein einfacher Crack nicht ausreichte

Viele klassische Kopierschutzsysteme lassen sich durch die Änderung einer einzigen bedingten Verzweigung umgehen. Eine fehlgeschlagene Prüfung wird dadurch als erfolgreich behandelt und das Spiel läuft weiter.

Bei Strip Poker Professional war die Situation grundlegend anders. Das Schutzsystem bestand aus mehreren voneinander abhängigen Elementen:

• verschlüsselten Produkt- und Aktivierungsdatensätzen,
• einem Loader, der die Inhalte während des Lesevorgangs entschlüsselte,
• eigenen Inhaltsschlüsseln für jedes einzelne Team,
• verschlüsselten Container- und Archivstrukturen,
• Programmverweisen auf CD-Pfade und aktivierte Produkte,
• Menüressourcen, die im richtigen Format und am richtigen Ort vorhanden sein mussten.

Ein Patch, der lediglich die Teamauswahl im Menü freigeschaltet hätte, hätte leere Einträge, beschädigte Daten oder Lesefehler erzeugt.

Die eigentliche Arbeit bestand darin, den gesamten ursprünglichen Datenpfad zu verstehen und durch einen reproduzierbaren lokalen Installationsprozess zu ersetzen.

Wie die Unlocker Entschlüsselungsfehler erkennen

Die Unlocker gehen nicht einfach davon aus, dass ein Vorgang wahrscheinlich erfolgreich war. Mehrere Validierungsstufen verhindern eine unbemerkte Beschädigung:

• Die Quelle muss eine unterstützte ISO-9660-Struktur enthalten.
• Die Quelldateien müssen die erwarteten Größen und Rohdatenbereiche aufweisen.
• Jedes entschlüsselte Teamarchiv muss mit dem bekannten Genus-VCL-Header beginnen.
• Die VCL-Verzeichniseinträge müssen auf gültige Positionen innerhalb des Archivs verweisen.
• Doppelte Dateinamen beim Zusammenführen der Archive werden als Fehler behandelt.
• Vor jeder Änderung der ausführbaren Datei werden die erwarteten Originalbytes geprüft.
• Die fertige Installation wird auf die erforderlichen Archive, Menüdateien und Aktivierungsdatensätze überprüft.

Anschließend wurde die fertige Installation in DOSBox gestartet und automatisiert durch den Titelbildschirm, die Menüauswahl und den Spielstart geführt. Screenshots aus jeder Phase ermöglichten reproduzierbare Funktionstests und visuelle Vergleiche.

Preservation statt bloßer Schutzumgehung

Unsere Unlocker enthalten weder die Spiele noch verschlüsselte oder entschlüsselte Mediendateien.

Jedes Werkzeug benötigt das eigene Original-ISO des Benutzers und führt sämtliche Extraktions-, Entschlüsselungs-, Rekonstruktions- und Patchvorgänge lokal auf dessen Computer aus.

Ziel des Projekts war die Wiederherstellung eines historischen Softwarezustands, der vom Hersteller ursprünglich vorgesehen und auf den verkauften CD-ROMs vollständig vorhanden war, später jedoch durch den Wegfall der externen Aktivierungsinfrastruktur unzugänglich wurde.

Gleichzeitig wollten wir dieses ungewöhnliche technische System dokumentieren, bevor das verbliebene Wissen darüber vollständig verloren geht.

Fazit

Die zusätzlichen Inhalte von Strip Poker Professional Volume I und Volume II galten über Jahrzehnte faktisch als verloren.

Tatsächlich waren die Daten weiterhin vollständig auf den Original-CD-ROMs vorhanden. Sie waren jedoch durch ein proprietäres Aktivierungs- und Verschlüsselungssystem geschützt, dessen externe Infrastruktur längst nicht mehr existierte.

Für Volume I extrahierten wir die verschlüsselten Teamarchive aus VEND0251, rekonstruierten den 64-Bit-Blockalgorithmus, entschlüsselten sämtliche VCL-Dateien, erzeugten einen vollständigen lokalen TEAM0.VCL-Container, rekonstruierten die Aktivierungsdatensätze und passten die Programmlogik an die neue Installation an.

Bei Volume II musste zusätzlich eine verschlüsselte äußere Containerstruktur rekonstruiert werden.

Der entscheidende Durchbruch war die Self-Key-Signatur innerhalb der versteckten Produktdatensätze. Ein korrekter Schlüssel entschlüsselte nicht nur den erwarteten Produktslot, sondern reproduzierte sich zugleich selbst innerhalb desselben Klartextdatensatzes.

Dadurch konnten die sechs internen Inhaltsschlüssel zweifelsfrei bestätigt und anschließend zur Entschlüsselung der eigentlichen Teamarchive verwendet werden.

Das Ergebnis ist keine Sammlung alter Cracks und kein Paket mit urheberrechtlich geschützten Spieldaten. Es handelt sich um eine neu entwickelte, reproduzierbare Preservation-Lösung, die aus dem eigenen Originaldatenträger des Benutzers wieder eine vollständige lokale Installation erzeugt.

Happy Gaming!

– Eric / DOSGAME.AT