OverDrive Media Console Analysis

In the previous article we investigated the background and technologies surrounding the DRM process used by the OverDrive Media Console. In this article we will turn our attention to the OverDrive Media Console itself in order to locate any mechanism which we can manipulate for our advantage.

Before we begin with the analysis of the OverDrive Media Console application it should be noted that there are some prerequisites to enable proper analysis:

• A jailbroken iDevice (For demonstration purposes an iPad and iPhone will be used). I have not had a chance to look into Android or Blackberry installations of OverDrive Media Console, but with file system access similar result may be achieved.
• An Adobe ID
• An installation of Adobe Digital Editions
• A system capable of running Python
• inpetkey
• ineptepub

Firstly SSH or otherwise gain command line access to your device and locate the installation of OverDrive Media Console. As an example, on the iPad the program was found at following location:

/private/var/mobile/Applications/EB126631-4B6C-40E5-8430-4F6B9ABC403C

If you’re having trouble the execute from the root (/ not /root) directory:

find * | grep OverDrive

Inspecting the program directory it can be seen that the EPUBs that have been downloaded are stored in an uncompressed format under:

[OverDrive Media Console Root]
- /Documents
-- /eBooks
--- /ePubs
---- /{EPUBID}.epub
----- ...
---- /{EPUBID}.epub
----- ...
---- /{EPUBID}.epub
----- ...

From this listing it can be seen that when one chooses to download an EPUB title through the OverDrive Media Console application the EPUB data is effectively fetched from the content server and stored locally. This functionality is what allows the program to operate in an offline mode. However, even though the content is stored locally it is still encrypted utilizing the AES-CBC-128 cipher as noted in each EPUB’s META-INF/encryption.xml file.

So now with all of this information one should be able to ZIP up the EPUB directory to create a specification-compliant EPUB file and use the available ineptkey and ineptepub tools to decrypt the file. However, let’s see how these tools work and verify their functionality with our newly created EPUBs.

First, since we have already installed completed the process of creating an Adobe ID, installing Adobe Digital Editions, and authenticating with our Adobe ID we will use the ineptkey tool to retrieve our private RSA cipher key.

The RSA cipher key was saved as adeptkey.der which includes the private cipher key in a x.509 certificate utilizing ASN.1 DER encoding. Now in theory all we have to do is use the ineptepub tool in conjunction with this certificate to extract the AES cipher key and decrypt the target EPUB content.

Strange. We get a failure, and the only message is that our file is not a valid ADEPT EPUB. So what situation can cause this error to be thrown? Examining the source we find the following logic statement:

if 'META-INF/rights.xml' not in namelist or \
'META-INF/encryption.xml' not in namelist:
raise ADEPTError('%s: not an ADEPT EPUB' % (inpath,))

So essentially if the EPUB does not contain a rights.xml or encryption.xml file in the archive’s META-INF subdirectory the document is assumed to not be a valid ADEPT archive. Indeed, upon further inspection of the archive this fact is confirmed insomuch that although there exists the required META-INF/encryption.xml document there is no META-INF/rights.xml document which contains the information needed to ultimately decrypt the document’s contents.

What does this mean? In essence, either Adobe (through their Adobe Content Server product) or OverDrive Inc (through their Content Reserve system) are apparently transmitting EPUBs in some sort of format that is not compliant with the ADEPT standard that they themselves created. To wit, does this mean that we’ve hit a brick wall in our analysis of the OverDrive Media Console Software? Hardly. Since the software can operate in an offline mode there must exist a method by which the information originally contained within the rights.xml is stored and retrieved locally.

In our next article we will delve even further into the inner workings of the OverDrive Media Console and bring to light several failures of the system and its architecture that allow for full automation of the DRM removal process with minimal effort.

[Thanks to Armin Tamzarian]