Though SafeDisc protection effectively prevents regular home users from creating functional copies of CDs or DVDs, it is quite easy for skilled software crackers to bypass. The early versions of SafeDisc did not make the discs very difficult to copy. Recent versions 2.9+ can produce discs that are difficult to copy or reverse engineer, requiring specific burners capable of burning the “weak sectors” and odd data formats that are characteristic of SafeDisc.

Previous versions of SafeDisc were overcome by disc image emulator software such as Daemon Tools and Alcohol 120%. SafeDisc currently blacklists such software, meaning that those who want to use this method must install additional software to cloak the mounter. Examples include curer om.

Another potential attack on SafeDisc is to pull the encrypted application out of the archive it is contained in. All SafeDisc encrypted discs contain an ICD file, an encrypted format used by SafeDisc to ensure that the original CD is loaded. UnSafeDisc circumvents and decrypts SafeDisc encrypted files by opening the ICD file format, decrypting it, and converting it to an EXE file. However each program requires a specific patch to enable full functionality.

Operation

SafeDisc adds a unique digital signature to the optical media at the time of replication. Each time a SafeDisc-protected program runs, the SafeDisc authenticator performs various security checks and verifies the SafeDisc signature on the optical media. The authentication process takes about 10 to 20 seconds. Once verification has been established, the sequence is complete and the program will start normally. The SafeDisc signature is designed to be difficult to copy or transfer from the original media. Certain multimedia programs are designed to run from the PC hard drive without accessing files from the program disc after the initial installation. SafeDisc will permit this as long as the consumer retains the original CD or DVD disc, which is required for authentication each time the program is launched. Failure to place the original disc in the drive when loading the program will prevent validation of the SafeDisc signature.

SafeDisc (V1)

SafeDisk V1 protected CDs can be recognized by several files on the CD:

• 00000001.TMP
• CLCD16.DLL
• CLCD32.DLL
• CLOKSPL.EXE
• DPLAYERX.DLL

And also by the existence of two files .EXE and .ICD (where is replaced with the actual game’s name).

The EXE executable is only a loader which decrypts and loads the protected game executable in the encrypted ICD file.

The initial version of SafeDisc was easy for home users and professional duplicators alike to copy, due to the fact that the ICD file can be decrypted and converted into an EXE file.

SafeDisc (V2)

The following files should exist on every original CD:

• 00000001.TMP
• 00000002.TMP (not always present)

The loader file (.EXE) is now integrated into the main executable, making the .ICD file obsolete. Also the CLOKSPL.EXE file, which was present in SafeDisc v1, no longer exists.

The SD2 version can be found inside the .EXE file through its string: “BoG_ *90.0&!! Yy>”, followed by three unsigned longs, these are the version, subversion and revision numbers (in hex). When making a backup, read errors will be encountered between sectors 822-10255.

The protection also has “weak” sectors, introduced with this version, which causes synchronization problems with certain CD-Writers. Digital signatures are still present in this version. But this has no effect on disc images mounted in Daemon Tools or similar programs. In addition, SafeDisc Version 2.50 added ATIP detection making it impossible to use a copy in a burner unless software that masks this is used (CloneCD has the ability to do this). SafeDisc Versions 2.90 and above make burning copies more difficult requiring burners that are capable of burning the “weak sectors”; these drives are uncommon.

SafeDisc (V3)

SafeDisc v3 uses a key to encrypt the main executable (EXE or DLL) and creates a corresponding digital signature which is added to the CD-ROM/DVD-ROM when they are replicated. The size of the digital signature varies from 3 to 20 MB depending how good the encryption must be. The authentication process takes about 10 to 20 seconds.

SafeDisc v3 is capable of encrypting multiple executables over one or more CD/DVD medias, as long as the executables are encrypted with the same key and the digital signature is added to each media. SafeDisc v3 supports Virtual Drives as long as the original CD/DVD is available. Once the CD has been authenticated the game should continue to run from the virtual drive (as long as the virtual drive software has not been blacklisted…).

With the introduction of SafeDisc Version 3 which included support for CD/DVD media, as well as virtual drives, the difficulty of burning a copy increased even further.

SafeDisc (V4)

The current SafeDisc version in use is Version 4. Over 40% of games are protected since August 2004, including Quake 4.

SafeDisс driver Vulnerability

SafeDisc installs its own Windows device driver to the user’s computer, named secdrv.sys. In addition to enabling the copy protection, it grants ring 0 access to the running application. This is a potential security risk, since trojans and other malware could use the driver to obtain administrator access to the machine, even if the programs are running under a limited account.

