Lessons from the Sony CD DRM Episode

In the fall of 2005, problems discovered in two Sony-BMG compact disc
copy protection systems, XCP and MediaMax, triggered a public uproar
that ultimately led to class-action litigation and the recall of
millions of discs. We present an in-depth analysis of these
technologies, including their design, implementation, and deployment.
The systems are surprisingly complex and suffer from a diverse array
of flaws that weaken their content protection and expose users to
serious security and privacy risks. Their complexity, and their
failure, makes them an interesting case study of digital rights
management that carries valuable lessons for content companies, DRM
vendors, policymakers, end users, and the security community.

This paper is a case study of the design, implementation, and
deployment of anti-copying technologies. We present a detailed
technical analysis of the security and privacy implications of two
systems, XCP and MediaMax, which were developed by separate companies
(First4Internet and SunnComm, respectively) and shipped on millions of
music compact discs by Sony-BMG, the world's second largest record
company. We consider the design choices the companies faced, examine
the choices they made, and weigh the consequences of those
choices. The lessons that emerge are valuable not only for compact
disc copy protection, but for copy protection systems in general.

The security and privacy implications of Sony-BMG's CD digital rights
management (DRM) technologies first reached the public eye on October
31, 2005, in a blog post by Mark
Russinovich [21]. While testing a rootkit
detector he had co-written, Russinovich was surprised to find an
apparent rootkit (software designed to hide an intruder's
presence [13]) on one of his systems.
Investigating, he found that the rootkit was part of a CD DRM system
called XCP that had been installed when he inserted a Sony-BMG music
CD into his computer's CD drive.

News of Russinovich's discovery circulated rapidly on the Internet,
and further revelations soon followed, from us,1 from Russinovich, and from others. It was discovered
that the XCP rootkit makes users' systems more vulnerable to attacks,
that both CD DRM schemes install risky software components without
obtaining informed consent from users, that both systems covertly
transmit usage information back to the vendor or the music label, and
that none of the protected discs include tools for uninstalling the
software. (For these reasons, both XCP and MediaMax seem to meet the
consensus definition of spyware.) These and other findings outraged
many users.

As the story was picked up by the popular press and public pressure
built, Sony-BMG agreed to recall XCP discs from stores and to issue
uninstallers for both XCP and MediaMax, but we discovered that both
uninstallers created serious security holes on users' systems. Class
action lawsuits were filed soon after, and government investigations
were launched, as Sony-BMG worked to repair relations with its
customers.

While Sony-BMG and its DRM vendors were at the center of this
incident, its implications go beyond Sony-BMG and beyond compact
discs. Viewed in context, it is a case study in the deployment of DRM
into a mature market for recorded media. Many of the lessons of CD
DRM apply to other DRM markets as well.

Several themes emerge from this case study: similarities between DRM
and malicious software such as spyware, the temptation of DRM vendors
to adopt malware tactics, the tendency of DRM to erode privacy, the
strategic use of access control to control markets, the failure of ad
hoc designs, and the force of differing incentives in shaping behavior
and causing conflict.

Outline

The remainder of the paper is structured as follows. Section 2
discusses the business incentives of record labels and DRM vendors,
which drive their technology decisions. Section 3 gives a high-level
technical summary of the systems' design. Sections 4–9 each cover
one aspect of the design in more detail, discussing the design choices
made in XCP and MediaMax and considering alternative designs. We
discuss weaknesses in the copy protection schemes themselves, as well
as vulnerabilities they introduce in users' systems. We cover
installation issues in Section 4, recognition of protected discs in
Section 5, player software in Section 6, deactivation attacks in
Section 7, uninstallation issues in Section 8, and compatibility and
upgrading issues in Section 9. Section 10 explores the outrage users
expressed in response to the DRM problems. Section 11 concludes and
draws lessons for other systems.

The goals of a CD DRM system are purely economic: the system is
designed to protect and enable the business models of the record label
and the DRM vendor. Accordingly, any discussion of goals and
incentives must begin and end by talking about business models. The
record label and the DRM vendor are separate actors whose interests
are not always aligned. Incentive gaps between the label and the DRM
vendor can be important in explaining the design and deployment of CD
DRM systems.

We first examine the record label's goals. Though the label would
like to keep the music from the CD from being made available on
peer-to-peer (P2P) file sharing networks, this goal is not
feasible [4]. If even one user can rip an unprotected copy
of the music and put it on a P2P network, it will be available to the
whole world. In practice, every commercially valuable song appears on
P2P networks immediately upon release, if not sooner. No CD DRM
system can hope to stop this. Real systems do not appear designed to
stop P2P sharing, but seem aimed at other goals.2

The record label's goal must therefore be to retard disc-to-disc
copying and other local copying and use of the music. Stopping local
copying might increase sales of the music—if Alice cannot copy a CD
to give to Bob, Bob might buy the CD himself.

Control over local uses can translate into more revenue for the record
label. For example, if the label can control Alice's ability to
download music from a CD into her iPod, the label might be able to
charge Alice an extra fee for iPod downloads. Charging for iPod
downloads creates new revenue, but it also reduces the value to users
of the original CD and therefore reduces revenue from CD sales.
Whether the new revenue will outweigh the loss of CD revenue is a
complex economic question that depends on detailed assumptions about
users' preferences; generally, increasing the label's control over
uses of the music will tend to increase the label's profit.

Whether the label would find it more profitable to control a use, as
opposed to granting it for free to CD purchasers, is a separate
question from whether copyright law gives the label the right to file
lawsuits relating to that use. Using DRM to enforce copyright law
exactly as written is almost certainly not the record label's
profit-maximizing strategy.

Besides controlling use of the music, CD DRM can make money for the
record label because it puts software onto users' computers, and the
label can monetize this installed platform. For example, each CD DRM
album includes a special application for listening to the protected
music. This application can show advertisements or create other
promotional value for the label; or the platform can gather
information about the user's activities, which can be exploited for
some business purpose. If taken too far, these become spyware
tactics; but they may be pursued more moderately, even over user
objections, if the label believes the benefits outweigh the costs.

The CD DRM vendor's primary goal is to create value for the record
label in order to maximize the price the label will pay for the DRM
technology. In this respect, the vendor's and label's incentives are
aligned.

However, the vendor's incentives diverge from the label's in at least
two ways. First, the vendor has a higher risk tolerance than the
label, because the label is a large, established business with a
valuable brand name, while the vendor (at least in the cases at issue
here) is a start-up company with few assets and not much brand equity.
Start-ups face many risks already and are therefore less averse to
taking on one more risk. The record label, on the other hand, has
much more capital and brand equity to lose if something goes horribly
wrong. Accordingly, we can expect the vendor to be much more willing
to accept security risks than the label.

The second incentive difference is that the vendor can monetize the
installed platform in ways the record label cannot. For example, once
the vendor's DRM software is installed on a user's system, the
software can control use of other labels' CDs, so a larger installed
base makes the vendor's technology more attractive to other labels.
This extra incentive to build the installed base will make the vendor
more aggressive about pushing the software onto users' computers than
the label would be.

In short, incentive differences make the vendor more likely than the
label to (a) cut corners and accept security risks, and (b) push DRM
software onto more users' computers. If the label had perfect
knowledge about the vendor's technology, this incentive gap would not
be an issue—the label would simply insist that the vendor protect
the label's interests. But if, as seems likely in practice, the label
has imperfect knowledge of the technology, then the vendor will
sometimes act against the label's interests. (For a discussion of
differing incentives in another content protection context,
see [9].)

DRM affects more than just the relationships among the label, the
vendor, and the user. It also impacts the label's and vendor's
positions in their industries, in ways that will shape the companies'
DRM strategies.

