Post another set to compare one encrypted jpg to another encrypted jpg (don't bother with the itc file).

Also...in that image you have it implies the encrypted version shows up as an unrelated image...for me it doesn't render as an actual jpg...

yeah, post another set of images. . .

The encrypted file shows up in firefox for me but looks garbled

To clear up confusion, the thumbnail of the encrypted image is just the default JPEG icon in Windows Vista.

I have posted another example set.

dave-
What do you mean by it showing up in firefox garbled? For me it only shows the filename when I try to view the encrypted image.

Some more albums with encrypted covers:

NOFX - Heavy Petting Zoo
NOFX - Ribbed
NOFX - Punk in drublic

I'm sure you've considered this, but what are the chances that the "downloadKey2=1160626777_b69d6ec64a43566af002c1ad7e09c9fd" line is significant?

josejuan05-
the downloadKey is significant in its own way (see http://marv.kordix.com/archives/000849.html) but not significant in the encryption of the artwork files. Only in obtaining them, which isn't a problem.

Every encrypted copy of a cover is the same as someone else's encrypted copy of that same cover. There are no individual unique keys to encrypt them or anything. To see this is true, grab an encrypted cover and have a friend grab the same encrypted cover from their computer, and compare the MD5 hashes. They should be identical.

The only similarity I've ssen so far is that the encrypted files all seem to begin with three bytes, 000100.

I tried throwing a couple of Decryption algorithms at it raw, and each of them consitently told me that the length of the encrypted image was off.

Are the encrypted files consistently 20 bytes larger thn the unencrypted?

>Are the encrypted files consistently 20 bytes larger thn the unencrypted?

If the image format is JPEG, yes.

Just noting observations:

I see there is an MD5 value (looks to be a base-64 encoded hash value) sent in the header of each response.

Marv, where are you getting your MD5 values? Are you computing a hash value for the entire stream of each file? (the encrypted, the itc, and the jpeg)

I'm going to have a go at this :)

Update: This is what I've been doing instead of working today ;)

It looks like they're using Rijndael encryption and sending back the initialization vector (IV) back through the response, using the "Content-MD5" header.

I was able to encrypt the unencrypted JPEG files myself and produce output which was consistently 20 bytes larger. This being the case, my guess would be that they are decrypting the JPEG, **THEN** wrapping it in an .itc, not decrypting an .itc file. I think you can remove the .itc file from the equation altogether.

This being the case, can you tell us what the Content-MD5 values were for the files you've posted (Or tell us what the albums were that you downloaded art for, so we can capture them ourselves). If I'm right, this may be a pretty easy operation to decrypt this stuff.

Yay. :)

>Marv, where are you getting your MD5 values? Are you
>computing a hash value for the entire stream of each file? (the
>encrypted, the itc, and the jpeg)

Those MD5 values I posted under each image were simply hashes of the respective files themselves, to be sure you the downloader got the files across the wire perfectly intact.

>This being the case, my guess would be that they are decrypting
>the JPEG, **THEN** wrapping it in an .itc, not decrypting an .itc
>file. I think you can remove the .itc file from the equation
>altogether.

Yes, that is correct. The only reason I included the ITC file was that my method of converting from ITC to JPG was hacked together and may have been imperfect somehow, so I wanted to include all "pure" files from the equation.

>This being the case, can you tell us what the Content-MD5
>values were for the files you've posted (Or tell us what the
>albums were that you downloaded art for, so we can capture
>them ourselves). If I'm right, this may be a pretty easy
>operation to decrypt this stuff.

The first example cover is "Spitalfield - Better Than Knowing Where You Are"
The second is "Evanescence - The Open Door"

Note: not all album artwork are JPEG- some are PNG. I chose example covers that happened to be JPEG to keep it simple.

Exchange for "Evanescence - The Open Door"

CLIENT:

GET /r10/Music/02/dc/e8/mzi.nubpqrmt.enc.jpg?downloadKey2=1163357975_2e07036bf8864d9cc73d5ebd83715a4f HTTP/1.1

Accept-Language: en-us, en;q=0.50

