Educated Guesswork: iPod/iTunes lockout, etc.?

« Well, as long as you're one of the 1.5 billion | Main | Bimodality in cancer survival improvements »

September 15, 2007

iPod/iTunes lockout, etc.?

The iPod/iPhone is obviously designed to be used with iTunes, but for a variety of reasons, some people want to use them without. A number of pieces of 3rd-party software have been developed that can talk to the iPod, copy songs to the disk, manage playlists, etc. However, the newest iPods appear to have some feature that makes this problematic:

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.

I have no special knowledge about this particular situation, but some initial reactions follow:

Even without reverse engineering iTunes, it may be possible to determine whether 0x32/20 is a SHA-1 hash by doing some simple entropy testing and looking at the average number of bits that change if you change the database at all.
If 0x58/20 really has some "similarities between versions" then it's probably not a SHA-1 hash, because digests appear random with respect to their inputs. Not everything that's 20-bytes is SHA-1.
If either of these values (0x32/20 in particular) is a SHA-1, then it should be pretty straightforward to figure out what data is being hashed is by reverse engineering iTunes.
Even if it's not SHA-1, unless Apple is going to break the invariant that any iTunes can manage any iPod, it pretty much must be possible to write a universal program that will compute whatever the function is. I.e., it's hard to see how it could be keyed to some specific iTunes instance.
I'm not entirely convinced that this is intended to lock out third party management software. It may just be some kind of ordinary database integrity check implemented in a fail-unsafe kind of way.

Posted by ekr at September 15, 2007 8:56 AM | Filed under: DRM