Protection Analysis

ONLINE > RECOLLECTION issue 2 Menu > Protection Analysis

Copy protection on the C64
by Pete Rittwage (of the C64 Preservation Project)
http://c64preservation.com

=====================================================
With extras by
Fungus, Antitrack & Ignorance of Nostalgia
http://nostalgia.c64.org
=====================================================

As we all know, many different protection methods were developed in the 1980's in a cat-and-mouse game with those that wanted to make a copy or remove the protection from a commercial C64 disk. My experience has been in exploring how the disk drive hardware was exploited by the publishers to keep you from being able to make a copy. The methods steadily increased in complexity from the release of the C64 until the early 90's, at which point the publishers seemed to give up on physical disk protection and started using manual or code lookups. Today, physical disk protection seems to have made a comeback on the CD/DVD format. (Arguably the most hard tries were done between 1985-1988 imho. With the exception of the "late" Timex v2 / v3 in the 90s. Your mileage may vary - Antitrack)

Here are the different methods in roughly the order in which they appeared on the scene, only to be cracked in hours by teenagers. (My longest crack still took three weeks, and three afternoons for "ZMC & the alien mindbenders" was pretty fair too imho. Toki (cartdrige) took three weeks for Legend. Besides that, well, most typical crack time was something like 5-15 hrs depending on the slow crunching time as well. At least back then. Thats why I had to do my "own" LZW-search-routines - Antitrack)


Intentional Bad Sectors / Disk Errors

This protection consists of a bad sector purposefully created somewhere on the disk. The loader would typically check it's existence by normal block-read commands. If the error isn't found, it's knows it's a copy and aborts. Typically used around 1982-1984.

In the beginning, there were no copy programs except Jim Butterfield's "DISK COPY/ALL" that came on the 1541 test/demo disk (Yes, DISK is misspelled that way on the original disk) (Ahem, not on any of my 18 or so original 1541 test demo disks - Fungus). This program could not reproduce these errors, and even if it could, it took *FOREVER* to copy disks. Like most protections, though- it only foiled casual copiers. Clever crackers early on figured out how to scan an original disk for these errors and the methods for recreating the errors were not difficult. Most of these methods were examined and made available to the general public through the book "Inside Commodore Dos" which included type in programs to recreate nearly any disk error. (There was another very early book featuring the study of copy protection schemes. It was called the "Copy protection handbook" by two authors, it appeared around 1983, and hypothesized about creating readerrors and illegal ID errors and even different densities. Pretty far out for such an old book. Kudos to the authors for being so early on disk drive programming. The other very good book was "Anti cracker book" in German by Publisher "Data Becker" - Antitrack). The package also included a disk and file copyer, error scanner, and some other small examples. Soon after, more sophisticated copy programs came out that could detect and reproduce these errors (such as Clone Machine or Mr Nybble) which marked the end of this era. Most higher-profile publishers of disk software only used this method through 1984.

This protection was easily removed by crackers by searching the code for the block-read commands and removing them. Some later titles also ran rolling checksums of the block-read code and would abort if you modified them, so the checksum routines had to be found and removed also. Early games from Activision and countless others used this method. In Europe, Ocean used this protection well up into the 90's!

Many publishers started combining encryption and other obfuscation techniques with the error protection in order to make the protection more difficult for the crackers. In addition they began using the CBM80 cartridge autostart routine to stop people from using HESMON and other cartridge based monitors from being used. (That never worked though, for if you switched on the cart it had "automatic" priority over the RAM-version of the CBM80 routine, and besides that, if you have Dolphindos or any other speeder, they can ignore this autostart stuff. This is also how to crack cart games in the beginning - Antitrack)


Fat Tracks

This protection involves placing a track on the disk that is actually 2 tracks (4 half-tracks) wide. This has two effects. The first is that one track is invalid because Commodore DOS stores the track number as part of the track header, which is now for the wrong (previous) track. Secondly, these tracks are perfectly aligned on the disk since they were written at the same time (or perhaps just with exact skew alignment).

The protection is checked by the program by stepping the head up and down between these 2 tracks and the half-track between them while reading the whole time. Normally, a half-track will contain a garbled combination of it's neighbouring tracks. However, since these two tracks are now identical and aligned, this track should contain the same data as both of it's neighbours. If it doesn't, it knows it's a copy.

