Dr. Michael Geist is the Canada Research Chair of Internet and E-commerce Law at the University of Ottawa., nz leak on wipo treaties

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.