How We Restored a Forgotten Strip Poker Game

The additional teams from Strip Poker Professional Volume I and Volume II had not disappeared from the original CD-ROMs. The files were still present in full, but they were encrypted and tied to a telephone-based activation system that has not existed for decades.

Simply patching the game executable was therefore not enough. The actual images, animations, menu resources, and game data had to be decrypted, reconstructed, and correctly reintegrated into the games.

This article explains how we reconstructed the protection system, how the two volumes differ technically, and how we turned the encrypted content on the original discs into complete local installations again.

An Activation System from the Pre-Internet Era

Artworx released two CD-ROM editions of Strip Poker Professional during the 1990s. The discs contained several additional teams of opponents, but only part of the content was immediately available after purchasing the game.

Additional teams could be purchased through a telephone hotline. The customer provided a serial number or system-generated identifier and received an activation code in return.

The activation process stored encrypted product records on the computer. The included VendorSystem loader evaluated those records and decrypted the purchased content while it was being read from the CD.

This system worked only while the publisher or activation service remained available. Once the hotline disappeared, the additional content remained physically present on the original discs, but new installations could no longer activate it through the intended process.

Even owners of the original CD-ROMs were therefore unable to access a significant part of the content they had received on those discs.

The real problem was not a locked menu option. The media files themselves were encrypted. Bypassing a single protection check could not produce working additional teams.

Building on Earlier Preservation Research

Our work did not begin from zero. Earlier research by -=CHE@TER=-, also known as CTPAX-X, had already documented important parts of the VendorSystem and VEND technology.

That research provided essential information about the file formats, encrypted product records, and the general architecture of the original loader.

Special thanks also go to ELDRICUS for providing the original ISO images required for the technical analysis.

Some community members contacted former Artworx programmer Arthur Welsh. Unfortunately, the original development files and activation tools were no longer available. The remaining option was therefore to reconstruct the system from the software and data that had actually been shipped to customers.

The final reconstruction and development of the unlockers were carried out by DOSGAME.AT with the assistance of OpenAI.

The Shared Technical Foundation

Both volumes use proprietary container files and a custom symmetric encryption algorithm. The team data is stored in files with the VCL extension.

These are archive containers created with the Genus system. Internally, they contain a directory of DOS filenames, file offsets, file sizes, and the corresponding data.

A valid decrypted VCL archive begins with a characteristic signature:

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

This signature was extremely useful during the analysis. It gave us a reliable piece of known plaintext. When a block was decrypted with the correct key, the resulting file had to begin with this exact header.

Incorrect keys could therefore be rejected immediately instead of producing apparently plausible but damaged output files.

The Proprietary Block Algorithm

The encryption processes data in blocks of eight bytes, meaning that it is a 64-bit block algorithm.

For the team archives, a 32-bit key is divided into two 16-bit halves and expanded into four initialization words:

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

The algorithm uses these eight initialization bytes to construct a 32-byte working vector. Each encrypted eight-byte block then passes through:

1. an initial XOR operation using part of the working vector,
2. eight rounds of word exchanges, XOR operations, and byte substitutions,
3. a final XOR operation using another part of the working vector.

The substitution stage uses a specially arranged 256-byte lookup table. This is not DES, IDEA, or another standard cipher. It is a proprietary VendorSystem algorithm.

For our tools, we had to reconstruct both the decryption process and the inverse encryption process. Reading the archives was only one part of the task. We also had to generate valid encrypted activation records in the exact format expected by the original software.

Volume I: Encrypted Team Archives inside VEND0251

In Strip Poker Professional Volume I, the protected additional archives are located inside the large file VEND0251.

The six team archives are stored at fixed raw offsets. Each archive has a known original size and its own 32-bit content key. Their physical order inside the container does not match the numerical order of the teams.

Archive     Offset in VEND0251     Size               32-Bit Key
-----------------------------------------------------------------------
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

Step 1: Extracting the Encrypted Ranges

The Volume I unlocker reads the original ISO directly as an ISO 9660 file system and copies the normal game files into a local destination directory.

VEND0251 is treated separately as a raw data source. For each team, the tool seeks to the known offset and reads exactly the encrypted archive area.

Because the algorithm processes only complete eight-byte blocks, the internal working length is rounded up to the next multiple of eight. Only the bytes belonging to the actual original archive size are written to the final output file.

Step 2: Decrypting and Validating the Archives

Each encrypted area is decrypted block by block using its corresponding team key.

The first decrypted bytes must contain the expected Genus VCL header. If the signature is missing, the tool stops. This prevents an unsupported ISO or an incorrect key from silently creating corrupted files.

