Saturday, December 5, 2009

CD Protection Tricks

Overview

CD-checking software protection is used by almost all programs distributed on CD. The products in this category range from very simple defenses (that aren't real protection against crackers at all) to highly sophisticated protective software.

The simpler products only check to see whether a program started running without the correct CD, which would threaten the program's functionality. There are many ways to find out whether the original CD has been inserted into a CD-ROM drive. And, while most protective software is helpless against "burned" CDs, it can at least make it impossible to simply copy a program to a hard drive.

One reason to use such simple defenses is to protect against the so-called "ripping" of games. "Ripping" refers to the removal of large but unessential parts of the game, like animation, music, or DirectX. The shrunken game is then compressed so that people with slower connections can download it from the Internet, thus significantly increasing the number of pirated copies.

How CD-Checkers Work

The classic CD checkers have their place in the world, and when correctly programmed, can cause problems even for the better crackers. Still, this protection is often easy to find and remove.

Most checking routines use the GetDriveTypeA API call to find the CD drive, and all other checks are performed only after determining which drive is the CD-ROM. The simplest protective software only checks for the CD's name or label. If the CD's name has been changed, the program will not run, since the program has determined that the original CD isn't in the drive.

Some protection developers have tried to complicate CD copying by naming CDs in a way that causes an error during copying, often using a blank space in the CD name or some special character that appears as a blank space. Until recently, many burners couldn't copy such CDs.

Another common trick is to check for one or more selected files on the CD, especially those that are most commonly removed from ripped versions, such as DirectX, animation, music, and documentation. This technique was commonly used with 80-minute CDs because, in the past, the limited supply of 80-minute CD media meant that crackers had to remove something from the program in order to make their version fit on available CDs. Even today, crackers sometimes remove something to be able to copy the game to normallength CD-Rs.

The most complicated protective software, like SecuROM or SafeDisc, can check errors on the CD.

Random checks that test for the presence of the original CD as the game is being played are very unpopular with crackers, and often result in the protection being incorrectly removed from a game and many subsequent repairs being required. This kind of protection has been successfully used with several games (see Figure 4.1).

CD Protection Software

Let's take a look at the CD protection software available to you, and we'll consider what works and what doesn't work, and why.

CD-Cops

CD-Cops is commercial protection from Link Data Security (http://www.linkdata.com) that isn't very widely used. CD-Cops recognizes original CDs and rejects copies. CDs protected with CD-Cops can be identified by a window appearing on the screen once the program starts, as well as by the CDCOPS.DLL file and files with .GZ_ and .W_X extensions on the CD.

The protection itself is a part of a protected executable file. When this file is started, it checks to see whether the original CD is present by testing the angle between the first and the last accessible CD blocks. The original CD contains an 8-byte code with the correct angle and a checking routine detects the angle on the CD and then compares it with the decoded correct angle. When a burned copy of the original CD is present, the angle will differ, and the program will not run. (One advantage of this protection scheme for the CD manufacturer is that it doesn't require a special CD copying machine.)

CD-Cops's testing routine is a truly sophisticated piece of programming. It also uses a clever trick: It sets a timer to see if the testing routine runs for a long time, which would mean it is being traced. If it finds that the routine is running for a long time, it causes an error in the program. CD-Cops also contains several checksums, which prevent changes to the program code—parts of the routine are decoded in memory when running.

But CD-Cops has a critical weakness: It can be decoded without the original CD. In fact, you can even find a decoder for it on the Internet. The reason is that the program's creators left the correct code in the program which, even though encoded, some clever crackers were able to decode. Had CD-Cops used a technique similar to SafeDisc, which decodes the program without checking it, and only after reading the angle from the CD, it would have been impossible to decode a CD-Cops—protected program without the original CD.

DiscGuard

DiscGuard from TTR Technologies (http://www.ttrtech.com) packs its protection with the executable files on the CD and encodes them; a digital code on the original CD is then used for decoding. When a user attempts to copy a CD protected with DiscGuard, the digital code is not copied correctly, and when the copied program is started, the decoding routine identifies it as a copy and runs it as a demo version or with other limitations, as the developers wish.

One distinct disadvantage for developers using DiscGuard is that they need to use either a special copying machine—a device called DG-Author—to produce DiscGuard-protected CDs.

As far as I know, DiscGuard has been used with only one popular program, the Colin McRae Rally game. While the cracker who removed the protection failed the first time, a corrected working version was posted the very next day. Given the fact that this was a completely new kind of protection, the speed with which it was cracked didn't reflect well on its developers. Their only salvation was that the cracker was Moelch, who later became famous for cracking Settlers 3.

One advantage of DiscGuard is that there is no universal decoder, probably because it is rarely used. LaserLock

LaserLock is commercial protection from MLS LaserLock International (http://www.laserlock.com). The LaserLock-protected CD contains an invisible directory with files containing unreadable errors. The encoding software is used together with a laser mark when the CD is produced, which at first made it truly impossible to copy, but it can actually be gotten around quite easily. While there is no decoder for LaserLock, there is a program that can copy a LaserLocked CD to a hard drive. Alternatively, you can set a CD-burning program to ignore errors and copy the CD, and the error-containing files can even be saved with a hex editor, and all readable parts of the file can be copied into a file on the hard drive.

LaserLock has protected many programs and games, the most well known of which are Fallout 2, Shogo, and SpecOps. (LaserLock was massively upgraded in its last version. While it appears as though this protection may someday become obsolete, LaserLock is currently used quite fequently. However, there is a public decoder for this protection.)

SafeCast

SafeCast is commercial protection from C-Dilla (http://www.c-dilla.com), which also developed SafeDisc, described next. (C-Dilla is now a part of Macrovision, http://www.macrovision.com.) SafeCast is designed for development teams and is supposed to prevent program copying during development. It requires no special copying machines, and the protection is designed especially for burned CDs. When beta testers receive the encoded CDs, they must contact the company that encoded the CD to receive either by mail or email the code necessary to run the program.

SafeDisc

SafeDisc (often called C-Dilla because of the company that developed it) is today's most commonly used protection, so we'll take a detailed look at it. It is used by international game producers such as Ubi Soft Entertainment, GT Interactive, Interplay Entertainment, Microprose, Red Storm Entertainment, Take2

Interactive Software and TalonSoft, Electronic Arts, and Microsoft.

As with other commercial protection, SafeDisc's release was preceded by a huge campaign on the Internet claiming that its protection couldn't be removed and that it was unconquerable. Of course, a pirated version of the first SafeDisc-protected game appeared about one week after the release of the game. This certainly didn't make the people at C-Dilla happy, and it calls their protection into question, but because there is no adequate competition, SafeDisc continues to be the choice of more and more distributors.

The presence of these files on a CD signals the presence of SafeDisc:

00000001.tmp

clcd16.dll

clcd32.dll

clokspl.exe

dplayerx.dll

SafeDisc-protected CDs also contain both a main EXE file and a file with the same name as the main EXE, but with the .icd extension. The EXE contains the main protection, and the original EXE file is encoded in the ICD file. This encoded EXE uses anti-disassembling macros, which make it very difficult to trace.

SafeDisc also uses several anti-debugging tricks designed to thwart Soft-ICE, in particular. First, it divides the EXE into two parts. The first part contains only decoding information for the second part, but otherwise has no important code. The second part is encoded by the first one, which makes it impossible to change anything in the first part, even when attempting to do so in memory.

A protective device in the first part of the EXE uses the CreateFileA trick (described in Chapter 7) to check for the presence of SoftICE. If SoftICE is found, a message appears warning that a debugger must be removed from memory. If the cracker disregards the warning and tries to work around it, the program wrongly decodes the second part of the EXE as soon as the debugger is found again. The decoding routine itself then tests again for the presence of the debugger using CreateFileA.

SafeDisc also uses an INT 68h trick (also described in Chapter 7). If a debugger is found, the decoding constants will be set incorrectly, and the second part of the EXE will be incorrectly decoded.

Note An older version of SafeDisc used a trick with the debug register that could discover any active debugger. This trick had to be removed, though, because it was incompatible with Windows NT.

The second part of the EXE tests for the presence of the original EXE using a simple CD check, and tries to read errors from the original CD. If it finds an error, it displays a window requiring the user to insert an original CD. If the cracker tries to get around this warning, the program will simply crash rather than display an error message after the next incorrect decoding.

The second part of the EXE, behind the test for the original CD, contains a program that calculates the code necessary to decode the original EXE. The program first runs CLOKSPL.EXE, which shows only a picture during loading. Next, the program is fully engaged in calculating the decoding key according to various conditions. CD errors are read and, depending on the presence or lack of errors, conditions are either true or false.

It is almost impossible to influence the program with a patch because it reads the errors with CLCD16.DLL and CLCD32.DLL. Eventually the calculation result is XORed with the actual date, which means that the code is different every day. (It would be interesting to run the program right before midnight, because the date change should trigger the decoding security device.)

Finally, the second part of the EXE file decodes a small routine found in memory, which contains addresses for calling DPLAYERX.DLL and the correct decoding key. It is difficult to stop the running program in this small decoding routine. Tracing is out of the question because it was started by creating a new thread, and the second part of the EXE calls it with Resume Thread API calls. One way to get into it, though, is to change the first instruction at the beginning to INT 3h, set a breakpoint in SoftICE at INT 3h, run the program, and then, once the program stops at the breakpoint, replace the INT 3h with the original value. In this routine, SafeDisc loads DPLAYERX.DLL into memory and then calls its procedure.

DPLAYERX.DLL works like the main EXE. While the library is loading into memory, the _DllMain@12 function is started, and it secures the decoding of the second part of the DLL. The function (Ox77F052CC) is called together with a key for decoding the original EXE, and the key is once again XORed with the date so that the correct key is used for decoding.

The _DllMain@12 function works like the first part of the EXE and contains the same anti-debugging tricks. Anti-debugging tricks are again used at the beginning of the second function, Oc77F052CC. When a debugger isn't found, the program decodes the original EXE, which is encoded in the file with an .icd extension. (Decoding is performed in memory, and the program is not saved to disk.) Once the EXE is correctly decoded, the original program is launched.

SafeDisc was a perfect piece of programming, but, as with all commercial protection, once it had been overcome once, it could easily be overcome again. You can find a decoder for SafeDisc on the Internet that allows a SafeDisc-protected program to be run from a one-to-one copy of the original CD, including errors. The problem with these decoders is that it's difficult to create an exact one-to-one copy of the CD, because such a CD may contain more than 22,000 errors. Too, when copying, the CD must be read only at 1x speed so that the errors are read correctly and, moreover, not all CD-R or CD-ROM drives can read these errors correctly even at 1x.

Given the ease with which SafeDisc can be overcome, it would be ridiculously naive to use SafeDisc protection alone (remember Settlers 3). Still, SafeDisc is the best commercial protective software on the market, and it's not a bad investment for a company that doesn't want to develop their own protection. While SafeDisc will not stop the distribution of pirated software, it will dramatically reduce the copying of original CDs by average users.

NoteA program for decoding SafeDisc (unSafeDisc) without an original CD has appeared recently. RISC clearly worked very hard and carefully analyzed the decoding. Because he found several serious failings in SafeDisc's design, he was able to create a program that may be able to decode all known versions of SafeDisc. The presence of this decoder could, of course, limit SafeDisc's commercial feasibility. The question now is whether the developers will make radical changes, completely rewrite the protection, or wait until their protection becomes essentially unnecessary. (At the present time, there is a new and improved version of SafeDisc, called SafeDisc2. Technology is better than in the previous version, but it has been broken and it is possible find a decoder for it.)

SecuROM

SecuROM (http://www.securom.com) is commercial protection from Sony DADC. The similarities between SecuROM and SafeDisc suggest that SafeDisc is probably based on SecuROM, and that SafeDisc's creators simply improved SecuROM. This is suggested by the presence of the files CMS16.DLL, CMS_95.DLL, or CCMS_NT.DLL on the SecuROM-protected CDs. Like SafeDisc, SecuROM is in continuous development.

SecuROM's protection is based on the same principle as SafeDisc. Though it has been used to protect many games and programs, including Forsaken, Descent, FreeSpace, FIFA 99, Alpha Centauri, Machines, and the famous Diablo 2, I won't describe it in detail because it is being used less and less. The short story is that some SecuROM data is encoded in an EXE file, which is only correctly decoded once the original CD is inserted. Special copying equipment is required to produce a SecuROM-protected CD.

While it's not easy to crack SecuROM's protection, it's certainly not impossible. It's slightly easier to remove SecuROM than it is to remove SafeDisc because only some of the data is encoded, and because its decoding routine and protection system is somewhat simpler. Basically, the memory dumper that saves the

EXE file to disc after correct decoding can be used for decoding, as with SafeDisc. (Naturally, this can also be done manually in a debugger, but it would be slightly more time-consuming.) Note that SecuROM, like SafeDisk, was upgraded in its latest versions.

You can find a SecuROM decoder on the Internet that is able to start programs from a one-to-one CD copy. On the other hand, it isn't easy to make such a copy: Its creation may take several hours, and the result is far from certain.

If you start a SecuROM-protected program from an original CD, you can dump it using the latest version of ProcDump. While developers should consider this cracking possibility, it would be even better if SecuROM itself concentrated on tackling this flaw.

VOB

VOB is the latest commercial protection in the SecuROM and SafeDisc family, and, in my opinion, also the best. Debugging VOB is a real pain because it uses anti-disassembling macros that prolong debugging terribly and make it very unpleasant. Otherwise it is nothing revolutionary. (See Figure 4.2.)

ther CD Protection Tricks

There are some other protection schemes used for CDs:

CD contains more than 74 minutes of data

Damaged TOC (table of contents)

CD contains huge files

CD contains physical errors

CD contains one or more huge files

Demo has selected program functions limited

CD Contains More Than 74 Minutes of Data

I first saw this type of protection in the game Commandos. It is based on a user's inability to copy the program to a typical 74-minute CD because the program is too big (larger than 660MB). The program's original CD is written at a higher than normal density, which makes it a higher capacity.

When this protection first appeared on the market, it was effective because it wasn't possible to buy 80-minute CD-Rs, and crackers had to remove something from the program to be able to copy it. The Commandos protective software was ready for that though, and if it found that any audio tracks had been removed from the CD, the game refused to run.

This type of protection doesn't make much sense today though, since the price of 80-minute media is almost on par with 74-minute CD-Rs, and all better burning programs and burners can work with 80-minute media. This protection scheme would only make sense if the CD were larger than 80 minutes, but if it were, some CD-ROM drives would have trouble reading it. Damaged TOC (Table of Contents)

If you try to copy a CD protected with a damaged table of contents, the burning program will display an error message and will refuse to copy the CD. Protection software uses this principle by adding an extra data block to the CD (besides the main one), often placing it between audio tracks. Because ISO format doesn't support two data blocks on one CD, the burning program will fail. The Achilles heel of this protection is that all better burning programs let the user switch off the warning and make the copy. (This copy protection was used with the Commandos game CD.)

Huge Files

This type of protection is often used together with the damaged TOC technique. The original CD contains files that are larger than 600MB once they are copied to a hard drive. In fact, once the entire CD has been copied to a hard drive, it may be larger than 2GB, causing the burning program to refuse to burn.

This type of protection was important because it prevented the CD from first being copied to a hard drive so that a 74-minute CD could be made from an 80-minute one. Currently though, with the availability of 80-minute CD-Rs (as discussed previously) this type of protection has lost its importance.

Physical Errors

This type of protection actually introduces physical errors onto the CD, such as a damaged track. (This technique hasn't been used very often, though it was used in the wonderful Settlers 3 protection.) Very few CD drives can read such errors. (I tried it with my TEAC drive, and I succeeded only after a long time. It was necessary to read it only at 1x speed and to be very patient, since reading the one CD took about six hours.)

Even though you can find a program on the Internet that makes the reading easier, this technique is still a good one. It may be difficult to produce the original CDs though, since the CD has to be mechanically damaged in just the right way, every time.

One or More Huge Files

This very good means of protection makes it difficult to create a ripped version from a program's CD. In this case, all files are combined into one or more very large files on the CD. If the files use encoding or compression, it is very difficult for the cracker to understand the file's structure, and to transform it back into small files in order to remove the files that he considers unnecessary.

When the protection is good, the cracker will have to combine the small files back again into a big file and replace, for example, the audio files that he wanted to remove with one-second pauses to shorten the file. Next, he will have to re-index the file header with the information about the lengths and locations of files in the large complex file. This isn't easy and it takes a lot of time, and besides which, it is easy to make a mistake and to create a useless copy of the game or program.

When combined with a program that checks to see whether changes have been made, this protection becomes even more difficult to remove.

Demo with Selected Program Functions Limited

In this situation, the protected program lacks several important functions; for example, Save is commonly disabled (see Figure 4.4). However, some programmers don't take enough care and they simply block the functions in the program code without removing them, in which case all the cracker needs to do is to unblock the function to make the program fully functional. When using this protection, important parts of the

Crackers cannot remove the protection from a program that doesn't contain important parts of the code to make it function. Their only way around protection that involves removing code from a program would be to write the missing code themselves, and this is highly unlikely.



In the next chapter we'll take a look at various programs that use compression and encoding techniques to protect software.

No comments:

Post a Comment