X-Apple-Tz: -21600

Cookie: s_vi=[CS]v1|44F4B7D000001FC1-A000B3D00006319[CE]

User-Agent: iTunes/7.0.2 (Windows; U; Microsoft Windows Vista Professional (Build 5600)) DPI/96

X-Apple-Validation: 47722C6A-522E8DCBF05AE6CE22CD177ECB3BE89C

Accept-Encoding: gzip, x-aes-cbc

X-Apple-Store-Front: 143441-1

Host: a1.phobos.apple.com

SERVER:

HTTP/1.1 200 OK

Server: Apache

ETag: "413bcd437ae6bce0d42d5bb70c0550ed:1158872269"

Content-MD5: QTvNQ3rmvODULVu3DAVQ7Q==

Last-Modified: Thu, 21 Sep 2006 20:57:16 GMT

Accept-Ranges: bytes

Content-Length: 268126

Content-Type: image/jpeg

Date: Tue, 07 Nov 2006 00:31:28 GMT

Connection: keep-alive

Got it. Thanks Marv.
Hey Chris, any thoughts?

I too am thinking its the AES algorithm in which case it might not be that hard to tackle, but I havn't had much time to give it a shot. I'll keep you updated.

Just for your gratification, I worte an article explaining ithe ITC file structure with a little more depth on my site.

Please bear with me as my site is woefully and almost perpetually under construction.

http://www.waldoland.com/dev/Articles/ITCFileFormat.aspx

Any luck with any of this? This problem has been rattling my brain. I wrote a C++ port of this, and at first it only affected a few of the albums. Now, it's pretty much everything. Any updates on any of your theories, or any way that I could help out? Please let me know.

I've just about exhausted my knowledge of cryptology... no success at all whatsoever.

I'm wondering... how much of a difference is there between the size of the payload being returned by the web service call, and the size of the actual "decrypted" image file? Is it possible that the image file itself is just a gzipped compressed resource, like the xml-rpc payload that is returned for the original request for a given artist and album?

So... I've been working a little on this on and off, but it doesn't look very hopeful. I just can't figure out what this stuff means. For instance, check out this stuff:

C:\Documents and Settings\First\Desktop>efsinfo *.jpg

C:\Documents and Settings\First\Desktop\

mzi.cptetbef.enc.jpg: Not Encrypted

something.enc.jpg: Not Encrypted

C:\Documents and Settings\First\Desktop>

This seems to indicate that those image files from the iTMS aren't encrypted, but that doesn't make much sense.

oh never mind, that was stupid. it's just microsoft's efs tool. it apparently doesn't detect other stuff like aes.

How did you do your test with the encryped images? I took one of the ITC files from whatever iTunes grabbed, extracted the image to look at it to see which album it was, used my Windows GUI program I wrote to get the album art, and then tried to compare the file my program retrieved. The "enc" file that was retrieved was like 400k and the ITC file was like 40k. Not sure what test you were doing to get the encoded, and then non-encoded files.

Hey Gang. Sorry I've been off for a while, settling into my new job.

For Levi:
Simple method to demonstrate encrypted artwork comparison:

Use Ethereal (or some other packet sniffer) to sniff the HTTP Messages as you perform the "Get Album Artwork" command in iTunes. In the HTTP response, you can see the encrypted album artwork is sent to iTunes.

Let iTunes do the work of decrypting the artwork and saving it into an.itc file. You can usually determine which .itc file was just created by using Search on the album artwork directories and finding files created within the last few seconds. (Bear in mind that that is just how I do it on Windows. You may have a different or better means of finding the .itc file) This should yield the .itc file for your album artwork.

Once you have the .itc file, use whatever script you like to extract the image data from the .itc file. (There are a couple mentioned in this post)

When comparing the encrypted data with the decrypted image data, the encrypted is typically about 20 bytes larger.

I think collectively, we've concluded that Apple is using and AES/Rijndael algorithm, being that we've been able to encrypt the image data on our own, using that scheme, into streams that are consistently 20 bytes larger than the original image.