Electronic Arts used this protection from about 1983-1986 (together with their 22-block "Pirateslayer" boot-loader which is really a little bit nasty, for he's overloading himself several times etc) and Activision used a tougher variant of it called "XEMAG 2.0" for many years. Removing these protections is trivial, as EA and Activision never changed the routines much between titles. (Well. Fixing one byte in the drive routine is trivial. Yes. Doing a nice crack, with levelpacking etc. isn't so trivial anymore, for the EOA loader can do pretty complex things too (loading single sectors instead of files etc) - Antitrack) Once you cracked one game, you could crack most all of them using the same method. Electronic Arts also made some effort to make tracing the loader a very long process by using p-code and run time modified indirect jumps. (P-code? I never saw one. I "only" saw 16 eors with timers and pretty heavy use of 'weird' locations like 0000-0300, ea00-0000 for 'weird' loaders, etc. About "run time jumps", well, thats the oldest trick in biz, so as a cracker you have to expect just that - Antitrack)


Half Tracks

The 1541 disk drive can write to about 41-42 tracks on a disk, even through CBM DOS only used 35 of them. The drive head motor could actually step to 82-84 different areas on the disk, so it would step twice for each track. Because of this, it was of course possible to read and write to the usually skipped "half-tracks" if you weren't worried about storing any data on the normal tracks. This would foil copy programs because they didn't search for and copy these half-tracks by default, so they instead got garbled, invalid mixes of the "real" data when trying to read them. Copiers later came out that could apparently scan for and detect these and copy them properly, I have not yet run into any disks which are known to use half-tracks out of around 2,500 originals, so please send them to me if you suspect one.

Removing this protection would involve decoding the loader that read the data from the half-track, recreating it on a normal track and modifiying the loader to read a real track and not a half track.


Extra Tracks

This protection simply relies on using disk tracks beyond the standard 35. Normally, copy programs default to copying only tracks 1-35, so these are missed. The most likely reason is that they would typically have trouble recognizing these normally unformatted tracks and lock/crash. Sometimes these tracks contained actual DOS-formatted data, but usually they were just "key" tracks. They could sometimes be nibbled, other times they could not, because they were combined with other protections.

Removing this protection involves finding the code that searches for this extra data and disabling it. If there is actual program data stored there then it would have to be relocated to a normal track (usually on another side, becuase a normal formatted disk can not hold the extra data) and the loader changed to reflect this.

Extra tracks were most prominently used by the GMA/SecuriSpeed loader, which appears on most Firebird, Domark, Hewson, and Electric Dreams releases. It was also used by some Sega, System 3, Mirrorsoft, and other titles in the form of "Para-Protect" which stored data on track 40. Many other protections also use extra tracks, Rapidlok (Accolade and others), V-Max (all versions), Pirate Slayer (all versions, which is EA), Keydos (Activision), Prodos (Also EA), Vorpal (Epyx), and many later protections in the European market of the 1990's (Hureka Sprint and Timex as well as more simple track/sector loaders). (Heureka Sprint is just a variation on Vorpal, which does superfast loading by having its own version of GCR encoding which can be decoded on the fly but wasting diskspace. Timex never used an extra track IMHO but always used a GCR-0-byte plus mark on track 18 sector 18 - Antitrack)


Alternative Bit Rates

To store extra data on the disk, Commodore designed their DOS so that the bit rate is higher on the outer tracks and lower on the inner tracks. Some disks were protected by ignoring this standard bit rate. Copiers later came out that would scan for the correct density and these disks could be copied that way. I have seen disks where standard DOS sectors were still used at different bit rates, as well as disks that have their own custom DOS. (You can also switch density rates right in the middle of the track, or between the start of sectors (more common) - Antitrack)

To remove this protection, the loader and data from these tracks has to be decoded and changed to use normal file loading. This was used as part of the protection by Rapidlok (Accolade, Avantage) and V-MAX (Cinemaware, Taito) titles.


Gap Protection (Hidden data)

In between all headers and data sectors on a track, there is some slack space called the "gap". When a disk is copied, the data in these gaps is not copied, but is reproduced according to the copying program used, sector-by-sector. Most would commonly just fill this space with "inert" bytes, which means just a space/timing filler that is ignored by DOS. [%0101010101 bytes e.g. $55 ; this is needed to adjust for the disk, for there are hardly two disks which carry exactly the same amount of bytes per track. that varies due to disk quality - Antitrack] There are some protections that check for specific bytes here, or even the length of the gaps, and know they're a copy if they are different or missing. This protection can only be copied with hardware solutions that either extend the RAM in the drive or add a parallel port so it can read and write the entire track in one pass. (Turbo nibbler 4 can copy it too, unless he isn't fooled by "other circumstances" altogether (i.e. too many syncs, etc - Antitrack)

