Slashdot Mirror
Sony Rootkit Phones Home
strider44 writes "Mark from Sysinternals has digged a little deeper into the Sony DRM and discovered it Phones Home with an ID for the CD being listened to. XCP Support claims that "The player has a standard rotating banner that connects the user to additional content (e.g. provides a link to the artist web site). The player simply looks online to see if another banner is available for rotation. The communication is one-way in that a banner is simply retrieved from the server if available. No information is ever fed back or collected about the consumer or their activities." Also on this topic, Matt Nikki in the comments section discovered that the DRM can be bypassed simply by renaming your favourite ripping program with "$sys$" at the start of the filename and ripping the CD using this file, which is now undetectable even by the Sony DRM. You can use the Sony rootkit itself to bypass their own DRM!" Update: 11/07 14:21 GMT by H : Attentive reader Matteo G.P. Flora also notes that an Italian lawyer has filed suit against Sony on behalf of the Italian equivalent of the EFF. Translation availabe through the hive mind. Update: 11/07 15:18 GMT by H : It does appear that in fact Sony does see through the $sys$ - see Muzzy's comment for more details.
CDex 1.51 had no issues ripping this CD.
Mark has also just posted how First 4 Internet, the creators of the rootkit, have made a rebuttle on Mark's claims: http://www.sysinternals.com/blog/2005/11/sonys-roo tkit-first-4-internet.html
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
-- Matti Nikki
As posted previously on another SONY DRM/rootkit article, here is a google search through Amazon listing the DRM'ed CDs:o m+intitle:%22%5BCONTENT/COPY-PROTECTED+CD%5D%22&nu m=100/
http://www.google.com/search?q=sony+site:amazon.c
SysInternal's Mark Russinovich has posted a new entry about Sony's XCP DRM technology.
According to his post, it seems Sony's fix "patch" makes a little "contact home" contacting Sony servers. This even when sony claims that their software didnt made contact with them.
Slashdot covered previously the intial XCP rootkit story.
The inquirer has an interesting article on the Sony DRM technology overall.
And it seems community have found several alternate uses for the XCP technology which include hiding game cheating software and even to bypass DRM technology
Ubuntu is an African word meaning 'I can't configure Debian'
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.
-- Matti Nikki
The rootkit installs a driver. In Windows (as in Linux and Mac OS X), lots of drivers (but not all) run in kernel mode. In particular, this one does. There is nothing to stop code running in kernel mode from doing anything it likes with the machine - it is running with the highest possible privileges.
In this case, the rootkit patches the system call table, so that calls to functions to look at directory contents are intercepted by the driver, which just pretends that no files starting with $sys$ exist.
There is nothing that Windows can do to stop drivers from doing this while they run in kernel mode. It can make it harder to do, though - I think the 64-bit versions of Windows check the system call table and blue screen if they find it's been changed. To get around that, the driver would either have to take over from Windows completely (not too practical) or find the code that checked the system call table and patch it.
Of course, you do need to have the right privileges to install a driver in order to install this rootkit. Usually, that means being an adminstrator.
Sorry, no bonus. The Van Zant CD with the rootkit has a CDDA logo. It's a multisession CD with real audio tracks with malware on a data track. Plus apparently one extra data track without filesystem, no idea what that is, shows up in my ripper.
In the front cover, no notice of protection. On the side, no notice. On the back, facing towards front, on left side of the cover (you know), there's "Content enhanced & Protected" text. On the reverse side, it says "Certain computers may not be able to access the digital file portion of this disc. Use subject to applicable end user license agreement". It says it needs a mac or PC with windows, pentium II, IE5, DirectX 9, 128M ram. Says that ripping with windows media player 9.0 works, and is compatible with Windows Media portable devices and Sony Walkmans.
So, yea, it pretends to be a CD. I don't know the standards to know if this is really a valid audio cd since it's multisession. It's definitely about trying to screw the consumer, though, since it tries to break the cd playback ability of the computer with the malware it ships with, under guise of "DRM".
-- Matti Nikki
Hope you weren't joking.