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
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 able to obtain a new iPod Classic or Nano.
Technorati Tags: copy control, itunes, iPod