Rapidlok info by Pete Rittwage

Rapidlok

Last Updated on 4/4/2010 by Pete Rittwage

According to the different copiers/patchers for this that existed are at least 7 different versions (plus variants) of this protection. There are multiple protection schemes all going on at once. Since this protection relies on exact sync lengths and contains bad GCR in the gaps, the disks seem to deteriorate quickly over the years. Many of my originals will not load any more, and the ones that do are erratic.

1) First, all tracks start with a sync mark about 320 bits long. Then, sector 0 has a sync about 480 bits long before it's header. If it isn't around this length, that track or sector won't load and you get a crash, so drive speed is an issue with this protection. All other syncs seem to be the standard 40 bits. It is very difficult to read/detect and write exact sync lengths due to drive speed differences and limitations of the 1541 hardware, but we should be able to get close enough to pass this part, which we can.

2) Each gap has bad GCR ($00) instead of the inert bytes we normally see. It has been found that these are not checked..

3) There is a key encoded on track 36. The key consists of a long sync, a series of encoded bytes, then some bad GCR. This track can be (carefully) reimaged.

4) If the key is properly loaded and decrypted from track 36, it corresponds to a table of 35 values that are the number of $7B bytes (this varies) expected to be in a special "sector" on each track.
4) It just has "time-bomb hooks" or add-ons that execute checksums, key checks, and track alignment at random times in the game to prevent patching.

---

News!

Banguibob has completely documented this protection and solved all remaining mysteries.
Check it out here!

Rapidlok remains one of the few remaining protections we can't get to run without partially cracking them, unfortunately. This may change in the future, though. Whoever wrote this protection, please stand up and tell us the history, because you win. :)

All versions load a key from track 36. This boots in VICE sometimes (bitshift) and on the real thing almost always if mastered properly. The key check when loaded checks a hidden "sector" on each track and counts the number of key bytes found. You get the black screen if this fails. I can patch this part out easily and it's what the software-based Rapidlok copiers all did back in the 80's. VICE cannot "autoload" these disks, they must be loaded manually. If you remaster these disks, your drive must run at 300rpm nearly exactly, and even then they are a little flaky.

I have different mastering runs of the same games with different versions of the protections, sometimes from the same region, so keep sending them if you have them. You can convert to G64 and run them through the tools to check what RL version they are and remove the keys. (I used the old Utilities Unlimited tool, email me if you need it)

v1-v4 : Patch out keycheck and they work fine. There doesn't seem to be a sync check except for Conflict in Vietnam, which checks sync between track 34/35.

v5-v6 : Patch out key check and they "usually" load in VICE. These disks will intermittently fail the add-on protection checks, depending on the title. Reset and reload and it usually runs fine- I attribute this to the VICE drive emulation not really being at "virtual 300rpm". A few do not pass ever and I suspect they might be bad dumps or just are variants that aren't patchable by normal tools.

v7? : Patch out key check and they won't boot - need to crack further for other self-checksums.

Protection schemes of this later era are far too complex for me to describe in any real detail in an accessible article like this one, much less explain how people went about cracking them. I would, however, like to very briefly introduce RapidLok, the most popular of the turnkey systems on the Commodore 64. It was the product of a small company called the Dane Final Agency, and was used in its various versions by quite a number of prominent publishers from early 1986 on, including MicroProse. You’ll find it on that first bona fide Sid Meier classic, the ironically-titled-for-our-purposes Pirates!, along with all of their other later Commodore 64 games.

The protection schemes we’ve already seen have modified their platforms’ standard disk formats to confuse copy programs. RapidLok goes to the next level by implementing its own custom format from scratch. A standard Commodore 64 disk has 17 to 21 sectors per track, depending on where the track is located; a RapidLok disk has 11 or 12 much larger sectors, with the details of how those sectors organize their data likewise re-imagined. Rapidlok also adds a track to the standard 35, shoved off past the part of the disk that is normally read from or written to. This 36th track serves as an encrypted checksum store for all of the other tracks. If any track fails the checksum check — indicating it’s been modified from the original — the system immediately halts.

Like any protection scheme, RapidLok must provide a gate to its walled garden, an area of the disk formatted normally so that the computer can boot the game in the first place. Further, writing to RapidLok-formatted tracks isn’t practical. The computer would need to recalculate the checksum for the track as a whole, encrypt it, and rewrite that portion to the checksum store out past the normally accessible part of the disk — a far too demanding task for a little Commodore 64. For these reasons, Rapidlok disks are hybrids, partially formatted as standard disks and partially in the protected format. Figure 5 below shows the first disk of Pirates! viewed with a contemporary copying utility.

Figure 5

As the existence of such a tool will attest, techniques did exist to analyze and copy RapidLok disks in their heyday. Among the crackers, Mitch of Eagle Soft was known as the RapidLok master; it’s his vintage crack of Pirates! and many other RapidLok-protected games that you’ll find floating around the disk-image archives today. Yet even those cracks, masterful as they were, were forced to strip out a real advantage that RapidLok gave to the ordinary player, that was in fact the source of the first part of its name: its custom disk format was much faster to read from than the standard, by a factor of five or six. Pirates who chose to do their plundering via Mitch’s cracked version of Pirates! would have to be very patient criminals.

But balanced against the one great advantage of RapidLok for the legitimate user was at least one major disadvantage beyond even the obvious one of not being able to make a backup copy. In manipulating the Commodore 64 disk drive in ways its designers had never intended, RapidLok put a lot of stress on the hardware. Drives that were presumably just slightly out of adjustment, but that nevertheless did everything else with aplomb, proved unable to load RapidLok disks, or, almost worse, failed intermittently in the middle of game sessions (seemingly always just after you’d scored that big Silver Train robbery in the case of Pirates!, of course). And, still worse from the standpoint of MicroProse’s customer relations, a persistent if unproven belief arose that RapidLok was actually damaging disk drives, throwing them out of alignment through its radical operations. It certainly didn’t sound good in action, producing a chattering and general caterwauling and shaking the drive so badly one wondered if it was going to walk right off the desktop one day.

The belief, quite probably unfounded though it was, that MicroProse and other publishers were casually destroying their customers’ expensive hardware in the name of protecting their own interests only fueled the flames of mistrust between publisher and consumer that so much of the SPA’s rhetoric had done so much to ignite. RapidLok undoubtedly did its job in preventing a good number of people from copying MicroProse games. A fair number of them probably even went out and bought the games for themselves as an alternative. Whether those sales were worth the damage it did to MicroProse’s relations with their loyal customers is a question with a less certain answer.