To remove the protection, the loader must be decoded and the check for the gap data removed. This was used on tons of titles, including many popular Epyx titles in the US, such as Summer Games II, Winter Games, World Games, etc. as part of the original "Vorpal" loader. This is probably the most widely used method to protect disks on the C64.






Long Sectors

Commodore drives have only 2K of RAM and can't fit an entire track's worth of data in RAM in one disk revolution, so it must be read as individual sectors by the copy program. So, if you create a sector longer than will fit in 2K of RAM, it can't be copied with a normal 1541 since the data would be broken up. These tracks/sectors can be copied with hardware solutions that either extend the RAM in the drive or add a parallel port so it can read and write the entire track in one pass. (or the nibble copy partially reads data from the sync mark on, and at the second time of reading, after sending all data to c64, it "knows" it must skip "so and so many" GCR bytes and then reads and sends these GCR bytes, until the whole track is finished. Of course, this can be fooled too - Antitrack)

These sectors often contained data important to the program, so to remove this protection you must decode the loader and recreate it all in standard sectors. (FILES! not sectors. Well yes you can do it on standard "sectors" too, e.g. on "Red Storm Rising", only because the format of the disk is SO SIMILAR to the real format of normal disks, all that was done was to eliminate one sync mark - Antitrack) This protection is used by some later titles, and early example being Datasoft's Conan, and later most V-MAX! protected titles from Cinemaware, Taito, and others. (I remember Defender of the Crown, V-Max: The copy protection involved tracks without "efficient" sync marks. The 1541 searched for "something else" but not for the syncs, which were there only to fool the copy program anyway. The "syncless" track was then decoded and resulted into a "normal" track loader - Antitrack)






Custom Formats

These are really an alternative form of the long sectors trick above, but they also entail changing the way that GCR is interpreted. If you write your own DOS, you can use your own disk format entirely, ignoring common sync, gap, header, and data conventions altogether and use whatever you want. This also neatly describes all Vorpal, V-Max, etc. tricks altogether. You only have to adhere to the hardware limitations of sync detection and no more than two '0' bits in a row, but even that didn't stop later innovations. However, you can even ignore syncs, as was done on V-Max in Defender of the Crown.

These protections were some of the hardest to remove, causing the cracker to decode and figure out how to read the data from the original disk (V-Max NTSC even impossible to read on an PAL 1541), then rewrite the entire loading/saving functions in the game to put it on a standard disk with standard files. Most programmers that went this far to protect their disks also covered their tracks with encryption, timing checks, checksums, and all sorts of pitfalls to foil us. Many companies used this method past 1985 or so, with one of the firsts ones out of the gate, Datasoft's Conan. Rapidlok and later V-max also use a custom encoding scheme.


Long Tracks

Normal drives spin at 300rpm and can "write" data at the highest density up to about 7700 GCR-encoded bytes per track. However, the drive can "read" more than that, within some margin of error depending on motor speed. Some protections took advantage of this and put more data on the track than could be written back out at 300rpm, making it difficult to copy. These couldn't be copied with software nibblers, and even hardware-assisted nibblers would "trim" the data in as non-destructive way as possible (reducing sync length and gaps) to fit the data on a track. It was also possible to slow down the disk drive during writing, but usually these disks relied on a combination of other protections as well.

A good example of this is Harald Seeley's "V-MAX!" mentioned above and used on many highly sought after titles from Cinemaware, Taito, and later Epyx's last Vorpal protection as used in California Games and other titles. To remove this heavy protection, you must decode the loader and recreate it all in standard DOS format.


Sync Counting/Gap Counting

A sync mark must be at least ten '1' bits long to signal the drive hardware that it's about to see GCR data. However, sync marks are usually much longer than this (40 bits) and have no limit to their length. When copying a disk, sync has to be reproduced rather than copied, since it is more like a "signal" than actual data stored on the disk exactly. For this reason, the length of a sync is also somewhat dependent on drive speed and will vary a little. Some protections count on this and measure the length of the syncs, or the occurrences of sync on a track, to see if they match, and know they're a copy if they don't. (I don't think it will really vary. You can use a timer inside the 1541 and check how many cycles were wasted since the start of the SYNC, and then you know the length of the sync from the timer chip. This was hardly being used by any nibbler though, which is a shame - Antitrack)

Microprose used this method on some titles, and in fact "trimming" the sync will fail the protection checks on a copy. To remove it, the loader must be decoded and rewritten (replaced by a normal DOS loader).

