Slashdot Mirror

Yes Record Companies are always sooo nice when it comes to DRM rootkits.

I've written some pages about Sony's XCP DRM system.

Summary about the DRM, what it does, and what its problems are: http://hack.fi/~muzzy/sony-drm/info.html

You can also find my research and opinions about the issue linked from there. Please send mail if you have anything to add or any corrections to my content.

Get it now (Mirrors)

I saw that, too. I just emailed 'muzzy@iki.fi' (the site owner) about it:
On your page at http://hack.fi/~muzzy/sony-drm/, under the section called "Dump from the First4Internet's ocx file", you have a block of hex code in which appears the text "pbclevtug (p) Nccyr Pbzchgre, Vap. Nyy Evtugf Erfreirq". This is a simple ROT13 translation of "copyright (c) Apple Computer, Inc. All Rights Reserved". Not sure if you noticed this, but if not, here you go!

First of all it seems that there is more than just LAME in there: http://hack.fi/~muzzy/sony-drm/

Second of all, am I the only one who finds it ironic that a DRM program designed to protect someone's copyrighted information is itself infringing on someone's copyright? I guess if Sony wants to fight those evil copyright violators they should start by putting themselves in jail.

The GO.EXE doesn't appear to contain LAME code even though it has been linked against it, however at least ECDPlayerControl.ocx on the CD (packed in XCP.DAT, installed along DRM) does contain code from LAME. It also uses Id3lib and mpglib, without attribution or any licenses shipped along. I spotted bladeenc dll there as well.

Check the bottom of my research page for info, http://hack.fi/~muzzy/sony-drm/
There's not much there at the moment but I'll be adding information as soon as everything can be properly confirmed and evidence gathered.

The Sony uninstaller is an ActiveX object marked safe for scripting (which means any website can use it in their code)

Its got some wonderful entries which still leave holes in your system (like rebooting your computer, and a method called "ExecuteCode")
The guys has only just started work, but has an expliotable test together which will reboot your machine.

Look here for more info about Sony uninstallation fun.

If that were true, it is strange that strings like "0.90", "LAME3.95", "3.95", "3.95 " -- indicating a specific version -- are in there.

I mean, why would they look for a *specific* version of LAME if they want to rule out mp3 encoding software running on the machine?

Also check this post: http://slashdot.org/comments.pl?sid=167537&cid=139 69409

"Go and check it yourself, and compare to lame sources. The data from tables.c is included in the executable in identical form (several large tables), also all the version strings are included, which the DRM system doesn't check.

The data is there, the big question is if it was linked accidently, or if it actually uses LAME code as well."

He's talking about the *data* of several large tables being in there.

Further more, the theory that the DRM software would be using these strings in order to look for "incompatible" programs does not look very plausable, because the DRM kit seems to look for program names rather than scanning the executables, judging from the strings posted here:

http://hack.fi/~muzzy/sony-drm-magic-list.txt

Besides, that does not explains the date from the tables being in there.

Further, we have a post by a F4I employee on usenet talking about an mp3 player he wrote:

http://groups.google.com/group/microsoft.public.wi ndowsmedia.drm/browse_frm/thread/8270cbc85f8e9cb8/ 7cb5c4ad49fa206e?lnk=st&q=FIRST4INTERNET&rnum=44&h l=en#7cb5c4ad49fa206e"

"I am currently writing an MP3 player with lots of bells and whistles including a wave editor, fades, reverbs etc.
What I now need is to be able to protect the files it creates. I have already written the routine to convert the MP3 into a WMA file.
Does someone have some simple C++ code which can write Microsofts DRM v1 properties that the user whishes to set(i.e. 3plays 4 copies etc) over the unprotected file to make it protected. There may be some cash on offer here if its easy to use! All I need is a procedure that performs this"

And, another thing is that LAME also seems to be cabable of decoding: http://mp3decoders.mp3-tech.org/decoders_lame.html

Taking things togeter, to me it looks unlikely that they are looking for a specific version of LAME by scanning trough executables, while for other mp3 playing software they simply look for the name of the executable.

I think it is very well possible they use of have used LAME in their mp3 player. Then the strings and tables either indicate that Lame is indeed being used by the bundled player to play mp3s, or they mistakenly linked the Lame library because they did use it in other parts of their software and somehow did not realise they were linking the Lame lib.

Just my luck, when I make it to slashdot it's something I've analyzed wrong. I tested to rename my ripping software to begin with $sys$ and it ripped it fine, but apparently something else was the deciding factor. I can't reproduce that effect!

There's definitely something fishy going on, however, with two magic lists in the DRM system (one in installer, one in $sys$DRMServer.exe), and the drmserver scans running processes and open windows, testing them against those lists. So far I haven't figured what it does when it finds a match. The code is written in C++ and although I've found the function call, it's virtual and I need to figure which vtable is being used and it's bitchy without a debugger. I'm not going to run this crap on my development systems, and my test machine doesn't even have net access, too much work to setup debuggers on it just yet :(

Anyway, the lists for everyone to see:
http://hack.fi/~muzzy/sony-drm-magic-list.txt
http://hack.fi/~muzzy/sony-drm-magic-list-2.txt
The first one is from installer, the second from drmserver

Just my luck, when I make it to slashdot it's something I've analyzed wrong. I tested to rename my ripping software to begin with $sys$ and it ripped it fine, but apparently something else was the deciding factor. I can't reproduce that effect!

There's definitely something fishy going on, however, with two magic lists in the DRM system (one in installer, one in $sys$DRMServer.exe), and the drmserver scans running processes and open windows, testing them against those lists. So far I haven't figured what it does when it finds a match. The code is written in C++ and although I've found the function call, it's virtual and I need to figure which vtable is being used and it's bitchy without a debugger. I'm not going to run this crap on my development systems, and my test machine doesn't even have net access, too much work to setup debuggers on it just yet :(

Anyway, the lists for everyone to see:
http://hack.fi/~muzzy/sony-drm-magic-list.txt
http://hack.fi/~muzzy/sony-drm-magic-list-2.txt
The first one is from installer, the second from drmserver