March 29, 2024

CD DRM: Attacks on Disc Recognition

Ed 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 next Friday. 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 from the middle of the paper, where we’re wading through details about the copy protection systems and the techniques they use to recognize protected CDs.

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 Disk Recognition

The active protection mechanisms introduced earlier selectively 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 attached to the CD-ROM and IDE devices called crater.sys and cor.sys. 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 ripped audio sound like it has come from a badly scratched or damaged CD; 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. This section discusses the security requirements for such a recognition system, describes the design and limitations of the actual recognition mechanism employed by the MediaMax scheme, and presents an improved design that better satisfies the requirements.

Recognition Requirements

Any disc recognition system must involve detecting some identifying feature on discs protected by a particular scheme. Ideally, such a feature would satisfy these requirements:

  1. Uniqueness. The feature should identify protected discs without accidentally triggering the copy protection on unprotected titles.
  2. Detectability. It should be possible for the active protection drivers running on client systems to reliably and quickly detect the feature in protected discs. In practice, this limits the amount of audio that can be read from the disc before deciding whether to apply protection.
  3. Indelibility. The feature should be difficult to remove without substantially degrading the quality of the audio; that is, it should be difficult to make a copy of the copy protected disc that does not itself trigger the protection.
  4. Unforgeability. It should be difficult to apply the feature to an unprotected album without the cooperation of the protection vendor, even if the adversary has access to protected discs.

This last requirement stems from the business strategies of the copy protection vendors. As discussed in earlier, many of these vendors are pursuing a platform building strategy. The biggest obstacle to the success of an active protection system is getting the protection software installed on client machines. Once installed, the software can regulate access to all discs protected by the scheme, even if the user learns to disable autorun or refuse future CD DRM installation requests. Thus each completed installation increases the effectiveness of the protection platform and heightens its value to the protection vendor and its music label clients.

Being widely installed adds value to these copy protection systems, but it also exposes them to a new class of attacks. The protection companies earn revenue from record labels who license their schemes, typically paying some fee per title or per copy. This revenue stream may be threatened if disc publishers can mark their discs as protected without paying.

There are advantages and disadvantages for the person placing the unauthorized marks. Copyright would prohibit rogue publishers from distributing an installer for the active protection software, though they might depend on the existing installed base from licensed titles. They would also be prevented from employing the components of the protection software that allow users to access restricted copies of the music; however, they could create their own software to provide this capability if they desired. On the other hand, free riding publishers would not be restricted to marking their disc for only one scheme. By identifying their discs as copy protected with multiple schemes, they could invoke multiple layers of security and provide stronger protection than is available with any single technique, all without paying. (It is possible that protection producers could have legal remedies against such free riders, such as through a patented identification feature, but we are unaware of any patents that cover the identification features known to be in use. Even if some kind of legal remedy is available, it’s worth designing the mark to prevent the problem too, at least if the cost of doing so is low.) Preventing free riding by publishers requires some kind of disc authentication mechanism to control access to installed active protection software—a meta-copy protection technique.

How MediaMax Recognizes Protected Discs

To find out how the disc recognition mechanisms employed by CD DRM systems stack up the ideal requirements, we examined the recognition system built into MediaMax CD-3 and MM-5 systems. The MediaMax 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, and well as their platform-building strategy. (The XCP scheme appears to use a less sophisticated disc recognition system based on a marker stored in the data track of protected discs. We may talk more about it later.)

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 virtual machine running on top of a Fedora Linux host system, which we modified by patching the kernel IDE-SCSI device to log all drive 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 data at a specific offset from the beginning of audio tracks—approximately 365 and 366 frames in (a CD frame is 1/75 second). 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. (By locating the watermark nearly five seconds after the start of the track, MediaMax reduces the likelihood that it will occur in a very quiet passage, where it might be more audible, and makes it more difficult to crop out.)

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 is a 1500 lb. granite slab unearthed by French archaeologists in Rosetta, Egypt, in 1799. A single Ptolemaic decree is written on the stone in three scripts: 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 (BMG, 2004), 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 into the audio of each track in 30 clusters. 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 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) and then patching up the two other bits, according to this table:

(This design seems to be intended to lessen the audible distortion caused by 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 LSBs that makes the watermark easier to detect or remove.)

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:

