Friday, March 12, 2010

Reverse Engineering: Youtube & h.264 for the masses

So a client asked me if he could get a youtube video in their new iPhone app. I replied it should be possbile ... Hence this post

Like any sensible mac user i signed up to the youtube beta as soon as i heard about it. My beloved 2007 macbook is starting to show it's age, and while it can handle 1080p videos without melting (it's sweats a fair bit!), flash videos truly bring it to its knees.

So first thing i did was select a random youtube video, this one happened to be a short about the upcoming indian premier league (i personally hate cricket, but anyways...).

I was immediately disheartened, it wasn't going to be as easy as simply reformatting the link ...

This format is new and exclusive to the HTML 5 beta, from my research the h.264 content delivered to the iphone has a different format, and is served from a different domain.

Also a quick glance shows that a different series of subdomains are used, and while i haven't tested, i'm guessing these are a series of load balance servers, so there is no guarantee that the video will be on the same server.

Even more bad news the signature param appears to change on every request, suggesting that it's generated for each session. I tested this, my using the same account to watch the same video, but once in safari and once in chrome, checking the signatures each time.

Signature A

Signature B

Beyond the signature nothing else seems to change. My guess is that youtube will have to open this up when they start to provide video embed tags instead or in addition to the standard object/embed mashup.
Retardation, tells me those are 2 SHA1 hashes separated by a dot, the age old question is whats the plain text?

I'm not kevin Mitnick (Holla at me Kevin ;) ). My minimal security knowledge tells me that the plain text includes a variable that is changing. My assumption is that it user session key, but with no know access to it. (Unless the people aka google are dumb uninformed, which is highly unlikely i assume they encrypt their session cookie).

So for now the h.264 videos are safe :(

No comments: