January 19, 2025

CD Copy Protection: The Road to Spyware

Advocates of DRM (copy protection) have been keeping their heads down lately, while they try to figure out what went wrong in the SonyBMG DRM spyware fiasco. No doubt they’ll try to explain it away as an anomaly – just a little speed bump on the road to the effective, unobtrusive DRM future that they’re sure will be arriving any day now.

There are some problems with this story. For starters, we’re not talking about a single DRM system – we’re talking about two totally separate systems (XCP and MediaMax), developed by rival companies, both of which turned out to be spyware and to endanger users, in strikingly similar ways. Is this just a coincidence?

Of course it’s not. If we look carefully at CD copy protection as a technical problem, we’ll see why DRM designers are drawn to spyware tactics as their best hope of stopping copying. Let me explain why.

CDs store music files in Compact Disc Digital Audio (CDDA) format, which is easily readable by a wide range of devices. If the music is encrypted or stored in some other tricky format, ordinary audio CD players won’t be able to read it, and the disc will be useless to most customers. So backward compatibility requires that the music be stored in a format that is readable by computer software.

(Technical digression: There are actually small differences between how a computer reads a disc and how ordinary audio CD players read it. So-called passive protection technologies try to exploit these differences by putting things on the disc that try to confuse computers without affecting ordinary players. For our purposes, it will suffice to say that purely passive protection systems are not viable, because computers are not so easily confused. To my knowledge, purely passive CD DRM technologies aren’t being used any more, although some current vendors combine passive protection with active measures. For reasons too boring to go into here, passive protection doesn’t really affect my analysis; and so to streamline the discussion I’ll assume from here on that there is no passive protection.)

If the music is encoded on the disc in a format that any software program can read, the only way to stop programs from reading it is to install software on the user’s computer, and to have that software actively interfere with attempts to read the disc, for example by corrupting the data stream coming from the disc. We call this “active protection”.

For example, suppose the user wants to use iTunes to read the disc. But the DRM vendor wants to stop the user from doing this, because iTunes can be used to make copies of the disc. The active protection software will detect this and will interfere to ensure that iTunes gets a garbled copy of the music.

Here’s the key issue: Active protection only works if the DRM software is running on the user’s computer. But the user doesn’t want the software on his computer. The software provides no value to him at all. Its only effects are to stop him from doing things he wants to do (such as listening to the music with iTunes), and to expose him to possible security attacks if the software is buggy.

So if you’re designing a CD DRM system based on active protection, you face two main technical problems:

  1. You have to get your software installed, even though the user doesn’t want it.
  2. Once your software is installed, you have to keep it from being uninstalled, even though the user wants it gone.

These are the same two technical problems that spyware designers face.

People who face the same technical problems tends to find the same technical solutions. How do you get software installed against the user’s wishes? You mislead the user about what is being installed, or about the consequences of installation. Or you install without getting permission at all. How do you keep software from being uninstalled? You don’t provide an uninstaller. Or you provide an uninstaller that doesn’t really uninstall the whole program. Or you try to cloak the software so the user doesn’t even know it’s there.

Of course, you don’t have to resort to these tactics. But if you don’t, your software will have trouble getting onto users’ computers and staying there. If your whole business model depends on installing unwanted software and preventing its uninstallation, you’ll do what’s necessary to make that model work. You’ll resort to spyware tactics. (Or you’ll quit and go into another business.)

Having set off down the road of CD copy protection, the music industry shouldn’t be surprised to have arrived at spyware. Because that’s where the road leads.

Not Just Another Buggy Program

Was anybody surprised at Tuesday’s announcement that the MediaMax copy protection software on Sony CDs had a serious security flaw? I sure wasn’t. The folks at iSEC Partners were clever to find the flaw, and the details they uncovered were interesting, but it was pretty predictable that a problem like this would turn up.

Security is all about risk management. If you’re careful to avoid unnecessary risks, to manage the risks you must accept, and to have a recovery plan for when things go wrong, you can keep your security under control. If you plunge ahead, heedless of the risks, you’ll be sorry.

If you’re a parent, you’ll surely remember the time your kid left an overfull glass of juice on the corner of a table and, after the inevitable spill, said, “It was an accident. It’s not my fault.” And so the kid had to learn why we don’t set glasses at the very edges of tables, or balance paintbrushes on the top of the easel, or leave roller skates on the stairs. The accident won’t happen every time, or even most of the time, but it will happen eventually.

If you’re a software vendor, your software creates risks for its users, and you have a responsibility to your customers to help them manage those risks. You should help your customers make informed choices about when and how to use your software, and you should design your software to avoid exposing customers to unnecessary risks. Your customers expect this from you, and they’ll hesitate to buy your product if they think you’re leaving the cyberjuice on the corner of the table.

The design of the MediaMax/Sony software is a case study in risk creation. I wrote about these risks two weeks ago:

But even if all [the software’s spyware] problems are fixed, the MediaMax software will still erode security, for reasons stemming from the basic design of the software.

