The pirate life for me

The naughty 90s
Permutations of existing techniques were coming thick and fast. Ever more vendors shipped ever increasingly convoluted solutions using dongles, keys, checksums and validation methods. With the advent of the Internet and popularisation of network-connected computers, challenge and response codes became popular. A user would receive their software in a box with an activation key on it. They would install the software, and then the software would ask for a validation code. The end user would put their activation key in and a validation key would come back from the software vendor server. This would then be input into the software - and provided it 'matched up' on both sides, the product would be activated.

This gave rise to the ever-popular keygen. Key generators became popular when the power of decompilation tools (and thus, reverse engineering) became accessible to those outside of large-scale software development teams. The premise of the keygen was simple. Pull apart the proprietary code by disassembling it into near-machine code, then figure out what sequences of keys or algorithms were used to create said keys. Once this information is obtained, put it into software that can run externally to the application, and generate based upon the algorithm.

Key generators today represent the largest 'market' for open piracy, often being created for everything from games to applications and operating systems. For many of the groups and individuals that make key generators, it's all about the challenge of the reverse engineering method and technique, rather than simply stealing software.

Of deformities and wobble sectors
Along the time line, it's now early turn of the century. Software companies are under threat, people are losing jobs, and the industry is under a slow but definite landslide. Here is where the 'fun' stopped and things became serious.

The RedBook CD standard was well in place for audio CDs, as were the respective standards for data DVDs. It became painfully apparent that it wasn't a problem for people with the right equipment to 1:1 copy media, no questions asked. The vendors had an ace up their sleeves, though. Along came SafeDisc.

Command and Conquer: Red Alert 2 started the trend. The disc would copy fine. Everything seemed sensible. It would then be installed from, and everything still seemed sane. Then the problems would arise. People couldn't play from their backup burnt media. Was the burner missing something? It sure was!

Weak sector and Eight to Fourteen Modulation (EFM) encoding were the key to the protection mechanism in Macrovision's SafeDisc.

First, the concept of the 'exclusive or' (XOR) needs to be understood. XOR is a bitwise operation. XORing a number with 1 flips a bit, but XORing with 0 does not. If your input bit reading from a disk was 1, and it was XORed with 1, the result would be 0. If your input bit was 1, and it was XORed with 0, the result would be 1.

The next part of the equation comes in understanding of how a CD/DVD drive actually works. A laser in the most modern of drives still finds it hard to detect frequent changes between physical pits and lands. As a result, changing the number of pits and lands frequently is a recipe for failure. In this respect, when reading/writing a CD or DVD, the number of these pit/land changes must be minimised. This is where EFM was invented. It turned eight bits into 14 bits, with an XOR lookup table alongside, as a hardware encoder/decoder.

The next step in understanding SafeDisc is the Digital Sum Value (DSV).

The DSV is an integer that changes at each point along the media. For every pit on the disc, the DSV is incremented by one, and for every land it is decremented by one. For instance, take the following series of pits and lands:

Pit-Pit-Pit-Pit-Land-Land-Land-Pit-Pit-Land-Land-Land-Land.

Here, the sequence of pits to lands would be +6, -7.

Here is where SafeDisc and several other copy protection techniques kick in. SafeDisc's weak sectors are already XORed with the verified outputs of what a sector XOR engine will be. Once this hits the EFM encoder on the way 'in', because it's already XOR'ed, it'll be twice the pattern that it was previously, and thus have to traverse twice the length on read 'in' or write 'out'. The algorithm used for calculating these merged bit patterns is far too intensive and slow for a burner to deal with. When confronted with these long chains of weak sectors a drive doesn't know what to do, so it throws the read away as garbage data or a read error. When this happens, the SafeDisc module gets the hint, understands that the media is forged, and refuses to run.