New iPod Checksum Cracked, Linux Supported
An anonymous reader writes "After 36 hours of reverse engineering, the method for producing the checksum on new iPods has been discovered." You can also get linux support working if that's what you crave for your shiny new toy.
Is it the iTunes store? Is it the sound quality? Is it the looks of the device?
What makes Apple's offering any better than anyone else's?
I don't get it at all.
What I don't get more than that is the people who buy the iPod just to put Linux on it. That actually causes negative understanding.
Apple rarely fights hard when it comes to hacking of their products. Often any "fix" they give out is easily removed by people in such a way that it is obvious Apple wasn't even trying.
You have little far to look at the "please dont pirate this software" code in OS X intel.
"Slashdot, where telling the truth is overrated but lying is insightful."
iTunes doenst even come close to the power of gtkpod
I hate poorly named mp3s, gtkpod can get my entire ipod properly organized in a matter of minutes because of the nifty variety of views.
The phrase "more better" is acceptable English. suck it grammar Nazis
The "Linux support" mentioned in the summary is so that you can use/sync/update the iPod while running linux on your computer, not so that you can run linux on your iPod.
Although it would be interesting to have an open-source iPod OS...
My blog
36 hours... Well after years and years most still have not cracked the method for avoiding the Slashdot effect
Infiltrated dot Net
The news around the web is all about this being an evil DRM checksum, but given how quickly the generation algorithm was found, isn't it possible that it is an integrity checksum?
A user can unplug a device at any time, even in the middle of a catalog write. It only seems prudent to checksum the data to make sure you don't have a corrupt file.
I'd be interested to hear if this is a tricky crypto algorithm, or the sort of simple MD5 or CRC of data that a programmer would whip out for integrity. This is important because if the intent was integrity we can expect it to not change. The problem is solved. If it was intended to detect reverse engineered and possibly incorrect files then we can look forward to more algorithms in the future.
TFA was silent on the matter. <wtbw> can i hear a fuck yeah? didn't really tell me much.
Here is a quick howto on using wtbw's code in linux to use a new generation iPod. I was answering this question repeatedly in IRC, so i decided to post this up:
./gethash /path/to/iPod/iPod_Control/iTunes/iTunesDB
1. Download the code.
2. Plug your ipod in and make sure it is mounted and run:
sudo lsusb -v | grep -i Serial
Look for your iPod device, and the firewireID should be the 16 character long hex string shown.
It should look something like this: 00A1234567891231
3. Edit main.cpp in the hash_crack directory and read the commetns at the top. You should insert your firewire ID where the comments specify, then run make to compile the hash program.
4. Next, sync your ipod with gtkpod, rhythmbox, banshee or Amarok, or whatever ur used to just like normal. Once this is complete, you should have an ipod with songs on it, that refuses to view the songs. To make it "see" the songs, u need to run the hash program we just compiled on the iTunesDB file. This should happen something like this:
This should output the proper hash for the current state of the iTunesDB, as well as the old hash for the previous state of the iTunesDB. We just need the first value.
5. Write this new hash value to the proper location in the iTunesDB where the hash is stored at address 0×58 of the iTunesDB file. This can be done with a program such as bvi.
Note: You will need to do the process of getting the hash on your iTunesDB every time you even so much as change a song name, or upload new music or video files.
A third possibility is that it is for a faster sync with the host. If you maintain hash digests on the ipod and the host, then you can test for equality by just comparing the hashes. If they are identical, then there is no need to sync. You can skip comparing everything else bit-by-bit.