For example, MediaMax requires administrator privileges in order to listen to a CD. You read that right: if you want to listen to a MediaMax CD, you must be logged in with enough privileges to manipulate any part of the system. The best practice is to log in to an ordinary (non-administrator) account, except when you need to do system maintenance. But with MediaMax, you must log in to a privileged account or you can’t listen to your CD. This is unnecessary and dangerous.

Some of the security risk of MediaMax comes from the fact that users are locked into the MediaMax music player application. The player app evades the measures designed to block access to the music; and of course the app can’t play non-MediaMax discs, so the user will have to use multiple music players. Having this extra code on the system, and having to run it, increases security risk. (And don’t tell me that music players don’t have security bugs — we saw two serious security bugs in Sony music software last week.) Worse yet, if a security problem crops up in the MediaMax player app, the user can’t just switch to another player app. More code, plus less choice, equals more security risk.

Sure enough, these risks enable the new attack, which exploits the presence of extra code on the system, and the fact that that code runs with full Administrator privileges.

The biggest risk of all, though, is that the software can install itself without the knowledge or consent of the user. When you decide to install a program on your computer, you take a security risk. But you take that risk knowingly, because you have decided the benefit provided by that program outweighs the risk. If you change your mind about that tradeoff, you can always uninstall the program.

But if you decline the MediaMax licence agreement, and the software secretly installs itself anyway, you will face risks that you didn’t choose. You won’t even know that you’re at risk. All of this, simply because you tried to listen to a compact disc.

Experience teaches that where there is one bug, there are probably others. That’s doubly true where the basic design of the product is risky. I’d be surprised if there aren’t more security bugs lurking in MediaMax.

Sony is still shipping CDs containing this dangerous software.

MediaMax Bug Found; Patch Issued; Patch Suffers from Same Bug

iSEC, EFF, and SonyBMG issued a joint press release yesterday, announcing yet another serious security bug in the SunnComm MediaMax copy protection software that ships on many SonyBMG compact discs. (SonyBMG has recalled CDs that use another copy protection system, XCP, but they have not yet recalled discs containing MediaMax.)

As we’ve written before, the first time you insert a MediaMax-bearing CD into your Windows computer (assuming you have Windows autorun enabled, as most people do), MediaMax installs some software on your computer. Once this initial software is on your computer, you are vulnerable to the new attack. The gist of the problem is that MediaMax installs itself in a directory that anyone is allowed to modify, even users who otherwise run with heavily restricted security permissions. Any program that comes along can modify your MediaMax files, booby-trapping the files by inserting hostile software that will be run automatically the next time you insert a MediaMax-bearing CD into your computer. And because MediaMax is run with full administrator privileges, the hostile program gets to run with full privileges, allowing it to inflict any mischief it likes on your PC.

Alex Halderman has discovered that the problem is worse than the press release indicates:

  • You are vulnerable even if you decline the MediaMax license agreement. Simply inserting a MediaMax-bearing CD into your PC paves the way for an attacker to come along and set a booby-trap. The trap will be sprung the next time you insert such a disc.
  • SonyBMG has released a patch that purports to fix the problem. However, our tests show that the patch is insecure. It turns out that there is a way an adversary can booby-trap the MediaMax files so that hostile software is run automatically when you install and run the MediaMax patch.
  • The previously released MediaMax uninstaller is also insecure in the same way, allowing an adversary to booby-trap files so that hostile software is run automatically when you try to use the uninstaller.

    (These attacks are similar to the exploit described in iSEC’s report, but they involve a different modification to the MediaMax files.)

Because of these problems, we recommend for now that if you have a Windows PC, you (1) do not use the MediaMax patch, (2) do not use the previously released MediaMax uninstaller, and (3) do not insert a MediaMax-bearing CD into your PC.

We have notified SonyBMG and MediaMax about these problems. We assume they will develop a new uninstaller that safely rids users’ computers of the MediaMax software once and for all.

The consequences of this problem are just as bad as those of the XCP rootkit whose discovery by Mark Russinovich started SonyBMG’s woes. This problem, like the rootkit, allows any program on the system to launch a serious security attack that would normally be available only to fully trusted programs.

According to the press release, SonyBMG intends to use MediaMax’s banner ad display feature to warn users about these vulnerabilities. While this is a positive step, it will fail to reach users who have rejected the MediaMax license agreement. This group is at particularly high risk, since they are probably unaware that the software is installed on their computers.

Worst of all, it is impossible to patch the millions of MediaMax-bearing CDs that are already out there. Every disc sitting on somebody’s shelf, or in a record-store bin, is just waiting to install the vulnerable software on the next PC it is inserted into. The only sure way to address this risk is take the discs out of circulation.

The time has come for SonyBMG to recall all MediaMax CDs.

UPDATE (Dec. 9): Sony and MediaMax have issued a new patch. According to our limited testing, this patch does not suffer from the security problem described above. They have also issued a new uninstaller, which we are still testing. We’ll update this entry again when we have more results on the uninstaller.

DRM, Incompatibility, and Market Power: A Visit to the Sausage Factory

