Using Rootkits to Defeat Digital Rights Management
The
Sony rootkit debacle highlighted the use of rootkits to prevent pirates and authors of CD burning, ripping, and emulation utilities from circumventing Digital Rights Management (DRM) restrictions on access to copyrighted content. It’s therefore ironic, though not surprising, that several CD burning and disc emulation utilities are also using rootkits, though the technology is being used in the opposite way: to prevent DRM software from enforcing copy restrictions.
Because PC game CDs and DVDs do not need to be compatible with set-top players software vendors can store data on media in unorthodox ways that require software support to read it. Attempts to make a copy of such media without the aid of the software results in a scrambled version and the software has DRM measures to detect and foil unauthorized copying.
CD burning and emulation software companies owe a significant amount of their sales to customers that want to store games on their hard drives. The legitimate claim for doing this is that it enables fast, cached access to the game., though it is well known that this is also used to make illegal copies of games to share with friends - so content-protected CDs and DVDs present a challenge the companies can’t ignore. One way to deal with the problem is to re-engineer the software that interprets the data stored on the media, but that approach requires enormous and on-going resources dedicated to deciphering changes and enhancements made to the encoding schemes.
An easier approach is to fool game DRM software into thinking its reading data for playing a game from its original CD rather than from an on-disk copy. DRM software uses a number of techniques to try to defeat that trick, but a straightforward one is simply to detect if CD emulation software is present on the system and if so, if the game is being run from an on-disk emulated copy. That’s where rootkits come in. Two of the most popular CD emulation utilities are
Alcohol and
Daemon Tools and they both use rootkits.
Alcohol advertises itself as enabling you “to make a duplicate back-up to recordable media of nearly all your expensive Game/Software/DVD titles, and/or an image that can be mounted and run from any one of Alcohol's virtual drives”. When you run a
RootkitRevealer scan of a system on which Alcohol is installed you see several discrepancies:
The first two are data mismatches whereas the last one is a key that’s hidden from Windows. A data mismatch occurs when RootkitRevealer obtains a different value from a Registry API than it sees when it looks at the raw Registry data where the value resides. When you view either of the values in Regedit they appear to be composed of sequences of space characters:
Why would Alcohol want to use data mismatching rather than the typical cloaking technique to hide the value altogether? The values in question are located in HKLM\Software\Classes\Installer\Products and HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall and both areas are where applications store information for use by the Windows Add/Remove Programs (ARP) utility. ARP uses the ProductName value in an application’s Products key as the name it displays in its list of installed applications so an empty value implies that we should see a product with no name in the list. However, a quick look shows that there are no missing names and we know that the value is associated with Alcohol, but it shows up in the list:
Using
Regmon to capture a Registry activity trace of ARP, which as a Control Panel applet is implemented as a DLL hosted by Rundll32.exe, confirms that ARP reads displayed Alcohol text from the mismatched ProductName value whereas Regedit sees only empty data for the same value:
The other mismatched value behaves the same way and it’s my guess that Alcohol masquerades strings that identifies its presence on a system from anything but ARP in order to avoid detection by DRM software like that included in games that disable themselves in the presence of CD/DVD copy and emulation software. There are many other signs DRM software can use to sense Alcohol’s presence, but the Alcohol developers likely discovered that a check of installed products is or was the most commonly used.
The remaining RootkitRevealer discrepancy is the cloaked Jgdd40 key in the Config subkey of the Vax347s driver. Alcohol must include a device driver that presents phantom devices to Windows in order to create virtual CD and DVD devices and Vax347s is the driver that fills that role. An easy way to see inside a cloaked Registry key is to open the parent of the inaccessible key in Regedit, choose Export from the File menu and select Registry Hive Files from the format drop down. Then copy the file to a different system, launch Regedit, navigate to HKLM, and choose Load Hive in the File menu. The name you enter for the key is up to you. When you follow the steps on the cloaked key you see a single value, Ujdew, within it:
The contents are binary data, but my guess is that it describes the volumes that the driver virtualizes. Game DRM software that is Alcohol-aware would be unable to determine whether the volume from which it was executing was on a real device or one that was emulated. Evidence that supports this theory lies in Jdgg40’s parent key, Config, which also contains a single value named Ujdew, but with slightly different contents than the one that’s hidden. The second value is almost certainly a decoy to throw off DRM developers that determined that it at one time contained virtual drive mappings:
Alcohol, like Sony’s rootkit, uses system call hooking to intercept Registry APIs and manipulate their behavior. This memory dump of the Windows kernel-mode system call table contains addresses that fall outside of the kernel image, the telltale sign of a system-call hook:
The addresses correspond to Registry-related system calls and the
debugger confirms that the addresses lie in a second Alcohol driver, Vax347b, that’s responsible for the cloaking:
On a system with Daemon Tools installed RootkitRevealer reports the presence of a single discrepancy:
An interesting aspect of Daemon Tools’s rootkit is that it doesn’t cloak the presence of the key listed, but rather denies access even to RootkitRevealer, which should be able to open any key regardless of the key’s security. Following the same steps I described earlier for gaining access to off-limit keys unveils the key’s contents:
Paralleling the Alcohol example, the key is part of Daemon Tools’ virtual device driver and appears to contain configuration information, implying that Daemon Tools hides the key to fool game anti-emulation software by preventing it from finding a way to distinguish virtual volumes from real ones.
There’s no proof that Alcohol and Daemon Tools use rootkits to evade DRM, but the evidence is compelling. If they do their usage is clearly unethical and even potentially runs afoul of the US
Digital Millennium Copyright Act (DMCA). In any case, there’s no reason for these products, or any product as
I’ve stated previously, to employ rootkit techniques.
[2/7/06: Clarification: when I say "their usage is celarly unethical" I'm not referring to users of the products, but to the utilities themselves being designed to circumvent DRM. I've previously defined rootkits and explained their risks.] Speaking of rootkits, here’s an
amusing video of a song named Patch Me Up by the North Sydney band Rootkit.
Originally by Mark Russinovich on 2/6/2006 9:27:00 AMMigrated from original Sysinternals.com/Blog