I spent a lot of my childhood playing games, of all sorts. I have lots of fond memories playing multiplayer Doom back in the early 90’s with my dad, computers tenuously linked over null modem cable. One of the more obscure games I enjoyed was Blobbo, a puzzle game released for classic Mac systems.

Blobbo was released as shareware, with the option of buying the full version of the game. The full version had a level editor, which I very much wanted. Unfortunately the full version of the game became impossible to find, the rights to the game were sold to a Japanese company who were originally going to do a console port of the game. Nothing came of it, and aside from the lite version of the game, it was seemingly lost.

This meant a bit of creative reverse engineering was required. First things first was to get the game running. Basilisk II would be the ideal starting point for that, being a 68k Mac emulator.

I spent a good while pouring through the games resources. There looked to be a way to enable the in-game level editor through crafty resource hacking, but this proved to be false. Even though I could get the menu entries to appear they were entirely non-functional. Taking a look through the disassembled code, I’d have to conclude that the code is entirely missing.

My next idea was to reverse engineer the level file format, so I could replace the levels in the game manually. The levels were all storeed as blev resources in the Blobbo game. The game level data looked like the following:

7fff 0000 0000 0000 0000 0000 0000 bbfe
1333 3126 0686 7353 547b b8b8 b898 9d5d
9d66 6668 e8c8 c8c8 4868 68e8 e8e8 c8c4
e4e4 24da fafa fa06 2624 2404 c638 383a
1a19 39c7 c7c4 4464 644c b7b7 bc94 94bc
bc9c 93b3 b393 9393 b34a 4a40 68e8 c0c0

The first 15 bytes in each level were all the same. The remainder of the data had to be the level layout. In my mind I was expecting the level to be a grid of tiles, with each number corresponding to a tile type. At first glance this didn’t appear to be the case. Each tile had a seemingly random value in it’s place, with no obviously repeated values.

What followed was a (slightly painful) debugging session where I single stepped through the game startup and watched the level data get loaded and decoded. Before long I had figured out how the level data was encoded.

The level loading process appeared to be the following:

  1. Load the raw level data from the blev section of the resource fork
  2. Skip the first 15 bytes
  3. Iterate through the remainder of the data
  4. Take the byte, xor it with the next byte of the data and store it

I whipped up a quick-and-dirty C routine to unwrap this first layer of encoding around the level data. It assumes source is a C-style array containing the full level data, including the first 15 bytes of preamble.

unsigned char *encrypted = &source[16];
unsigned char encode = source[15];
unsigned char *unencrypted = new unsigned char[length];
size_t length_packed = length - 16;
for(int i = 0; i < length_packed; i++) {
	unencrypted[i] = encrypted[i] ^ encode;
	encode = encrypted[i];

During my investigation, I found the level data was passed through a Mac toolbox function called UnpackBits after being decoded. This seemed to be a simple RLE style compression scheme.

After decoding it quickly became apparent how the level data was arranged. The level data is stored a simple 32x20 two-dimensional array of tiles.

I’ve made my work available online through my Github account. You can find it at https://github.com/ucosty/blobbo. There are currently two applications in that repository, one two decode the level data, and another to view Blobbo levels.