Even worse is that (beside the default configuration on Windows XP), most installers don’t set the security configuration appropriately, allowing every user to let the driver configuration point at an arbitrarily chosen executable which (at the next reboot) is started with administrator privileges.

On November 7, 2007 Microsoft stated that there is vulnerability in Macrovision SECDRV.SYS driver. on Windows and it could allow elevation of privilege. This vulnerability does not affect Windows Vista. The driver, secdrv.sys, is used by games which use Macrovision SafeDisc. Without the driver, games with SafeDisc protection would be unable to play on Windows.

SecuROM v1.x–v3.x

One of the following files should exist in the installed directory (Depending on the operating system) or in the root of the original CDs:

• CMS16.DLL
• CMS_95.DLL
• CMS_NT.DLL

The protection can also be recognized by DADC on the inside ring of the CD. DADC is a CD manufacturing plant; the more recent SecuROM protected games are also pressed in other plants. Open the main executable using a hex editor and search for the following ASCII text (it should appear twice): CMS

SecuROM v4.6

The protection modifies a CD-ROM’s q-channel in order to make a protected original distinguishable from a copy.

A set of nine locations where the Q-Channel is purposely destroyed is computed by the following function (demonstrated as python-code), using a vendor specific key.

BadSQ = 0x0VendorKey = [0,0,0,0,0,0,0,0,0]

Seed = [0,0,0,0,0,0,0,0,0]

BadSQTable = [0,0,0,0,0,0,0,0,0]

round = 0

for a in range (0,256):

BadSQ = BadSQ + (VendorKey[a % 9] & 0x1F) + 0x20

for b in range (0,9):

if (Seed[b] == a):

BadSQTable[round] = BadSQ

round += 1VendorKey[], Seed[] and BadSQ are initialized to secret values.

Possible optimizations were omitted to reflect the original implementation.

The function calculates nine sector numbers; if the corresponding Q-channel is not readable at these locations, the CD is considered being original. Note that the key is always the same for all titles issued by a specific vendor, resulting in identical Q-channel patterns. Also note that every key has 134,217,727 “twins” that will produce an identical BadSQTable.

SecuROM v4.7 and above

After development on SecuROM had apparently been stopped, SecuROM v4.7 had been the first updated version for months, obviously being a “public” beta. The new SecuROM brought several major changes about how the protection works and how it is integrated into the target program.

Unlike SecuROM v4.6, which relied on illegal SubQ-Information, the new scheme utilises “data density measurement” (not to be confused with “data position measurement” as being used by other protections). While the data density on normal CD/DVD-ROMs constantly degrades from the most inner to the most outer sector, data density on SecuROM v4.7 (and up) protected CD/DVD-ROMs is diversified by a certain, vendor specific pattern. This pattern can be reconstructed by high-precision time measurement during software<->CD/DVD-drive interaction and reflects the vendor-key as mentioned above.

To do so the protection defines a set of locations spread over the disc and issue two SCSI-read-commands per location to the drive. As the disc spins, the time it takes for the second command to return depends on the time it takes the disc to do a full round and thus depends on the data-density. To achieve the required timing-precision, the RDTSC command is used, which has a resolution of about 0.28 microseconds on x86-CPUs.

The pattern is made up from 72 locations, each either with normal or higher than normal density and thus reflects a binary pattern which assembles to the vendor specific key mentioned above.

SecuROM v4.84 and beyond includes “Trigger Functions” which allow the developer to program multiple and fully customizable authentication checks throughout the entire application. As the protection places itself between the application’s code and the OS, it can alter the behaviour of selected system functions.

Consider the following example (Pseudocode)

if (GetCurrentDate() == '13-32-2999') then    WorkCorrectly()

else

ScrewItUpSomehow()

end if

Obviously, a “normal” GetCurrentDate() function will never return ‘13-32-2999′. However, as SecuROM can modify the function’s result, the application can check for the protection’s presence during runtime; if the protection has been removed, the function will return with some other valid value, giving the application the opportunity to display an error message or render the application unusable (e.g. provoking a crash to desktop, making enemies invincible).

There are many different ways how “triggers” can be integrated into a program, making it much more complicated to universally circumvent the protection.

SecuROM v 7.x

Latest SecuROM Versions are all 7.x versions which are released and updated continuously. SecuROM 7.x, if run under a non-admin user account, installs its own service called UAService7.exe, which works in ring 3 of the computer’s operating system.
Securom has said: “it has been developed to enable users without Windows™ administrator rights the ability to access all SecuROM™ features” This has been called malware, and users must use 3rd party tools to remove ‘protection’ after uninstall of product.

