May 21, 2024

CD DRM: Attacks on the Player

Alex and I are working on an academic paper, “Lessons from the Sony CD DRM Episode”, which will analyze several not-yet-discussed aspects of the XCP and MediaMax CD copy protection technologies, and will try to put the Sony CD episode in context and draw lessons for the future. We’ll post the complete paper here later in the week. Until then, we’ll post drafts of a few sections here. We have two reasons for this: we hope the postings will be interesting in themselves, and we hope your comments will help us improve the paper.

Today’s excerpt is the last one we will post. By now, you have seen drafts of the all sections of the paper except the introduction, conclusion, and discussion of related work. The deadline for submission is (late) tomorrow night.

Please note that this is a draft and should not be formally quoted or cited. The final version of our entire paper will be posted here when it is ready.

Attacks on the Player

Increasingly, personal computers—and portable playback devices that attach to them—are users’ primary means of organizing, transporting, and enjoying their music collections. Sony and its DRM vendors recognized their trend when they designed their copy protection technologies. Rather than inhibit all use with PCs, as some earlier anti-copying schemes did~cite{}, XCP and MediaMax allow certain limited uses subject to restrictions imposed by DRM software.

XCP and MediaMax facilitate use on PCs using their own proprietary media players that are shipped on each protected CD. The schemes use active (and, with XCP, passive) protection to block other applications from accessing the CD audio, but a back door allows the scheme’s own player to bypass the protections.

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 player 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. [Footnote: Curiously, this bonus content is seldom copy protected, perhaps because it is of little value.]

