Open Computing for Geeks

With their new iPod series, Apple introduced a new Hash mechanism on the files database in the iPod : the tunesDB file.

After 36Hours of hacking, a group of developers found a way to generate the same Hash as generated by iTunes on windows or Mac Os X.

It seems quite strange to have such simple algorithm based on a kind of weak algorithm (SHA-1). The way the hash is done is also kind of dirty !

Here is a comment from a guy on this blog post http://www.backdot.com/?p=50 :

Superna: I wondered the same thing. Looking through the hash_linux
code, I don’t think it can plausibly be a simple corruption check. The
main reason I think this is that the hash only covers the first approx.
256kB of the database file. Anything after that isn’t checksummed. This
would be nonsensical if the intent were just to protect against
accidental db corruption.

The algorithm in a nutshell is a standard HMAC-SHA1 over the first
0×4006C bytes of the file, with a few fields (such as the hash field
itself) zeroed out. The HMAC key is derived in a very roundabout way
from the firewire ID of the iPod — it involves computing the LCM of
pairs of bytes in the fwid, which isn’t an activity I remember seeing
in other key-generation schemes, so it’s probably something homegrown
at Apple.

The hash_linux code seems to be obfuscated in a few ways, not sure why.

It seems this Hash system is an addition to the "copy between iPods" protection available since the first iTunes application on Mac Os 9. Maybe EMI wanted another protection with their contract with Apple for non-DRM music files !

Well, hopefully we have a way to break this protection, but will Apple stay without no reaction like the iPhone desimlock stuff or a brand new firmware and a new iTunes version will be available ?

We'll see !