Uninstalling U3

Not long ago I bought a small, cheap 256 MB Memorex USB flash drive to get files from here to there — the kind of files that are too small for a CD-R but also too big for a quick internet transfer. Unfortunately, it came preloaded with U3, a library that allows the USB drive to run specially designed programs without leaving data behind. Programs like Portable Firefox and Thunderbird are available, letting you bring all your day-to-day software wherever you go.

I, however, disliked the idea of bringing sensitive data such as email settings out into the open, in the event my drive got stolen or lost. Also, U3 launches each time you plug the drive into a Windows machine, and the last thing I need is more little alerts popping up when using Windows. It appears that the U3 company recently gave in to public demand and released a U3 uninstaller to completely remove the software (which has the side effect of formatting the entire drive). It worked like a charm. Now I’ve got my 6 MB partition back and I couldn’t miss U3 any less.

Update: Some more technical information on the U3 drives.

Uninstalling U3

XBMC Changes

When updating my copy of Xbox Media Center earlier today, I noticed that the XboxMediaCenter.xml file was missing. Looking into the matter further, I found that some significant changes had been made to the development of XBMC earlier this month.

The original XML configuration file has been removed, and most of the important options have been added to the program settings, allowing new shares to be connected directly inside Xbox Media Center. Bookmarks can now be added by starting up XBMC, pressing the white button on the controller, and choosing “Add Source.” For those who still prefer to open a file and type in the paths manually, edit the UserData/sources.xml just as you did before.

XBMC Changes

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 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 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:
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.

iTunes Art

MatteBook

I love Apple’s new MacBooks and would be selling my PowerBook right now in order to help cover the cost of a new portable, but I simply can’t get over the glossy screens Apple chose to install. The MacBook Pro line at least has the built-to-order option of a matte screen, but the “consumer” level MacBook has none. As the glossy LCD is really the only factor stopping me from shelling out for a new notebook this very second, I think it may be time to take matters into my own hacker hands.

After doing some searching, I discovered that LG-Philips manufactures the glossy MacBook LCDs. This shouldn’t have come as a surprise, as Apple uses LG and/or LG-Philips LCD panels in most, if not all of their computer products. The particular model used in the MacBook is LP133WXT, which appears to be a very new model, as a Google search turns up only the page linked to above.

The hack comes into play here, if you search for the first part of the LCD model, LP133, on eBay. To get better results, search for LP133*, where * is a wildcard. This search turns up a number of matte 13.3″ LG-Philips LCDs for auction, mostly from PC notebooks. As the glossy and matte versions are both manufactured by the same company, are the same size, and (more than likely) take the same power, I’m betting that the LCDs would be swapped with no ill effects.

I’ll keep my eyes open for more information as I save up some extra cash for a MacBook. Maybe if I wait, Apple will add the matte option in the near future…

MatteBook