One game I have quite fond memories of is Microsofts Pandora’s Box (1999), a puzzle game for PC created by the designer of Tetris. The game consists of a total of 361 puzzles of 10 different types, spread over 7 stages with increasing difficulty. Of course, being designed for Windows 95 and 98, the game shows its age: It is hardcoded to use a full-screen resolution of 640×480, writes its save files to the ‘Program Files’ directory, and shows a black screen when the built-in videos are playing, leaving you with audio only.
Wouldn’t it be cool to bring the game to 2023, getting it to run flawlessly under modern Windows (and possibly other operating systems), and making it possible to add more puzzles, while gathering some reverse engineering experience on the way?
The first goal I set is being able to modify the first Focus Point puzzle, specifically, changing the image used by that puzzle.
Setting up the reverse engineering environment
For my reverse engineering efforts I installed Windows 10 (64-bit, as I already knew the games runs fine under x64 Windows) on a virtual machine. Other tools I will be using in this post are:
- Microsoft Remote Desktop, to access the VM while having decent graphics/UI performance
- Windows Subsystem for Linux, with Debian as the guest distribution
- Python (installed under Debian in WSL)
- Visual Studio Code and its WSL extension
- HxD as my hex editor. As you may notice in the below screenshots, I tried ImHex at first as it looks much more modern and feature-rich, but I couldn’t get to grips with its search function.
Installing the game
Let’s get started by installing the game. I used the CD that I still have from back in the day, but the ISO is floating around the web on various abandonware websites if you want to follow along. You also want to grab the 1.0a patch (link to archive.org, as the original has long been taken down), as the game will not run on Pentium III and up without it.
I chose to do the ‘Full’ installation, so all game data is copied to the C: drive. Afterwards, install the 1.0a patch linked earlier.
By changing a single registry key, we can trick the game so that the CD is not required for launching, which is particularly useful when you used a physical disk to install the game. Launch the registry editor, navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Pandora's Box\1.0
on 32-bit Windows, or
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft Games\Pandora's Box\1.0
on 64-bit Windows. Change the value of the key ‘CDROMDIR’ to the path where the game was installed, e.g. ‘C:\Program Files (x86)\Microsoft Games\Pandora’s Box’. The game may now be launched without the CD in the (virtual) drive.
Let’s start by taking a look at the game files we installed:
If you have played the game, you can map most directories to the various puzzle types by looking at the directory name:
|FNF||Find and Fill|
All the above directories initially contain only sound effects in the WAV file format. After playing a few puzzles, ‘.rim’ files started appearing in some of these directories.
We then have another set of directories containing mostly WAV files:
|MUSIC||Music played on the map and puzzle screens|
|SCREENS||Menu sound effects|
The ‘pandora.htm’ and ‘pandora.mgd’ files in the ‘MUSIC’ directory seem to describe some sort of map or graph. Opening the HTM file in Firefox results in the message ‘(Browser does not support controls.)’. Out of curiosity I tried opening the HTM file under Windows 98 SE/Internet Explorer 5, but it showed the same message.
Finally, we have the ‘HELP’ directory which contains two files: ‘message.m20’ and ‘pandora.m20’. Inspecting them using the ‘string’ command in WSL reveals that they contain text sequences used in the game, like the instructions shown during tutorials.
Jumping back to the root directory, we have the following files:
|besttime.dat||Presumably contains high scores per puzzle|
|bkant.ttf||Book Antiqua font, used in the game|
|clcd16.dll||SafeDisc (copy protection) library|
|clcd32.dll||SafeDisc (copy protection) library|
|credits.dat||Contains the list of people who developed the game|
|dplayerx.dll||SafeDisc (copy protection) library|
|EBUSetup.sem||? (Empty file)|
|EULA.RTF||End User License Agreement|
|int01.avi to int07.avi||Trickster capture videos, played when a chapter is completed|
|loadbar.png||Shown next to the splash screen when starting the game|
|open.avi||Opening movie, played when first starting the game|
|pandora.eul||Exact copy of pandora.exe. Interestingly, on the CD this file matches the 1.0a executable, while the 1.0a patch is not even included on my disc!|
|pandora.exe||Main game executable, version 1.0a|
|pandora.rof||Game data (226 MB)|
|puzzle.dat||Game data (70 kB)|
|r<player name>.bly||Save data, only created after starting the game. Note: if the game is not launched as administrator, these files will instead be written to ‘%LOCALAPPDATA%/VirtualStore/Program Files (x86)/Microsoft Games/Pandora’s Box/’.|
|r<player name>.ply||Save data, see above|
|screens.rof||Another data file (68 MB)|
|splash.png||Game splash screen|
|tricks.bmp||? (Not a bitmap image despite the file extension)|
I determined the above information by inspecting the files with the ‘file’ and ‘strings’ commands under WSL. and by looking at their filenames.
The main files of interest are of course the large .rof files, as we haven’t seen any of the in-game asssets yet. Presumably these assets are combined into the .rof files.
Let’s take a look at the ‘pandora.rof’ file through ‘strings’:
strings pandora.rof | less
In the output we can immediately spot a few level and puzzle names, as well as a lot of PNG files:
3DSKIN LEVEL.0 LEVEL.01.MAUI LEVEL.02.PUCK LEVEL.03.ERIS LEVEL.04.COYOTE LEVEL.05.MONKEY LEVEL.06.ANANSI LEVEL.07.RAVEN LEVEL.08.SCALAWAG OVER SLICE TRIGRAMS 302.PNG BRACKET0.PNG BRACKET1.PNG BRACKET2.PNG BRACKET3.PNG DNARROW_D.PNG DNARROW_DH.PNG DNARROW_U.PNG ...
Let’s take a look through a hex editor:
At 0x184..0x23A we immediately spot something that looks like a directory listing. A bit further in the file, at 0x436, we spot another listing, this time of PNG files:
Let’s write down the following information for now:
- The first listing starts at 0x184 and is 0xB6 bytes long (including the final null terminator).
- The first listing contains 19 directory or file names (separated by null bytes).
- The second listing starts at 0x436 and is 0x14A bytes long.
- The second listing contains 25 directory or file names.
Let’s look at the start of the file next. As the game is designed to run on 32-bit Windows systems, we can assume all integers are 32 bits/8 bytes long, and the byte order is little endian.
The first integer (13 00 00 00 / 0x13 hexadecimal / 19 decimal) seems to denote the length of the directory index. We validate our hypothesis against the ‘screens.rof’ file: it starts with the sequence ’01 00 00 00′, and indeed contains only one directory named ‘SCREENS’.
Immediately next, at 0x4, we find the value 0xB6. This matches the length of our directory listing.
The next five integers seem to describe the first entry from the listing:
- 0x23A: this value matches a position immediately after the listing. This is probably the offset where the referred directory or file starts.
- 0x0 and 0x1: we don’t yet know what these values mean. Let’s ignore them for now.
- 0x7: this value matches the length of the file name, including the null terminator at the end.
- 0x0: this value is the offset of the file name relative to the start of the name table.
Again, we can check these hypotheses against either the ‘screens.rof’ file, or more conveniently, the next entry in the structure:
- 0x580: this again is a offset right after the second listing.
- 0x0 and 0x1: we still don’t know the meaning of those values, but they are the same as for the first entry.
- 0x4: matches the length of the name (‘BGL’, including a null terminator).
- 0x7: indeed matches the offset of the name relative to the name table offset.
We can conclude that the metadata entries thus consist of 5 integers, and as such are 20 bytes long each.
Now that we can parse directory listings, let’s look at the actual files embedded in the .rof file. In the second listing we see that there are PNG files present in. Wikipedia tells us all PNG files start with the sequence ’89 50 4E 47 0D 0A 1A 0A’. Let’s search the file for this sequence:
We get a first match at offset 0x526F2. It seems the contents .rof files are not compressed or encrypted in any way. Furthermore, notice the file starts immediately after the listing, so we know there is no metadata behind the listings.
Because the second file in the listing is also a PNG file, we can search for the signature again. The second signature occurs at 0x82C28. Assuming there is no metadata between the files, we can dump the region 0x526F2…0x82C27 and the result should be a valid PNG image:
And indeed, the range contains an asset from the game. We can also use the offsets (0x526F2 and 0x82C27) and size (subtracting the offset leaves 0x30536) to look for the metadata describing it:
The offset is found in between the first and second listing; the size is found immediately thereafter. We can also spot the offset of the second file (0x82C28) at 0x256..0x259, so we know the file entries too are 20 bytes in size.
The two integers between the directory listing and the offset of the first file contain values 0x19 and 0x14A, which again correspond to the number of files and the size of the name table.
Using all the above information, we can write a simple parser in Python that can print the directories and the files in them:
Resulting in the following output:
3DSKIN 302.PNG BRACKET0.PNG BRACKET1.PNG BRACKET2.PNG BRACKET3.PNG DNARROW_D.PNG DNARROW_DH.PNG DNARROW_U.PNG DNARROW_UH.PNG REVLF_D.PNG REVLF_DH.PNG REVLF_U.PNG REVLF_UH.PNG REVRT_D.PNG REVRT_DH.PNG REVRT_U.PNG REVRT_UH.PNG ROTATE_D.PNG ROTATE_DH.PNG ROTATE_U.PNG ROTATE_UH.PNG UPARROW_D.PNG UPARROW_DH.PNG UPARROW_U.PNG UPARROW_UH.PNG ... LEVEL.0 PUZZLE.1.IMH PUZZLE.10.BGL PUZZLE.11.TAN PUZZLE.12.FNF PUZZLE.2.ZOO PUZZLE.3.RTT PUZZLE.4.FSH PUZZLE.5.SKI PUZZLE.6.CHIS PUZZLE.7.JESS PUZZLE.8.RUB PUZZLE.9.SLICE LEVEL.01.MAUI CITY.06.CAIRO CITY.10.HONOLULU CITY.16.MADRID CITY.21.NEW YORK CITY.22.PARIS PUZZLE.1.OVL ...
The files in the puzzle directories (3DSKIN, FNF, FPN etc.) seem to be UI elements only. Looking at the level data, it is a reasonable assumption that the ‘files’ below them are actually be subdirectories.
LEVEL.0 probably contains the tutorial puzzles as there is one puzzle of each type, and LEVEL.01 to LEVEL.07 contain a directory per city (which presumably contain the puzzles for that city) and one to three standalone puzzles for the ‘boss fight’. Interestingly, there is a directory named ‘LEVEL.08.SCALAWAG’, which possibly contains the 40 additional puzzles from the ‘Puzzle Game of the Year Edition‘ re-release. As far as I know however my version of the game is not the Puzzle Game of the Year Edition (it is the European release by Xplosiv), so this raises the question whether the extra puzzles have always been included.
It seems like both directories and files are described by the same 20 bytes of metadata. Let’s look for a directory/file flag. Recall that there is one field that we do not know the meaning of yet. Let’s log the size and the unknown field for every entry:
... LEVEL.0 / 0 / 1 PUZZLE.1.IMH / 0 / 1 PUZZLE.10.BGL / 0 / 1 PUZZLE.11.TAN / 0 / 1 PUZZLE.12.FNF / 0 / 1 PUZZLE.2.ZOO / 0 / 1 PUZZLE.3.RTT / 0 / 1 PUZZLE.4.FSH / 0 / 1 PUZZLE.5.SKI / 0 / 1 PUZZLE.6.CHIS / 0 / 1 PUZZLE.7.JESS / 0 / 1 PUZZLE.8.RUB / 0 / 1 PUZZLE.9.SLICE / 0 / 1 LEVEL.01.MAUI / 0 / 1 CITY.06.CAIRO / 0 / 1 CITY.10.HONOLULU / 0 / 1 CITY.16.MADRID / 0 / 1 CITY.21.NEW YORK / 0 / 1 CITY.22.PARIS / 0 / 1 PUZZLE.1.OVL / 0 / 1 ...
Clearly, the unknown field denotes the type of the entry: 0 means file and 1 means directory. Furthermore, all directories have a size of 0, so we can ignore this field when processing a directory.
The final directory metadata structure thus looks as follows:
Let’s rework our script so it can parse an arbitrary mix of directories and files:
And indeed there are a lot of nested directories below the ‘LEVEL’ folders:
... LEVEL.01.MAUI: CITY.06.CAIRO: PUZZLE.01.FPN: PUZZLE.ZOO PUZZLE.02.SLC: 1OBJ_1.PNG 1OBJ_1A.PNG 1OBJ_2.PNG 1OBJ_2A.PNG ...
In the next post, we will take a look at the following tasks:
- Extracting the files we just listed;
- Repacking the .rof file after making changes;
- Examining the .ZOO file that contains a Focus Point puzzle, and modifying the image embedded in it.