Classic Computer Magazine Archive CREATIVE COMPUTING VOL. 9, NO. 7 / JULY 1983 / PAGE 130

A layman's guide to disk protection. Phillip Tubb.

My company, ALF Products, is one of the few copying services in the U.S. for Apple-compatible floppy disks. Since I started this service, I have talked to several companies about the advantages and disadvantages of "copy-protected" or "copy-resistant" disk formats. And since ALF started advertising the copying service, mentioning our ability to copy disks with modified formats, several people have called asking if we can make back-up copies of copy resistant disks for them.

Our service is primarily mass duplication (at least 50 and up to several thousand of each disk) for software houses and peripheral manufacturers, so we can't help these individuals; but in talking with them I have picked up quite a bit of information.

I think we are all familiar with the customer's desire for software that can be backed up, thus providing him with lifetime access to the software. And we are equally familiar with the software companies' desire for software that isn't so easy to pirate.

So I'd like to touch on two other aspects of copy-resistant disks: the technical side, and some future marketing aspects. Since I am familiar only with disks compatible with the Apple computer, keep in mind that only some of this information will apply to other systems. Technical Background

The Apple computer is well suited to copy-resistant disk formats. Those who aren't familiar with disk technology ask "If my Apple can read the disk, why can't my Apple Copy program copy it?"

The Apple disk drive design is rather simple, with most of the work being done by the software. The hardware allows a program to write a byte (eight bits) of data onto the disk, to read a byte from the disk, to turn the motor on and off, to position the read/write head at various places on the disk, and to select Drive 1 or Drive 2.

Because of certain technical aspects of magnetic recording, all bytes written to or read from the disk have a most significant bit of one, and no byte can have two or more zeros in a row with the 13-sector controller or three or more zeros in a row with the 16-sector controller.

Bytes are written to and read from the disk at a set rate which is hardware controlled and thus unchangeable (with one small exception). Since the disk makes one full rotation in 1/5th of a second (give or take some for motor speed variations), only a certain number of bytes can be written on a track (a track is one circle around the disk during which the read/write head remains the same distance from the center). Within these capabilities/limitations, the task of the software is to take a certain number of data bytes, normal bytes in which the most significant bit may be either a zero or a one and in which there may be up to eight zeros in a row, and write them onto the disk using the special bytes just described in such a fashion that they can later be read off the disk and re-assembled in the original bytes.

Obviously, there are many, many ways to do this. The copy program Apple supplies with its disk drive is designed to work with one particular method. It will not copy disks which use any other method. Apple's drive controller card contains a small "boot-up" program in ROM which will read (and then run) a small program from a particular track on the disk if it is written in a particular fashion.

So, a certain number of bytes must be written onto this track in the Apple format or the disk will not boot. However, the small boot-up program on the disk can be any small program and still be compatible with the Apple ROM. Once loaded and running, this program can read the rest of the disk itself, and thus the remainder of the disk can be in any format.

If the Apple boot-up ROM can read this small program, so can any skilled programmer. He can then determine how it reads whatever it reads off the disk. Then he, too, can read whatever the program reads. By continuing to read and understand each program that is read off the disk, the programmer can eventually understand the entire disk format and know the data content of the disk.

Then he can modify the programs on the disk to function properly on a disk which is formatted in the standard way, thus creating a copy that can easily be copied. Or he can devise a program which will copy the entire disk, thus letting the programmer create as many copies as he desires, each of which is still as difficult to copy as the original. This process can take much longer than it would take simply to write the program from scratch, or it may take only a few minutes.

Preferable would be a scheme to copy the disk without being concerned about how it is formatted or how programs work with the disk. It would seem that a "disk duplicator" could be built that would copy a disk as easily as a cassette tape duplicator seems to copy a tape. This never seems to work out. To understand why, let's consider a simple protection scheme.

