December 22, 2024

Posts Comments

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

December 4, 2005 by

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.

Filed Under: Uncategorized Tagged With: , ,

The DMCA Should Not Protect Spyware

December 2, 2005 by

Yesterday was the deadline to submit requests for limited exemptions from the DMCA’s ban on circumvention of access control technologies. This happens every three years. Alex Halderman and I submitted a request, asking for an exemption that would allow the circumvention of compact disk copy protection technologies that have certain spyware-ish features or create security holes. We’d like to thank Aaron Perzanowski and Deirdre Mulligan of the Samuelson Clinic at UC Berkeley, whose great work made this possible.

Many people decided not to submit exemption requests in this round, because of the way previous rounds have been handled. For example, the EFF argues that the process is so strongly tilted against exemptions, and the Copyright Office tries so hard to find excuses not to grant exemptions, that there is no point in asking for one. Even Seth Finkelstein, the only person who has had any real record of success in the process, decided to sit out this round. I submitted requests for research-related exemptions in 2000 and 2003; and having seen how those requests were handled, I sympathize with the skeptics’ position.

Nevertheless, I think it’s worth asking for this exemption, if only to see whether the Copyright Office will acknowledge that copy protection technologies that install spyware or otherwise endanger the security or privacy of citizens are harmful. Is that too much to ask?

To most readers here, the most interesting paragraph of our exemption request is this one:

Researchers like Professor Edward Felten and Alex Halderman waste valuable research time consulting attorneys due to concerns about liability under the DMCA. They must consult not only with their own attorneys but with the general counsel of their academic institutions as well. Unavoidably, the legal uncertainty surrounding their research leads to delays and lost opportunities. In the case of the CDs at issue, Halderman and Felten were aware of problems with the XCP software almost a month before the news became public, but they delayed publication in order to consult with counsel about legal concerns. This delay left millions of consumers at risk for weeks longer than necessary.

The DMCA exemption process continues, with reply comments due February 2.

Filed Under: Uncategorized Tagged With: , , , ,

Sony, First4 Knew About Rootkit Issue in Advance

November 30, 2005 by

Security vendor F-Secure contacted SonyBMG and First4Internet about the companies’ rootkit software on October 4 – about four weeks before the issue became public – according to a Business Week story by Steve Hamm.

Here’s the key part of the article’s chronology:

Nevertheless, Sony BMG asked First4Internet to investigate. Both Sony BMG and F-Secure say that it was on Oct. 17 that F-Secure first spelled out the full scope of the problem to Sony. The security company’s report on the matter, sent that day to First4Internet and Sony BMG, confirmed there was a rootkit in XCP and warned that it made it possible for hackers to hide viruses and protect them from antivirus software products. F-Secure referred to XCP as a “major security risk,” according to a copy of the e-mail supplied to BusinessWeek Online by F-Secure.

Sony BMG says it asked the two software companies to investigate and find a solution to the problem. “From the moment our people learned that F-Secure had identified a potential problem we contacted our vendor and in no uncertain terms told them you have to get with F-Secure and find out what needs to be done about it,” says Daniel Mandil, Sony BMG’s general counsel.

BOGGED DOWN. What happened next is in dispute. F-Secure had a conference call with executives of First4Internet on Oct. 20. It says First4Internet argued that there was no real problem because only a few people knew of the vulnerability XCP created, and said an update of the XCP software, due out early next year, would fix the problem on all future CDs.

At first glance, this looks like a standard story about disclosure of a security vulnerability: vendor ships insecure product; researchers report flaw privately; vendor drags feet; researchers report flaw publicly; problem fixed right away. The story features the classic vendor error of seeing insecurity as a public relations problem rather than a customer safety issue: “there was no real problem because only a few people knew of the vulnerability”.

But if we read this as just another vulnerability disclosure, we’re missing an important part of the story. In the usual case, the security vulnerability exists by mistake – the vendor doesn’t know the vulnerability exists until somebody points it out. Here, the rootkit-like functionality was not a mistake but a deliberate design decision by the vendor.

Which suggests the question of what exactly F-Secure was disclosing to Sony and First4Internet, or more precisely what it was disclosing that they didn’t already know. They must have known about the rootkit already – it was a design decision they had made – and if they had any kind of clue they would have known that users would hate having a rootkit on their machines, especially one that provided an obvious hiding place for other malware. As far as I can see, the only new information F-Secure would have disclosed was that F-Secure planned to treat the program as malware.

It’s interesting, too, that other makers of anti-malware tools didn’t seem to notice the problem until Mark Russinovich’s public disclosure. As of mid-September, this malware had been on the market for months and presumably had been installed on hundreds of thousands of computers, but still none of the anti-malware vendors had discovered it. (According to the Business Week article, F-Secure didn’t discover the malware itself, but learned of it on Sept. 30 from John Guarino, a computer technician in New York who had discovered it on several clients’ computers.) It’s not a good sign that all of the major anti-malware vendors missed it for so long.

Finally, we have to consider the possibility that Sony and First4Internet understood the significance of the rootkit, but simply felt that copy protection trumped users’ security. First4Internet probably held that view – otherwise it’s hard to explain their design decision to deploy rootkit functionality – and Sony may well have held it too. We know already that entertainment companies want to redesign our computers in the hope (which is ultimately futile) of stopping copying. From there, it’s not so large a step to decide that users’ security simply must be sacrificed on the altar of copy protection.

What did SonyBMG know, and when did it know it? We’ll find out more as the lawsuits proceed.

Filed Under: Uncategorized Tagged With: , , ,

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

November 28, 2005 by

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.

Filed Under: Uncategorized Tagged With: , , ,

What Does MediaMax Accomplish?

November 23, 2005 by

I wrote yesterday about the security risks imposed by the SunnComm MediaMax copy protection technology that ships on some Sony CDs. (This is not to be confused with the XCP technology that Sony recalled.) MediaMax advocates may argue that it’s okay to impose these security risks on users, because MediaMax effectively prevents copying of music. Which raises an obvious question: How effective is MediaMax, really, in stopping copying?

The answer: Not very.

MediaMax reportedly can be defeated by the well-known trick of drawing a circle around the outer edge of the CD with a felt-tip pen, or covering the outer edge with tape.

MediaMax can be defeated by the well-known trick of holding down the Shift key while inserting the CD.

MediaMax can be defeated by the well-known trick of rebooting the computer after inserting the CD.

(These first three attacks don’t work if MediaMax is installed on the user’s computer. But MediaMax has released an uninstaller than anyone can use.)

MediaMax can be defeated by the well-known trick of not using a Windows PC. (Amusingly, Mac users are allowed to install MediaMax if they want to. To do this, the user has to browse the CD and double-click a MediaMax installer icon which might as well be labeled “Click here to make this CD less useful.” Users who are smart enough not to do this can access the music normally.)

MediaMax can be defeated by telling Sony you want to move the music into iTunes or an iPod. They will then send you instructions for defeating MediaMax by making an unprotected copy of the CD.

All this, and I haven’t even started talking about the details of how the MediaMax technology works and any detailed flaws in its operation.

The bottom line: MediaMax makes your computer less secure and your music less available for lawful use, while achieving very little against pirates.

Filed Under: Uncategorized Tagged With: , , ,