Muzzy's research about Sony's XCP DRM system

I've collected some of my findings about the Sony's XCP DRM rootkit here. Enjoy! I've been rewriting the page as new information has been uncovered, although currently the updates are rare.

I've also written a short summary about the XCP DRM system and my opinions as separate pages. This page tries to stick to the facts, so if you think there's something biased or wrong here, please mail me

Latest updates

The Old Uninstaller

The uninstaller required you to install an ActiveX control to your system before you could even request for an uninstall url. Turns out, the uninstaller activex marks itself safe for scripting, and has plenty of interesting methods available for everyone to use. Although I have not analyzed them in depth, I have tested one of them to confirm it really does what I think it does. It's called "RebootMachine". If you have installed Sony's ActiveX control, follow the link to invoke the RebootMachine method. I don't even want to know what the ExecuteCode method does...

The InstallUpdate method has a bigger security hole, see's post about the uninstaller hole. They refer that trying my reboot demo to test if you're vulnerable might make things worse, this is because I copypasted the html from F4I's site so it used to prompt to install the ActiveX control. I have since changed it, since F4I could change their interfaces anytime anyway, it doesn't serve any purpose to provide the install ability in the demo.

Scriptable methods left behind

The uninstaller leaves behind lots of methods, here are the names:

Considering anyone can reboot the computer using these, I suspect security wasn't thought about for even a second during development of this thing. Virus writers and such would be very interested in analyzing what these methods do, as some of them are remotely exploitable... by design.

Magic lists

The installer and player both contain some interesting lists of exe names, window names, and so on. So far I don't know what these are used for, but I'd guess it's a blacklist system. Your guess is as good as mine, but the DRM system scans for them every two seconds.

I've been told these lists are used to hook these processes' APIs to use the DRM system's noise-adding versions. I haven't been able to confirm this so far.

LAME references?

On the CD, the file Contents\GO.EXE contains some strings

00056c18  68 74 74 70 3a 2f 2f 77-77 77 2e 6d 70 33 64 65  http://www.mp3de
00056c28  76 2e 6f 72 67 2f 00 00-30 2e 39 30 00 00 00 00
00056c38  4c 41 4d 45 33 2e 39 35-20 00 00 00 33 2e 39 35  LAME3.95 ...3.95
00056c48  00 00 00 00 33 2e 39 35-20 00 00 00 00 00 00 00  ....3.95 .......

It appears GO.EXE has LAME linked in accidently, but at least the ECDPlayerControl.ocx does use it as well and is definitely not linked accidently. Some people have been speculating that this is used to detect LAME, but that's not the case. The GO.EXE doesn't appear to refer to this data ever, meaning it's completely unused there. So, they've screwed up and accidently linked LAME against the installer, instead of only linking it against the other components in the DRM system where it's used and needed.

Four files total on the CD (three of them in compressed XCP.DAT) contain LAME strings, and it appears that at least one of them contains LAME code as well. This is certainly copyright infringement. And here's Sebastian Porst's blog post, with information on LAME code in ECDPlayerControl.ocx that ships with the DRM.

Many people have noticed that neither Sony BMG nor F4I appear to be licensing the MP3 patents, which could make the LAME code a patent violation as well. However, you should note that the sheer amount of patents existing today likely covers most of the software out there in one way or another. This case just happens to be more obvious, since it contains known software with known patent coverage. Also, while Sony BMG is not listed, Sony is and at least I don't have any clue to how patent licensing really works and who needs to do it. If you plan to make an issue out of the patent situation, please verify thefacts on your own

Strange stuff on the XCP.DAT

I've extracted the XCP.DAT that comes on the CD, and inside I've found the most wondrous stuff. It appears there's stuff like mpglib.dll, some version of bladeenc dll, etc. Both of these are LGPL, and my understanding is that these can't be used (or even distributed?) without mentioning about it in the documentation.

There's also Adaptec's ASPI stuff on the CD, but apparently there's permission to distribute this stuff. I have no idea, though, I'd have to research about this a bit more. These end up very visible in the installed system, though (TMPX dir in windows\system32) so maybe even F4I isn't stupid enough to infringe with these files

