Abstract
Problem: A company needed serious changes to a shipped game — new mechanics, artwork, and graphics modes (EGA/VGA) — but had lost the source code to their patches, leaving only the original unpatched source and the compiled patched executable.
Approach: Rather than re-implementing all patch fixes from scratch in the original source, Tim Cain proposed directly hex-editing the patched executable — modifying the compiled binary by hand using an Emacs-based hex editor and his knowledge of 8086 assembly.
Findings: The approach worked. He reverse-engineered the game's custom compression algorithm to build an art pipeline, added new graphics resolutions, rewrote game mechanics, and shipped a complete "new" game — all without writing a single line of high-level language code.
Key insight: Tim was proud of the technical achievement but disliked the game itself, so he deliberately kept his name out of the credits — a rare case of an uncredited developer by choice, not by oversight.
The Setup
In the 1990s, a company approached Tim Cain with an unusual request. They had a shipped game that had already gone through two patches (one quite extensive), and now wanted to release it as an essentially new product with a new title. The requirements were:
- New game mechanics
- New artwork
- New graphics resolution support (upgrading from CGA to include EGA and VGA modes)
The catch: they had lost the source code to both patches. They had the original base game source archived, but not the patched versions. There was no bug list either — only the public-facing patch notes that shipped to customers.
The Hex Editing Proposal
The company expected Tim to take the base source code and manually re-fix every bug from both patches using only the patch notes as a guide. Tim proposed an alternative: directly hex-editing the patched executable.
This meant opening the compiled .exe file in a binary/hex editor and modifying the machine code by hand. Some people at the company doubted it was possible; others doubted it could be done in a reasonable timeframe. They compromised: Tim got a couple of weeks to prove the approach.
His tools were simple:
- An Emacs-based hex editor (Tim was firmly in the Emacs camp — "the VI people were crazy and I think they drank human blood")
- His knowledge of 8086 assembly language
Reverse-Engineering the Compression
The first major challenge was the art pipeline. Tim needed to get new artwork into the game for the higher-resolution graphics modes, but the game stored art in a custom compressed format — and the tool for converting artist-provided art into that format was lost along with the patch source.
Tim's solution was methodical:
- Found the decompression routine in the assembly code
- Traced through it to understand exactly what it did
- Identified it as a custom form of run-length encoding (RLE)
- Reverse-engineered a compression algorithm from the decompression code
- Wrote a new tool that could read standard art formats (LBM/Deluxe Paint) and output the game's proprietary compressed format
This was necessary because the game shipped on floppies — storing uncompressed art for three resolution modes simply wouldn't fit.
The Editing Technique
Tim's approach to modifying the binary had a consistent pattern:
- When he needed to replace functionality, he would jump from the beginning of the old code block to the end of the executable, write new assembly code there, then jump back
- The old code remained in place but was never executed — dead code left intentionally
- Sometimes he simply overwrote code with NOPs (null operations)
- He acknowledged the dead code was messy but pragmatic: "I was running out of time... I didn't have time for this"
The Result
After several weeks of work, Tim delivered a complete new game:
- New title screen and menus
- Three graphics modes (CGA, EGA, VGA) with resolution selection defaulting to CGA
- New artwork for each resolution
- Modified game mechanics
- All previous patch bug fixes preserved (since he worked from the already-patched binary)
The moment he could demo the new title screen in higher resolution with better artwork, it "changed hearts and minds" — the stakeholders immediately saw it looked like a different game and gave full approval to continue.
QA confirmed all previously-patched bugs remained fixed. Tim introduced a couple of new bugs during his work, fixed those, and the game shipped.
Why No Credit
After all this technical achievement, Tim sat down to actually play the finished game — and didn't like it. It wasn't his genre, he had nothing to do with the original design, and he thought it was "a real stinker of a game."
So he simply didn't add his name to the credits in the executable. When the company offered to credit him (a VP personally asked "Are you sure?"), he declined and also asked them not to include his name in the printed manual.
Reflection
Tim still thinks about the game occasionally. He's proud of the technical work — building an entire game without writing a single line of high-level code, doing everything in assembly through a hex editor. But he's glad it's not in his portfolio. For the rest of his career, virtually no one knew he'd done it.
As he put it: "I'm proud of what I did, even if I'm not proud of the game."