For example, DRM vendors are in a kind of standards war—a company
that controls DRM standards has power to shape the online music
business. DRM vendors fight this battle by spreading their platforms
widely. Record labels want to play DRM vendors off against each other
and prevent any one vendor from achieving dominance.

Major record companies such as Sony-BMG are parts of larger,
diversified companies, and can be expected to help bolster the
competitive position of their corporate siblings. For example, parts
of Sony sell portable music players in competition with Apple, so
Sony-BMG has an incentive to take steps to weaken Apple's market
power.

Having examined the goals and motivations of the record labels and DRM
vendors, we now turn to a description of the technologies they
deployed.

CD DRM systems must meet difficult requirements. Copy protected discs
must be reasonably compliant with the CD Digital Audio standard so
that they can play in ordinary CD players. They must be unreadable by
almost all computer programs in order to prevent copying, yet the DRM
vendor's own software must be able to read them in order to give the
user some access to the music.

Most CD DRM systems use both passive and active anti-copying measures.
Passive measures change the disc's contents in the hope of confusing
most computer drives and software, without confusing most audio CD
players. Active measures, in contrast, rely on software on the
computer that actively intervenes to block access to the music by
programs other than the DRM vendor's own software.

Active protection software must be installed on the computer somehow.
XCP and MediaMax use Windows autorun, which (when enabled)
automatically loads and runs software from a disc when the disc is
inserted into the computer's drive. Autorun lets the DRM vendor's
software run or install immediately.

Once the DRM software is installed, every time a new CD is inserted
the software runs a recognition algorithm to determine whether the
disc is associated with the DRM scheme. If it is, the active
protection software will interfere with accesses to the disc, except
those originating from the vendor's own music player application.
This proprietary player application, which is shipped on the disc,
gives the user limited access to the music.

As we will discuss further, all parts of this design are subject to
attack by a user who wants to copy the music illegally or who wants to
make uses allowed by copyright law but blocked by the DRM. The user
can defeat the passive protection, stop the DRM software from
installing itself, trick the recognition algorithm, defeat the active
protection software's blocking, capture the music from the DRM
vendor's player, or uninstall the protection software.

The complexity of today's CD DRM software offers many avenues of
attack. On the whole, today's systems are no more resistant to attack
than were simpler early CD DRM systems [10, 11]. When there are fundamental limits to security,
extra complexity does not mean extra security.

Discs Studied

Sony deployed XCP on 52 titles (representing more than 4.7 million
CDs) [1]. We examined three of them in detail:
Acceptance, Phantoms (2005); Susie Suh, Susie Suh
(2005); and Switchfoot, Nothing is Sound (2005). MediaMax
was deployed on 37 Sony titles (over 20 million CDs) as well as dozens
of titles from other labels [1]. We studied three
albums that used MediaMax version 3—Velvet Revolver,
Contraband (BMG, 2004); Dave Matthews Band, Stand Up
(Sony, 2005); and Anthony Hamilton, Comin' from Where I'm
From (Arista/Sony 2005)—and three albums that used MediaMax version
5—Peter Cetera, You Just Gotta Love Christmas (Viastar,
2004); Babyface, Grown and Sexy (Arista/Sony, 2005); and My
Morning Jacket, Z (ATO/Sony, 2005). Unless otherwise noted,
statements about MediaMax apply to both version 3 and version 5.

Active protection measures cannot begin to operate until the DRM
software is installed on the user's system. In this section we
consider attacks that either prevent installation of the DRM software,
or capture music files from the disc in the interval after the
disc has been inserted but before the DRM software is installed
on the computer.

Both XCP and MediaMax rely on the autorun feature of Windows.
Whenever removable media, such as a floppy disc or CD, is inserted
into a Windows PC (and autorun is enabled), Windows looks on the disc
for a file called autorun.inf and executes commands contained in
it. Autorun is commonly used to pop up a splash screen or simple menu
(for example) to offer to install software found on the disc.
However, the autorun mechanism will run any program that the disc
specifies.

Other popular operating systems, including MacOS X and Linux, do not
have an autorun feature, so this mechanism does not work on those
systems. XCP ships only Windows code and so has no effect on other
operating systems. MediaMax ships with both Windows and MacOS code,
but only the Windows code can autorun. The MacOS code relies on the
user to double-click an installer, which few users will do. For this
reason, we will not discuss the MacOS version of MediaMax further.

Current versions of Windows ship with autorun enabled by default, but
the user can choose to disable it. Many security experts advise users
to disable autorun to protect against disc-borne
malware. If autorun is disabled, the
XCP or MediaMax active protection software will not load or run. Even
if autorun is enabled, the user can block autorun for a particular
disc by holding down the Shift key while inserting the
disc [11]. This will prevent the active
protection software from running.

Even without disabling autorun, a user can prevent the active
protection software from loading by covering up the portion of the
disc on which it is stored. Both XCP and MediaMax discs contain two
sessions, with the first session containing the music files and the
second session containing DRM content, including the active protection
software and the autorun command file. The first session begins at
the center of the disc and extends outward; the second session is near
the outer edge of the disc. By covering the outer edge of the disc,
the user can prevent the drive from reading the second session's
files, effectively converting the disc back to an ordinary
single-session audio CD. The edge of the disc can be covered with
nontransparent material such as masking tape, or by writing over it
with a felt-tip marker [19]. Exactly how much of the
disc to cover can be determined by iteratively covering more and more
until the disc's behavior changes, or by visually inspecting the disc
to look for a difference in appearance of the disc's surface which is
often visible at the boundary between the two sessions.

Even if the copy protection software is allowed to autorun, there is a
period of time, between when a protected disc is inserted and when the
active protection software is installed, when the music is vulnerable
to copying. It would be possible to have the discs immediately and
automatically install the active protection software, minimizing this
window of vulnerability, but legal and ethical requirements should
preclude this option. Installing software without first obtaining the
user's consent appears to be illegal in the U.S. under the Computer
Fraud and Abuse Act (CFAA) as well as various state anti-spyware
laws [2, 3].

Software vendors conventionally obtain user consent to the
installation of their software by displaying an End User License
Agreement (EULA) and asking the user to accept it. Only after the
user agrees to the EULA is the software installed. The EULA informs
the user, in theory at least, of the general scope and purpose of the
software being installed, and the user has the option to withhold
consent by declining the EULA, in which case no software is installed.
As we will see below, the DRM vendors do not always follow this
procedure.

If the discs didn't use any other protection measures, the music would
be vulnerable to copying while the installer waited for the user to
accept or reject the EULA. Users could just ignore the installer's
EULA window and switch tasks to a CD ripping or copying application.
Both XCP and MediaMax employ temporary protection mechanisms to
protect the music during this time.

The first time an XCP-protected disc is inserted into a Windows
machine, the Windows autorun feature launches the XCP installer, the
file go.exe located in the contents folder on the
CD. The installer displays a license agreement and prompts the user
to accept or decline it. If the user accepts the agreement, the
installer installs the XCP active protection software onto the
machine; if the user declines, the installer exits after ejecting the
CD, preventing other applications from ripping or copying it.

While the EULA is being displayed, the XCP installer continuously
monitors the list of processes running on the system. It compares the
image name of each process to a blacklist of nearly 200 ripping and
copying applications hard coded into the go.exe program. If
one or more blacklisted applications are running, the installer
replaces the EULA display with a warning indicating that the applications need to be closed in order for the
installation to continue. It also initiates a 30-second countdown
timer; if any of the applications are still running when the countdown
reaches zero, the installer ejects the CD and quits.3

