From todays solar eclipse, which could be partially watched from Germany, I tried to take some pictures.

Good that I kept my special eclipse sun glasses from 1999 (when we had a total eclipse over south Germany I completely missed due to the bad weather back then). Most of the time it was cloudy, but I still managed to get some nice pics.

Yesterday I played around a bit with what hardware sensors can do and how to access them in linux.

hddtemp

The first, and quite trivial tool I tried was hddtemp. You don't need to do anything further, just install it and run
hddtemp /dev/hda
(Assuming your harddisk is hda, which is usually the case)

It supports a bunch of harddisks by default and if it doesn't know your HD, it tries to access it with some default-values. Extending the hd-database seems to be trivial, I already sent a patch for my HD. Output looks like this:
/dev/hda: SAMSUNG MP0804H: 46°C

lm_sensors

lm_sensors is a bunch of drivers and tools to use hardware-sensors on motherboards. As you probably have no idea what chips your motherboard has, lm_sensors brings a tool called sensors-detect to help you. The way to go is just enabling everything (except debugging, which you usually don't need) in the kernel-sections i2c and hardware monitoring as module and let sensors-detect to the work.
Basically, pressing return all the time should be okay. At the end, it'll tell you which kernel-modules are useful for your system.

After that, running sensors shows something like this:
max6657-i2c-0-4c
Adapter: SMBus I801 adapter at 1100

M/B Temp: +40°C (low = -65°C, high = +127°C)
CPU Temp: +36.6°C (low = +35.1°C, high = +72.2°C)
M/B Crit: +110°C (hyst = +100°C)
CPU Crit: +110°C (hyst = +100°C)

Well, not that useful, but interesting to know that I have at least 3 temperature-sensors in my laptop.

Update: As noted by Joshua Jackson in the comments, with smartctl /dev/hda (from smartmontools) you get the temperature and much more information about your HD.

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.