The iTunes database is, as an obfuscation, AES-encrypted with a constant key (“BHUILuilfghuila3“ as ASCII). I got the value from brian d foy’s original code and it’s worked well for titl. From around version 8.2 the file is compressed before encryption: it’s a smart move for a file format with so much redundancy and, thanks to a hint, some code and a patch, titl went back to health.
Now, with version 10, decryption of some libraries fails. New empty libraries work but a full migrated one fails. Is there a new key? Is there a new intermediate step? For a new key, I’m essentially forced to mount a partial known-plaintext attack against my own data. Titl is very intentionally a clean-room project, so I’m not about to start disassembling iTunes binaries.
(Update: This is now fixed, thanks to Brad Lowe. Encryption remains the same but now stops after the first 100KiB.)
Ironically, I ran into these problems while trying to salvage more data after iTunes split off a few of my albums’ first tracks into their own separate identically-titled albums. For comparison, the iOS Notes app uses a SQLite database and rudimentary HTML. Very easy to recover, as I found after a botched device restore left me with a few missing files. Two points: firstly, if your software is perfect, I may not need direct access to my data. Secondly, your software is not perfect.
)