Yesterday Alex wrote about how SonyBMG’s XCP CD copy protection software includes a feature – apparently built on illegally copied open-source code – to translate music files into the FairPlay format used by Apple’s iTunes and iPod, but the feature was not exposed to users. The details are interesting. But equally interesting, I think, is the question of how this situation came about. Why would Apple make compatibility so difficult? Why would First4Internet go to the trouble to make its software compatible? Why would First4Internet and/or SonyBMG then turn off this already-working feature? And why would SonyBMG then blame Apple for the difficulty of moving XCP files into iTunes and iPods?

Today I’ll try to answer these questions. My answers will be speculative, as I’m not privy to any special information about the companies’ plans. But the story I’ll tell should be plausible, at least, and it will shed some light on how companies use DRM (copy protection) as a weapon in struggling for market supremacy.

Let’s start by reviewing why Apple makes it hard for others to encode files in the Apple FairPlay format that is used by iTunes and the iPod. Apple could easily facilitate such encoding if it wanted to; but it doesn’t. Instead, Apple seems to be trying to ensure that customers are locked in to a particular DRM scheme. This is the strategy we would expect from a company with high market share – customers try to avoid lock-in, but if they must be locked in they typically choose to be locked in to the dominant vendor. So the dominant vendor – Apple in this market – often tries to foster market structures with lock-in.

Recall that when RealNetworks, an Apple rival, created its Harmony software, which could translate Real-format files into FairPlay, Apple cried foul. Apple hung the dreaded “hacker” label on RealNetworks and threatened to sue on some vague DMCA theory. When Real didn’t back down, Apple just changed the FairPlay format, rendering Real’s software incompatible once again. Apple was willing to use both legal threats and technical changes to frustrate compatibility.

First4Internet (F4I), in developing its XCP copy protection software, started out with no market share. F4I knew that customers wouldn’t want its software, because the main effect of the software is to stop customers from doing things they want to do. F4I wanted to reduce the unpleasantness of using its software, and one way to do that was to give customers a way to transfer XCP music files into iTunes or an iPod. And that meant translating the files into FairPlay format. To do this, F4I could have reverse-engineered iTunes and written code to do the translation. Instead, it apparently just swiped some open-source code called DRMS (written by Sam Hocevar and DVD-Jon), in violation of the DRMS license. Using this code, F4I built a working translate-to-FairPlay function as part of its software.

At some point, F4I licensed its software to SonyBMG. F4I would surely have told SonyBMG about the FairPlay compatibility feature. But when SonyBMG CDs shipped with F4I’s XCP software on them, the compatibility feature was disabled and hidden from users. Somebody must have decided to disable the feature, and it’s hard to believe it was anybody but SonyBMG. SonyBMG was F4I’s first major customer. SonyBMG was putting its name on the CDs. And SonyBMG would have been the main target for hacking accusations and/or lawsuits from Apple. So we have to conclude that SonyBMG chose not to make the software on its CDs FairPlay-compatible.

Why would SonyBMG do this? It would have been easier to retain compatibility, and SonyBMG’s customers would have benefited. So SonyBMG must have thought compatibility would hurt it, somehow. How might that happen? Perhaps SonyBMG was afraid Apple could bring a successful lawsuit against it; but that seems unlikely given the apparent weakness of Apple’s legal claims. Two other theories seem more likely.

The first theory is that SonyBMG wanted to avoid the public spectacle of two DRM companies fighting with each other. DRM advocates like to argue (against the evidence) that the only impact of DRM is to prevent infringement. When DRM companies fight over compatibility, this just emphasizes the role of DRM as a strategic tool companies use to lock other companies out of markets, and that sets back the cause of DRM. Much better from SonyBMG’s viewpoint, perhaps, to maintain the fiction of one big happy DRM family, even if customers suffer.

The second theory is that SonyBMG was trying to fragment the world of music-file formats, in order to reduce Apple’s negotiating power. Record companies have been complaining lately that Apple, as the biggest seller of Internet-delivered music, has too much market power. Apple’s market power helps it drive a hard bargain with record companies in negotiating the price and terms of Apple’s online music sales. SonyBMG, as a record company, would like to see Apple’s market power shrink.

Whichever explanation is right, it certainly appears that SonyBMG decided that XCP shouldn’t be compatible with FairPlay.

What SonyBMG did next showed a particular sort of genius. It blamed Apple for the incompatibility. Indeed, SonyBMG went so far as to ask its customers to petition Apple to solve the problem. Here’s SonyBMG’s web site:

Sony BMG wants music to be easily transferable to any device that supports secure music. Currently, music from our protected CDs may be transferred to hundreds of such devices, as both Microsoft and Sony have assisted to make the user experience on our discs as seamless as possible with their secure formats.
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.
If you believe that you should be able to easily move tracks from your protected CD to your iPod then we encourage you to use the following link to contact Apple directly and tell them so. http://www.apple.com/feedback/ipod.html

If you were SonyBMG, and you were clever but not overly concerned with telling the truth in public, this is exactly what you would say in this situation. Why pass up a chance to paint Apple as the bad guys?

Running through this whole convoluted tale are two consistent threads. DRM is used as a weapon not against infringers but against market rivals. And when companies use DRM to undermine compatibility, law-abiding customers lose.

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.