Id3Lib is here as well, in very visible form. There's nothing mentioned about this on the CD, however sony ships Id3lib sources on their site along their OpenMG stuff, and it's unclear if the DRM uses the LGPL version of this library or the older public domain version.

It appears that the file ECDPlayerControl.OCX actually uses these LGPL libraries, and since there's no license or mention of this in the documentation, it would mean that they're not complying with LGPL here either and thus are infringing copyrights on open source projects. I wish I could share these files with everyone so others could verify these facts as well, but that'd be copyright infringement as well :(


Infringes copyrights on LGPL and GPL code, does things illegal under DMCA and EUCD

The party just keeps on going. In addition to above mentioned LAME code found here, it appears there's GPL code as well. I'm not a lawyer, but this could be a DMCA/EUCD violation too? The code in question is VLC's demux/mp4/drms.c -- the de-DRMS code which circumvents Apple's DRM. The control flow is the same, the constants are equal (apparently with one exception), the two magic arrays are equivalent as well. This includes the p_secret2 string which is rot13'd Apple copyright string (used as data by the algorithm).

If you have the XCP on your system, you can go see ECDPlayerControl.ocx in the system32 dir and search for "Nccyr" in it. If you have a disassembler, see the function at virtual address 0x10089E00 and compare it to DoShuffle() in drms.c and note the resemblance.

Also check out Sebastian Porst's post about mpglib code found in ECDPlayerControl.ocx and Sam Hocevar's confirmation that it is based on his code and originates from VLC

Dump from the First4Internet's ocx file

00108018  aa aa aa aa 00 77 75 01-80 45 55 00 00 45 72 01  .....wu..EU..Er.
00108028  80 45 42 00 00 77 42 01-80 00 00 00 01 9d d5 c1  .EB..wB.........
00108038  81 49 14 80 01 89 5c 81-81 49 54 80 01 5d d4 81  .I....\..IT..]..
00108048  80 00 00 00 03 bb a3 81-82 aa a2 00 03 bb a3 01  ................
00108058  82 a2 22 00 02 a2 3b 81-80 00 00 00 37 57 57 6d  .."...;.....7WWm
00108068  a5 75 52 4a 25 57 52 6d-a5 54 52 4a 37 54 72 6b  .uRJ%WRm.TRJ7Trk
00108078  80 00 00 00 38 b9 dd d5-92 a0 55 54 13 a0 95 5d  ....8.....UT...]
00108088  92 a1 15 44 3a 39 dd c5-80 00 00 00 55 55 55 55  ...D:9......UUUU
00108098  70 62 63 6c 65 76 74 75-67 20 28 70 29 20 4e 63  pbclevtug (p) Nc
001080a8  63 79 72 20 50 62 7a 63-68 67 72 65 2c 20 56 61  cyr Pbzchgre, Va
001080b8  70 2e 20 20 4e 79 79 20-45 76 74 75 67 66 20 45  p.  Nyy Evtugf E
001080c8  72 66 72 65 69 72 71 2e-00 00 00 00 d4 ee 0a 10  rfreirq.........

Variable declarations from VLC drms.c DoShuffle()

The p_secret2 string is rot13'd version of Apple's copyright string, and is used as data during the DRM process. I suppose apple put it there to help any legal battles, as it'd clearly flag the DRM system as something they made, and everyone decoding the protected works will need to use that string. Jon ran it through rot13 to avoid having it present in plaintext form. Although the string is created by Apple, its presence is not indication that Apple's copyright is being infringed.

    static uint32_t p_secret1[] =
        0xAAAAAAAA, 0x01757700, 0x00554580, 0x01724500, 0x00424580,
        0x01427700, 0x00000080, 0xC1D59D01, 0x80144981, 0x815C8901,
        0x80544981, 0x81D45D01, 0x00000080, 0x81A3BB03, 0x00A2AA82,
        0x01A3BB03, 0x0022A282, 0x813BA202, 0x00000080, 0x6D575737,
        0x4A5275A5, 0x6D525725, 0x4A5254A5, 0x6B725437, 0x00000080,
        0xD5DDB938, 0x5455A092, 0x5D95A013, 0x4415A192, 0xC5DD393A,
        0x00000080, 0x55555555

    static char p_secret2[] =
        "pbclevtug (p) Nccyr Pbzchgre, Vap.  Nyy Evtugf Erfreirq.";

