Peter’s blog

Seems like Apple is trying to stop third parties controlling their new iPods.

Apple cuts us off:
So, it’s finally happened. Unhappy with other media players being better than iTunes, Apple have apparently decided to stop them from working with the new range of iPods.

Who does this affect?

This affects Linux users - there’s no iTunes for Linux, so popular Linux iPod management tools like gtkpod and Rhythmbox will not work with the new range of iPods.

Windows users who just plain don’t like iTunes and perfer an alternative like Winamp, Ephpod or many of the other iPod management applications out there.

How?

The iPod keeps track of the songs and playlists in your iPod with a database file - the iTunesDB, found in the iPod_Control/iTunes/ hidden folder on the iPod.

Back in the early days of the iPod, the format of this file was quickly reverse-engineered by people who wanted to use iPods without iTunes. This was more important back then because iTunes only existed on the Mac, so Windows users were stuck with Real Player (which was just awful), and Linux users had exactly nothing.

The format of this file has evolved over the years as the iPod added support for video, podcasts, album artwork, smart playlists etcetera. The basic structure of the file has always remained the same, so these changes were easy enough for us to work out and keep up to date with.

With the release of the new range of iPods - the new Nano, the iPod Classic and the iPod Touch, we were expecting more of the same - a few tweaks here and there and everything would be fine. No so.

At the very start of the database, a couple of what appear to be SHA1 hashes have been inserted which appear to lock the iTunes database to one particular iPod and prevent any modification of the database file. If you try to do either of these, the hashes will not match and the iPod will report that it contains “0 songs” when the iTunesDB would otherwise be perfectly adequate.

Can’t you get around this?

Well, maybe. We really need people who are excellent at reverse engineering to help.

This is what we know so far about the start of the iTunesDB file:

MHBD header:
0x00   4  mhbd
0x04   4  header size = 0xBC       (changed)
0x08   4  filesize
0x0C   4  unknown = 1
0x10   4  version number = 0x19    (changed)
0x14   4  child count    = 0x05    (changed)
0x18   8  itunes databaseid
0x20   2  unknown = 2
0x22   2  unknown = 0x0263         (changed, 0x0000 before)
0x24   8  ipod identification?     (changed)
0x2C   4  zero padding
0x30   2  unknown = 1
0x32  20  unknown, changing completely from itdb to itdb
0x46   2  language, seen: de, en
0x48   8  library persistent id
0x50   4  unknown, seen: 1, 5
0x54   4  unknown, seen: 0x08, 0x0D, 0x1D, 0x4D, 0x8D
0x58  20  unknown some similarities between versions
0x6C   4  timezone offset in seconds. +2*60*60 -> 0x00001C20, -4*60*60 = 0xFFFFC7C0 (really?)
0x70  76  zero padding 0x00000000

0×32 is most likely a SHA1 hash, and 0×58 also could be.

The question is, could you help? Hop along to freenode #gtkpod if you have some serious technical expertise in this kind of thing and are able to obtain a new iPod Classic or Nano.

Technorati Tags: copy control, itunes, iPod