Al Capone Does My Shirts

Breaking Down One of the Most Famous Floppy Protection Schemes

Most people who hear about Al Capone Does My Shirts remember it as a cute reference to the movie, but in practice it was one of the most technically sophisticated copy protection systems ever shipped on 5¼-inch floppy for the Apple II. Broderbund put it in 1984, designed by Ron Civera, and it layered enough tricks together that cracking it took real effort at the time. I spent more hours than I care to admit reverse-engineering these things back in the late eighties and early nineties, so here is how it actually works. The core idea is not any single trick but a stack of them. The disk contains sectors formatted in ways that the standard DOS won't touch, bad sector markers placed deliberately where they should not be, and data arranged on tracks using non-standard bit densities. When you try to copy the disk with a normal utility like CopyII-plus or even DiskDoubler, the copy fails or produces a disk that runs but quickly encounters a check the game detects. The first layer most people hit is the bad sector trap. The disk contains intentionally corrupted sectors that return an error code when read through normal means. The protection code expects that error, then reads past the bad data to extract a value. If the sector was copied as a normal readable block, the checksum fails. You have to either preserve the exact error behavior or fake the error response when the protected program reads the disk.

The second layer involves variable track density. The Apple II floppy controller can read and write both FM and MFM depending on how the data is formatted, but standard copy tools do not let you control which mode applies to which track. Al Capone uses this to hide data on tracks that look empty or malformed to ordinary tools. The game itself includes custom disk I/O routines that bypass standard DOS calls and talk directly to the disk controller.

What It Feels Like When You Are Actually Trying to Make a Working Copy

Here is the practical side. You boot the original disk, drop into monitor, and start walking through the disk read routines to see which sectors are being accessed and what error codes they expect. That takes patience because the protection code scatters its checks across multiple routines and often stores flags in zero-page memory locations that change between reads. One thing nobody warns beginners about is that the Apple II Plus and the IIe behave differently on some of these checks. The IIe's ROM includes slightly different disk controller handling, and a patch that works perfectly on a II Plus can fail on an IIe because the timing of the interrupt response differs by a handful of cycles. I learned this the hard way when a cracked version ran fine on my II Plus but locked up the moment someone booted it on an IIe. The workaround was to detect the machine type in the patch and adjust the timing loops accordingly, adding about twelve cycles of NOP padding on the IIe path. Another thing that catches people out is the timer-based check. Some versions measure how long a read takes between two specific sectors. If the disk is being accessed through a emulator or a fast loader that buffers reads, the timing is too fast and the protection detects the discrepancy. You need a loader that does raw sector reads without any buffering, or you need to inject artificial delays into the critical section of the disk I/O routine.

Common Pitfalls When People Try to Replicate This

The biggest mistake I see is treating the protection as one monolithic block. It is not. Each check is independent, and fixing one breakage often unbreaks another in a way that is not obvious. People patch the bad sector handler, test, and declare victory, only to find the game crashes later on a memory check that was previously masked by the earlier error handling path. A second mistake is trying to copy the disk sector-by-sector with a tool that normalizes errors. Some utilities automatically skip bad sectors or replace them with zeros. That destroys the protection's expectation because the game reads those sectors and checks the exact error code, not the data content. You need a utility that preserves the raw sector structure including the error bytes, or you need to rebuild the bad sectors yourself with the correct CRC values and corrupted data patterns.

When This Protection Completely Fails

The honest limitation is that Al Capone Does My Shirts does not hold up well on modern hardware or accurate emulators that bypass the physical disk entirely. If the emulator presents a virtual disk image and the protection never actually talks to a floppy controller, most of the timing and bad-sector checks become irrelevant. Similarly, on hardware where the disk controller has been replaced or modified, the protection routines that depend on exact controller behavior will misfire. I ran into this with a community disk replacement project where the custom controller firmware changed the interrupt timing enough that the protection's delay loop counted wrong and triggered a false failure. The fix was to patch the game's check to accommodate the new interrupt latency, which meant understanding the original author's assumptions about cycle timing rather than just patching blindly. There is no single official download page for the protection source code since Broderbund never released it, but there are well-documented analysis papers and disassemblies floating around the retro computing scene. The Apple II History site has references, and the BreakPoint magazine archives from the mid-eighties contain discussions of the scheme. For practical purposes, most people working on this use a hex editor combined with Apple II monitor dumps and a tool like ADTPro to handle the raw sector reads and writes. The actual cracked version of the game itself is widely available in abandonware archives if you want to study the result, but the real value is in understanding how the layers interact rather than just taking a pre-cracked build. The protection is old, the hardware is obscure, and the techniques are largely academic now. But if you are trying to preserve software from that era or understand how copy protection evolved, this remains one of the better case studies for a multi-layer approach that was genuinely difficult to beat without detailed knowledge of the Apple II disk controller internals.