2,3,1,1,2,2,3,3,2,3,3,3,1,3,2,3,2,1,3,2,2,3,2,2,2,1,3,3,2,1,2,3,3,1,2,2,3,
1,2,3,3,1,1,2,2,1,1,3,3,1,2,3,1,2,3,3,1,3,3,2,1,1,2,3,2,2,3,3,3,1,1,3,1,2,
1,2,3,3,2,2,3,2,1,2,2,1,3,1,3,2,1,1,2,1,1,1,2,3,2,1,1,2,3,2,1,3,2,2,2,3,1,
2,1,3,3,3,3,1,1,1,2,1,1,2,2,2,2,3,1,2,3,2,1,3,1,2,2,3,1,1,3,1,1,1,1,2,2,3,
2,3,2,3,2,1,2,3,1,3,1,3,3,3,1,1,2,1,1,2,1,3,3,2,3,3,2,2,1,1,1,2,2,1,3,3,3,
3,3,1,3,1,1,3,2,2,3,1,2,1,2,3,3,2,1,1,3,2,1,1,2,2,1,3,3,2,2,3,1,3,2,2,2,3,
1,1,1,1,3,2,1,3,1,1,2,2,3,2,3,1,1,2,1,3,2,3,3,1,1,3,2,1,3,1,2,2,3,1,1,3,2,
1,2,2,2,1,3,3,1,2,3,3,3,1,2,2,3,1,2,3,1,1,3,2,2,1,3,2,1,3

The 288-bit raw watermark is detected by the active protection software only when it has certain properties, as shown in the sequence below. In the 288-bit sequence, 96 positions have fixed bit values, either 0 or 1. The trailing 32 positions have arbitrary values (as indicated by _), and can be used to store a 32-bit disc-specific value. The other 192 positions are divided into 32 groups of linked values (denoted az and alpha-zeta). In each group, three positions share the same value and three share the complement value. This allows the scheme to encode a second 32-bit value, though in actual discs it appears to be a different random value in each of the 30 mark clusters.

Attacks on the MediaMax Watermark

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 manipulate the audio in the frequency domain and attempt to resist removal by lossy compression, multiple conversions between digital and analog formats, and other common transformation. 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 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 MediaMax 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 LSBs of each sample–to forge it with minimal loss of fidelity. Such an attacker could transplant the three LSBs 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.

Secure Disc Recognition

Having shown that the MediaMax watermark fails to provide either strong resistance to removal or strong resistance to forgery, we ask whether it is possible to securely accomplish either or both of these goals.

As far as indelibility is concerned, watermarking schemes have a poor history of resisting removal. This is especially true against an adversary who has oracle access to the watermark detector, as was the case with a previous application of watermarks to audio copy protection, SDMI, and with CD DRM systems. Making marks that are both indelible and unforgeable is likely much more difficult. There seems to be tension between marks that are difficult to remove and ones that are hard to forge. Enforcing both requirements creates two ways to fool the detector–by rendering the mark invisible and by making it appear forged. If, as in CD DRM, either situation leads to the same result (no protection), the attacker’s power is multiplied.

In contrast, a mark strongly robust to forgery is simple to create based on digital signatures if we aren’t concerned with its being easy to remove. A very simple scheme works as follows:

  • To sign an audio track, the licensed publisher reads a fixed portion L1 of the audio data (say, the first ten seconds), then computes a cryptographic hash of L1 and signs it using a public key signature algorithm to derive the signature SL1 := SignKS(Hash(L1)). SL1 is then stored at a second location in the track by setting the LSB of each sample in the region to the corresponding bit in the signature. A 320-bit DSA signature could be embedded in this way using approximately the same space as one mark cluster of the MediaMax watermark.

  • The publisher keeps the signing key KS secret, and builds the corresponding verification key KV into the client software. When presented with a CD, the software checks for a valid signature. First it reads the audio from the signed area of the track and hashes it, and it locates and extracts the signature stored in the LSBs in the second mark location. Next, it verifies the signature on the hash using KV. If the signature is correct, the watermark is valid and genuine; otherwise, forgery or data corruption is indicated.

Forging such a mark would require defeating the digital signature scheme or splicing both L1 and SL1 from a legitimately marked album. We set L1 to be several seconds of audio to make such splicing less appealing.