Disassembly from ECDPlayerControl.ocx

.text:10089E90  mov     eax, [edx]               ; p_commands[i]
.text:10089E92  test    eax, eax                 ; if zero,
.text:10089E94  jz      loc_10089F21             ;   continue loop
.text:10089E9A  mov     cl, al                   ; i_index
.text:10089E9C  shr     eax, 8                   ; source code ands first
.text:10089E9F  and     eax, 3                   ; same as (&0x300)>>8
.text:10089EA2  dec     eax
.text:10089EA3  jz      short loc_10089F03       ; case 1
.text:10089EA5  dec     eax
.text:10089EA6  jz      short loc_10089EE5       ; case 2
.text:10089EA8  dec     eax
.text:10089EA9  movzx   eax, cl
.text:10089EAC  jz      short loc_10089EC9       ; case 3
.text:10089EAE  mov     ecx, eax
.text:10089EB0  add     eax, eax
.text:10089EB2  mov     ebx, offset unk_100C5D46
.text:10089EB7  sub     ebx, eax
.text:10089EB9  movsx   eax, word ptr [ebx]
.text:10089EBC  shr     ecx, 4                   ; i_index>>4
.text:10089EBF  mov     ebx, [esi+ecx*4]
.text:10089EC2  lea     ecx, [esi+ecx*4]
.text:10089EC5  add     ebx, eax

Code from drms.c

Notice that the first three switch cases are outside the disassembly, although you can see the jumps. The default case is visible and you can see the code matches.

        if( !p_shuffle->p_commands[ i ] )

        i_command = (p_shuffle->p_commands[ i ] & 0x300) >> 8;
        i_index = p_shuffle->p_commands[ i ] & 0xff;

        switch( i_command )
        case 0x3:
            p_bordel[ i_index & 0xf ] = p_bordel[ i_index >> 4 ]
                                      + p_bordel[ ((i_index + 0x10) >> 4) & 0xf ];
        case 0x2:
            p_bordel[ i_index >> 4 ] ^= p_shuffle_xor[ 0xff - i_index ];
        case 0x1:
            p_bordel[ i_index >> 4 ] -= p_shuffle_sub[ 0xff - i_index ];
            p_bordel[ i_index >> 4 ] += p_shuffle_add[ 0xff - i_index ];

What is DRMS doing there?

Alex Halderman has an answer for this. Turns out, it's used to add (not remove) the DRM. This way, the CD could've been iTunes compatible. However, the code is not active, although it's usable and works. There probably was intention to include this functionality, but F4I/SonyBMG changed their mind at the last minute and just deactivated it instead of removing it completely. The reason they used GPL'd code was likely to speed up the development, reverse engineering it from scratch would've been more expensive. Copyright infringement was faster to do. There's a tiny difference in the analyzed code between VLC and XCP that most likely means it's custom made and intentionally included. Sebastian Porst has an annotated disassembly showing how the source matches with the drms.c code, with this one exception.

Who's responsible?

I have rather strong opinions on this, however, so read my Rant and Whine page if you want to hear about it.

Sony is claiming it's innocent since development was done by F4I, and they merely licensed the software. The ECDPlayerControl.ocx however has an interesting string in it, used for debugging, which reveals information about the developer's filesystem. The project has been developed in a directory called "XCP Player Code\Sony ActiveX Player\XCPPlayerControl\", which indicates that Sony had the product tailored for them, or perhaps even completely custom made. It's unclear how much Sony BMG knew of the technicalities involved in the DRM system, however it's obvious that they knew the main features - taking over the consumer system. They're facing several lawsuits about it, and it remains for courts to decide if they've broken the law or not.

Updated 2005-12-06 Matti Nikki <>