Chapter 9: Protection Mechanisms Based on Binding to Storage Media

Protection Mechanisms Based on Physical Defects

The idea of protection mechanisms of this type lies in intentionally damaging disc surface in one or more locations. When the drive attempts to read sectors located in the damaged area, it will drag the read head for a while and then, after several failed reading attempts, return an error message. Most end- user copiers will be unable to copy such a disc, and will terminate their operation abnormally after encountering the first damaged sector. More advanced copiers capable of skipping damaged sectors, will succeed in copying all of the readable information on a defect-free disc. However, in this case, absolutely normal and readable sectors will be located in positions occupied by damaged areas (such sectors, however, will contain irrelevant garbage, since the copier failed to copy these them).

The protection mechanism will check the storage medium for the presence of physically damaged sectors in the predefined locations, and, if the sectors with predefined numbers can be read without a problem, the protection will conclude that it is dealing with an unauthorized copy of the original disc.

As a rule, the physical defects, to which protection mechanisms bind, are tiny spots (approximately one or two millimeters in diameter) burnt on the disc surface by a laser. They can easily be located visually when viewing the disc in reflected light (see Fig. 9.1). At first glance, it seems that we d be able to reproduce an identical damage on the copied medium by precisely measuring their geometric coordinates (using a palette, for instance). Practice, however, shows that this isn t the case. This is because sector numbers are not in any way bound to their physical location. Depending on the width of the spiral track, the size of the Lead-in area and the lengths of the pits and lands, the same geometric area of the disc can contain sectors with different numbers! The probability of the fact that these sectors will coincide for two irrelevant lots of discs is negligible. Therefore, any attempt at blindly copying such a disc will fail.

Fig. 9.1: Disc with an intentionally damaged sector (a small volcano a little below the middle of the screen). Using specialized equipment allows you to burn the surface exactly in the center of the spiral track

Under such conditions, we ll have to play another trick, and imitate the read failure programmatically. The first idea that comes to mind is creating a simple CD-ROM emulator that would report read error, when an attempt is made to access sectors that are checked by the protection. This will deceive the protection mechanism. At the same time, both the emulator itself and the image of the original CD can be easily burnt into a CD-R disc, using the over-burn method. Another technique of cracking consists in the implementation of a resident program that intercepts all attempts at accessing CD-ROM and returns read error messages when checking specific CD sectors.

Both methods were already widely used by the time of MS-DOS and 5 diskettes, so it is a tried and true technology. Clearly, a CD isn t the same thing as a diskette, but the techniques for working with them are generally the same. The only problem is that Windows NT requires administrative privileges for installing a disc emulator, and not every user has been granted such privileges. With these considerations in mind, using the interceptor might be the better option, since no special privileges are required for intercepting API calls. All you have to do is to correct the import table! As a variant, it is possible to set breakpoints to API functions or set hooks on them. Which functions are to be intercepted will be covered later in this chapter.

One positive difference in favor of CDs when compared with diskettes is that they allow for the emulation of physical defects at the logical layer. Do you recall the errorcorrection codes located in the end of each sector? Now imagine what will happen if they are purposefully modified so that an irrecoverable error is reported even in cases where a sector was read successfully (an error that can t be corrected even by means of redundancy). The drive s firmware, having carefully analyzed the situation, even having attempted to read the sector several times, will finally cease these vain attempts to position the read and return an error message. However, we aren t going to clarify whether this was a physical or a logical error. This means that the software will consider both physical and logical errors as absolutely the same! In general, the protection might ask you to return the contents of the damaged sector in a RAW format. In this case, if the disc surface isn t physically damaged, this sector will be read successfully. If this is the case, we are dealing with a copy. However, not all drives support RAW reading. Therefore, most legal users will blame protection developers for any attempt at industrial use of this type of check. These complaints are caused by hardware incompatibilities, so this approach isn t recommended. However, developers of protection mechanisms can ”to borrow a term from chess ”play a knight s move. If the drive doesn t support RAW reading, then the protection relies on the information that is supplied to it. Otherwise, an additional check must be carried out. The copy will be usable only when inserted into the drives that do not support RAW reading.

Finally, it is possible to load the protection into disassembler/debugger, locate the procedure that checks for damaged sectors, and then crack it! Naturally, for this it is necessary to know how such a check is carried out, to which facts it is necessary to pay attention, and what to search for (don t even suggest a full analysis of the protection code).

Operating systems of the Windows family are surprisingly rich with the tools for working with CDs at the sector level. Besides the obvious CreateFile/DeviceIoControl , there are ASPI (Windows 9x/NT) and SPTI (Windows NT only). There is also a wide variety of other interfaces. When working under Windows 9x, you can directly call on the CDFS driver through the ABSOLUTE_READ ^[i] function ” INT 2Fh (or, to be more precise, through the 16-bit DLL stub, calling the Simulate Real Mode Interrupt DPMI function ^[ii] ). More detailed information on this topic is provided in the Q137813 How Win32 Applications Can Read CD-ROM Sectors in Windows 95" technical note, which is supplied as part of Knowledge Base, accompanying the Microsoft Visual Studio product. There is also the source code of the function for working with the CD-ROM at the sector level.