Clearly this watermark is highly vulnerable to removal. If even a single bit of the hashed region is changed, the mark will not be recognized as valid. Yet the watermark MediaMax actually uses is also vulnerable to corruption by a single bit too while being far less resistant to forgery. Robustness to removal, while desirable in principle, is of limited value in real CD DRM applications. Removal of the watermark is unlikely to be the weakest link protecting the audio, and while the gains from creating a more indelible watermark are slight, the loss to free riders from an easily forgeable mark is potentially much larger.

Make Your Own Copy-Protected CD with Passive Protection

Here’s a great gift idea just in time for the holidays: Make your friends and relatives their very own copy-protected CDs using the same industrial-grade passive protection technology built into XCP and Macrovision discs.

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’s sometimes possible to confuse computers without affecting ordinary players — or so the theory goes. In practice, the distinction between computers and CD players is less precise. 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. For these reasons, copy protection vendors now use active protection — special software designed to block copying.

Discs with XCP or Macrovision protection employ active protection in conjunction with a milder form of passive protection. You can create your own CD with exactly the same passive protection by following a straightforward five-step procedure. I’ll describe the procedure here, and then explain why it works.

What you’ll need:

  • A computer running a recent version of Windows (instructions are Windows-specific; perhaps someone will write instructions for MacOS or Linux)
  • Nero, a popular CD burning application
  • CloneCD, an advanced disc duplication utility
  • Two blank recordable CDs

Step 1: Burn a regular audio CD

Start Nero Burning ROM and create a new Audio CD project. [View] Add the audio tracks that you want to include on your copy-protected disc. [View] When you’re ready to record, click the Burn button on the toolbar. In the Burn tab, make sure “Finalize disc” is unchecked. [View] Insert a blank CD and click Burn. Be careful not to infringe any copyrights! For loads of great music that you can copy legally, visit Creative Commons.

Step 2: Add a data session to the CD

Start another Nero compilation, this time selecting the “CD-ROM ISO” project type. In the Multisession tab, make sure “Start Multisession disc” is selected; and in the ISO tab, make sure Data Mode is set to “Mode 2 / XA”. [View] Add any files that you want to be accessible when the CD is used in a computer. You might include “bonus” content, such as album art and lyrics. [View] For a more professional effect, consider adding the installer for your favorite spyware application and creating an Autorun.inf file so it starts automatically. When you’re finished, click the Burn toolbar button. Insert the audio CD you created in Step 1, and click Burn. [View] Nero should warn you that the disc you’ve inserted is not empty; click Yes to add your data files as a second session. [View]

At this point, you’ve created a CD that contains both audio tracks and data files. The data files you put on the CD should be visible in Windows Explorer (in My Computer, right click the CD icon and click Open) and the audio tracks should be rippable with your favorite audio player. To add passive copy protection, you’ll need to modify the layout of the data on the disc so that the audio tracks are more difficult to access.

Step 3: Rip the CD as a CloneCD image file

Make sure the CD you just created is still in the drive and start CloneCD. Click the “Read to Image File” button. Select your drive and click Next. Choose “Multimedia Audio CD” and click Next. [View] Select an easy to find location for the image file and click OK to begin ripping.

Step 4: Modify the image file to add passive protection

The CloneCD image you created in step 3 actually consists of three files with names ending in .CCD, .IMG, and .SUB. The .CCD file describes the layout of the tracks and sessions on the CD. You’ll edit this file to add the passive protection.

Start Windows Notepad and open the .CCD file. Modifying the file by hand would be tedious, so I’ve created an online application to help. Copy the entire contents of the file to the clipboard and paste it into this form, then click Upload. Copy the output from the web page and paste it back into Notepad, replacing the original file contents. [View] Save the file and exit Notepad.

Step 5: Burn the modified image to create a copy-protected CD

Insert a blank CD and start CloneCD again. Click the “Write From Image File” button. Select the image file you modified in step 4 and click next. Select your CD recorder and click Next. Select “Multimedia Audio CD” and click OK to begin burning. [View]

That’s it! You’ve created your very own copy-protected CD.

Now it’s time to test your disc. If everything worked, the files from the data session will be visible from My Computer, but the audio tracks will not appear in Windows Media Player, iTunes, and most other mainstream music players. The CD should play correctly in standalone CD players.

