apple cuts us off

Apple cuts us off

Updated - the protection has been reversed!

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 = 0xFFFF

C7C0 (really?)

0x70 76 zero padding 0x00000000

0x32 is most likely a SHA1 hash, and 0x58 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