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.

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.