How it works. To see how this form of passive protection works, you can examine the layout of the CD you created. Start Nero and select Disc Info from the Recorder menu. You should see something like this:

(The exact number of tracks you see will depend on how many songs you included.)

Notice that the tracks are grouped into two sessions — essentially two independent CDs burned onto the same disc. Unprotected CDs that combine audio and data files contain audio tracks in the first session and a single data track in the second. The only difference in the passive protected CD you just created is that the second session contains two tracks instead of one.

You added the extra track (shown in yellow) when you edited the disc image in step 4. This simple change makes the audio tracks invisible to most music player applications. It’s not clear why this works, but the most likely explanation is that the behavior is a quirk in the way the Windows CD audio driver handles discs with multiple sessions.

For an added layer of protection, the extraneous track you added to the disc is only 31 frames long. (A frame is 1/75 of a second.) The CD standard requires that tracks be at least 150 frames long. This non-compliant track length will cause errors if you attempt to duplicate the disc with many CD drives and copying applications.

Caveat emptor. Yes, your copy-protected CD is “industrial strength” — XCP and Macrovision employ exactly the same passive protection — but even the pros have their limitations. There are many well-known method for defeating this kind of passive protection, such as:

  • Enhanced software – Advanced CD ripping programs avoid the Windows CD audio driver altogether and communicate directly with the CD drive. Thus, programs such as EAC are able to rip the tracks without any difficulty. – Better CD copying applications, including Nero, support a recording mode called Disc-at-Once/96; this lets them create an exact duplicate of the protected disc even though the last track has an illegal length.
  • Other operating systems – The discs can be ripped with standard software on Macs and on Linux systems. These platforms don’t suffer from the limitation that causes ripping problems on Windows.
  • Magic markers – The famous magic marker trick involves carefully drawing around the outer edge of the CD. This blocks out the second session, allowing the disc to be ripped and copied just like an unprotected CD.

And of course, at any time Microsoft could fix the Windows quirk that is the basis for this technique, rendering it completely ineffective.

Despite these limitations, who wouldn’t enjoy finding a homemade copy-protected CD in their stocking? They’re a great way to spread holiday cheer while preventing anyone else from spreading it further.

Hidden Feature in Sony DRM Uses Open Source Code to Add Apple DRM

For weeks, the blogosphere has been abuzz with tales of intrigue about Sony’s XCP copy protection system. Among the strangest revelations was that XCP itself infringes on the copyrights to several open source software projects. In one case, Sam Hocevar found conclusive evidence that part of XCP’s code was copied from a program called DRMS, which he co-authored with DVD Jon and released under the terms of the GPL open source license. What made this finding particularly curious is that the purpose of DRMS is to break the copy protection on songs sold in Apple’s iTunes Music Store. Why would XCP rip off code intended to defeat another vendor’s DRM?

The answer is that XCP utilizes the DRMS code not to remove Apple DRM but to add it. I’ve discovered that XCP uses code from DRMS as part of a hidden XCP feature that provides iTunes and iPod compatibility. This functionality has shipped on nearly every XCP CD, but it has never been 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. This strongly suggests that the infringing DRMS code was deliberately copied by XCP’s creator, First4Internet, rather than accidentally included as part of a more general purpose media library used for other functions in the copy protection system.

This isn’t the first time another vendor has tried to make its DRM compatible with Apple’s. Apple’s DRM, a system called FairPlay, places restrictions on songs purchased through the iTunes Music Store. FairPlay is the only DRM compatible with the immensely popular 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. Apple responded by making vague legal threats and updating iTunes to break this compatibility. It looks like the people at 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.

Intriguingly, the FairPlay compatibility code in XCP is not limited to converting files from XCP CDs. The code appears to support conversion into FairPlay of files in a wide variety of input formats – MP3s, WAV files, raw audio files, and standard unprotected audio CDs – in addition to XCP-protected discs. It’s also strange that the FairPlay compatibility code is shipped but not made available for use by applications, not even XCP’s own player software. (Technically, the code is not exported from the shared library where it is stored.) This might indicate that First4Internet decided to remove the feature at the very last minute, shortly before XCP CDs started to ship.