The six large archives can be processed in parallel. This does not change the algorithm, but it significantly reduces the processing time on modern computers.

Step 3: Rebuilding TEAM0.VCL

Once the operation is complete, TEAM1.VCL through TEAM6.VCL exist as readable archives again. However, that alone is not sufficient.

The game expects its main content inside TEAM0.VCL and normally accesses additional teams through the original activation path. We therefore had to analyze the internal VCL structure as well.

• The container header is 0x80 bytes long.
• Each directory entry occupies 26 bytes.
• An entry contains a DOS filename, a data offset, a file size, and an additional status value.
• The archive data begins immediately after the final directory entry.

The unlocker reads every entry from TEAM0.VCL through TEAM6.VCL, checks for duplicate filenames, calculates the new offsets, and writes a single complete local container.

The menu resources TEAM1INF.VXC through TEAM6INF.VXC are also added.

Certain selection graphics are expected as separate files. The unlocker therefore additionally extracts:

TEAM1.VXC  through TEAM6.VXC
TEAM1B.BXL through TEAM6B.BXL

Step 4: Adapting SPROG.EXE to the Local Installation

The executable SPROG.EXE still contained references to the original team containers, CD paths, and activation states.

The unlocker therefore applies several byte-verified modifications:

• Team loading is redirected to the newly rebuilt local TEAM0.VCL.
• Local CD-path checks and incorrect-CD error paths are bypassed.
• The opponent-selection system treats the available teams as locally activated content.
• The intended local save-game path is enabled.
• An additional bug affecting pot, round, and offer values when beginning a new game is corrected.

Before any modification is written, the tool verifies the expected original bytes. An unsupported executable is rejected instead of being patched blindly.

Step 5: Reconstructing the Product Records

Volume I stores activation information in SETUP\PREFS.PRF. The relevant records are eight bytes long and contain a slot number, status flags, and a 32-bit content key in their decrypted form:

[Slot: 16 Bit] [Flags: 16 Bit] [Key: 32 Bit]

Product ID 0x000532 is used when encrypting these records. The additional teams are assigned to hidden product slots:

Hidden Slot     Team      Key
-----------------------------------
0x12            TEAM4     0x681169CF
0x13            TEAM3     0xE29EAEA4
0x14            TEAM6     0xEC8963CF
0x15            TEAM5     0x723B2B53
0x17            TEAM2     0xF2174D30
0x18            TEAM1     0x27B450D2

The unlocker creates these records in the encrypted format expected by the original system. It does not merely enable a visible menu flag. It reconstructs the local state of a fully activated installation.

The surviving Volume I implementation documents the final keys, archive structure, decryption process, and validation method. The precise original research path through which every Volume I key was first recovered is less completely documented than the corresponding Volume II analysis.

The keys themselves are nevertheless conclusively validated by the resulting activation records and the unambiguous Genus VCL archive structure.

Volume II: Two Independent Encryption Layers

Volume II uses a more advanced and substantially more complicated design. The protected files are stored inside VEND0278.

This file is not simply a sequence of encrypted VCL archives. It first forms its own encrypted, HFS-like container or file-system layer.

Volume II therefore required two separate protection layers to be rebuilt:

1. Outer layer: decrypting and interpreting the VEND0278 container.
2. Inner layer: separately decrypting the TEAM?.VCL archives stored inside it.

The original VendorSystem loader performed the outer decryption while reading the data.

During the analysis, this path could be traced into the internal VENDRUN processing, including the read and decode path identified as b035.

To create a permanent local installation, this behavior had to be reproduced outside the discontinued activation system.

The Critical Weakness: The Key Confirmed Itself

The most important breakthrough in Volume II came from the hidden product records.

A correctly decrypted eight-byte record contained not only the product slot, but also the same 32-bit key that had been used to decrypt it. In simplified form, the structure was:

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

The final four bytes contain the key in little-endian order. This meant that a candidate key could be tested immediately.

After decryption, both the expected hidden slot and the candidate key itself had to appear in the plaintext.

A concrete example:

Encrypted record:
A0 C8 19 9C C8 57 36 93

Candidate:
0x68647DC3

Decrypted result:
00 00 00 18 C3 7D 64 68

The result contains slot 0x18, followed by C3 7D 64 68. This is exactly 0x68647DC3 in little-endian representation.

The key was therefore not merely plausible. It was structurally confirmed by the decrypted record itself.

This was not blind trial and error through the user interface. The known record structure provided a deterministic cryptographic test for every candidate.

