I spent
the whole weekend looking for a DRM-encumbered Sony CD so that I could check
for myself whether my code was really being redistributed without permission.
I eventually found one: Suspicious Activity?, by The Bad Plus. A rather
enjoyable post-modern jazz album. I am lucky, it could have been
Céline Dion.

As expected, installing the CD’s custom player also installed a stealth
aries.sys driver along with a few other interesting files such
as $sys$DRMServer.exe, all hidden in a $sys$filesystem
directory. I rapidly got rid of this cruft and started studying the really
important file, ECDPlayerControl.ocx.
It is the file Sebastian Porst and Matti Nikki found to be containing parts of mpglib, LAME, faad2, VLC...

Evidence that the DRMS code comes from VLC

There are of course obvious similarities between some functions and
structures of ECDPlayerControl.ocx and the ones in VLC’s source.
However, given how precise the implementation of a cryptographic protocol
needs to be, the possibility that two separate implementations show many
similarities must not be dismissed. The data structures and constant tables
especially are likely to be identical. I think however that I found strong
enough evidence that this is not the case here.

The original drms.c was written by Jon on 01/05/04. I then hacked on that file on 01/18/04 and reorganised it, also replacing the reverse-engineered MD5 and AES functions with clean implementations, then Jon added DRMSv2 support on 05/05/04 and I reorganised the code again on 05/08/04. Some of these changes were specific to VLC (not in that they made the code unusable outside of VLC, but rather that they made it possible to use an external MD5 hash provider, for instance), so they were the bits I was looking for in ECDPlayerControl.ocx.

For instance, Jon’s original code had the following instruction:

p_acei[ 4 ] = 0x5476212A;

Since all bytes of this long word are comprised between 0x20 and
0x7f, it was later rewritten like this:

char p_secret1[] = "Tv!*";

This change makes the code more human-readable because many other secrets
in the Apple DRMS protocol are ASCII strings. Also, I know how to look for
binaries that use the string "Tv!*", but it takes me some more time
to think of a way to find binaries that use 0x5476212A. And the
Sony rootkit uses the following (only relevant lines shown):

The use of xxxxx+4 shows that
ECDPlayerControl.ocx uses a string instead of a 32 bits integer to
store the secret, disregarding the fact that the 5th character of the string
(a null char) is never used.

Another example: in this commit
I reorganised the DoExtShuffle() function, merging
FourthPass() and FifthPass() and discarding a structure
allocated on the stack. What is important here is that DoExtShuffle()
was built by a complex combination of choices, the main purpose of which being
to reduce the size of the C functions:

Note how i_ret is not reused and could be merged into the
p_bordel array, or maybe SecondPass() merged into
FirstPass(). This choice is definitely a legacy of how the code
evolved. And the Sony equivalent: a perfect match.

After having studied the Sony code for a while, I have of course gathered
dozens of such examples. But I also discovered a few new things.

Where does the DRMS code come from?

The code undoubtedly comes originally from VLC, but it has traveled a lot. I
would be surprised if it came directly from VLC, as no other part of
VLC is included with the rootkit. And although there are parts of FAAC in the Sony code and FAAC
includes VLC’s drms.c, the version currently in the FAAC CVS is
horribly outdated.

Sebastian Porst also noticed a few obvious differences between the
Sony code and the version of drms.c present in VLC. The most
obvious being this one:

That 0x01000400 is a version check for 4th generation iPods
firmwares. I also discovered at least 40 KB of new lookup tables that seem
to be used for more buffer shuffling. At first I thought it was simply
F4I’s DRM implementation, but the shuffling calls are nested with iPod
hardware information retrieval from our DRMS code, so they’re really part
of drms.c.

Sony distributing a DRMSv3 descrambler?

The only explanation I can think of is that someone took the VLC code,
added support for an upcoming Apple DRMS format version and redistributed
the software without letting the VLC authors know, probably violating the
GPL (I only say that because I have not found the software yet, but I
feel pretty safe in saying it).

Since it is based on GPL software, I was already entitled to ask Sony
for the source code of ECDPlayerControl.ocx. But as the copyright
holder of a significant part of the software they counterfeited, maybe I have
a greater chance of being heard.

Not that it would be difficult to reverse-engineer it yet another time,
but it would be awesome if the next opensource iTunes Music Store file player
was contributed by Sony!