This technique might prevent some unsophisticated users from copying
the disc while the installer is running, but it can be bypassed with a
number of widely known techniques. For instance, users might kill the
installer process (using the Windows Task Manager) before it can
eject the CD, or they might use a ripping or copying application that
locks the CD tray, preventing the installer from ejecting the disc.

The greatest limitation of the XCP temporary protection system is the
blacklist. Users might find ripping or copying applications that are
not on the list, or they might use a blacklisted application but
rename its executable file to prevent the installer from recognizing
it. Since there is no mechanism for updating the blacklist on
existing CDs, they will gradually become easier to rip and copy as new
applications not on the blacklist come into widespread use.
Application developers may also adapt their software to the
blacklisting technique by randomizing their process image names or
taking other measures to avoid detection.4

MediaMax employs a different—and highly controversial—temporary
protection measure. It defends the music while the installer is
running by installing, and at least temporarily activating, the active
protection software before displaying the EULA. The software
is installed without obtaining consent, and it remains installed (and
in some cases, permanently active) even if the user explicitly denies
consent by declining the license agreement.

MediaMax discs install the active protection driver by copying a file
called sbcphid.sys to the Windows drivers directory,
configuring it as a service in the registry, and launching it.
Initially, the driver's startup type is set to “Manual,” so it will
not re-launch the next time the computer boots; however, it remains
running until the computer is shut down, and it remains installed
permanently [11]. Albums that use MediaMax
version 5 additionally install components of the MediaMax player
software before displaying a license agreement. These files are not
removed if the EULA is declined.

Even more troublingly, under some common circumstances—for example,
if the user inserts a MediaMax version 5 CD and declines the EULA and
later inserts a MediaMax CD again—the MediaMax installer will
permanently activate the active protection software (by setting its
startup type to “Auto,” which causes it to be launched every time
the computer boots). This behavior is related to a mechanism in the
installer apparently intended to upgrade the active protection
software if an older version is already installed.

We can think of two possible explanations for this behavior. Perhaps
the vendor, SunnComm, did not test these scenarios to determine what
their software did, and so did not realize that they were activating
the software without consent. Or perhaps they did know what would
happen in these cases and deliberately chose these behaviors. Either
possibility is troubling, indicating either a deficient design and
testing procedure or a deliberate decision to install software after
the user denied permission to do so.

Even if poor testing is the explanation for activating the
software without consent, it is clear that SunnComm deliberately chose
to install the MediaMax software on the user's system even
if the user did not consent. These decisions are difficult to
reconcile with the ethical and legal requirements on software
companies. But they are easy to reconcile with the vendor's platform
building strategy, which rewards the vendor for placing its software
on as many computers as possible.

Even if no software is installed without consent, the temporary
activation of DRM software, by both XCP and MediaMax, before the
user consents to anything raises troubling ethical questions. It is
hard to argue that the user has consented to loading running software
merely by the act of inserting the disc. Most users do not expect the
insertion of a music CD to load software, and although many (but not
all) of the affected discs did contain a statement about protection
software being on the discs, the statements generally were confusingly
worded, were written in tiny print, and did not say explicitly that
software would install or run immediately upon insertion of the disc.
Some in the record industry argue that the industry's desire to block
potential infringement justifies the short-term execution of the
temporary protection software on every user's computer. We think this
issue deserves more ethical and legal debate.

Another way to prevent copying before active protection software is
installed is to use passive protection measures. Passive protection
exploits subtle differences between the way computers read CDs and the
way ordinary CD players do. By changing the layout of data on the CD,
it is sometimes possible to confuse computers without affecting
ordinary players. In practice, the distinction between computers and
CD players is imprecise. Older generations of CD copy protection,
which relied entirely on passive protection, proved easy to copy in
some computers and impossible to play on some CD
players [10]. Furthermore, computer hardware and
software has tended to get better at reading the passive protected CDs
over time as it has become more robust to all manner of damaged or poorly
formatted discs. For these reasons, more recent CD DRM schemes rely
mainly on active protection.

XCP uses a mild variety of passive protection as an added layer of
security against ripping and copying. This form of passive protection
exploits a quirk in the way Windows handles multisession CDs. When CD
burners came to market in the early 1990s, the multisession CD format
was introduced to allow data to be appended to partially recorded
discs. (This was especially desirable at a time when recordable CD
media cost tens of dollars per disc.) Each time data is added to the
disc, it is written as an independent series of tracks called a
session. Multi-session compatible CD drives see all the sessions, but
ordinary CD players, which generally do not support the multisession
format, recognize only the first session.

Some commercial discs use a variant of the multisession format to
combine CD audio and computer accessible files on a single CD. These
discs adhere to the Blue Book or “stamped multisession” format.
According to the Blue Book specification, stamped multisession discs
must contain two sessions: a first session with 1–99 CD audio tracks,
and a second session with one data track. The Windows CD audio driver
contains special support for Blue Book discs. It presents the CD to
player and ripper applications as if it were a normal audio CD.
Windows treats other multisession discs as data-only CDs.

XCP discs deviate from the Blue Book format by adding a second data
track in the second session. This causes Windows to treat the disc as
a regular multisession data CD, so the primary data track is mounted
as a file system, but the audio tracks are invisible to player and
ripper applications that use the Windows audio CD driver. This
includes Windows Media Player, iTunes, and most other widely used CD
applications. We developed a procedure for creating discs with this
passive protection using only standard CD burning hardware and
software.

This variety of passive protection provides only limited resistance to
ripping and copying. There are a number of well-known methods for
defeating it:

Advanced ripping and copying applications avoid the
Windows CD audio driver altogether and issue commands directly to the
drive. This allows programs such as Nero and
Exact Audio Copy to recognize and read
all the audio tracks.

Non-Windows platforms, including MacOS
and Linux, read multisession CDs more robustly and do not suffer from
the limitation that causes ripping problems on Windows.

The felt-tip marker trick, described above, can also
defeat this kind of passive protection. When the second session is
obscured by the marker, CD drives see only the first session and treat
the disc as a regular audio CD, which can be ripped or copied.

The active protection mechanisms employed by XCP and MediaMax
regulate access to raw CD audio, blocking access to the audio tracks
on albums protected with a particular scheme while allowing access to
all other titles.

To accomplish this, the schemes install a background process that
interposes itself between applications and the original CD driver. In
MediaMax, this process is a kernel-mode driver called
sbcphid.sys. XCP uses a pair of filter drivers called
crater.sys and cor.sys that attach to the CD-ROM and
IDE devices [21]. In both schemes, the active
protection drivers examine each disc that is inserted into the
computer to see whether access to it should be restricted. If the disc
is recognized as copy protected, the drivers monitor for attempts to
read the audio tracks, as would occur during a playback, rip, or disc
copy operation, and corrupt the audio returned by the drive to degrade
the listening experience. MediaMax introduces a large amount of random
jitter, making the disc sound like it has been badly scratched or
damaged; XCP replaces the audio with random noise.

Each scheme's active protection software interferes with attempts to
rip or copy any disc that is protected by the same scheme, not merely
the disc from which the software was installed. This requires some
mechanism for identifying discs that are to be protected. In this
section we discuss the security requirements for such a recognition
system, and describe the design and limitations of the
actual recognition mechanism employed by the MediaMax scheme.

Any disc recognition system detects some distinctive feature of discs
protected by a particular copy protection scheme. Ideally such a feature would satisfy four requirements: it
would uniquely identify protected discs without accidentally
triggering the copy protection on other titles; it would be
detectable quickly after reading a limited amount of audio
from the disc; it would be indelible enough that an attacker
could not remove it without significantly degrading the quality of the
audio; and it would be unforgeable, so that it could not be
applied to an unprotected album without the cooperation of the
protection vendor, even if the adversary had access to protected
discs.

