Page 16

XCP CDs were released.

This strongly suggests that the infringing DRMS code was deliberately copied

by XCP's creator, First4Internet, rather than accidentally included as part of a more general purpose media
library used for other functions in the copy protection system.

This isn't the first time another vendor has tried to make its DRM compatible with FairPlay. FairPlay

is the only DRM compatible with the iPod, and Apple has declined to license it to rival music distributors,
effectively locking rivals out from the iPod platform (at least as long as the rivals insist on using DRM). In
2004, RealNetworks attempted to work around Apple and reverse engineered FairPlay so that Real Player
could create FairPlay files for use with the iPod [9]. Apple responded by making vague legal threats and
updating iTunes to break this compatibility. The evidence suggests that First4Internet wanted to create their
own iPod compatibility system, but rather than take the time to reverse engineer FairPlay themselves, they
copied critical pieces of code from DRMS in violation of the GPL license.

Understanding how XCP uses code from DRMS requires some background information about FairPlay.

When a customer purchases a song from the iTunes Music Store, she receives a FairPlay encrypted audio

file that can only be played with knowledge of a secret key assigned to her by Apple. iTunes retrieves this
key from an Apple server and stores it on the hard drive in an encrypted key database (a file called

Info.sidb

). When the user plays the song again, or if she copies it to an iPod, iTunes reads her key from

the database instead of reconnecting to the server [34].

FairPlay's security depends on the encrypted key database being difficult for anyone but Apple to deci-

pher, so it is protected using a proprietary encryption method and a system-dependent secret key.

iTunes

encrypts the key database using a two step process. First it pads the plaintext database by XORing it with
the output of a proprietary pseudorandom number generator (PRNG) using a system-dependent seed; then
it applies AES encryption in ECB mode with a system-dependent key. As a consequence of this design, the
code for the PRNG is exactly the same whether the file is being encrypted or decrypted. To decrypt, iTunes
applies AES decryption, then XORs the same PRNG output again. This explains why parts of the DRMS
code--in particular, a function called

DoShuffle

, which computes the PRNG's output--are useful for

encryption as well as their original purpose, decryption.

The proprietary PRNG must have been especially difficult to reverse engineer. Rather than expend this

effort themselves, XCP's authors appear to have lifted the DoShuffle code verbatim from DRMS. XCP uses
this code to manipulate the iTunes key database in the process of adding FairPlay protection. Starting with
an unencrypted audio file, such as a track from a protected CD, XCP applies AAC compression in memory,
then encrypts using the same algorithm as FairPlay. Instead of using an Apple-assigned user key, XCP
creates a new random user key and, with the help of the DRMS code, adds it to the iTunes key database.

This ensures that the song file can only be used on the computer where it was created.

The XCP FairPlay compatibility code is contained in a file named

ECDPlayerControl.ocx

that is

installed the first time an XCP CD is played. The code can be tested by jumping to a function at debugger
offset 0x10010380 (apparently the start of a thread for transferring music to iTunes). This function takes
one parameter, a wide character string of the form

. This syntax causes the

function to convert an MP3 file to a FairPlay-protected AAC file. Variations can be used to specify other
audio sources: WAV files, raw audio files, standard unprotected audio CDs, and XCP copy-protected CDs.
Before calling the function, it is necessary to initialize a Windows

CriticalSection

object and set the

ECX

The entry function calls a subroutine (offset 0x10027D20) that converts an audio file into a FairPlay-

protected AAC file. This call another subroutine (offset 0x1008A470) that reads the iTunes key database,

XCP's FairPlay-compatibility code works with iTunes up to iTunes version 4.8. iTunes 4.9, released June 28, 2005, includes

changes unrelated to FairPlay that cause the XCP code to fail. XCP CDs released after this date do not appear to contain an updated
version of the code.

As security experts predicted, this protection was quickly broken. Today DRMS is able to defeat FairPlay because Jon Lech

Johansen reverse engineered the database decryption code in iTunes.