In any case, the code is present and still works. It’s possible to execute it by jumping to the right memory location after performing some basic setup. I’ve used this method to test various aspects of the software. Here is a screenshot of iTunes playing a protected file that I made from a regular MP3 file using the hidden XCP functionality:

It seems these findings raise more questions than they answer. Where did the code come from? Since it supports audio sources other than XCP CDs, did First4Internet license it from another vendor? Why did Sony disable the code but continue to ship it? How does iTunes compatibility fit in with Sony’s overall copy protection strategy? Which is the greater evil – incompatible DRM platforms or GPL violations? Tune in again tomorrow when Ed will weigh in on these and other conundrums.

* * *

[This rest of this post contains technical information about how XCP uses the DRMS code. Feel free to stop reading now if you aren’t interested in the details.]

Understanding how XCP uses code from DRMS requires some basic knowledge about FairPlay. When you buy a song from the iTunes Music Store, you receive a FairPlay encrypted audio file that can only be played with knowledge of a secret key assigned to you by Apple. iTunes retrieves this key from an Apple server, which prompts you to log in with your Apple ID and password. Your user key is stored on your hard drive in an encrypted key database (a file called SC Info.sidb). When you play the song again, or if you try to copy it to an iPod, iTunes reads your key from the database instead of reconnecting to the server.

FairPlay’s security depends on the encrypted key database being difficult for anyone but Apple to decipher, so it is protected using a proprietary encryption method and a system-dependent secret key. (As security experts predicted, this protection was quickly broken; today DRMS is able to defeat FairPlay because DVD Jon painstakingly reverse engineered the database decryption code in iTunes.) iTunes encrypts the key database using a two step process. First, it XORs the plaintext database with the output from a proprietary pseudorandom number generator (PRNG) using a system-dependent seed; then it applies AES encryption 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 complex, 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 compresses the audio in memory, then encrypts it 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. Here is how the DRMS code ties in with the rest of the library. (I’ve provided a debugger offset for each function as an aid to other investigators.) The DRMS DoShuffle subroutine (0x10089E00) is called from only two places, a function that encrypts the iTunes key database (0x1008A0C0) and a function that decrypts it (0x1008A300). Both these functions are called from only one other routine, which serves to read the key database, decrypt it, and, if necessary, to add the XCP user key to the database and write it out again in encrypted form (0x1008A470). This routine is called by a higher level function that converts an audio file into a FairPlay-protected AAC file (0x10027D20). You can test these functions by jumping into an earlier routine (0x10010380, apparently the start of a thread for transferring music to iTunes) after some simple initialization. I’ll happily provide serious investigators with rough sample code and instructions.

My tests indicate that 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.

MediaMax Permanently Installs and Runs Unwanted Software, Even If User Declines EULA

In an earlier post I described how MediaMax, a CD DRM system used by Sony-BMG and other record labels, behaves like spyware. (MediaMax is not the same as XCP, the technology that Sony-BMG has recalled; Sony-BMG is still shipping MediaMax discs.) MediaMax phones home whenever you play a protected CD, automatically installs over 12 MB of software before even displaying an End User License Agreement, and fails to include an uninstaller.

Part of the software that MediaMax installs is a driver meant to interfere with ripping and copying from protected discs. I had believed that MediaMax didn’t permanently activate this driver—set it to run whenever the computer starts—unless the user accepted the license agreement. As it turns out, this belief was wrong, and things are even worse that I had thought.

In the comments to our last MediaMax story, reader free980211 pointed out that the driver sometimes becomes permanently activated if the same protected CD is used more than once, even if the user never agrees to the EULA. This wasn’t apparent from my earlier tests because they were conducted under tightly controlled conditions, with each trial beginning from a fresh Windows installation and involving only carefully scripted operations. I’ve performed further tests and can now confirm that MediaMax is permanently activated in several common situations in spite of explicitly withheld consent.

When this happens depends on what version of MediaMax is being used. An older version, called CD-3, was introduced in 2003 and is present on albums released as recently as this summer. There is also a newer version, MediaMax MM-5, which has been shipping for a little over a year. You can tell which version is on a CD by examining the files in the disc’s root directory. Albums protected by MediaMax CD-3 contain a file called LAUNCHCD.EXE, while MM-5 albums include a file named PlayDisc.exe.