This last requirement stems from the DRM vendor's platform building
strategy, which tries to put the DRM software on to as many computers
as possible and to have the software control access to all marked
discs. If the vendor's identifying mark is forgeable, then a record
label could mark its discs without the vendor's permission, thereby
taking advantage of the vendor's platform without
paying.5

To find out how well the disc recognition mechanisms employed by CD
DRM systems meet the ideal requirements, we examined the recognition
system built into MediaMax. This system drew our attention because
MediaMax's creators have touted their advanced disc identification
capabilities, including the ability to identify individual tracks
within a compilation as protected [16]. XCP
appears to use a less sophisticated disc recognition system based on a
marker stored in the data track of protected discs; we did not include
it in this study.

We determined how MediaMax identifies protected albums by tracing the
commands sent to the CD drive with and without the active protection
software running. These experiments took place on a Windows XP VMWare
virtual machine running on top of a Fedora Linux host system, which we
modified by patching the kernel IDE-SCSI driver to log all CD device
activity.

With this setup we observed that the MediaMax software executes a disc
recognition procedure immediately upon the insertion of a CD. The
MediaMax driver reads two sectors of audio at a specific offset from
the beginning of audio tracks—approximately 365 and 366 frames in (a
CD frame stores 1/75 second of sound). On unprotected discs,
the software scans through every track in this way, but on
MediaMax-protected albums, it stops after the first three tracks,
apparently having detected an identifying feature. The software
decides whether or not to block read access to the audio solely on the
basis of information in this region, so we inferred that the
identifying mechanism takes the form of an inaudible watermark
embedded in this part of the audio stream.6

Locating the watermark amid megabytes of audio might have been
difficult, but we had the advantage of a virtual Rosetta Stone. The
actual Rosetta Stone—a 1500 lb. granite slab, unearthed in Rosetta,
Egypt, in 1799—is inscribed with the same text written in three
languages: ancient hieroglyphics, demotic (simplified) hieroglyphics,
and Greek. Comparing these inscriptions provided the key to
deciphering Egyptian hieroglyphic texts. Our Rosetta Stone was a
single album, Velvet Revolver's Contraband, released in three
different versions: a U.S. release protected by MediaMax, a European
release protected by a passive scheme developed by Macrovision, and a
Japanese release with no copy protection. We decoded the MediaMax
watermark by examining the differences between the audio on these
three discs. Binary comparison revealed no differences between the
releases from Europe and Japan; however, the MediaMax-protected U.S.
release differed slightly from the other two in certain parts of the
recording. By carefully analyzing these differences—and repeatedly
attempting to create new watermarked discs using the MediaMax active
protection software as an oracle—we were able to deduce the
structure of the watermark.

The MediaMax watermark is embedded in the audio of each track in 30
clusters of modified audio samples. Each cluster is made up
of 288 marked 16-bit audio samples followed by 104 unaltered
samples. Three mark clusters exactly fit into one 2352-byte CD audio
frame. The watermark is centered at approximately frame 365 of the
track; though the detection routine in the software only reads two
frames, the mark extends several frames to either side of the
designated read target to allow for imprecise seeking in the audio
portion of the disc (a typical shortcoming of inexpensive CD
drives). The MediaMax driver detects the watermark if at least one
mark cluster is present in the region read by the detector.

A sequence of 288 bits that we call the raw watermark is
embedded into the 288 marked audio samples of each mark cluster. A
single bit of the raw watermark is embedded into an unmarked audio
sample by setting one of the three least significant bits to the new
bit value (as shown in bold below) and then setting the two other bits
according to this table:7

Original bits

Marked bits

0__

_0_

__0

1__

_1_

__1

_____________111

011

101

110

111

111

111

_____________110

011

101

110

110

110

111

_____________101

011

101

100

101

110

101

_____________100

011

100

100

100

110

101

_____________011

011

001

010

100

011

011

_____________010

010

001

010

100

010

011

_____________001

001

001

000

100

010

001

_____________000

000

000

000

100

010

001

The position of the embedded bit in each sample follows a fixed
sequence for every mark cluster. Each of the 288 bits is embedded in
the first-, second-, or third-least-significant bit position of the
sample according to this sequence:

The active protection software reads the raw watermark by reading the
first, second, or third bit from each sample according to the sequence
above. It determines whether the resulting 288-bit sequence is a
valid watermark by checking certain properties of the sequence
(represented below). It requires 96 positions in the sequence to have
a fixed value, either 0 or 1. Another 192 positions are divided
into 32 groups of linked values (denoted a–z and
α–ζ below). In each group, three positions share the
same value and three share the complement value. This allows the
scheme to encode a 32-bit value (value A), though in the discs we
studied it appears to take a different random value in each mark
cluster of each protected title. The final 32 bits of the raw
watermark may have arbitrary values (denoted by _ below) and encode a
second 32-bit value (value B). MediaMax version 5 uses this value
to distinguish between original discs and backup copies burned through
it proprietary player application.

The MediaMax watermark fails to satisfy the indelibility and
unforgeability requirements of an ideal disc recognition system. Far
from being indelible, the mark is surprisingly brittle. Most advanced
designs for robust audio watermarks [7, 6]
manipulate the audio in the frequency domain and try to resist
removal attempts that use lossy compression, multiple conversions
between digital and analog formats, and other common
transformations. In contrast, the MediaMax watermark is applied in the
time domain and is rendered undetectable by even minor changes to the
file. An adversary without any knowledge of the watermark's design
could remove it by converting the tracks to a lossy format like MP3
and then burning them back to a CD, which can be accomplished easily
with standard consumer applications. This would result in some minor
loss of fidelity, but a more sophisticated adversary could prevent the
mark from being detected with almost no degradation by flipping the
least significant bit of one carefully chosen sample from each of the
30 watermark clusters, thereby preventing the mark from exhibiting the
pattern required by the detector.

The watermark also fails to satisfy the unforgeability requirement.
The mark's only defense against forgery is its complicated,
unpublished design, but as is often the case this security by
obscurity has proved tedious rather than impossible to defeat. As it
turns out, an adversary needs only limited knowledge of the
watermark—its location within a protected track and its confinement
to the three least significant bits of each sample—to forge it with
minimal loss of fidelity. Such an attacker could transplant the three
least significant bits of each sample within the watermarked region of
a protected track to the corresponding sample from an unprotected
one. Transplanting these bits would cause distortion more audible that
that caused by embedding the watermark since the copied bits are
likely to differ by a greater amount from the original sample values;
however, the damage to the audio quality would be limited since the
marked region is only 0.4 seconds in duration. A more sophisticated
adversary could apply a watermark to an unprotected track by deducing
the full details of the structure of the watermark, as we did; she
could then embed the mark in an arbitrary audio file just as well a
licensed disc producer.

Though MediaMax did not do so, it is straightforward to create
an unforgeable mark using digital signatures. The marking algorithm
would extract a segment of music, compute its cryptographic hash,
digitally sign the hash, and write the hash into the low-order bits of
audio samples elsewhere in the music file. The recognition algorithm
would recompute the hash, and extract and verify the signature.
Though unforgeable, this mark would be no more indelible than the
MediaMax scheme—making an indelible mark is a more difficult
problem.

Increasingly, personal computers—and portable playback devices that
attach to them—are users' primary means of organizing, transporting,
and enjoying their music collections. Sony-BMG and its DRM vendors
recognized this trend when they designed their copy protection
technologies. Rather than inhibit all use with PCs, as some earlier
anti-copying schemes did [10], XCP and MediaMax
provide their own proprietary media players, shipped on each protected
CD, that allow certain limited uses of the music subject to
restrictions imposed by the copyright holder.8