Once a team archive had been decrypted, the Genus VCL signature provided a second independent confirmation.

The Internal Volume II Keys

Team      Internal Content Key
--------------------------------
TEAM1     0x68647DC3
TEAM2     0x0DE45369
TEAM3     0xEAD77ECE
TEAM4     0x6D270A21
TEAM5     0x80E57A2D
TEAM6     0x91EB784B

IMPORT.DAT linked the hidden product slots to the actual team files. This made it possible to determine which confirmed product record belonged to which encrypted archive.

From VEND0278 to a Local Installation

Once the outer container decryption had been reconstructed, the internal files could be read from VEND0278.

At that stage, however, the team archives were still unusable because each of them was protected with its own separate content key.

The complete Volume II process therefore consisted of:

1. reading the original CD or ISO image,
2. decoding the outer VEND0278 structure,
3. mapping the internal product records to team files through IMPORT.DAT,
4. decrypting every team archive block by block,
5. validating the decrypted VCL structure,
6. extracting and integrating the decrypted game data locally.

Only the combination of both layers produced usable content. Merely opening the outer container or modifying the game executable would not have been sufficient.

The Main Differences between Volume I and Volume II

Feature               Volume I                         Volume II
--------------------------------------------------------------------------------
Main container        VEND0251                         VEND0278

Protection layers     Team archives at fixed          Encrypted outer container
                      raw offsets                      plus encrypted team archives

Key validation        Activation records and          Self-key signature and
                      Genus VCL header                 Genus VCL header

File mapping          Known offsets and sizes          Container file system and
                                                       IMPORT.DAT

Local reconstruction  Rebuilt TEAM0.VCL and            Outer container decoding and
                      modified SPROG.EXE               local archive extraction

Why a Simple Crack Was Not Enough

Many traditional copy-protection systems can be bypassed by changing one conditional branch in an executable. A failed check becomes a successful check, and the game continues.

Strip Poker Professional was fundamentally different. Its protection system consisted of several interdependent elements:

• encrypted product and activation records,
• a loader that decrypted data while reading it,
• separate content keys for the individual teams,
• encrypted container and archive structures,
• program references to CD paths and activated products,
• menu resources that had to exist in the correct format and location.

A patch that only unlocked the team-selection menu would have produced empty entries, corrupted data, or read errors.

The real work was understanding the entire original data path and replacing it with a reproducible local installation process.

How the Unlockers Detect Decryption Errors

The unlockers do not assume that an operation has probably succeeded. Multiple validation stages prevent silent corruption:

• The source must contain a supported ISO 9660 structure.
• The source files must contain the expected sizes and raw data ranges.
• Every decrypted team archive must begin with the known Genus VCL header.
• VCL directory entries must point to valid locations inside the archive.
• Duplicate filenames encountered while merging archives are treated as errors.
• Expected original bytes are checked before an executable is modified.
• The completed installation is checked for the required archives, menu files, and activation records.

The completed installation was then launched in DOSBox and automatically guided through the title screen, menu selection, and game startup. Screenshots from each stage made reproducible functional testing and visual comparison possible.

Preservation Rather than Simple Protection Bypassing

Our unlockers contain neither the games nor the encrypted or decrypted media files.

Each tool requires the user's own original ISO image and performs every extraction, decryption, reconstruction, and patching step locally on that user's computer.

The purpose of the project was to restore a historical software state that had originally been intended by the publisher and was physically present on the sold CD-ROMs, but had become inaccessible because the external activation infrastructure no longer existed.

We also wanted to document this unusual technical system before the remaining knowledge about it disappeared completely.

Conclusion

The additional content from Strip Poker Professional Volume I and Volume II had effectively been lost for decades.

In reality, the data was still present on the original CD-ROMs. It was protected by a proprietary activation and encryption system whose external infrastructure had long since disappeared.

For Volume I, we extracted the encrypted team archives from VEND0251, reproduced the 64-bit block algorithm, decrypted every VCL file, built a complete local TEAM0.VCL container, reconstructed the activation records, and adapted the program logic to use the new installation.

Volume II additionally required the reconstruction of an encrypted outer container structure.

The decisive breakthrough was the self-key signature inside the hidden product records. A correct key decrypted not only the expected product slot, but also reproduced itself inside the same plaintext record.

This allowed the six internal content keys to be confirmed conclusively and then used to decrypt the actual team archives.

The result is not a collection of old cracks and not a package containing copyrighted game data. It is a newly developed, reproducible preservation solution that rebuilds a complete local installation from the user's own original disc.

Happy Gaming!

– Eric / DOSGAME.AT