On a standard Apple disk, data are written on 35 concentric circles called tracks; these tracks are numbered from 0 to 34 and are spaced about 1/48" apart. The solid lines in Figure 1 show a few of these tracks. Since the head positioning mechanism in the drive can position the read/write head in 1/96" increments, the dotted lines show possible track positions which are not used. (Attempting to use 1/96" track spacing would cause adjacent tracks to be erased or modified each time a track was written.) Positioning the head to these track positions is easy; the only difficulty is reading and reproducing the data on each track. Drive Speed

Assuming the drive speed is exactly 300 rpm, there will be about 6378 bytes (special bytes, remember) of data. Now here is where the problems creep in.

When the disk to be copied is read, the number of bytes read will be the same as the number of bytes that were originally written. So if the drive was running, say, 1% fast when the disk was written there will be about 6314 bytes to read. Similarly, if it were running 1% slow, there would be 6442 bytes to read.

What then if the original drive was running 1% slow, and your drive is running 1% fast? How will you write 6442 bytes in 6314 bytes worth of time? You won't. Could the drive be adjusted to the same speed as the drive that wrote the original disk? No. To get the speeds within, say, one bit of each other would require an accuracy better than 0.002%, and drives normally vary more than ten times that amount from one revolution to the next, and well over 50 times that from one minute to the next, even under the best conditions.

The way this speed problem is overcome during normal copying is by varying the amount of unnecessary data scattered around the track and/or by putting a section of unnecessary data at one place on the track (where writing starts and stops). If the locations of these spots of data (or the location of one spot) are known, the drive speed is easily good enough to allow the track to be written while adding or removing only unnecessary data. In the Apple format, each of the 13 or 16 sectors is preceeded by a section of unnecessary data.

Since the object of easy copying is to eliminate the need to know anything about the contents of the particular disk being copied, the simplest programs written to copy copy-resistant disks are written on copy copy-resistant disks are written on the assumption that certain "clues" will be available concerning the location of unnecessary data. In the vast majority of cases, these areas are easily found using simple program algorithms.

A hex byte of FF is almost universally used for such areas, due to technical aspects of disk reading. However, the situation is complicated by the fact that the 13-sector controller can also read and write an 8-bit byte followed by a single zero bit, and the 16-sector controller can read and write an 8-bit byte followed by one or two zero bits. These zero bits are not present when the disk is read, except as an almost undetectable difference in read-back speed.

Several techniques are used to make it difficult to find any of these key spots, or to mislead a copy program into treating a section as unnecessary when, in fact, it is part of the ordinary data. A more effective technique is to use a special copying program that reads each track (or perhaps only a few tracks) after the copy is made, then modifies the program on the disk. When the user runs the program, it can check to see if the number of bytes on each track is the same as when the disk was originally written. If not, the copy is illegal, and the program can erase the disk (and ask you to insert various other disks you have on hand, slyly erasing each one).

It is difficult, then, to copy a track. I am often asked if an analog system could be used to connect the read head from one drive to the write head of another. The speed problems still apply (to some degree even when using the single spindle, dual hub drives) as does the question of when to start and stop writing. (When writing is stopped, a small amount of magnetic garbage occurs.)

But the question is rendered meaningless due to shifts which occur in the magnetic data. The data read from a disk are not exactly the same as the data written on the disk. The controller is designed to process the data read from the disk until it looks like the data written on it. If this processing is not done, or is done improperly because the exact format of the track is not known, the shifting effect may become so large that the controller will not be able to read the copy. Ways to Prevent Copying

Even assuming you could copy a track exactly, there are still ways to prevent copying. Figure 2 shows a popular scheme. You will notice that each track is still at least 1/48" away from every other track, but that they are not positioned at the same places as Apple tracks. Usually, fewer tracks are available on the disk when this scheme is used. Non-standard track spacings complicate copying disks even once you have a sufficiently versatile track-copying program running. However, it is obvious that the appropriate spacing can be deduced, or even found by trial and error.

Now examine Figure 3. This is a scheme I have come up with to defeat the track spacing detectives. Each track is still 1/48" away from any other track at any given point. However, in any given circle around the disk there is a track less than 1/48" away. This format cannot be copied using a full-track copy program even if it has variable spacing capabilities. It has the disadvantage of a lower total storage capacity, like most track spacing schemes, and it is difficult to make in the first place.

By now you have realized that anyone who understands how the system works can, with a little imagination, come up with new ways to defeat general purpose copy programs. Due to the high data rates involved (and thus the small amount of processor time available), very small effects can be used. I see no end to the battle between copy-resistant formats and special copy programs to defeat them.

In a general sense, any format for which the master disk is the same as the copies produced can be copied--a program like the program that did the copying in the first place will do. However, if the copy is different in some way from the master, it may be that no program can copy the disk unless the program on the disk is understood. An example of this is the program that, when run, checks each track to determine what the disk speed was when the copy was produced. Each copy will be different, because the speed during copying will vary at each revolution; and each program will be modified to function with the exact speed that occurred.

To sum up, a key question is "Can a program be developed that defeats all formats?" My answer is "no." While such a program (or a special machine) may, in fact, be possible, it seems very unlikely today. Future Marketing

I am suggesting that disks which the customer is unable to copy will continue to be possible. But will they remain practical? There is growing rebellion among consumers. Two factors strike me as important.

First, any program that can be written once can be written again. If you are annoyed that you can't copy VisiCalc (to pick just one example), so is someone else. And that someone else may be a programmer who sees writing VisiCalc as an afternoon's effort. Soon, WonderSoft is selling Opticalc which is not only copyable, but sells for $25 less! Are there big bucks to be made in writing programs (new programs, done from scratch) that have the same features as programs on copy-resistant disks, marketed on standard format disks? My guess is yes, and it is completely legal. Most people consider ethical as well, although some disagree.

Second, there is much talk about hard disks. In fact, there is such talk about several new storage devices. Many of these have fixed media but large capacity. If these become more popular, as many people are sure they will, floppy disks may increasingly be a convenient and inexpensive method for getting software from the vendor to the customer. But the customer will then want to transfer the program immediately to his MegaStore which is fast and convenient. How will the customer do this with copy-resistant disks? Probably by buying Opticalc from WonderSoft.

Records, cassettes, eight-tracks, radio and television broadcasts--all these are easily duplicated to the satisfaction of the listener/viewer. Yet these industries still exist, despite complaints that all are suffering greatly from illegal pirating. Perhaps it is time the software industry found out how they're doing it.