The XCP and MediaMax players launch automatically using autorun when a
protected disc is inserted into a PC. Both players have similar
feature sets. They provide a rudimentary playback interface, allowing
users to listen to protected albums, and they allow access to “bonus
content,” such as album art, liner notes, song lyrics, and links to
artist web sites. The players access music on the disc, despite the
active protection, by using a special back door interface provided by
the active protection software.

XCP and MediaMax version 5 both permit users to burn copies of the
entire album a limited number of times (typically three). These
copies are created using a proprietary burning application integrated
into the player. The copies include the player applications and the
same active (and passive, for XCP) protection as the original album,
but they do not allow any subsequent generations of copying.

Another feature of the player applications allows users to rip the
tracks from the CD to their hard disks, but only in DRM-protected
audio formats. Both schemes support the Windows Media Audio format by
using a Microsoft product, the Windows Media Data Session
Toolkit [17], to deliver DRM licenses
that are bound to the PC where the files were ripped. The licenses
allow the music to be transferred to portable devices that support
Windows Media DRM or burned onto CDs, but the Windows Media files will
not be usable if they are copied to another PC. Because XCP and
MediaMax create Windows Media files, they are vulnerable to any attack
that can defeat Windows Media DRM. Often, DRM interoperation allows
attacks on one system to defeat other systems as well, because the
attacker can transfer protected content into the system of her choice
in order to extract it.

The XCP and MediaMax version 5 players both exhibit similar
spyware-like behavior: phoning home to the vendor or record label with
information about users' listening habits despite statements to the
contrary from the vendors. Whenever a protected disc is inserted, the
players contact web servers to retrieve images or banner ads to
display. Part of the request is a code that identifies the album.
XCP discs contact a Sony web site,
connected.sonymusic.com [20];
MediaMax albums contact license.sunncomm2.com, a site operated
by MediaMax's creator, SunnComm. These connections allow the servers
to log the user's IP address, the date and time, and the identity of
the album. This undisclosed data collection, in combination with
other practices—installation without informed consent and the lack
of an uninstaller—make XCP and MediaMax fit the consensus definition
of spyware.

The XCP and MediaMax version 5 players were designed to enforce usage
restrictions specified by content providers. In practice, they
provide minimal security because there are many ways that users can
bypass the limitations. Perhaps the most interesting class of attacks
targets the limited number of burned copies permitted by the players.
Both players are designed to enforce this limit without communicating
with any networked server; thus, the player must keep track of how
many allowed copies remain by storing state on the local machine.

It is well known that DRM systems like this are vulnerable to rollback
attacks. A rollback attack backs up the state of the machine before
performing the limited operation (in this case, burning the copy).
When the operation is complete, the old system state is restored, and
the DRM software is not able to determine that the operation has
occurred. This kind of attack is easy to perform with virtual machine
software like VMWare, which allows the entire state of the system to
be saved or restored in a few clicks. XCP and MediaMax both fail
under this attack, which allows unlimited copies to be burned with
their players.

A refined variation of this attack targets only the specific pieces of
state that the DRM system uses to remember the number of copies
remaining. The XCP player uses a single file,
%windir%\system32\$sys$filesystem\$sys$parking, to record how
many copies remain for every XCP album that has been used on the
system.9 Rolling back
this file after a disc copy operation would restore the original
number of copies remaining.

A more advanced attacker can go further and modify the
$sys$parking file to set the counter to an arbitrary value.
The file consists of a 16 byte header followed by a series of 177 byte
structures. For each XCP disc used on the machine, the file contains a
whole-disc structure and an individual structure for each track. Each disc
structure stores the number of permitted copies remaining for the disc as
a 32-bit integer beginning 100 bytes from the start of the structure.

The file is protected by primitive encryption. Each structure is XORed
with a repeating 256-bit pad. The pad—a single pad is used for all
structures—is randomly chosen when XCP is first installed and stored in
the system registry in the key
HKLM\SOFTWARE\$sys$reference\ClassID. Note that
this key, which is hidden by the rootkit, is intentionally misnamed
“ClassID” to confuse investigators. Instead of a ClassID, it
contains the 32 bytes of pad data.

Hiding the pad actually doesn't increase the security of the design.
An attacker who knows only the format of the $sys$parking
file and the current number of copies remaining can change the counter
to an arbitrary value without needing to know the pad. Say the
counter indicates that there are x copies remaining and the attacker
wants to set it to y copies remaining. Without decrypting the
structure, she can XOR the padded bytes where the counter is stored with
the value x ⊕ y. If the original value was padded with p,
the new value will be (x ⊕ p) ⊕ (x ⊕ y) = (y ⊕ p),
y padded with p.

Ironically, Sony itself furnishes directions for carrying out another
attack on the player DRM. Conspicuously absent from the XCP
and MediaMax players is support for the Apple iPod—by far the most
popular portable music player. A Sony FAQ blames Apple for this
shortcoming and urges users to direct complaints to them:
“Unfortunately, in order to directly and smoothly rip content into
iTunes it [sic.] requires the assistance of Apple. To date, Apple has not
been willing to cooperate with our protection vendors to make ripping
to iTunes and to the iPod a simple experience.” [23].
Strictly speaking, it is untrue that Sony requires Apple's cooperation
to work with the iPod, as the iPod can import MP3s and other open
formats. What Sony has difficulty doing is moving music to the iPod
while keeping it wrapped in copy protection. This is because Apple
has so far refused to support interoperation with its FairPlay DRM.

Yet so great is consumer demand for iPod compatibility that Sony gives
out—to any customer who fills out a form on its web
site [22]—instructions for working around its own
copy protection and transforming the music into a DRM-free format that
will work with the iPod. The procedure is simple but cumbersome: users
are directed to use the player software to rip the songs into Windows
Media DRM files; use Windows Media Player to burn the files to a blank
CD, which will be free of copy protection; and then use iTunes to rip
the songs once more and transfer them to the iPod.

Besides suffering from several kinds of attacks that expose the music
content to copying, the MediaMax version 5 player makes the user's
system more vulnerable to attack. When a MediaMax CD is inserted into
a computer, Windows autorun launches an installer from the disc. Even
before displaying a license agreement, MediaMax copies almost twelve
megabytes of files and data related to the MediaMax player to the hard
disk. Jesse Burns and Alex Stamos of iSEC
Partners discovered that the MediaMax installer sets file
permissions that allow any user to modify its code directory and the
files and programs in it [5].

As Burns and Stamos realized, the lax permissions allow a
non-privileged user to replace the executable code in the MediaMax
player files with malicious code. The next time a user plays a
MediaMax-protected CD, the attack code will be executed with that
user's security privileges. The MediaMax player requires Power User
or Administrator privileges to run, so it's likely that the attacker's
code will run with almost complete control of the system.

Normally, this problem could be fixed by manually correcting the
errant permissions. However, MediaMax aggressively updates the
installed player code each time the software on a protected disc
autoruns or is launched manually. As part of this update, the
permissions on the installation directory are reset to the insecure
state.

We discovered a variation of the attack suggested by Burns and Stamos
that allows the attack code to be installed even if the user has never
consented to the installation of MediaMax, and to be triggered
immediately whenever the user inserts a MediaMax CD. In
our attack, the attacker places hostile code in the DllMain
procedure of a code file called MediaMax.dll, which MediaMax
installs even before displaying the EULA. The next time a MediaMax CD
is inserted, the installer autoruns and immediately attempts to check
the version of the installed MediaMax.dll file. To do this,
the installer calls the Windows LoadLibrary function on the
DLL file, which causes the file's DllMain procedure to
execute, along with any attack code placed there.

