Thursday, March 23. 2006
Ein neuer schokokeks

Nachdem dieser in jüngerer Zeit immer häufiger unter der Last ächzte, musste der alte Keks weichen. Gerade eben haben wir den Umzug vollzogen auf einen brandneuen AMD64 mit 2 GB Ram etc.
Schleichwerbung: Wer einen professionellen, etwas anderen Webservice-Provider sucht, der ein bißchen mehr bietet als üblich, darf sich gerne mit mir in Verbindung setzen.
Thursday, March 9. 2006
Reverse engineering onlinetvrecorder
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.
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.
Posted by Hanno Böck
in Computer culture, Cryptography, English, Linux
at
21:17
| Comments (4294967295)
| Trackbacks (2)
Sunday, March 5. 2006
DSL-Modem Internals

Es handelt sich um ein originales Telekom/Siemens-Gerät und dürfte zu einer sehr frühen Generation gehören (war unser erstes DSL-Modem).
Nebst den für den gewöhnlichen Betrieb benötigten Anschlüssen 10BT und BBAE befand sich noch eine weitere Buchse mit der Beschriftung ATM (was wohl sowas wie ein High-End-Netzwerkstandard auf der Ebene von Ethernet ist), sowie ein zugeschraubter, etwas ungewöhnlicher Anschluss, der aus zwei quadratischen und zwei runden Öffnungen (je circa 1 mm Durchmesser) besteht, vermutlich für Wartungsarbeiten, Firmwareupdates o.ä..
Das Gehäuse ist so konstruiert, dass es sich praktisch nicht zerstörungsfrei öffnen lässt (insofern besser nicht mit Geräten ausprobieren, die noch funktionieren sollen), eine Reparatur dürfte somit nicht vorgesehen sein. Die entsprechenden Verhakungen lassen sich jedoch einfach mit einem Schraubenzieher aufbrechen.
Die Beschriftung der Chips sollten sich auf nebenstehendem Bild lesen lassen.
Für kreative Verwendungszwecke bin ich offen, bitte in die Kommentare posten.
(Page 1 of 1, totaling 3 entries)