Apple Panic

Apple Panic was one of the first arcade ports to reach the Apple II — and one of the first to ship with copy protection serious enough to defeat every nibble copier of its era. This project documents the full reverse engineering of that protection: how the disk was structured, how the loader worked, what it was hiding, and why it was so hard to copy.

What the protection does

The disk uses non-standard track geometry that no contemporary DOS 3.3 routine would read correctly. The loader that handles the first-stage read is itself encoded — the bytes on disk are not the bytes that execute. It decodes itself in place, reads the remaining tracks with a custom nibble routine, decompresses 45 KB of game data into memory, and then overwrites the loader with clean stack space before jumping to the game entry point.

By the time the game is running, every trace of the protection mechanism is gone.

What the research found

Working from a WOZ disk image and a full disassembly of the 8,800-line ApplePanic.asm source, the project traced every stage of the load sequence:

• The non-standard sector interleave and why it defeats DOS 3.3
• The self-modifying decode loop and the key byte that unlocks it
• The compression scheme — a simple but effective literal + run-length format — and the decompressor in the loaded code
• The exact memory layout at the moment the game starts

nibbler

The project produced nibbler, a WOZ disk analysis toolkit that reads, validates, and reports on arbitrary disk images at the nibble level. It was built specifically to study Apple Panic but handles any WOZ 2.0 image.

Articles

The full story is told across five articles in the Apple Panic series.