This problem is exacerbated because parts of the MediaMax software are
installed automatically and without consent. Users who have declined
the EULA likely assume that MediaMax has not been installed, and so
most will be unaware that they are vulnerable. The same installer
code performs the dangerous version check as soon as the CD is
inserted. A CD that prompted the user to accept a license before
installing code would give the user a chance to head off the attack.

Fixing this problem permanently without losing the use of protected
discs requires installing a patch from SunnComm. Unfortunately, as we
discovered, the initial patch released by Sony-BMG in response to the
iSEC report was capable of triggering precisely the kind of attack it
was supposed to prevent. In the process of updating MediaMax, the
patch checked the version of MediaMax.dll just like the
MediaMax installer does. If this file was already modified by an
attacker, the process of applying the security patch would execute the
attack code. Prior versions of the MediaMax uninstaller had the same
vulnerability, though both the uninstaller and the patch have since
been replaced with versions that do not suffer from this problem.

Active protection methods install and run software components that
interfere with accesses to a CD. Users can remove or deactivate the
active protection software by using standard system administration
tools that are designed to find, characterize, and control the
programs installed on a machine. Deactivating the protection will
enable arbitrary use or ripping of the music, and it is difficult to
stop if the user has system administrator privileges. In this
section, we discuss how active protection may be deactivated.

The MediaMax active protection software is easy to deactivate, being
comprised of a single device driver named sbcphid.
The driver can be removed by using the
Windows command sc delete sbcphid to stop the driver, and
then removing the sbcphid.sys file containing the driver
code. MediaMax-protected albums can then be accessed freely.

To counter deactivation attempts, a vendor might try technical tricks
to evade detection and frustrate removal of the active protection
software. An example is the rootkit-like behavior of XCP, discovered
by Mark Russinovich [21]. When XCP installs its
active protection software, it also installs a second program—the
rootkit—that conceals any file, process, or registry key whose name
begins with the prefix $sys$. The result is that XCP's
main installation directory, and most of its registry keys, files, and
processes, become invisible to normal programs and administration
tools.

The rootkit is a kernel-level driver named $sys$aries that
is set to automatically load early in the boot process. When the
rootkit starts, it hooks several Windows system calls by modifying the
system service dispatch table (the kernel's
KeServiceDescriptorTable structure) which is an array of
pointers to the kernel functions that implement basic system calls.
The rootkit modifies the behavior of four system calls:
NtQueryDirectoryFile, NtCreateFile,
NtQuerySystemInformation, and
NtEnumerateKey.10 These calls are
used to enumerate files, processes, and registry entries. The rootkit
filters the data returned by these calls to hide items whose names
begin with $sys$.

On intercepting a function call, the rootkit checks the name of the
calling process. If the name of the calling process begins with
$sys$, the rootkit returns the results of the real kernel
function without alteration so that XCP's own processes have an
accurate view of the system.

The XCP rootkit increases users' vulnerability to attack by allowing
any software to hide—not just XCP. Malware authors can exploit the
fact that any files, registry keys, or processes with names beginning
in $sys$ will be hidden, thereby saving the trouble of
installing their own rootkits. Malware that lacks the privileges to
install its own rootkit can still rely on XCP's rootkit.

Only kernel-level processes can patch the Windows system
service dispatch table, and only privileged users—normally, members
of the Administrators or Power Users groups—can install
such processes. (XCP itself requires these privileges to install.)
Malicious code running as an unprivileged user can't normally install
a rootkit that intercepts system calls. But if the XCP rootkit is
installed, it will hide all programs that adopt the $sys$
prefix so that even privileged users will be unable to see them. This
vulnerability has already been exploited by at least two Trojan
horses seen in the wild [15, 14].

The rootkit opens at least one more security vulnerability. The
modified functions do not check for errors as carefully as the
original Windows functions do, so the rootkit makes it possible for an
ordinary program to crash the system by calling one of the hooked
functions, for example by calling NtCreateFile with an
invalid ObjectAttributes argument. We do not believe this
vulnerability can be exploited to run arbitrary code.

Deactivating XCP's active protection is more complicated because it
comprises several processes that are more deeply entangled in the
system configuration, and are hidden by the XCP rootkit. Deactivation
requires a three-step procedure.

The first step is to deactivate and remove the rootkit, by the same
procedure used to deactivate MediaMax (except that the driver's name
is aries.sys). Disabling the rootkit and then rebooting
exposes the previously hidden files, registry entries, and processes.

The second step is to edit the registry to remove references to XCP's
filter drivers and CoDeviceInstallers. XCP uses the Windows filter
driver facility to intercept commands to the CD drives and IDE bus.
If the code for these filter drivers is removed but the entries
pointing to that code are not removed from the registry, the CD and
IDE device drivers will fail to initialize. This can cause the CD
drives to malfunction, or, worse, can stop the system from booting if
the IDE device driver is disabled. The registry entries can be
eliminated by removing any reference to a driver named
$sys$cor from any registry entries named
UpperDrivers or LowerDrivers, and removing any lines
containing $sys$caj from any list of CoDeviceInstallers in
the registry.

The third step is to delete the XCP services and remove the XCP
program files. Services named $sys$lim,
$sys$oct, $sys$drmserver, cd_proxy,
and $sys$cor can be deactivated using the sc
delete command, and then files named crater.sys,
lim.sys, oct.sys, $sys$cor.sys,
$sys$caj.dll, and $sys$upgtool.exe can be
deleted. After rebooting, the two remaining files named
CDProxyServ.exe and $sys$DRMServer.exe can be removed.

Performing these steps will deactivate the XCP active protection,
leaving only the passive protection on XCP CDs in force. The procedure
easily could be automated to create a point-and-click removal tool.

The use of rootkits and other spyware tactics harms users by
undermining their ability to manage their computers. If users lose
effective control over which programs run on their computers, they can
no longer patch malfunctioning programs or remove unneeded programs.
Managing a system securely is difficult enough without spyware
tactics making it even harder.

Though it is no surprise that spyware tactics would be attractive to
DRM designers, it is a bit surprising that mass-market DRM vendors
chose to use those tactics despite their impact on users. If only one
vendor had chosen to use such tactics, we could write it off as an
aberration. But two vendors made that choice, which is probably not a
coincidence. We suspect that the vendors let the lure of platform
building override the risk to users.

Ultimately, there is little a CD DRM vendor can do to stop users from
deactivating active protection software. Vendors' attempts to
frustrate users' control of their machines are harmful and will trigger
a strong backlash from users. In practice, vendors will probably have
to provide some kind of uninstaller—users will insist on it, and
some users will need it to deal with the bugs and incompatibilities
that crop up inevitably in complex software. Once an uninstaller is
released, users can use it to remove the DRM software. Determined
users will be able to keep CD DRM software off of their machines.

The DRM vendors responded to user complaints about spyware-like
behavior by offering uninstallers that would remove their software
from users' systems. Uninstallers had been available before but were
very difficult to acquire. For example, to get the original XCP
uninstaller, a user had to fill out an online form involving personal
information, then wait a few days for a reply email, then fill out
another online form and install some software, then wait a few days
for yet another email, and finally click a URL in the last email. It
is hard to explain the complexity of this procedure, except as a way
to deter users from uninstalling XCP.