MD5 was designed by Ronald Rivest in 1991 to replace an earlier hash function, MD4. In 1996, a flaw was found with the design of MD5; while it was not a clearly fatal weakness, cryptographers began to recommend using other algorithms, such as SHA-1. In 2004, more serious flaws were discovered making further use of the algorithm for security purposes questionable.

Vulnerability

Because MD5 makes only one pass over the data, if two prefixes with the same hash can be constructed, a common suffix can be added to both to make the collision more reasonable.

All that is required to generate two colliding files is a template file, with a 128-byte block of data aligned on a 64-byte boundary, that can be changed freely by the collision-finding algorithm.

Recently, a number of projects have created MD5 “rainbow tables” which are easily accessible online, and can be used to reverse many MD5 hashes into strings that collide with the original input, usually for the purposes of password cracking.

Applications

MD5 digests have been widely used in the software world to provide some assurance that a transferred file has arrived intact. Forexample, file servers often provide a pre-computed MD5 checksum for the files, so that a user can compare the checksum of the downloaded file to it. Unix-based operating systems include MD5 sum utilities in their distribution packages, whereas Windows users use third-party applications.

However, now that it is easy to generate MD5 collisions, it is possible for the person who created the file to create a second file with the same checksum, so this technique cannot protect against some forms of malicious tampering. Also, in some cases the checksum cannot be trusted (for example, if it was obtained over the same channel as the downloaded file), in which case MD5 can only provide error-checking functionality: it will recognize a corrupt or incomplete download, which becomes more likely when downloading larger files.

MD5 is widely used to store passwords. A number of MD5 reverse lookup databases exist, which make it easy to decrypt password hashed with plain MD5. To prevent such attacks you can add a salt to your passwords before hashing them. Also, it is a good idea to apply the hashing function (MD5 in this case) more than once—see key strengthening. It increases the time needed to encode a password and discourages dictionary attacks.

Algorithm

MD5 processes a variable-length message into a fixed-length output of 128 bits. The input message is broken up into chunks of 512-bit blocks; the message is padded so that its length is divisible by 512. The padding works as follows: first a single bit, 1, is appended to the end of the message. This is followed by as many zeros as are required to bring the length of the message up to 64 bits fewer than a multiple of 512. The remaining bits are filled up with a 64-bit integer representing the length of the original message.

The main MD5 algorithm operates on a 128-bit state, divided into four 32-bit words, denoted A, B, C and D. These are initialized to certain fixed constants. The main algorithm then operates on each 512-bit message block in turn, each block modifying the state. The processing of a message block consists of four similar stages, termed rounds; each round is composed of 16 similar operations based on a non-linear function F, modular addition, and left rotation.

Pseudocode

//Note: All variables are unsigned 32 bits and wrap modulo 2^32 when calculating

var int[64] r, k//r specifies the per-round shift amounts
r[ 0..15] := {7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22}
r[16..31] := {5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20}
r[32..47] := {4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23}
r[48..63] := {6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21}

//Use binary integer part of the sines of integers as constants:

for i from 0 to 63
    k[i] := floor(abs(sin(i + 1)) × (2 pow 32))

//Initialize variables:

var int h0 := 0×67452301
var int h1 := 0xEFCDAB89
var int h2 := 0×98BADCFE
var int h3 := 0×10325476

//Pre-processing:

append “1″ bit to message
append “0″ bits until message length in bits ≡ 448 (mod 512)
append bit (bit, not byte) length of unpadded message

as 64-bit little-endian integer to message

//Process the message in successive 512-bit chunks:

for each 512-bit chunk of message
    break chunk into sixteen 32-bit little-endian words w[i], 0 ≤ i ≤ 15

//Initialize hash value for this chunk:

    var int a := h0
    var int b := h1
    var int c := h2
    var int d := h3

//Main loop:

    for i from 0 to 63
        if 0 ≤ i ≤ 15 then
            f := (b and c) or ((not b) and d)
            g := i
        else if 16 ≤ i ≤ 31
            f := (d and b) or ((not d) and c)
            g := (5×i + 1) mod 16
        else if 32 ≤ i ≤ 47
            f := b xor c xor d
            g := (3×i + 5) mod 16
        else if 48 ≤ i ≤ 63
            f := c xor (b or (not d))
            g := (7×i) mod 16
temp := d
        d := c
        c := b
        b := b + leftrotate((a + f + k[i] + w[g]) , r[i])
        a := temp

//Add this chunk’s hash to result so far:

    h0 := h0 + a
    h1 := h1 + b
    h2 := h2 + c
    h3 := h3 + d
var int digest := h0 append h1 append h2 append h3

  //(expressed as little-endian)

  //leftrotate function definition

  leftrotate (x, c)
      return (x << c) or (x >> (32-c));