Under Windows NT, reading/writing sectors is even easier. It is enough to open the disc in the cooked -mode ^[iii] , after which it will be possible to work with it at the logical level. Figuratively speaking, the entire contents of the CD will be interpreted as one large file. A detailed description of this process can be found in the Q138434 How Win32-Based Applications Read CD-ROM Sectors in Windows NT technical note, which is part of the Microsoft Knowledge Base.

By the way, to check the disc for the existence of a physical defect, it isn t necessary to go to the raw sector level. File exchange is a tool that is just as efficient. Obviously, a file that contains at least one damaged sector can t be read, and any attempt at doing so will produce an error! The main advantage of this method is that it can be implemented using any language and operating with only standard capabilities. There is no need for API calls and a monstrous IOTCL . Calls to fopen/fread functions will be enough!

Thus, there are many different methods of binding to the disc, and locating the protection mechanism in the code of the application being cracked is a tedious job. If setting breakpoints to the DeviceIoControl function do not produce a result (which is rare), then you ll have a tough time. You might end up spending all night cracking this protection. Let API spy and context search help you. While you probably agree that everything is clear with the spy, you may ask, why do we need context search? Knowing the numbers of bad sectors, you can try to locate the corresponding constants in the body of the program. If the developer of the protection mechanism hasn t used any other additional tricks, the numbers of the sectors being controlled are written in the program code as is. In this case, all that remains to do is to set a breakpoint to the corresponding memory cell and wait until that cell is accessed. Naturally, if you are investigating the program on a disassembler instead of a debugger, you ll need to use cross-references instead of breakpoints.

If, despite all your efforts, you still cannot crack the protection, try to use Clone CD and/or Alcohol 120%. Both utilities recognize bad sectors and simulate them at the logical level. Clone CD does this using error-correction codes, while Alcohol 120% achieves the same goal using error-correction codes and virtual disc! As practice has shown, there is no need to use virtual disc in most cases. Protection mechanisms in most cases are very credulous, and can be deceived easily by changing the checksum of a sector.

Thus, the reliability of protection mechanisms based on this approach is unsatisfactory. You ll have to carefully weigh all of the pros and cons before you decide to implement this kind of protection in your programs. Any advanced user who has some experience in working with Clone CD, will copy such a disc easily ”and you ll find yourself out of job. Furthermore, to create physical defects with the required precision and quality ( high-quality physical defect is certainly an interesting phrase!), you ll require expensive equipment, something not available to every freelance programmer. With regard to scratching the disc with a needle, this is not an option. First, this method is unreliable, bad for the health of CD-ROM drives, and finally, not particularly aesthetically pleasing.

If you still decide to opt for this type of protection, bear in mind a few pieces of advice. First, introduce the damage on the side of protective layer, not on the side of the polycarbonate base. In other words, this should be done on the top side of the disc. When damaging the disc, remember that an attempt to create a deep radial scratch usually produces a very poor result. The disc loses its mechanical strength, which means that sooner or later, it will be torn to pieces by the centrifugal forces. This almost always means curtains for the CD-ROM drive. It is better to create a small pinhole in the reflective layer. This will be enough to make one or more sectors unreadable. This can be achieved using a normal sewing needle.

Now, let s discuss the question of how to avoid damaging useful data when introducing physical defects. Scratching the unwritten area of a CD is practically useless, because it won t be read. For this reason, as an experiment, write something useless to the test disc (something that you won t mind losing). One possible algorithm is as follows .

1. Take a new CD-R disc and burn to it all of the files of your program, except for the information contained in the protection mechanism that binds to the disc. As a rule, this will be the main executable file of your program, although the protection mechanism may be located in one of the DLLs or even implanted into a data file (although this, of course, is an exaggeration).

2. Press the <EJECT> button and, using any method, mark the location of the last written track (for instance, you can just measure the diameter of the burnt area using a ruler).

3. Once again, return the disc to the drive and write approximately 150 MB of garbage there. This trash will serve as the testing material for scratching. Don t close the session yet!

4. Now, introduce one or more physical defects to the disc. You can do this by prodding the area of the last written track with a sharp needle.

5. Start any disc doctor and register the positions of all of the bad sectors.

6. Hard-encode the numbers of bad sectors into the program that you are going to protect and burn the protection module to the CD-R, closing all sessions.

7. That s all! Your protection is ready for use.

^[i] EAX := 1508h , see Interrupt List by RalfBraun.

^[ii] This, by the way, is a very useful function, which allows Win32 applications do whatever things that are allowed to MS-DOS applications (free access to the hardware, working with interrupts, and so on).

^[iii] The disc can be opened in cooked mode by means of the CreateFile function called as follows: hCD = CreateFile ("\\\\. \\X: " , GENERIC_READ , FILE_SHARE_READ FILE_SHARE_ WRITE , NULL , OPEN EXISTING , FILE ATTRIBUTE NORMAL , NULL) ; where X stands for the drive letter.