XCP and MediaMax both permit users to burn copies of the entire album a limited number of times (typically 3). These copies are create using a proprietary burning application integrated into the player. They include the player applications and 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 [citation[, 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 scheme or burned onto CDs, but the Windows Media files will not be usable if they are copied to another PC.

Attacks on Player DRM

The XCP and MediaMax players were designed to enforce usage restrictions specified by content providers. In practice, they provide minimal security, because there are a number of 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; therefore, 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. In a rollback attack, the state of the machine is backed up 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. The 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. [Footnote: We did not determine how the MediaMax player stores the number of copies remaining.] This file is hidden and protected by the XCP rootkit. With the rootkit disabled, a user can back up the file, copy the album, and then restore the backup to set the remaining copy counter back to its original value.

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 records. For each XCP disc used on the machine, the file contains a whole-disc record and an individual record for each track. Each disc record stores the number of permitted copies remaining for the disc as a 32-bit integer beginning 100 bytes from the start of the record.

The file is protected by primitive encryption. Each record is XORed with a repeating 256-bit pad. The pad—a single one is used for all records—is randomly chosen when XCP is first installed and stored in the system registry in the key HKLMSOFTWARE$sys$referenceClassID. 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. Say the counter indicates that there are x copies remaining and the attacker wants to set it to y copies remaining. Without decrypting the record, she can XOR the padded bytes where the counter is stored with the value (x XOR y). If the original value was padded with p, the new value is (x XOR p) XOR (x XOR y) = (y XOR p), which is just y padded with p.

iPod Compatibility

Ironically, Sony itself furnishes directions for carrying out another kind of 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 with more than 80% of the market [citation]. 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 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.” [citation]. Strictly speaking, it is untrue that Sony requires Apple’s cooperation to work with the iPod. They ship thousands of albums that work “smoothly” with iTunes every day: unprotected CDs. 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 license its proprietary DRM, a system called FairPlay.

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 [citation] —instructions for working around its own copy protection and transforming the music into a DRM-free format that will work with iTunes. 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.

XCP’s Hidden iPod Support

A further irony came to light in the weeks following the public disclosure of the XCP rootkit when it was discovered that XCP itself apparently infringes on the copyrights to several open source software projects. In one case, Sam Hocevar found strong evidence that part of XCP’s code was copied from a program called DRMS, which he co-authored with Jon Lech Johansen and released under the terms of the GPL open source license. This was particularly curious, because the purpose of DRMS is to break Apple’s FairPlay DRM. Its presence is interesting enough to warrant a brief diversion from our discussion of player-related attacks.

We discovered that XCP utilizes the DRMS code not to remove Apple DRM but to add it, as part of a hidden XCP feature that provides iTunes and iPod compatibility. This functionality shipped on nearly every XCP CD, but it was never enabled or made visible in the XCP user interface. Despite being inactive, the code appears to be fully functional and was compatible with the current version of iTunes when the first XCP CDs were released. [Footnote: XCP’s FairPlay-compatibility code works with iTunes up to iTunes version 4.8. iTunes 4.9, released June 28, 2005, included 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.] This strongly suggests that the apparently 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 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 [citation]. 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 a 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 SC 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.

FairPlay’s security depends on the encrypted key database being difficult anyone but Apple to decipher, so it is protected using a proprietary encryption method and a system-dependent secret key. [Footnote: 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.] 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 <m P 3>< "C:test.mp3">. 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, you must initialize a Windows CriticalSection object and set the ECX register to the object’s address minus 0x6C.

The parent function calls a subroutine (offset 0x10027D20) that converts an audio file into a FairPlay-protected AAC file. A second subroutine (offset 0x1008A470) reads the iTunes key database, decrypts it, and, if necessary, adds the XCP user key to the database and re-saves it in encrypted form. The iTunes database encryption function
(0x1008A0C0) and decryption function (0x1008A300) both made use of the DoShuffle routine (0x10089E00) taken from DRMS.

MediaMax Player Security Risks

Besides suffering from several kinds of attacks that expose the music content to copying, the MediaMax player make the user’s system more vulnerable to attack. When a MediaMax CD is inserted into a computer, Windows autorun launched an installer from the disc. Even before the installer displays a license agreement, it copies almost 12 megabytes of files and data related to the MediaMax player to the hard disk and stores them in a folder named
%programfiles%Common FilesSunnComm Shared. Jesse Burns and Alex Stamos of iSec partners first discovered that the MediaMax installer sets insecure permissions on this directory and the files and programs it contains [citation]. The installer grants “Everyone” (all users) the “Full Control” privilege. Normally, application files shared by all users on a Windows system can only be modified by members of the “Administrators” and “Power Users” groups.

As Burns and Stamos realized, this misconfiguration could lead to a dangerous privilege escalation attack. The incorrect permissions allow a non-privileged user to replace the executable code in the MediaMax player files. A user might plant malicious code deliberately in order to attack the system, or accidentally as the result of an email virus. 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 and triggered even more easily—simply by inserting MediaMax CDs without ever consenting to the software’s installation. In the original attack, the user needed to accept the MediaMax license agreement before attack code could be inserted or executed, because the code was placed in a file called MMX.EXE that was not copied to the system until after the agreement was accepted. In our version, the attacker modifies a different file, MediaMax.dll, which MediaMax installs even before displaying a license agreement, and places attack code in the file’s DllMain() procedure. The next time a MediaMax CD is inserted, the installer autoruns and immediately attempts to check the version of the installed MediaMax.dll file. The installer calls the Windows LoadLibrary function on the DLL file, which causes the file’s DllMain() procedure to execute, together with any attack code inserted there.

This problem was exacerbated because part of the MediaMax software are installed automatically and without consent. Users who declined the license agreement would likely assume that MediaMax was not installed, and so most were unaware that they were 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 would give the user a chance to head off the attack.

Fixing the problem permanently without losing the use of protected discs requires applying a patch from MediaMax. Unfortunately, we discovered, the initial patch released by Sony in response to the iSec report was capable of triggering precisely the kind of attack it attempted to forestall. In the process of updating MediaMax, the patch checks the version of MediaMax.dll just like the MediaMax installer does. If this file has already been booby trapped by an attacker, the process of applying the security patch could 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.


  1. Can I ask how or what software can you use to burn music that I have already ripped to my computer but cant burn it onto a disk due to this drm thing….


  2. HI!
    I’m italian, Can you translate this text in italian? i don’t know english very vell.

    Bye bye

  3. Ned Ulbricht says

    These copies are create using a proprietary burning application integrated into the player.

    “create” should be “created”.

    (Although if I were writing, I might be tempted to alter the voice of this sentence.)

  4. the zapkitty says

    Ned Ulbricht Says:
    “A Sony BMG FAQ? Or a SunnComm FAQ?”

    Sony BMG… as it says in the link you reference 🙂

    “SONY BMG has worked out an indirect way for consumers to move content into these environments”

    Of course SuncMax wouldn’t put up data on how to bypass the snake oil they sold Sony… unless Sony requested they do it.

  5. the zapkitty says

    Alan Says:

    “If a sidebar isn’t possible, then adding it as its own section after Player Attacks might do the trick.”

    And now someone beats me to the punch 🙂

    I do agree with Alan: In mid topic you segue from “DRM Media Player Attacks” to “When DRM Media Players attack.”

    Sidelining that, inserting it later, or appending it would work.

    What you need to complete and balance this section is analysis of the Mediamax player. I’d look at it but I can’t get the SuncMax crap to run under Wine in Linux 🙂

  6. Ned Ulbricht says

    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 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.’’ [citation].

    A Sony BMG FAQ? Or a SunnComm FAQ?

    SunnComm FAQ #11.


    Unfortunately, in order to directly and smoothly rip content into iTunes it 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.


  7. Sorry, in my last comment, I only meant that the discussion on XCPs hidden iPod support should be sidebarred, not the subsection about Sony BMG directing users on how to remove the DRM to copy the songs to the iPod.

    Obviously, the Sony directions fit nicely with the “Attacks on DRM” theme (and has delicious poetic irony to-boot).

  8. This series is excellent. Keep up the good work.

    One comment. The lengthy sub-section on the iPod compatibility and XCP copyright infringement detracts from the message of the “Player Attacks” section and makes it a little too long. However, on its own it is good information.

    If possible, putting the iPod compatibility and copyright infringement story in a sidebar (and referencing it from the text where appropriate) would be perfect. If a sidebar isn’t possible, then adding it as its own section after Player Attacks might do the trick.

  9. Ned Ulbricht says

    s/Sony/Sony BMG/g

  10. Thank you so much guys! I’m getting ready to start my Extended Essay for my International Baccalaureate diploma, and I plan to use the final copy as one of my primary sources. My question that I’ll analyse is (Or at least the current question, I’m still tweaking it): What kind of an impact does CD protection technology have on consumers, and is it beneficial? Now that you guys are writing this academic paper, I’ll be able to actually have a reputable source to quote from. (IB tends to like proper sources. They don’t seem to trust just blogs! Hmm…)

    But I just wanted to thank you guys again for all the great work you’ve done on researching all of this. It was actually your site that gave me the idea to write my essay on CD protection technology, since I had been victim of the XCP technology, and I found this while looking for information about it.
    Keep up the great work!

  11. Guys,
    I am just now going back and reading some of the events that have taken place in the last 2 1/2 years. As a part time local recording artist, I personally can not stand the direction that the music industry is drifting towards. It cast a shadow over the very reason why we do it. People like you is what keeps society fair and honest. Keep up the good work, and even us musicians are behind you!

    Drums – Grey Conspiracy

  12. Greetings…I first wanted to commend you for your informative website. Without individuals such as yourselves, these DRM issues would likely not have come to light.
    I have a question which perhaps you have an answer for, or can point me in the right direction. Saturday, Jan 28, I became infected with the Sunncomm Media Max 5 malware, after placing a CD in my drive (My Morning Jacket, Z). I subsequently discovered the Sunncomm folder in the Common Files directory, as well as the sbcphid driver, which was actively running. As your blog has noted, there are security issues associated with the official uninstaller, so I am attempting to remove Media Max myself. The following day (Sunday Jan 29), I used System Restore. I restored my computer back to Saturday, 11:01 am, which was several hours prior to the installation of Media Max. I then inspected my computer, and it seems that the sbcphid driver was no longer present, nor were most of the dozen or so files in the Common Files/Sunncomm folder. I did discover that a subfolder (“Sys”), as well as two .SKN files, remained. I deleted the entire Sunncomm folder, emptied the Recycle Bin, and restarted my computer. I did not disable System Restore. I have since rebooted my computer, and can find no trace of the Sunncomm files. Have I successfully removed Media Max from my computer? Do I need to edit the Registry, or take other action? If so, what?
    Once again, I thank you for your efforts. Any help would be greatly appreciated.

  13. “FairPlay’s security depends on the encrypted key database being difficult anyone but Apple to decipher. l .”

    This should probably read “FairPlay’s security depends on the encrypted key database being difficult for anyone but Apple to decipher. . .”

    It’s interesting to read about all these media files on a user’s hdd that would not be useable if/when the user buys new hardware. Are the vendors really proposing that a consumer pay for all music again when they upgrade their PC? Wasn’t there a counter keeping track of how many times a track was ripped as well as how many times a disk was copied? Consumers would surely revolt when this situation reared its ugly head.

  14. Ned Ulbricht says

    Jesse Burns and Alex Stamos of iSec partners first discovered that the MediaMax installer sets insecure permissions on this directory and the files and programs it contains [citation].

    Media Max Access Control Vulnerability, by Jesse Burns and Alex Stamos (Information Security Partners LLC), 29 Nov 2005, published at Electronic Frontier Foundation website.

  15. Dang – zapkitty beat me to it by about 2 minutes. Apologies for the dupe.

  16. In the section titled “Attacks on Player DRM,” seventh paragraph, second sentence seems to have some words missing at the end (after “without.”)

  17. the zapkitty says

    Something got clipped…

    “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. ”

    Should say something like:

    “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 access to the pad hidden in the registry.”