The uninstallers, when users did manage to get them, did not behave
like ordinary software uninstallers. Normal uninstallers are programs
that can be acquired and used by any user who has the software. The
first XCP uninstaller was customized for each user so that it would
only work for a limited time and only on the computer on which the
user had filled out the second form. This meant, for example, that if
a user uninstalled XCP but it was reinstalled later—say, if the user
inserted an XCP CD—the user could not use the same uninstaller again
but would have to go through the entire process again to request a new
one.

Customizing the uninstaller is more difficult, compared to a
traditional uninstaller, for both vendor and user, so it must benefit
the vendor somehow. One benefit is to the vendor's platform building
strategy, which takes a step backward every time a user uninstalls the
software. Customizing the uninstaller allows the vendor to control
who receives the uninstaller and to change the terms under which it is
delivered.

As user complaints mounted, Sony-BMG announced that unrestricted
uninstallers for both XCP and MediaMax would be released from the
vendors' web sites. Both vendors chose to make these uninstallers
available as ActiveX controls. By an unfortunate coincidence, both
uninstallers turned out to open the same serious vulnerability on any
computer where they were used.

The original MediaMax uninstaller uses a proprietary ActiveX control,
AxWebRemove.ocx, created and signed by SunnComm. Users
visiting the MediaMax uninstaller web page are prompted to install the
control, then the web page uninstalls MediaMax by invoking one of the
control's methods.

This method, Remove, takes a URL and a numeric key as
arguments. Remove contacts the URL, passing it the key. If
the server finds the key to be valid, it returns another URL for the
uninstaller. The ActiveX control downloads code from the uninstaller
URL and then executes it. After running the uninstaller, the ActiveX
control contacts the server again to notify it that the key had been
used. MediaMax has been removed, but the ActiveX control remains on
the user's system.

At this point, a malicious attacker's web page can invoke the
control's Remove method, passing it a URL pointing to a
malicious server controlled by the attacker. The control could
contact this server, and then download and run code from a location
supplied by the malicious server. By this method, an adversary could
run arbitrary code on the user's system.

The flaw in this design, of course, is that MediaMax ActiveX control
does not validate the URL it is passed, and does not validate the
downloaded code before running it. Validating these
items, perhaps using digital signatures, would have eliminated the
vulnerability.

The original XCP uninstaller contains the same design flaw and is only
slightly more difficult to exploit. XCP's ActiveX-based uninstaller
invokes a proprietary ActiveX control named CodeSupport.ocx.
Usually this control is installed in the second
step of the three-step XCP uninstall process. In this step, a
pseudorandom code generated by the ActiveX control is sent to the XCP
server. The same code is written to the system registry. Eventually
the user receives an email with a link to another web page that uses
the ActiveX control to remove XCP, but only after verifying that the
correct code is in the registry on the local system. This check
tethers the uninstaller to the machine from which the uninstallation
request was made. Due to this design, the vulnerable control may be
present on a user's system even if she never performed the step in the
uninstallation process where XCP is removed.

Matti Nikki first noted that the XCP ActiveX control contains
suspiciously-named methods, including InstallUpdate(url),
Uninstall(url), and RebootMachine() [18]. He
demonstrated that the control was still present after the XCP
uninstallation was complete, and that its methods (including one that
rebooted the computer) were scriptable from any web page without
further browser security warnings.

We found that the InstallUpdate and Uninstall
methods have an even more serious flaw. Each takes as an argument a
URL pointing to a specially formatted archive that contains updater or
uninstaller code and data files. When these methods are invoked, the
archive is retrieved from the provided URL and stored in a temporary
location. For the InstallUpdate method, the ActiveX
control extracts from the archive a file named InstallLite.dll
and calls a function in this DLL named InstallXCP.

Like the MediaMax ActiveX control, the XCP control does not validate
the download URL or the downloaded archive. The only barrier to using
the control to execute arbitrary code is the proprietary format of the
archive file. We determined the format by disassembling the control.
The archive file consists of several blocks of gzip-compressed data,
each storing a separate file and preceded with a short header. At the
end of the archive, a catalog structure lists metadata for each of the
blocks, including a 32-bit CRC. The control verifies this CRC before
executing code from the DLL.

With knowledge of this file format, we were able to construct an
archive containing (benign proof-of-concept) exploit code, and a web
page that would install and run our code on a user's system without
any browser security warnings, on a computer containing the XCP
control. The same method would allow a malicious web site to execute
arbitrary code on the user's machine. Like the MediaMax uninstaller
flaw, this problem is especially dangerous because users who have
completed the uninstallation may not be aware that they are still
vulnerable.

Obviously, these vulnerabilities could have been prevented by careful
design and programming. But they were only possible at all because
the vendors chose to deliver the uninstallers via this ActiveX method
rather than using an ordinary download. We conjecture that the
vendors made this choice because they wanted to retain the ability to
rewrite, modify, or cancel the uninstaller later, in order to further
their platform building strategies.

Compared to other media on which software is distributed, compact
discs have a very long life. Many compact discs will still be
inserted into computers and other players twenty years or more after
they are first bought. If a particular version of DRM software is
shipped on a new CD, that software version may well try to install
and run decades after it was developed. The same is not true of most
software, even when shipped on a CD-ROM. Very few if any of today's
Windows XP CDs will be inserted into computers in 2026; but today's
music CDs will be, so their DRM software must be designed carefully
for future compatibility.

The software should be designed for safety, so as not to cause
crashes or malfunction of other software, and may be designed for efficacy, to ensure that its anti-copying features remain effective.

Safety is easier to achieve, and probably more important. One
approach is to design the DRM software to be inert and harmless on
future systems. Both XCP and MediaMax do this by relying on Windows
autorun, which is likely to be disabled in future versions of Windows for
security reasons. If the upcoming Windows Vista disables autorun by
default, XCP and MediaMax will be inert on most Vista systems.
Perhaps XCP and MediaMax used autorun for safety reasons; but more
likely, this choice was expedient for other reasons.

Another safety technique is to build in a sunset date after which the
software will make itself inert. A sunset would improve safety but
would have relatively little effect on record label revenue for most
discs, as we expect nearly all revenue from the disc to have been
extracted from the customer in the first three years after she buys
it. If in the future more copies of the album are pressed, these could
have updated DRM software with a later sunset.

When a new version of DRM software is released, it can be shipped on
newly pressed CDs, but existing CDs cannot be modified retroactively.
Updates for existing users can be delivered either by download or on
new CDs. Downloads are faster but require an Internet connection; CD
delivery is slower but can reach non-networked machines.

Users will generally cooperate with updates that help them by
improving safety or making the software more useful. But
updates to retain the efficacy of the software's usage controls will
not be welcomed by users.

Users have many ways to stop updates from downloading or installing,
such as write-protecting the software's code so that it cannot
be updated, or using a personal firewall to block network connections
to the vendor's download servers. System security tools, which are
designed generally to stop unwanted network connections, downloads,
and code installation, can be set to treat CD DRM software as malware.

A DRM vendor who wants to deliver unwanted updates has two options.
First, the vendor can simply offer updates and hope some users will
not bother to block them. For the vendor and record label, this is
better than nothing. Alternatively, the vendor can try to force users
to accept updates.

If a user has the ability to block DRM software updates, a vendor who
wants an update must somehow convince the user that updating is in her
best interest. One approach is to make a non-updated system painful
to use.

Ruling out dangerous and legally risky tactics such as logic bombs
that destroy the user's system or hold her (unrelated) data hostage,
the vendor's strongest tactic for forcing updates is to make the DRM
software block all access to protected CDs until the user accepts an
update. The DRM software might check with a network server, which
periodically would produce a digitally signed and dated certificate
listing allowed versions of the DRM software. If the software on the
user's system found that its version number was not on the list (or if
it could not get a recent list), it would block all access to
protected discs. The user would then have to update to a new version
to get access to her protected CDs.

