Page 17

decrypts it, and, if necessary, adds the XCP user key to the database and re-saves it in encrypted form. The
iTunes database encryption function (0x1008A0C0) and decryption function (0x1008A300) both make use
of the

DoShuffle

routine (0x10089E00) taken from DRMS.

6.3

Attacks on the Backdoor

We note that the DRM vendor must include some kind of limited back door so that the vendor's own CD-

reading software can reliably access the music on the disc. The active protection software will offer some
kind of interface that can be called to get access to the raw data from the disc, or to deactivate (temporarily)
the active protection. This back door interface must be protected so that an ordinary program cannot use the
back door to access the music. There are three ways to protect the back door.

1. Secret interface. The back door interface can be kept secret so that ordinary programmers do not

know how to call it. This method is disfavored because its security by obscurity method violates
Kerckhoffs's Principle [19].

2. Secret key passed as argument. There can be a secret key that must be passed to the back door interface,

and the active protection software can be programmed to ignore requests that do not contain the correct
key. This is superior to the secret interface method because it relies on a randomly generated key rather
than secrecy of algorithm information. But an adversary who can interpose himself into the back door
interface can observe the key, and can act as a man in the middle to modify the calls being made to
the active protection software.

3. Cryptographic protocol. The vendor's application software can use a cryptographic protocol to com-

municate with the active protection software. The sort of protocol used for secure remote procedure
call on a network would be suitable, with the network messages replaced by calls across the back
door interface, so that each back-and-forth pair of messages in the protocol was replaced by a single
call and return. This approach makes interface snooping and interposition attacks useless (assuming
the protocol is properly secure). However, it cannot stop an adversary from reverse engineering the
vendor's application-level software to learn the protocol and extract any keys.

6.4

MediaMax Player Security Risks

Besides suffering from several kinds of attacks that expose the music content to copying, the MediaMax
version 5 player makes the user's system more vulnerable to attack. When a MediaMax CD is inserted
into a computer, Windows autorun launches an installer from the disc. Even before displaying a license
agreement, MediaMax copies almost twelve megabytes of files and data related to the MediaMax player
to the hard disk and stores them in a folder named

%programfiles%

Common Files

SunnComm

Shared

. Jesse Burns and Alex Stamos of iSec Partners discovered that the MediaMax installer sets file

permissions that allow any user to modify its code directory and the files and programs in it [5].

As Burns and Stamos realized, the lax permissions allow a non-privileged user to replace the executable

code in the MediaMax player files with malicious code. The next time a user plays a MediaMax-protected
CD, the attack code will be executed with that user's security privileges. The MediaMax player requires
Power User or Administrator privileges to run, so it's likely that the attacker's code will run with almost
complete control of the system.

Normally, this problem could be fixed by manually correcting the errant permissions. However, Media-

Max aggressively updates the installed player code each time the software on a protected disc autoruns or
is launched manually. As part of this update, the permissions on the installation directory are reset to the
insecure state.