iTunes Art

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 600×600 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

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 600×600 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 600×600-100 shown above is replaced with 170×170-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:

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.

iTunes Art

15 thoughts on “iTunes Art

  1. kris says:

    Why not go to google images and type in the album name? It’s not a jpeg of the original artwork, but there are usually good quality scan’s of the actual booklet.


  2. That’s what I’ll have to do from now on. It was really nice to be able to just paste the URL into a textfield and instantly get square, high-quality artwork without the minor hassle of sifting through images and then tweaking them before adding them to music.


  3. “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.”

    I really don’t know that much about programming, but could this timemarker change in code be used to manage time-limited movie rentals via iTunes?
    Just an uninformed thought…


  4. Ah, that’s true., of all places, has 500×500 pixel artwork that’s decent. Occasionally, I find that they don’t have a lot of the artists I’m looking for. Maybe that’s my fault for having unusual tastes in music ;-)


  5. Some friends and I picked up on this awhile ago and they’ve blogged it. Fortunately, I managed to populate the majority of my music collection [for the Mac mini + Front Row] before they yanked the plug. Heck, I even borrowed the source to integrate into my own site!

    For some good news, I do know a bunch of guys on the iTunes, iTMS and iLife product teams from my years at Apple, and I’ve put my feelers out to see if there’s anything they can tell me “off the record.”

    While I agree Apple is in the right to restrict access [notice that low-res versions still work], it’s somewhat unfair when consumers purchase newer Macs with Front Row and have crappy, low-res album art littering the interface.

    The answer is out there. Only time will tell if we can beat it.


  6. Dave says:

    Hey Collin. A few random thoughts.

    The MD5 must include info specific to a particular album so you can’t mod the album title in the URL to access others.

    Probably includes the timestamp to make sure you can’t build a permanent repository/communal web site mapping albums to fixed URLs (they’re no good after a week.)

    Might want to include the size info in case you have separate super-hi-res images.

    All of the above is included as part of the URL so I’d just use that in the MD5.

    Now, to make harder to reverse engineer include other hidden, possibly static, more probably somehow dynamic (calculated?) info in the MD5. Dissecting iTunes would be the only way to discover that.

    If this is intended as a generic method to protect access to iTMS URLs I’d suspect the base URL up to the MD5 is used as the only core data so it could easily be applied to any URL. As long as I’m relying on this to protect my URLs in general I’d also put a lot of work into the hidden data to make it very hard to reverse engineer, and include a per application (album art, lyrics, etc) tag in the MD5 just to confuse things a bit more.

    Or maybe none of the above ;-)


  7. I’ve always thought it’d be nice if when ripping a CD it downloaded the album art from iTunes and added it in like it does with ID3 tags from the CDDB. I’d bet that it’s the record companies that don’t want them doing that more than anything, though.


  8. Jonny says:

    What we need is someone to set up a website which is a database for artwork. People who have bought tracks off itunes simply copy and paste the artwork into a paint program and save the file, then submit it to the site. That way they’re all the high quality images from itunes but they’re not owned by them. I can’t do it because I don’t have a clue about setting up websites, but if someone did it would eventually have most covers on.


  9. I really don’t think that a database with user-submitted artwork would be a good solution. It would take ages for users to upload the artwork everyone would need, and never mind the possibility of being sued for copyright infringement. It’s just…a lot of work, a lot of dependence on people exporting and uploading artwork for free, and very little payoff.


  10. thanks for the info. Very interesting. Seriously though… it’s not like Apple is loosing money on the bandwidth. I get teh feeling they made a bunch of people mad for no apparently good reason.


  11. Dave says:

    A new database would be a good idea, but you would have the problem of people uploading crap quality images. No one would ever agree on a standard. And unless a lot of people used it the database would be pretty small. Sites like Amazon, Walmart and iTunes have hundreds of people working on the site and has gradually been built up over the year, not an overnight thing.

    I used to use, then moved to Amazon…I will check Walmart and Coveralia out.


  12. tavo says:

    hey guys, i change from pc to mac and upload my music database with a hard drive in the mac.
    I select the folders of the music inside of the itunes music folder, and move inside of itunes. only some of the artwork where copied. do you know what can i do ?


Leave a Reply to Olly Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s