Sony's Compact Disc Controversy

From Consumer Affairs:

It's been a bad few weeks for Sony BMG Music. First was the revelation that their copy-proof compact discs contained software that could hide files on any computer the disc was played on, and could cripple the entire machine if a user tried to remove it. Even a quickly-issued "patch" to the software didn't soothe buyers' outrage.

Now the entertainment giant is facing a potential class-action lawsuit in California for violation of a state law that forbids "inducing" the installation of spyware or similar utilities on a personal computer in order to use a particular application.

The issue first came to light when Mark Russinovich, a software designer and Windows expert, found evidence of a "rootkit" on one of his systems. Rootkits are tools designed to camouflage changes to a computer system made after a hacker or spyware vendor has compromised it.

Russinovich investigated the rootkit and traced it back to a company called First 4, which recently struck a deal with Sony to provide digital rights management (DRM) for its CD music releases. DRM controls the usage of a CD and is often used to block it from being copied onto a computer or to make multiple copies.

There's no mention of the rootkit in the end-user license agreement (EULA) that a buyer agrees to when they play the disc, and attempting to remove it can cripple Windows computers, which may require a full reformat and reinstall of the computer's hard drive.

From Sysinternals:

Last week when I was testing the latest version of RootkitRevealer (RKR) I ran a scan on one of my systems and was shocked to see evidence of a rootkit. Rootkits are cloaking technologies that hide files, Registry keys, and other system objects from diagnostic and security software, and they are usually employed by malware attempting to keep their implementation hidden (see my “Unearthing Rootkits” article from thre June issue of Windows IT Pro Magazine for more information on rootkits). The RKR results window reported a hidden directory, several hidden device drivers, and a hidden application:
Given the fact that I’m careful in my surfing habits and only install software from reputable sources I had no idea how I’d picked up a real rootkit, and if it were not for the suspicious names of the listed files I would have suspected RKR to have a bug. I immediately ran Process Explorer and Autoruns to look for evidence of code that would activate the rootkit each boot, but I came up empty with both tools. I next turned to LiveKd, a tool I wrote for Inside Windows 2000 and that lets you explore the internals of a live system using the Microsoft kernel debugger, to determine what component was responsible for the cloaking.Rootkits that hide files, directories and Registry keys can either execute in user mode by patching Windows APIs in each process that applications use to access those objects, or in kernel mode by intercepting the associated kernel-mode APIs. A common way to intercept kernel-mode application APIs is to patch the kernel’s system service table, a technique that I pioneered with Bryce for Windows back in 1996 when we wrote the first version of Regmon. Every kernel service that’s exported for use by Windows applications has a pointer in a table that’s indexed with the internal service number Windows assigns to the API. If a driver replaces an entry in the table with a pointer to its own function then the kernel invokes the driver function any time an application executes the API and the driver can control the behavior of the API.It’s relatively easy to spot system call hooking simply by dumping the contents of the service table: all entries should point at addresses that lie within the Windows kernel; any that don’t are patched functions. Dumping the table in Livekd revealed several patched functions:
I listed one of the intercepting functions and saw that it was part of the Aries.sys device driver, which was one of the images I had seen cloaked in the $sys$filesystem directory:

READ the rest HERE