When you insert a CD containing either version of MediaMax, an installer program automatically starts (unless you have disabled the Windows autorun feature). This installer places the copy protection driver and other files on the hard disk, and then presents a license agreement, which you are asked to accept or decline. In the following scenarios the driver may become permanently activated even if you always decline the agreement:

  • You insert a CD-3 album, then later insert an MM-5 album
  • You insert an MM-5 album, then later insert a CD-3 album
  • You insert an MM-5 album, reboot, then later insert the same album or another MM-5 album

These steps don’t have to take place all at once. They can happen over a period of weeks or months.

This is bad news for people who like to play CDs in their computers. Many users are unaware that their CDs contain MediaMax until the license agreement appears on their screens, but by this time it may be too late to stop the driver from being permanently activated. Even if users are careful to decline the EULA every time, the circumstances when the software becomes active anyway are common enough to be practically inevitable.

This may be an annoyance to music fans—unless you disable the driver, you’ll have a hard time playing any MediaMax-protected titles, let alone copying them to your iPod—but it’s also a security risk, since the driver is loaded as part of the Windows kernel and has the ability to control virtually any aspect of the computer’s operation. We don’t know whether the MediaMax driver contains any vulnerability that can be exploited to do further damage, but the way it is installed creates a dangerous precedent.

Is this behavior illegal? It should be. Installation of system level software where the user has explicitly denied permission raises serious security concerns and is wrong.

Not Again! Uninstaller for Other Sony DRM Also Opens Huge Security Hole

I have good news and bad news about Sony’s other CD DRM technology, the SunnComm MediaMax system. (For those keeping score at home, Ed and I have written a lot recently about Sony’s XCP copy protection technology, but this post is about a separate system that Sony ships on other CDs.)

I wrote last weekend about SunnComm’s spyware-like behavior. Sony CDs protected with their technology automatically install several megabytes of files without any meaningful notice or consent, silently phone home every time you play a protected album, and fail to include any uninstall option.

Here’s the good news: As several readers have pointed out, SunnComm will provide a tool to uninstall their software if users pester them enough. Typically this requires at least two rounds of emails with the company’s support staff.

Now the bad news: It turns out that the web-based uninstaller SunnComm provides opens up a major security hole very similar to the one created by the web-based uninstaller for Sony’s other DRM, XCP, that we announced a few days ago. I have verified that it is possible for a malicious web site to use the SunnComm hole to take control of PCs where the uninstaller has been used. In fact, the the SunnComm problem is easier to exploit than the XCP uninstaller flaw.

To be clear, the SunnComm security flaw does not apply to the software that ships on CDs, but only to the uninstaller that SunnComm distributes separately for removing the CD software. So if you haven’t used the uninstaller, you’re not vulnerable to this flaw and you don’t need to do anything.

If you visit the SunnComm uninstaller web page, you are prompted to accept a small software component—an ActiveX control called AxWebRemoveCtrl created by SunnComm. This control has a design flaw that allows any web site to cause it to download and execute code from an arbitrary URL. If you’ve used the SunnComm uninstaller, the vulnerable AxWebRemoveCtrl component is still on your computer, and if you later visit an evil web site, the site can use the flawed control to silently download, install, and run any software code it likes on your computer. The evil site could use this ability to cause severe damage, such as adding your PC to a botnet or erasing your hard disk.

You can tell whether the vulnerable control is installed on your computer by using our AxWebRemoveCtrl detector.

We have created a tool that will disable the control and/or block it from being installed. To apply our tool, download this file to a temporary location, then double click on the file’s icon in Windows. (Windows may ask you to confirm that you wish to add the information in the file to the system registry–choose “Yes.”) After the tool has been applied, you may delete the file you downloaded. The tool will take effect as soon as you close and restart Internet Explorer. We recommend that anyone who has used the SunnComm uninstaller run our tool as soon as possible.

Unfortunately, if you use our tool to block the control, you won’t be able to use SunnComm’s current uninstaller to remove their software. It’s up to them to replace the flawed uninstaller with a safe one as soon as possible, and to contact those who have already used the vulnerable uninstaller with instructions for closing the hole.

UPDATE (Nov. 18): We are currently helping SunnComm test a new version of the uninstaller.