libgourou is a free implementation of Adobe's ADEPT protocol used to add DRM on ePub files. It overcome the lacks of Adobe support for Linux platforms.

There are a few limitations, but nothing too serious:

• Only ePub is supported. No PDF
• Command line only
• Alpha quality software. It works - but is a bit finickity

You can compile the code yourself, but I just downloaded the pre-built binaries.

On Ubuntu / Pop I needed to sudo apt install libzip-dev.

Once you've unzipped the download, cd into it and run:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PWD

Then

./adept_activate -u youremail@example.com -p SuperStrongPassword

Use the same credentials as you do in Adobe Digital Editions. You can just use the -u flag and type your password in at the prompt - but I couldn't get that to work. The -p flag worked fine.

After a few seconds, you'll see: youremail@example.com fully signed and device activated in /home/you/libgourou_utils_0.3.1/./.adept

Then run: ./acsmdownloader -f whatever.acsm

After a few moments, you'll see: Created whatever.epub

That's it! Your file is downloaded and you can read the ePub.

Note: If you try to download a PDF, you'll get an error saying: Exception code : 0x5007 Message : whatever.epub

You can rename the file back to .pdf, but it will still be encrypted.

Sure, you can futz around with Docker, WINE, and old versions of Python - and if you're lucky, you might get a book out of it.

I wasn't quite so lucky. I wanted to see if I could download an ePub without using Adobe Digital Editions. Spoilers! I couldn't. But this is what I found.

The First ACSM file

When you buy an eBook, the vendor sends you a .acsm file. Adobe Content Server Message is a simple XML file. This is what it looks like and what each line means:

<fulfillmentToken fulfillmentType="buy" auth="user" xmlns="http://ns.adobe.com/adept">
  <distributor>urn:uuid:b479af7f-09bf-48f5-a6c6-...</distributor>
  <operatorURL>http://drm.firebrandtech.com/fulfillment</operatorURL>
  <transaction>67809895895d46aab...</transaction>
  <expiration>2021-07-19T18:55:59-04:00</expiration>

This states I've purchased the book, who distributes it, where the download server is, and some metadata

Next, metadata about the book:

  <resourceItemInfo>
    <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
    <resourceItem>0</resourceItem>
    <metadata>
      <dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">The End of Bias</dc:title>
      <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jessica Nordell</dc:creator>
      <dc:publisher xmlns:dc="http://purl.org/dc/elements/1.1/">Granta Publications</dc:publisher>
      <dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">urn:ean:9781846276774</dc:identifier>
      <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">application/pdf</dc:format>
    </metadata>
    <licenseToken>
      <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
      <permissions>
        <display/>
        <excerpt/>
        <print/>
        <play/>
      </permissions>
    </licenseToken>
  </resourceItemInfo>

Finally, a digital signature:

  <hmac>rL4Ttn7ASp16Y4...=</hmac>
</fulfillmentToken>

The Second ACSM file

When you open the .acsm file in Adobe Digital Editions (ADE), the software creates a new .acsm file. This one is signed with the key that Adobe generates when you register with it. This is what the file looks like and what each line means:

First, information about me as a user, and my device:

<fulfill xmlns="http://ns.adobe.com/adept">
  <user>urn:uuid:99b1e32d-5b39-4968-8ef6-c5cb6a739ec8</user>
  <device>urn:uuid:ac790662-5da0-4075-aee2-99b3c4592619</device>
  <deviceType>standalone</deviceType>

Then a repeat of the original .acsm:

  <fulfillmentToken fulfillmentType="buy" auth="user">
    <distributor>urn:uuid:b479af7f-09bf-48f5-a6c6-...</distributor>
    <operatorURL>http://drm.firebrandtech.com/fulfillment</operatorURL>
    <transaction>67809895895d46...</transaction>
    <expiration>2021-07-19T18:55:59-04:00</expiration>
    <resourceItemInfo>
      <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
      <resourceItem>0</resourceItem>
      <metadata>
        <dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">The End of Bias</dc:title>
        <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jessica Nordell</dc:creator>
        <dc:publisher xmlns:dc="http://purl.org/dc/elements/1.1/">Granta Publications</dc:publisher>
        <dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">urn:ean:9781846276774</dc:identifier>
        <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">application/pdf</dc:format>
      </metadata>
      <licenseToken>
        <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
        <permissions>
          <display/>
          <excerpt/>
          <print/>
          <play/>
        </permissions>
      </licenseToken>
    </resourceItemInfo>

Then, a different HMAC:

    <hmac>rL4Ttn7ASp16...=</hmac>
  </fulfillmentToken>

And, finally, another digital signature

  <signature>znoLnR2A4wG1uE85oXPYzSZjTRNo76ctgfR8COY8nlNTCcPge9O6VeB5UY...=</signature>
</fulfill>

POSTING the file

Digital Editions then posts the new .acsm file to the DRM server mentioned. It replies with a location where the file can be downloaded from. In this case:

http://drm.firebrandtech.com/media/77d79621-0e96-4f4f-8fee-....pdf

That's literally just the resource's UUID as the filename. It can be downloaded and opened in ADE.

Signing the file yourself

So, if you've downloaded the first .acsm file and have your encryption keys extracted from ADE you can sign it yourself, right?

I dunno. I'm no good at reverse engineering binaries. I suspect so. ADE is a Shockwave / Flash app - so I doubt it has anything too taxing in there - but it is beyond my skillset.

Further Reading

• gedonder's notes on ACSM
• Karl Voit's rant about ADE

We argued loudly, passionately, deployed logic and reason, and provided specific technical details.

Naturally, we were ignored.

Sure, Flash was only on a few high end devices now, but the BBC were confident that Flash would be soon be available on all Android devices and our perceived problems would evaporate.

Naturally, reality decided to ignore their wishful thinking.

Two years and one week after the BBC announced its Flash for Android strategy, Adobe announced it was killing Flash for Android.

High end Android devices like the Nexus - and any device running Android 4.1 would be incapable of running Flash. So there was no way to use iPlayer.

BBC iPlayer

@BBCiPlayer

For those asking about Nexus 7 / Jelly Bean 4.1 - we are testing the app and will be releasing an update soon. Thanks for your patience.

---

This failure is exactly what happens when you choose vendor driven proprietary "solutions" rather than established and open standards.

This embarrassing turn of events is exactly what happens when you refuse to listen to the geeks making logical arguments.

This monumental cock-up over the Olympics is exactly what happens when you refuse to engage with reality and let prejudice drive your decision making process.

Here are the facts:

• Most Android devices cannot use the Flash based iPlayer app.
• Mobile Flash is now dead for future phones and tablets.
• Android devices can play exactly the same files as those served to the iPhone via iPlayer.

So why not just serve up the iPhone's MP4 files to any device which can play them? The BBC refuse to answer that simple question.

Want to know something funny? I was blogging about how to deliver iPlayer's iPhone streams to other models of mobile in March 2008!

Plus ça change.

We can only guess what shenanigans were involved with the BBC's original decision to bet the Android farm on Flash.

Perhaps now our BBC will pay more attention to the geeks who care so much about it.