New iPod Checksum Cracked, Linux Supported 422
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.
Re:What's the draw? (Score:1, Informative)
The iPod, if not the best sounding music player, is easily one of the best. But mostly it's the UI. It's difficult to explain why if you haven't used one for a few days, but the iPod UI, to use a cliche, just works. Other players just seem clunky and awkward by comparison.
I'm sure for many others the looks of the device play a big factor as well, but I'd still be using an iPod if it was brown.
Re:What's the draw? (Score:5, Informative)
I can take an iPod plug it into a connector in my car and completely control it from my steering wheel and see the info on the stereo's display. works perfectly. I can do the same with my Crestron Whole house audio system, my alarm clock, etc...
No other mp3 player on the market can do that. NONE. Apple opened up the connector interface and had a rs232 control interface down in that connector so other devices can control it, All other mp3 makers sit in the corner curled up screaming "MINE MINE!" or are not smart enough to think about 3rd party control like that.
That is why I use it, my daughter uses it, and I reccomend the iPod to all my clients what are doing whole house automation and audio integration. Only the ipod can do advanced integration that is seamless from the car to the home to the bedroom. (even the wife if you buy a iGazim attachment)
That is why.
Re:hopefully (Score:2, Informative)
2. Install Amarok.
Shouldn't take more than an hour.
So: No hoping needed here.
Re:What's the draw? (Score:5, Informative)
Linux support is so obvious for 99 out of 100 usb mp3 player out there it is not even worth mentioning. These mp3 players just behave like a generic USB pen disk. That you need a special (circumvention?) program for a iPod is the strange issue here.
Re:What's the draw? (Score:4, Informative)
1) Easy connection to cars. My iPod plugs into my truck's (factory) radio, and I get all the music info on there as well as easy browsing of the music. All the factory controls work, and its hidden in the glove box.
2) Lots of 3rd party speaker/dock solutions.
3) The iPod camera adapter.
The iPod camera adapter is really a very under-reported item, I think. I recently was in Alaska and didn't want to bring my laptop with me. My iPod has about 25g of free space on it, and I burned through 2/3 of that pulling pictures each day off my two digital cameras, and was able to use it to show pictures to my family (although it'd be nice if they added RAW viewing to it).
If you use it as a stand alone player in your pocket, then you're absolutely right.
Erm... Quarts-wm? (Score:4, Informative)
Re:usable? (Score:5, Informative)
Although it would be interesting to have an open-source iPod OS...
Re:What's the draw? (Score:3, Informative)
When my iPod died I got a Sansa and I love it. My 10gb Sansa (8gb + 2gb SD) cost $100 cheaper than a 4GB Nano.
Re:What's the draw? (Score:5, Informative)
That's huge. You can get iPod interfaces for most higher-end car stereos for example, not to mention the plethora of docks, cases, etc.
Re:usable? (Score:5, Informative)
Sansa what? (Score:2, Informative)
Re:What's the draw? (Score:4, Informative)
Just like Windows (Score:4, Informative)
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.
Re:usable? (Score:3, Informative)
Re:What's the draw? (Score:3, Informative)
As I understand it, it has been tested and is known not to work because the new iPods have completely different hardware than the old ones.
Re:What's the draw? (Score:1, Informative)
Note that Apple is moving away from the scrollwheel with the iPod Touch. Even they know that linear motion (slide to select, hold to scroll fast) makes more sense than circular (around and around and around...)
Re:Good because linux support is better (Score:3, Informative)
I am glad that they're still working on it, because I feel that people should be able to do this (on general principle). It's an audio player. I don't see why it is such a big deal to Apple that it only work on OS X and Windows, but that's why I'm a scientist and not a business person.
-Q
Re:Not a good article (Score:4, Informative)
iTunes copies two things onto an iPod when you sync: The files containing music, and a database of those files, so that the iPod can find the music quicker.
With the new iPods, the database has a checksum, which is based on the contents of the database and the serial number of the iPod. If that checksum is not correct, the iPod will refuse to play any music. Obviously iTunes knows how to calculate the checksum and stores it on the iPod.
Linux applications that could download music files + database onto an iPod didn't have the code to calculate the checksum, so after using a Linux application to fill a new iPod with music, the iPod wouldn't work. The hack that has been developed within 36 hours is really a hack: First you have to run a program that reads the serial number. Then you modify the hack program by typing in that serial number into the source code. Then you run whatever software you used to copy music onto the iPod. Then compile and run the "hack" program: It will read the database, calculate the checksum and add the checksum to the database, and everything works.
That is of course a horrible complicated way (for the end user) to do it. Expect all the Linux music players to be updated soon so that all this will happen automatically.
Re:What's the draw? (Score:2, Informative)
I am suspicious of the origins of this exploit (Score:1, Informative)
Either this is a particular preamble to application of SHA1 that's been applied elsewhere (anyone know?), or someone with access to iTunes source has been more helpful than Apple might have liked
void GenerateKey(unsigned char *pFWID, unsigned char *pKey){
memset(pKey,0, 64);
int i;
unsigned char y[16];
for(i=0;i> 8;
unsigned char lo = lcm & 0xFF;
y[i*4] = ((table1[hi] * 0xB5) - 3);
y[i*4 + 1] = ((table2[hi] * 0xB7) + 0x49);
y[i*4 + 2] = ((table1[lo] * 0xB5) - 3);
y[i*4 + 3] = ((table2[lo] * 0xB7) + 0x49);
}
for(i=0;i iTunesDB
void GenerateHash(unsigned char *pFWID, unsigned char *pDataBase, long lSize, unsigned char *pHash)
{
long lSizeWithoutHeaders = lSize - SIZE_OF_HEADERS;
long lSizeToUse = std::min((long)0x40000, lSizeWithoutHeaders) + SIZE_OF_HEADERS;
unsigned char key[64];
GenerateKey(pFWID, key);
int i;
for (i=0; i 64; i++)
key[i] ^= 0x36;
SHA1_CTX context;
SHA1Init(&context);
SHA1Update(&context, key, 64);
SHA1Update(&context, pDataBase, lSizeToUse);
SHA1Final(pHash, &context);
for (i=0; i 64; i++)
key[i] ^= 0x36 ^ 0x5c;
SHA1Init(&context);
SHA1Update(&context, key, 64);
SHA1Update(&context, pHash, 20);
SHA1Final(pHash, &context);
}
Re:What's the draw? (Score:2, Informative)
I didn't ignore. It wasn't the issue. My question was not how others have done it. My question to you was whether or not you were creative enough to be able to imagine a button-based solution that would be both accurate and also allow quick navigation among 800+ songs? The scroll wheel has the "advantage"* of acceleration for quick general navigation while buttons have the advantage of precise navigation for specific selection. Can you imagine some solution that would provide both advantages? I'm sure you can unless you try to be intentionally obtuse.
* I say "advantage" because I really am not convinced it is one. When I'm at the top of the list and want to get to a song in the M's, I'm screwed. If I start going moderately fast, the dang thing zips into fast mode and zips me right on past M's into the O's, P's, or even R's. So I'm forced to carefully go slow so that the thing doesn't get into fast-scroll mode--and navigating 800+ songs with the scroll wheel in slow mode is no faster than doing it with a logical button configuration would be. About the only time the scroll wheel's "fast mode" is useful to me is if I have to be in the A's or B's and want to quickly zip to the Y's. For anything else, I find myself carefully moderating my speed so I don't lose control of the scroll and zip to the end of the alphabet.
The problem is that the alphabet is too short for it to work efficiently. If the alphabet had 100 or 150 characters, the fast mode would be great. But it's only 26 characters long. By the time the thing gets into fast mode, I'm usually 1/4th of the way through the alphabet. Once in fast mode, it seems I can almost immediately skip 10+ characters by the time I can respond to the fact that I'm now in fast mode. So getting into fast mode might take about 7 characters and then I almost immediately get another 10 added to that as I react to now being in fast mode. So by the time I "slow down," I'm already at the 17th letter of the alphabet. Again, the normal solution is intentionally avoiding fast mode at which point I'd rather have a semi-intelligent button design. And, no, 800+ button presses is not the most intelligent way to do it, even if that's the way it's been done by button-based units so far.