Protection Analysis II: Copy protections on tape
RECOLLECTION issue 3
By Tom Roger Skauen (SLC of Kvasigen)
Copy protections on tape is nowhere near as effective as the common copy protection on disk, but they still were enough to make the life harder for crackers. The weakest link in the tape protections is that you can, with the proper hifi deck or a special adapter for the C64, easily duplicate the tape in its whole. I have heard rumors about some originals having an extra frequency which throws off attempts with the hifi decks, but never seen such a tape myself. This would not work on the adapter for connecting two tape drives to the C64.
In Europe, most software was released on tape before on disk (if ever). So, tapes were not only cheaper and more easy to crack than disks, but also earlier. This made tapes the most attractive for most crackers. I won't bother going into detail on how to break these loaders here, as that has been covered by QED in another article for C= Hacking (I think). Instead I will mention a few ways the software companies used in order to prevent tampering with their software, and then trying to prevent someone from releasing their own versions of the games.
Since a tape deck is a pretty simple thing, you cannot be very creative with how you load the data. It needs to be loaded from point A to point B, unlike disk where you have all kind of nasty tricks like fat tracks, bad sectors, etc. One way of fighting this was by trying to obfuscate the loader code and do real time manipulation and even change its behaviour. Visiload (used by for example Mastertronic) being a very good example of this. So, why not let's start explaining a bit about that one.
Storing data in one full block
Visiload's structure is very odd. First of all, ALL data is stored in one single block. Meaning that there's no gap between files, they are just instantly overloaded if needed (for example loading pics). This means, since there is only a pilot signal at the start of the block. Pilot signals are used as a sync mark to know where data begins. As long as it's the start of a data block, it's not ABSOLUTELY necessary to have one, but most loaders do, probably because first bits of a block can be corrupted depending on what kind of methods used for mastering. Recognising the start of a new file inside such a block is close to impossible, though. This prevents modifying the loader for halting between each file to save off to either another tape or to disk (Many crackers made tools that did this for certain loader systems). Workarounds for this could be either dumping to a RAM Expansion Unit, or keep track of amount of blocks/files loaded when the C64s memory was, rewind tape, let it sync up again and count blocks/files until it was back at where it left). Another loader using the same technique is the Ocean/Imagine loader, but the loader is much easier to bring down. There are also others, but this article isn't ment to cover the specifics about different loading systems.
Relocating the loader
Let's go back to Visiload again, as Visiload also uses this nasty trick. It several times loads a new loader, either over itself or to another place in the memory. This is to prevent modifications of the original loader. If a modified loader is used, this will be overwritten with the original loader again and voiding the crackers work and plan about dumping the files to another media.
Obfuscating the data
Data can also be obfuscated in many ways to make it hard for a cracker to figure out what he just dumped. Once again, I would like to mention Visiload. Visiload doesn't encrypt data as many loaders does, but it's "randomly" reversing bit order and byte size. Visiload is probably the only loader I know that doesn't always loads 8 bits for one byte. This makes it crucial to find out what triggers changes in the loader. The only reasonable way to beat loaders like Visiload is probably to figure out what the loader does, then write one on your own which suits your needs. There are also other ways of obfuscating data. Loaders like Rack-It and Cyberload uses EOR to "encrypt" files, but EOR-value can usually be pulled from the loader as soon as you have busted it and it may not always be EOR-ed either. Another nifty way of doing this, is like one of the Gremlin loading systems. Data is first read into memory, and then the loader uses itself as a key to decrypt the data. Wildsave does something similar, but it loads backwards and does operation to each byte depending on what memory address it is loaded to.
Hardware checks
Quite a few loading systems also checks for certain hardware. Some loaders check for a disk drive, others try to detect a cartridge and some even both. If these are found, game often crash or freeze either while loading or after loaded. Some loaders (Cyberload being the only one I know, but likely to be more) also checks if memory has been zero filled. If certain memory areas is detected being zeroed out, loader will fail already on boot.
In the end, none of the tape systems is particularly hard to do as soon as you successfully bypass the auto start and have full control of what the loader does. In most cases, the loaders can be modified slightly to do the job and where that's not an option, there is nothing from stopping a cracker from writing his own loader as soon as he has the format figured out. Each loader's format rarely changes between games, and even between versions of the same system. Many loaders even uses the exact same block format. If you found this interesting and is up for a challenge, try cracking games using Visiload, Cyberload or Bleepload. That ought to keep you busy for some time... happy hacking.
