Part II: Low-Level Control over Hardware

The only good thing good about standards in computer science is that there are so many to choose from.

Folklore

Overview

The methods of interacting with hardware are numerous . Depending on the particular features of the problem to be solved and on those of the equipment itself, one of a number of control interfaces may be the most important. At the highest level of the interface hierarchy, there is the family of operating system API functions that carry out the basic input/output operations (for instance, opening a file, or reading data from a file). For most applications, this proves to be more than enough. Unfortunately, however, this set of functions doesn t allow you to write even the simplest CD-copying program. In order to achieve this, it is necessary to go by at least one level deeper in the hierarchy, calling on the driver of specific device directly.

Standard disc drivers supplied as part of the Windows 9 x and Windows NT operating systems support a limited set of basic commands (such as read a sector, view a TOG, etc.), which do not allow for the full implementation of all of the capabilities of contemporary CD-ROM/R/RW drives . However, their set of functions is sufficient for the writing of the simplest protection mechanisms.

The overwhelming majority of protection mechanisms of this type can be copied well enough by standard copying. This, by the way, is not surprising, since both the copier and the protection feed from the same trough , that is, from the same set of instructions. On second thought, perhaps it s better to say that they use the same set of control commands working with the device at the logical level.

To create protection that can t be cracked, you must dive to the very bottom of the well, and talk to the device in its native language. Although optical drive controllers support a high-level set of commands (in fact, at a considerably higher-level than floppy drives do), and despite the fact that drive interface is based on specific equipment and CD-ROM/R/RW discs were not initially designed with an eye on protection, it is still possible to create discs that are practically impossible to copy at this level.

Despite popular opinion, it isn t necessary to write a custom driver to achieve low-level control over drives. All of the required drivers have already been written. The developer has only to choose one of the competing interfaces, which ensures low-level interaction with SCSI/ATAPI devices from the user -mode application level. This list is quite long, and it includes ASPI, SPTI, and even MSCDEX (which has been practically forgotten, but is still supported by Windows 98/ME operating systems). Each of these interfaces has its own advantages and drawbacks. That s why commercial products must support them all.

Since the programming of optical drives goes far beyond the limits of the topic of CD protection (which still is the main topic of this book), we will cover hardware interfaces only briefly and in a simplified form.

The information that will be provided below is sufficient for studying all of the above-listed interfaces from scratch, and for doing this on your own. Even if you have never encountered the topic of programming SCSI/ATAPI devices before, it is unlikely that you will experience any difficulties while reading this chapter.