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
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 freedom-to-tinker.com'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.
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.
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.
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 v.org/..0.90.... 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
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 :(
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
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.........
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.";
.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
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 ] )
{
continue;
}
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 ];
break;
case 0x2:
p_bordel[ i_index >> 4 ] ^= p_shuffle_xor[ 0xff - i_index ];
break;
case 0x1:
p_bordel[ i_index >> 4 ] -= p_shuffle_sub[ 0xff - i_index ];
break;
default:
p_bordel[ i_index >> 4 ] += p_shuffle_add[ 0xff - i_index ];
break;
}
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.
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.