DRM: September 2007 Archives


September 23, 2007

Apparently the iPod SHA-1 thingamajig has been reverse engineered. As I said earlier, I'm not convinced that this actually was intended to lock down the iPod. However, it's interesting to ask how one would actually do that in a way that was harder to reverse engineer.

Two goals were ascribed to the alleged SHA-1 in the database:

  • Stop any programs other than iTunes from managing the iPod.
  • Lock the iPod to a specific instance of iTunes.

If all you have is a hammer, everything looks like a nail, and if you're a COMSEC guy, problems like this bring crypto to mind. At a high level, there are two cryptographic strategies for this kind of job: encrypt the database which is then decrypted by the iPod/iTunes or apply an integrity check which is checked by the iPod/iTunes. Each of these have advantages in some contexts, but we can treat them mostly the same for the purposes of our discussion, so without loss of generality, let's talk about an integrity check.

The difficulty, as with most cryptographic contexts, is key management. We want to make sure that only legitimate copies of iTunes can produce databases that the iPod can verify, which means that iTunes has to contain a key that isn't known to third party developers. There are two options here: all copies of iTunes have the same key—this is basically the same as a fixed, secret, integrity check function or one over unknown data, i.e., the situation we have now. Any system of this type is very vulnerable to key extraction via reverse engineering. Once you have the key (or the function) you can write your own program.

The other approach is to use a separate key for each copy of iTunes. When a new iPod is attached to iTunes, it gets a copy of the key (imprinted). The most attractive mechanism here is probably to use public key cryptography and put the public key on the iPod. The key can even be signed by Apple to avoid false imprinting. Then all database updates are signed and the iPod verifies them. Of course, you can still mount a reverse engineering attack and extract the key from a single copy of iTunes, but then we're in an arms race where Apple can program new iPods to ignore that key, thus forcing the third-party software authors to constantly change keys.1

Another strategy for the attacker is not to extract a single key but rather to have the third-party software extract keys from a valid copy of iTunes, though this is obviously this is a bit inconvenient if you don't want to be involved with Apple's software at all.

If this sounds like the kind of issues you have with DRM, it is. And like DRM, the attacker has an enormous advantage as long as your system is software only and he's prepared to reverse engineer it. The situation changes a lot if you are willing to have trusted hardware (in this case on the host computer) but that would be a big change for Apple.

1. If Apple is willing to force people to register online, you can make detection and revocation of extracted keys much more efficient.


September 15, 2007

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.