I knew "CD-Index" didn't sound right when wrote it previously. It's actually a TOC (Table of contents).
There are several basic ways of protecting a Disc from being copied:
Incorrect TOC and its Consequences
TOC invalidation is a cruel, ugly, but strangely widespread technique in protection mechanisms. End-user copiers (Easy CD Creator, Stomp Record Now!, Ahead Nero) actually go a little nuts when encountering discs of this type. Copiers of protected disks (Clone CD, Alcohol 120%) are much more loyal to an incorrect TOC. However, in order to obtain a usable copy, they require a specific combination of reading and burning devices. Even given this, successful copying of these discs is not guaranteed.
The burning device must support the RAW DAO (Disc At Once) mode, i.e., the mode by which the entire disk is written at a single pass. The RAW SAO (Session At Once) mode isn’t suitable for this purpose, since it orders the drive to write the session contents before writing the TOC. Consequently, the drive has to analyze the TOC on its own in order to determine the session length and its starting address. An attempt to write an incorrect TOC in SAO mode generally results in unpredictable drive behavior. Consequently, it is pointless to hope for the generation of a usable copy of a protected disc! As a rule, the first session with an incorrect TOC encountered by the drive proves to be the last. This is because there is no room to write all of the other sessions (TOC invalidation is usually aimed at increasing the session size to several gigabytes).
The CD-reading device, besides reading in a Raw mode (which is supported by practically all drives), must be able to recognize an incorrect TOC. When it encounters such a case, it must automatically switch to a “reserved” addressing resource, namely, to the Q subcode channel. Otherwise, the session containing the incorrect TOC will be unavailable for reading even at the sector level.
Thus, not all equipment is appropriate for copying discs with incorrect TOCs. About one third of all available copier models are unsuitable for this purpose. In order to find out if the model that you have chosen supports the RAW DAO mode, refer to the online Help system of Clone CD, which provides a long list of various drives (unfortunately, the ones that I have chosen are not listed here), along with their characteristics. Another approach is to issue the 46h (GET CONFIGURATION) SCSI/AT API command and check the drive’s response. Of my two copiers, only NEC supports the RAW DAO mode. The situation is even more complicated with regard to determining the ability of reading incorrect sessions, since this ability represents exclusively internal drive logic. As a rule, even if the drive is capable of working with an incorrect TOC, the drive itself does not indicate this, and drive manufacturers usually do not advertise this feature. This information has to be found experimentally. For instance, take a disk with an intentionally invalidated TOC (later in this chapter, I’ll explain how to create one), insert it into the drive, and try to read sectors from an incorrect session. Different drives might react very differently. For instance, PHILIPS, depending on the “mood” of its circuitry, might either report a read error or return a stream of unintelligible gibberish, where even a SYNC in the raw header isn’t recognizable.
The main drawback of protection mechanisms based on TOC invalidation is that some drives refuse to recognize these disks, and, therefore, make playback impossible. A legal user, who has suffered inconveniences due to the incompatibility of his or her hardware with the protection mechanism, will, in the best case, complain and return the disk to the manufacturer. Naturally, this can be only done if he or she is able to eject this trash from the drive. This question is problematic, since the embedded microprocessors of some drives simply “hang” when they attempt to analyze an incorrect TOC. In these cases, the drive, literally speaking, retreats into its shell. It becomes fully abstracted from all of the “irritants” of the outside world, including the user’s attempts to eject the disk. Of course, the hole for ejecting disks in emergency cases hasn’t been removed entirely, but, according to some rumors, it isn’t present on all drives (although myself have never encountered a drive lacking this feature). On the other hand, this hole in many cases is concealed behind the decorative panel. Cases where the user isn’t aware of the existence of this feature or how to use it, are even more frequent. Macintosh systems lack these holes (or Mac users never suspected that they might exist). Anyway, the number of law suits that they have filed is virtually uncountable. The most interesting fact here is that the courts have ruled in favor of an overwhelming majority of these suits. As a result, the developers have had to pay for the “repair” of equipment, moral injury, and, finally, the legal costs for the cases. (By the way, removing protection from disks written with crude violations of the standard, and in particular, those with an incorrect TOC, is not considered to be cracking. Consequently, it can’t be prosecuted by Law. Therefore, if you encounter discs of this type, crack them without any qualms).
Incorrect Starting Address for the Track
To create a protected disk with a incorrect TOC, we will need: Any burner capable of creating multi-session disks (Roxio Easy CD Creator, for example); a copier of protected disks that stores the TOC contents in a text file that can be edited (Clone CD, for example); and, finally, a burning drive that supports the RAW DAO writing mode. Although I don’t like this style of presenting materials, for the sake of simplicity, all actions will be described in the form of step-by-step instructions.
Step One: Creating an Original Disk. Take a virgin CD-R disk from the pack, or, better still, an “old stager” CD-RW. Insert it into the drive and write a couple of sessions in standard mode. It would be even better (or, to be more precise, more obvious) if the second session includes all of the files from the first session—the one, the TOC of which we are going to disfigure. The most interesting question is whether or not the drive will be able to read its contents.
Step two: Obtaining the image of the original disk. Start Clone CD and instruct it to create an image of the original disk (at this stage, the chosen profile for settings is not critical. Because the disk isn’t protected yet, we can use both the Data CD and Protected PC Game options with the same level of success. Note that it isn’t necessary to click the Create “Cue-Sheet” checkbox, because this option is available only for single-session CDs).
Step three: Invalidating the starting address of the first track in the CD image. If everything has been done correctly and both the software and the hardware operate normally, the following three files will be created on your hard disk: IMAGE.CCD— containing the contents of the Q subcode channel of the Lead-in area or, simply speaking, the TOC; IMAGE.IMG—the raw disk image containing all sectors starting from 00:00:02 and including the total number of available sectors; and IMAGE.SUB —the contents of the subcode fields of the Program Memory Area. In principle, the latter file might not be present (it is created only if the Read subchannels from data tracks checkbox is set). This circumstance is not critical, however, because, at this point, we are mainly interested in the TOC itself and not the subcode channels! Open the IMAGE.CCD file using any plain-text editor and try to translate the language of the disk geometry into normal, human-friendly language.
An Example of Implementing Protection at the Software Level
Now let us demonstrate how to implement this type of protection programmatically. The simplest thing to do is to send a command to read a raw TOC to the drive (opcode: 43h, format: 2h) and compare the result returned by this command with the predefined pattern. It is up to the protection (it’s its private affair), which fields that command will check. It is at least sufficient to check the number of sessions and the starting address of the corrupted track. At the maximum protection level, it is possible to check the entire TOC. Naturally, it is recommended to avoid a byte-by-byte comparison of the TOC being checked with the original, since this approach implies laying a stake on the specific features of the drive’s firmware. The standard remains silent about the order, in which the TOC contents must be returned. Therefore, its binary representation might vary from drive to drive (although, in practice this does not happen). A competently designed protection system must analyze only those fields where it is explicitly bound to their contents.