I think the trick that is left is just to figure out what Apple is using as an encryption/decryption key for that algorithm.

Dig it?

Waldo:
Ok, I see what you guys were doing. I was using the tool that I wrote (http://leviwilson.com/Projects) to download the artwork by querying the iTunes server and using the returned URL to grab it. The images that iTunes uses from the ITC files are significantly smaller that way (in one case 65.2KB for ITC and 520KB using my method). What are the odds that the key that they use is in iTunes.exe? Just wondering if they would be dumb enough to have it statically defined in their executable.

This sounds like a job for DVD Jon. Jon has established credentials as an über encryption geek (after all he has cracked the iTunes Fairplay DRM and before that the DVD CSS encryption).

Levi,

>Just wondering if they would be dumb enough to have it statically defined in their executable.

My guess is that they're using some combination of string values embedded in their exe, and the MD5 value sent back to the HTTP Response.

Well Folks....

I have encrypted images and 3gp. Can any one tell me how to decrypt these files in PC..

for eg.. i have flower.jpg.enc

Reply as soon as possible

Your Replies will be highy appreciated...

umm... to 'break' itunes album art encryption, (in windows this works, dunno about mac) drag the album art displayed onto desktop. unencrypted bitmap album art for you there. Delete the album art from itunes then drag one from desktop in if you really want. This has worked for years, and works on purchased as well as album art retrieved by itunes.

Think simple people...

Todd-
Yes, it is simple to get artwork files from the iTunes Store if you go through the iTunes program. This is not news.
A problem with the way you are talking about getting the art is that you end up with a large bitmap copy of the cover even though it has already been JPEG compressed. If you want to get the true smaller JPEG file out of iTunes you can simply convert the ITC files it creates back to the original JPEGs through any number of methods (my new favorite being dragging ITC files to BitmapRip).

But what WE aim to do is come up with a method to get the decrypted artwork WITHOUT the help of iTunes. If this could be achieved, the method could be put into scripts and apps that would be able to grab iTunes art all by themselves.

But until then, yes, we have to let iTunes do the work.

I, too, have been unsuccessfull in the decryption of these files. Thought I should share my observations with you, anyway;

AES/Rijndael seems to be it. The data is in chunks, that is divisible with those of AES. I doubt the Content-MD5 is the IV, though. I've exhausted all possible options there.

Interesting find: If you extract all strings from the iTunes binary, you *will* stumble upon a lot of garble, but also the 16-byte string "DontMessWithThis". Coincidently, 16-byte strings are perfectly fine as AES keys.

I wrote a script that applied 5-6 common algorhitms to two files, and compared how similar the results were. I reached 12% at best, but of course, the slightest bit will tilt the result, so that's no good. But I have tried Blowfish/AES/IDEA etc. with all 16-byte strings extracted from the iTunes binary, with no luck. I've used the Content-MD5 as the IV, and also let my computer use random IVs and have it run for days. No luck.

Oh, and that's CBC and EBC respectively. *sigh*

uhm i think that comparing similarity is not a good aproach. if is succesfully decryped would match 100% if not, no matter how many bytes are equal.

I came here because I've just fetched using itunes almost all artwork for my mp3 collection and now i want to save them as "folder.jpg" for each album folder. I've succesfully coded an app to strip the .itc header and output the raw jpg but do you know how to guess for what album (and its location) is that artwork?

knoopx-
Nope, I've been manually dragging my JPGs into the proper places. Sorry.

knoopx:

You're right, similarity is a bad approach. I didn't rely much on it either, it was just for good (bad) measure.

Is there any way to use this UNIX command to convert files within Mac OS X? Thanks. :)

>I came here because I've just fetched using itunes almost all artwork for my mp3 collection and now i want to save them as "folder.jpg" for each album folder. I've succesfully coded an app to strip the .itc header and output the raw jpg but do you know how to guess for what album (and its location) is that artwork?

knoopx,
The .itc file is named with the "Persistent ID" of the track. You can get track information by opening the iTunes Music Library.xml file and searching for the item that matches.

I don't know how well you know xml, but the query should be reasonably simple.