This approach would convince some users to update, and would thereby
prolong the DRM's efficacy for those users. But it has several
drawbacks. If the computer is not networked, the software will
eventually lock down because it cannot get certificates. (If the
software kept working in this case, users could avoid updates by
preventing the DRM software from making network connections.) A bug
in the software could cause an accidental but irreversible lockdown.
Or the software could lock itself down if the vendor's Internet site is
shut down, for example if the vendor goes bankrupt.

Strong-arm tactics can also be counterproductive, by giving the user
further reason to defeat or remove the DRM software.11 The software is more likely to remain on
the user's system if it does not behave annoyingly. Trying to force
updates can reduce the DRM system's efficacy if it convinces users to
remove the DRM altogether.
From the user's standpoint, every software update is a security
risk—a possible vector for hostile or buggy code.

Given the problems with forced updates, and the user backlash they
likely would have triggered, we are not surprised that neither XCP nor
MediaMax tried to force updates.

One notable aspect of the Sony CD DRM episode was the level of outrage
expressed by users. All too frequently, bugs in popular software products
endanger users' security or privacy, and users just grumble and update
their software. Users' anger over the CD DRM episode was much more
intense. What made this issue so different?

There are three answers. First, many users did not expect audio CDs
to contain software. Users did not want the software, and they
recognized that Sony-BMG chose to include it anyway. Unlike (say) an
email client, which necessarily includes complex software components
that might have bugs, CDs need not include software, so users are less
willing to accept the risk of security problems in order to get CDs.

Second, some harmful aspects of the CD DRM software reflected
deliberate choices by the vendors (and by extension, Sony-BMG). Users
who might be willing to forgive implementation errors will not accept
the deliberate introduction of security and privacy risks. There can
be little question that XCP's rootkit functionality, the installation
without consent of MediaMax software, the lack of uninstallers, and
phone-home behavior were put in place deliberately by the vendors.

Third, when the vendors did make apparent implementation errors, the
errors were compounded by the products' aggressive installation and
reluctant uninstallation mechanisms. For example, the file permission
problem discovered by Burns and Stamos was difficult to fix because
the MediaMax autorun program aggressively reset the permissions to
dangerous values, without asking the user for permission, every time a
disc was inserted. Similarly, the vendors' apparent desire to limit
use of their uninstallers led to designs that relied on downloading
code using ActiveX controls—leaving users just one bug away from
critical code-download vulnerabilities.

These factors led some users to conclude that Sony-BMG and the DRM
vendors not only put their own business interests ahead of their
customers' interests, but also made deliberate choices that endangered
customers' security and privacy. Users who would have forgiven a few
implementation mistakes by a well-intentioned vendor were not so quick
to forgive when they felt the vulnerabilities were less than
accidental.

Though Sony-BMG and other copyright owners will presumably tread more
carefully in the future, there remains a fundamental tension between
DRM vendors' desire to control and limit how computers are used, and
the need of users to manage their own systems. Users and DRM
distributors will continue to struggle for control of users'
computers.

Our analysis of Sony-BMG's CD DRM carries wider lessons for content
companies, DRM vendors, policymakers, end users, and the security
community. We draw six main conclusions.

First, the design of DRM systems is driven strongly by the incentives
of the content distributor and the DRM vendor, but these incentives
are not always aligned. Where they differ, the DRM design will not
necessarily serve the interests of copyright owners, not to mention
artists.

Second, DRM, even if backed by a major content distributor, can expose
users to significant security and privacy risks. Incentives for
aggressive platform building drive vendors toward spyware tactics that
exacerbate these risks.

Third, there can be an inverse relation between the efficacy of DRM
and the user's ability to defend her computer from unrelated security
and privacy risks. The user's best defense is rooted in understanding
and controlling which software is installed, but many DRM systems rely
on undermining this understanding and control.

Fourth, CD DRM systems are mostly ineffective at controlling uses of
content. Major increases in complexity have not increased their
effectiveness over that of early schemes, and may in fact have made things
worse by creating more avenues for attack. We think it unlikely that
future CD DRM systems will do better.

Fifth, the design of DRM systems is only weakly connected to the
contours of copyright law. The systems make no pretense of enforcing
copyright law as written, but instead seek to enforce rules dictated
by the label's and vendor's business models. These rules, and the
technologies that try to enforce them, implicate other public policy
concerns, such as privacy and security.

Acknowledgments

We are grateful for the expert legal advice of Deirdre Mulligan and
her colleagues at U.C. Berkeley: Aaron Perzanowski, Sara Adibisedeh,
Azra Medjedovic, Brian W. Carver, Jack Lerner, and Joseph Lorenzo
Hall. We are also grateful to Clayton Marsh at Princeton. Sadly,
research of this type does seem to require support from a team of
lawyers.

We thank the readers of Freedom to Tinker for their comments on
partial drafts that we posted there; thanks especially to C. Scott
Ananian, Randall Chertkow, Tim Howland, Edward Kuns, Jim Lyon, Tobias
Robison, Adam Shostack, Ned Ulbricht, and several pseudonymous
commenters. Jeff Dwoskin provided valuable technical assistance, and
Shirley Gaw, Janek Klawe, and Harlan Yu gave helpful feedback. We are
also grateful to the anonymous reviewers for their suggestions.
Thanks to Claire Felten for help with copy editing.

This material is based upon work supported under a National Science
Foundation Graduate Research Fellowship. Any opinions, findings,
conclusions or recommendations expressed in this publication are those
of the authors and do not necessarily reflect the views of the
National Science Foundation.

As news of the
rootkit spread, we added to the public discussion with a series of 27
blog posts analyzing XCP and MediaMax. This paper provides a more
systematic analysis, along with much new information. Our original
blog entries can be read at
http://www.freedom-to-tinker.com/?cat=30&m=2005.

Music
industry rhetoric about DRM often focuses on P2P, and some in
the industry probably still think that DRM can stop P2P sharing. We
believe that industry decision makers know otherwise. The design of
the systems we studied in this paper supports this
view.

Similar
application blacklisting techniques have been used in other security
contexts. The client software for World of Warcraft, a massively
multiplayer online role playing game, checks running applications
against a regularly updated blacklist of programs used to cheat in the
game [12].

Forging a mark is probably not copyright
infringement. Unlike the musical work in which it is embedded, the
mark itself is functional and contains little or no expression, and
therefore seems unlikely to qualify for copyright protection. In
principle, the mark recognition process could be covered by a patent,
but we are unaware of any such patent relating to XCP or MediaMax.
Even if the vendor does have a legal remedy, it seems worthwhile to
design the mark to prevent forgery if the cost of doing so is low.

By locating the
watermark nearly five seconds after the start of the track rather than
at the very beginning, MediaMax reduces the likelihood that it will
occur in a very quiet passage (where it might be more audible) and
makes cropping it out more destructive.

This design seems to be intended to
lessen the audible distortion caused by setting one of the bits to the
watermark value. The change in the other two bits reduces the
magnitude of the difference from the original audio sample, but it
also introduces a highly uneven distribution in the three least
significant bits that makes the watermark easier to detect or remove.

The
restrictions imposed by the DRM players only loosely track the
contours of copyright law. Some uses that could be prohibited under
copyright—such as burning three copies to give to friends—are
allowed by the software, while some perfectly legal uses—like
transferring the music to one's iPod—are prevented.

This file is hidden and protected by the XCP rootkit.
Before the user can access the file, the rootkit must be disabled, as
described in Section 7.2. We did not determine how the
MediaMax player stores the number of copies remaining.