Recent changes Random page
Science Fiction
Biggest wikis
See more...

IPhone H.264 version

From Beebhack

Jump to: navigation, search

On the 7th of March 2008 the BBC launched an iPhone compatible version of their web-based iPlayer service. Visitors to iPlayer site using an iPhone would be presented with a slightly tweaked interface, but crucially where users of the site using a desktop web browser, iPhone users would see an embedded Quicktime player streaming H.264 video (referred to on iPlayer as MP4) over a normal HTTP protocol. This is the current method used by download scripts.


[edit] Overview of video request process

The process for requesting the H.264 video is as follows:

  1. Video page is requested and a "BBC-UID" cookie is set, containing the URL-encoded User-Agent string of the browser.
  2. The iPhone version of iPlayer renders a Quicktime object into the page which requests the video URL as[PID]?[RAND] where [PID] is the programme version ID and [RAND] is a random number, although the random number is apparently unused by the service. This URL must have:
    1. The Quicktime User-Agent header
    2. The BBC-UID cookie
    3. A "Range" header of "0-1"
  3. The video URL then 302 redirects to a much more complex URL. The same headers are sent
    1. BBC-UID cookie
    2. Quicktime User-Agent
    3. The "Range" header, this time using "0-"

[edit] Example HTTP headers sent by an iPhone session

Accept: */*
Cookie: BBC-UID=74a79c638cbe4c2d416e453f70f0dcf063d0b78d20c0c1d4843ffaaf85b17c9c0Mozilla%2f5%2e0%20%28iPhone%3b%20U%3b%20CPU%20like%20Mac%20OS%20X%3b%20en%29%20AppleWebKit%2f420%2e1%20%28KHTML%2c%20like%20Gecko%29%20Version%2f3%2e0%20Mobile%2f4A93%20Safari%2f419%2e3
User-Agent: Apple iPhone v1.1.4 CoreMedia v1.0.0.4A102
Connection: close
Range: bytes=0-1

This is then followed by a redirect response and the client creates another request to the actual media location:

Cookie: BBC-UID=74a79c638cbe4c2d416e453f70f0dcf063d0b78d20c0c1d4843ffaaf85b17c9c0;
User-Agent: Apple iPhone v1.1.4 CoreMedia v1.0.0.4A102
Connection: close
Range: bytes=0-

[edit] Timeline of BBC updates to iPhone interface

[edit] 7th March 2008

iPhone compatible version launched. The weak user-agent checking was spotted and exploited immediately.

[edit] 13th March 2008

Although the BBC did not announce the nature of their "fix", it was quickly uncovered by monitoring network traffic between Apple devices and the iPlayer servers. Whereas before the service had only checked for the iPhone/iPod browser's User-Agent HTTP header, it was now also checking the distinctive User-Agent and Range headers sent by the media subsystem. Once this was added to existing scripts, they continued to function largely as normal. By the end of that day, a few developers had already updated their scripts to work around the update:

[edit] 7th April 2008

"Irregular Shed" noticed that the BBC have tightened up the user agent checking required to convince iPlayer that it is talking to an iPhone/iPod Touch. Whereas previously it was sufficient to pass nothing more than "iPhone" as a user agent string to access the service, it now checks for more. To be on the safe side, all scripts should make use of the full, verbose user agent string:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

... or the iPod Touch equivalent:

Mozila/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like Gecko) Version/3.0 Mobile/3A101a Safari/419.3

[edit] 6th June 2008

From early June 2008, the BBC changed the mechanism used to encode their videos for the iPhone/iPod Touch. Although downloading via spoofing still works, the downloaded files will not play on any common desktop software.

In fact the DRM appears to be a simple XOR of a large section of the plain vanilla MP4 with a repeating two-byte pattern. Specifically, the first 0x2800 bytes are unchanged, then the next bytes are XOR'd with values beginning 0x3c, 0x53, 0x3c, etc., then the last 0x400 bytes are unchanged. Just to make things interesting the two bytes immediately before the last 0x400 clean ones are XOR'd with reversed values. So (for example) the file is XOR'd with 0, 0,..(0x2800 times).., 0x3c, 0x53, .... ,0x3c, 0x53, 0x3c, 0x53, 0x53, 0x3c, 0, 0, ..(0x400 times)... To recover the original file, just XOR again with these values.

In some files, the number of reversed bytes at the end is greater than two. These files may not decode correctly with current programs.

(Here is a Perl script for XOR decoding the above files)

(Here is a patch for the ruby iplayer-dl for XOR decoding as the file is downloaded)

[edit] 9th June 2008

Working code was produced from the above discovery to decode the XOR'd video data. See Decode Programs

Rate this article:
Share this article: