Command-Tab

About two months ago, Apple limited iTunes album art access to users who download a song or album requiring the artwork. While this has no effect on those who simply buy from iTunes, many people – myself included – found it very useful to be able to retrieve 600x600 pixel artwork from iTunes and apply it to music gotten elsewhere. The download scheme has been changed, most likely with the sole purpose of breaking third-party systems that gather artwork automatically. While Apple has every right to do this, it makes adding metadata to a new album just slightly more complicated than it used to be. iTunes has always had great quality album art, even beyond what Amazon provides, and it was great to be able to add that into new music with very few steps.

Back when album art was “easy” to get from iTunes, all one had to do was control-click (right-click) on the album title, choose “Copy iTunes Music Store URL”, paste the link into the field on this site, and click Submit. The high resolution artwork for the referenced album was then displayed, and it could be pasted directly into iTunes’ song information windows.

From the front, the iTunes artwork-grabbing script was easy, fast, and painless. The code side was more complicated, as the given album URL had to be retrieved from the iTunes Music Store, decrypted using a symmetric key (which must have been derived from the iTunes binary), and scanned for image links. If found, the medium size album image URL – the very image seen when an album description page is loaded in iTunes – could then be modified to produce the full size artwork URL.

To see what changes Apple made after I became aware of the situation, I first opened the iTunes Music Store and added the “Free Single of the Week” to my cart (I shop in iTunes using a shopping cart system because I’m indecisive, okay?). I then started up my OS X packet-sniffing program of choice, Eavesdrop, and began watching web traffic over my WiFi connection. Since iTunes uses a web-based store, presumably to slip effortlessly through firewalls, every byte of communication between the Music Store and my computer would be logged for review. Upon clicking the “Get Song” button, a small bit of activity began, ending with a bunch of packets coming my way. My song arrived, but that was the least of my interests as my attention turned to the timing of the data that was sent and received. As soon as the transaction was initiated, my computer first requested a set gzip compressed of font styles, perhaps for display somewhere in the Music Store or new Mini-Store. Nothing spectacular there. The very next request was for the URL http://a1.phobos.apple.com/r10/Music/14/36/a4/mzi.aihenrgv.600x600-100.jpg?downloadKey=1154640230_abe417e7d789521ccd1ccb355b23775a. Before the album art method was changed, it was possible to load the part of the URL above up to the “?” and ignoring everything after, resulting in the download of the full 600x600 image. The unmodified URL retrieved by the artwork script above was similar to the one requested today, with the slight difference of the size parameter tacked onto the end. In the Music Store, the 600x600-100 shown above is replaced with 170x170-99, and that link still returns a smaller, store-sized version without requiring a downloadKey section.

So, what is this downloadKey that Apple has implemented? Keen observers will note that the first chunk of the downloadKey string contains a Unix timestamp of the instant of purchase/download. 1154640230 is the number of seconds that have passed since the Unix epoch, marking the exact time the tranfer was initiated. The second half is 32 bytes long, which happens to be the same length as an MD5 hash. Unfortunately, hash functions are designed to work one-way only; Getting the original text out of the hash is (damn near) impossible except for brute force attacking it, and that could take eons. Where does that leave those interested in continuing being able to get great quality album artwork from iTunes? Out in the cold, for now. Until someone disassembles iTunes and figures out what data is being hashed, the downloadKey cannot be recreated without first purchasing the song and thus defeating the whole purpose. On top of that, the time marker in the downloadKey is also one week from the date of purchase, likely limiting access to the image for that time period. After the noted time has passed, I’m betting that the access privileges are revoked.

Both the expiration date and the mysterious hash in the downloadKey are probably stored in a database on Apple’s end, and the full size image is served back only if the request has the right hash and is within the noted time period. I can’t even begin to speculate why the time is in the URL to begin with, as the webserver can compare the hash and timestamp of any particular request without revealing the timestamp. Unless the webserver is taking in the timestamp from the URL, I can’t see the purpose of displaying it. If it is being done that way, why even bother if we can freely modify the timestamp anyway? Such an obstacle would be like locking a keypad protected door, but allowing any code to reopen it.

While I’m disappointed to have inconclusive results for my analytic efforts, here are some facts I’ve discovered:

• Neither the timestamp nor the hash can be changed without resulting in an immediate rejection of the image request.
• The source computer – the one downloading the song – is able to generate the downloadKey without any meaningful communication to the Music Store. The answer is right in front of us, it’s just hidden. Security methods that allow the “attacker” to hold all the pieces of the puzzle tend not to stay secret.
• The hash is not an MD5 of the timestamp, nor is it an MD5 of the song itself, as it has not even begun to download at the time of the image request.
• Both the timestamp and hash change each time the same song is downloaded. The timestamp’s reason for changing is obvious.
• Unix timestamps can be quickly converted to a readable date by doing php -r "echo date('r',1154640230);" in the Terminal.
• It appears that the full size artwork must be requested prior to the song download, as it is then applied to each finished transfer. One would expect that the artwork is already in the songs, but it must not be if it’s being requested independently.
• References to an MD5 function exist all around every instance of “downloadKey” in the iTunes binary. Apple is either most definitely using MD5 for a hash, or they are going to an awful lot of effort to create a wild goose chase. My bet is on the former.

Here are a two downloadKey strings for those interested in pursuing this topic further: 1154640230_abe417e7d789521ccd1ccb355b23775a 1154667369_c0d7aa281b0b0247e094c194ed360659

Short of disassembling iTunes, which is out of my skill level, I think this is far as I can go. Hopefully someone with more skill can pick up here. For now, I’ll have to resort to Amazon and Google Images for album art sources.