Hanno's blog

Google has the reputation to be free software-friendly. Without doubt they did a lot in the past, especially many Summer of Code-Projects, that developed essential features for free software projects.

That google is also willing to put legal threat on free software projects if they compete in their are, they recently showed against the project gaia. It was a project to have a replacement client for google earth (google's own client is proprietary). It was done by pure reverse engineering. The author took the project down after he received a letter from google.

It's quite questionable if gaia is doing anything illegal. They didn't use any data from google, they just provided another client for the service. In my opinion it's very important to fight for the right to reverse engineer. Many essential free software projects wouldn't exist if we couldn't reverse engineer. Just think of many hardware drivers, filesystem support, samba, many multimedia codecs, support for proprietary document formats (e. g. doc in OOo) and lot's more.

By the way, I took the freedom to host a copy of the latest gaia-version (and, as requested by some comments, the win32-patch for gaia). It's GPL, so everyone is free to continue the development.

onlinetvrecorder, a service that let's you record broadcasts from some german television stations, provides it's files in .otrkey-format, which can be decoded using their binary otrdecoder-tool, considering you have requested the recording in advance.

As there is no information how the format and authentication work, I had a deeper look at it.

Getting the key

Using some network sniffer, the authentication is very simple, it just requests them with http, the URL is
http://www.onlinetvrecorder.com/uncrypt.php?email=[email]&pass=[pass]&filename=[file]
(filename is the .wmv-name without otrkey)
Inside that file is an ascii/hex-encoded number with 128 bit. That very much looks like a key.

This already gives us the possibility to manually download the key and, if we want to re-decode some movie (because we lost the wmv or because we want to decode a file before it's completely downloaded to already start watching the recording), save the key to a local webserver as uncrypt.php, forward the hostname to 127.0.0.1 and re-start otrdecoder.

The cryptography

From what I found out yet, the file is encrypted with some sort of blowfish. The encrypted and decrypted files are exactly the same size, that means we have no IV and a variant of blowfish that does no padding.

The best I got till now was using mcrypt with ecb-mode:
mcrypt -d -a blowfish-compat -s 16 -o hex -b --noiv -m ecb --nodelete -f [keyfile] [file]

This decrypts the first 256 bytes correctly, after that it seems to mix up things (the correct decryption continues at byte 512). From what I read in Schneier[1996] (»Applied cryptography«), there is an ecb variant using ciphertex stealing that avoids padding. I found no easy-to-use implementation of that.
Having a commandline-cryptography tool that supports more options than mcrypt would be handy here.