V-max on some versions and a few one off protections also use a gap counting method, to check the number of gap bytes in a specified area of the disk. Usually this is between the last sector of the track and the first (not always the last gap is checked).






Track Synchronization or Skew Alignment

Commodore drives do not use index hole detection, so lining the tracks back up when writing a disk is nearly impossible. Since disks weren't usually mastered with a 1541, but rather with machines that could do track sync based on the index hole, protections took advantage of this in different ways. They would move to a half-track or the next track in the middle of reading to see if the data that should be there exists. If it doesn't arrive in time, it knows it's a copy. (there is another trick mentioned in the German mag 64er. You can measure the angular difference between three tracks. You search for a special GCR-mark on the track, you move one track ahead, also check for special GCR mark, read timer, and repeat this procedure 3 times. Thus you have 3 timer values. Their quotient must always be the same i.e timer1/timer2/timer3 must be a constant. If it isnt, you know that the angle between the GCR-marks is incorrect and thus its a copy - Antitrack)

Removing this protection requires finding and removing the check for track alignment, but most often this was only part of the picture. Most of the venerable Rapidlok protected games (Accolade, Avantage) used this as well as a bad of other dirty tricks to prevent copying. To remove it, the loader and all data must be decoded and rewritten. This was also used on a few V-max protection games from Game*Star (Activision).


Weak Bits / Unformatted Data

When a Commodore disk drive reads more than two '0' bits in a row, it clocks in a random '1' bit occasionally and can lose framing, which is like bit-shifting the data in real time. Single occurrences of this sequence won't always cause framing loss, but too many in a row will cause the drive to return "random" bytes until it sees the next real '1' bit. Most copiers can't detect or duplicate this, so protections checked a byte somewhere in this weak area and if it reads the same thing over and over, it knows it's a copy.

This protection is used in some form by:
* Microprose
* Datasoft (Bruce Lee, The Goonies, Mr. Do!)
* Rainbow Arts, Time Warp, Gremlin, and Magic Bytes in the form of RADWAR/BETASKIP. Yes, the RADWAR cracking group created a copy protection. Which is better known as TIMEX. :)
* U.S. Gold and many other publishers in the form of what we call the CYAN loader. This is due to the way in which it crashes when the protection check fails.

The protection is usually used in conjunction with others, but to remove it you must disassemble the loader and remove the check for it (and you should always try to convert the data to normal DOS files anyway).


Signature (Key) Tracks

This protection revolves around a track being mastered in a non-standard way. It can be all sync '1' bits (which we call a 'sync-killer' track), unformatted (or all '0' bits), filled completely with some other byte, or filled a special byte sequence and then a key like EA's PirateSlayer and Prodos (Nearly all EA games from 1985 onwards), or a combination of all of these like Keydos from Activision (Predator, Grave Yardage, Rampage etc).

These tracks generally foil most all copy programs because they either cannot handle all or long sequences of '1' or all '0' bits, or they are just read incorrectly/out of framing. To remove the protection, you must decode the loader and remove the check for the key.


No SYNC (or extremely short sync)

The meanest protection that came about used tracks on the disk that had *no* sync marks. Most copiers cannot read these tracks and most times think they're empty. The later Vorpal uses this, which was released on California Games, The Games Winter and Summer Editions, etc. Late V-MAX protected titles had extremely short syncs (only 10 bits) which would be missed by a normal BIT/BVC check for sync, due to a 5-cycle CPU jitter in the CBM drive design.

To remove this protection, the data must be read with the routines from the copy protection and you have to save all data to file. Then you must replace the original loader with a normal file loader.

Signed,

Peter Rittwage
C64 Preservation Project



On some further notes, many games combined several of these protections. And also added things like p-code, obfuscation / encryption / decryption (timer or otherwise), embedded checks inside this kind of code, runtime overloading (overloading the running code with different code), compression techniques, length of load time checks, and many other tricks. All of these things, of course making the removal of the protection even more difficult and should be included in the protection descriptions. Since many of these techniques are combined with the actual disk protection itself in order to create a more solid protection. They also combined more than 1 loader using 2 different disk formats on the same title and swapping between loaders when needed. Some even split data of different files in the SAME sectors, so each sector could contain data from one or many files.

I thought I'd also mention a few of the more difficult games to crack.

Star Rank Boxing - V-max V1 custom, Harald Seeley and Alien Technologies, the entire game is converted to p-code with embedded track to track alignment checks which run randomly through the game. (p-code? really? its in basic? I don't know! - Antitrack)

Pirate Slayer and Prodos Games, one of the most difficult set of loaders due to their overloading of themselves several times and timer encryption, as well as cartridge checks for things like Action Replay (before they existed no less). Arctic Fox, Legacy Of The Ancients, Skate or Die, Ski or Die, The Bards Tale, etc.

Take Down Wrestling - V-max 1 custom again, normal V-max with the nastyest timer encrypted code. It runs simultanious decryptions loops on the C64 and 1541 and swap data over the serial buss to decode each other, on the fly. This decryption also lasts for a whopping 30 seconds or so REAL TIME.

Datasoft Games, Conan, Goonies. Excellent encryption routines, using stack and other low memory encryption/decryption techniques in sections. As well as either long sectors or weak bit protections.

Gordian Tomb - a Timex title, run time encryption and decryption on the fly again, as well as custom sectors.

Riddles & Stones - Runtime en- and decryption of the code and checking a particular Sector on disk if it?s a copy.






Rubicon - Rubicon's protection is an interesting story as the protected version of Rubicon has never been cracked. It used a very special "bad sector" on the disk. It was changing the speed of the rotating floppy disk and also de-justed the binary reading of the floppy header. This combination during the read operation made it impossible for any type of copy program such as Burst Nibbler to copy the disk. A manual re-sync with just three bytes "SKY" (abbreviation for Snacky, who did the protection) were then verified.

Also added were countless checks for the protection at the start and in the game; just the "Ending" of Rubicon alone, meaning the demo you saw once you finished the game, was protected by more that 20 different routines that verified each other. Changing or removing one routine would end up in a crash later one. The beginning of Rubicon was protected by a modded version of the Timex V3 system. Improvements were done to the third version of Timex by closing the "attack points" that flawed the protection. The tape protection for Rubicon was also vicious. Again Timex V3 was used in conjunction with a 256 block file load. Meaning that the complete memory was used by loading a file that filled up everything. During the load, the loader was modified to incorporate the Timex system.

Paperback Writer - which is not a game but a word processor. It has a custom disk format with one sync per track only, but Burstnibbler 1.8 / 1.9 can handle it. What made it so "special" was there was so many decoding loops and weird programming until "finally" the loading of the main program started. I think I counted over 100 simple, but efficient decoding loops. There were also many timer and even sound chip checks in the middle of the program e.g. when printing something. The same Canadian dude also later did the copy protection for the Amiga game "Dragon's Lair", which was not cracked for many months.

There is of course many more, but if anyone happens to want to see how difficult cracking on the c64 can get, these are the games to be looking at.






Cartridge Protection (Antitrack)

Normal Carts simply consist of ROM memory between 8000-9fff, or 8000-Bfff. These appeared around 1983 first (Commodore Soccer, Jupiter Lander etc.?)

How to "crack" them is always the same: Switch off the 64, switch to Dolphin Dos, insert cart, press SPACE while switching on the 64, and voila! There goes the ROM memory, which simply can be saved to file. Most programs don't need the RAM memory under the ROM memory and thus the same RAM area can be loaded from file and started just by pressing Reset or Restore. Ocean thought it would be cool to provide games on cart, and supposed these automatically became "uncrackable". A switch register at $DF01 provided a bank switch between lots of possible ROM data between $8000-$9fff, thereby enabling the option to "load" more data from ROM. A copy loop would imitate loading and simply copy the ROM to RAM. Which however means, you don't really NEED the ROM area for playing the game.

"Shadow of the Beast" had just this very conceptional flaw - it did not really "need" the ROM area, you can store all data to the RAM area "below" the ROM at the same adress, replace the "loader" with a normal file loader, and the game happily works. It's really that simple. The only trick was to find enough RAM memory for your own disk loading system.

Ocean Software, however, found out about it, and when they released TOKI, the whole game needed almost all RAM memory from the 64 as well as the darned ROM area at $8000-$9fff. Thus, Legend's work was to rewrite the entire game; RAM was gained by removing the music altogether; the music routine curiously wasted a lot of RAM memory, almost in the size of a typical ROM cart memory, perhaps deliberately.

It took Legend three weeks to reprogram and relocate the entire game, so it would use RAM instead of ROM and normal files instead of copied ROM memory, but they succeeded. After that, Ocean Software possibly gave up on cartridge protection. :-)

Much respect to the original crackers of the scene, who did this stuff armed with little more than sector editors, printed dissassemblies, Ram expansions for the disk drive/C64 and HESMON cartridges, you guys really deserve it.