iPod Classic and iPod Nano 3G, 4G

[GodEater]

edit:

We now have wiki pages for each device:

http://www.rockbox.org/wiki/IPodNano2GPort
http://www.rockbox.org/wiki/IpodNano3GPort
http://www.rockbox.org/wiki/IpodNano4GPort
http://www.rockbox.org/wiki/IpodClassic1G

end edit


This is a bit of an irregular post here, given that to our knowledge no such port is underway. However, given the number of queries that we get on the subject, this post is to outline some of the challenges that face a port to these three targets, which may go some way to explaining :

1) Why there isn't one yet.
2) Why no-one in the current Rockbox team really fancies a crack at them.

Also - please note this is the SECOND TIME we've put this thread up. The original one disappeared in a puff of smoke. No amount of checking through logs shows any evidence of who deleted it - so we're assuming it was an act of Jobs^H^H^H^HGod. Maybe we should take the hint

This is what Bagder has to say on the matter. What he says here applies to all three models, despite him only mentioning the Classic directly.

Nobody has done any sufficient research or investigation on the iPod Classics for anyone to tell how feasable a Rockbox port is or not. But, based on the assumption that the firmware and design choices are similar to that of the Nano 2nd generation, it offers great challenges to any hacker wanting to go down this road.

Many many people confuse this matter with the recently discussed Apple adding a new checksum to the itunes database, and then the subsequent “crack” of that system. This will only allow Linux-users to use these ipods. It certainly does not in any way make it easier to run alternative firmwares on them.

I would rather say that you should all take this as an indication that Apple really doesn’t care one bit about Linux users. In fact, they only care for those who buy their whole package and that package is Windows with itunes or MacOS with itunes. If you’re not buying that concept, you should avoid Apple. Yes I really mean that.

To get Rockbox running on these models or any of the other newer ipod versions, we need fearless and skilled people to get players, rip them apart and do some actual hard-core research on how their internals work and how the firmware is stored and how firmware upgrades are made etc. The same old new-rockbox port drill.

Update: for the less brave, there are still things that can be done as first steps. They involve doing “fdisk -l” on the targets and if there’s a firmware partition present, make a dd dump and make that available for analysis. And any related stuff a little depending on how things look.

Shortly after Bagder posted this on his blog - someone decided to do the fdisk -l trick, and we learned to our dismay that Apple have gone one step further with the Classic, which is to say they've *completely* hidden where the firmware lives - it's not just a partition marked as empty - it's not exposed at all over UMS.

We've also downloaded a firmware update for the Classic from Apple's site, and having looked at it, our other fears were confirmed - which is that the entire image is encrypted. Without knowing how to decrypt it, we can't reverse engineer it - which we'd need to do - since the hardware in the new iPods - despite looking similar on the outside - is completely different on the inside. No existing Rockbox code will work on it. Without knowing how to re-encrypt it - it's not possible to run any third party code on these iPods at all - let alone a lovely firmware like Rockbox.

[saratoga]

I think you mean the Classic and Nanos right?  The Touch can be made to run 3rd party apps, and might be able to run rockbox-as-an-app someday.

[GodEater]

Correct.

When I wrote this post originally, I was unaware of the flexibility of the iPod Touch (and therefore I guess also the iPhone) - so that is a possible way forward for those targets.

[LambdaCalculus]

Read GodEater's post above. He already mention attempting to read the firmware partition on the hard drive with no success.

Every iPod made has a firmware partition on its main storage. This has not changed from the 1st gen onward. You can verify this for yourself by doing a fdisk -l in Linux; two partitions will be shown. (NOTE: The Classic, and possibly the 3G nano, do not show a second "firmware" partition.)

[hdragun]

There may still be a firmware partition on these ipods.
i did some experimentation on mine (ipod nano 3g) and i have found 3 partitions
They are:
1: 32kb (format unknown)
2: 475,072kb (format win95 fat32)
3: 3,325,732 (format unknown)
and a MBR

interestingly the main fat32 formated partition is only 463Mb as opposed to the ~3.7Gb it identifies as.

The below image shows the partition layout:

[GodEater]

This is quite interesting, since it's completely different to the fdisk -l output we once had (can someone post it again please?) for the iPod Classic.

Dumping the contents of the two smaller partitions and making them available for download somewhere would be a useful next step to take here.

[hdragun]

Yes it is different from the fdisk -l
When i print the fdisk -l on my ipod i get only one partition although it too is interesting.
The following is what I get for fdisk -l for my ipod (/dev/sdb)

Code: [Select]

Disk /dev/sdb: 3892 MB, 3892056064 bytes
38 heads, 42 sectors/track, 595 cylinders
Units = cylinders of 1596 * 4096 = 6537216 bytes
Disk identifier: 0x20202020

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         596     3800580    b  W95 FAT32
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(0, 1, 1) logical=(0, 1, 22)
Partition 1 has different physical/logical endings:
     phys=(59, 37, 42) logical=(595, 13, 42)
Note that this is not unique to my ipod. I have an identical ipod 3g nano (4Gb) that has a similar (if not identical) fdisk -l

Interestingly when I look at it  using gparted it either tells me that it cannot read the fat32 partition or that the whole drive is empty.

As to dumping the two partitions, (1 and 2 on my previous post) i will try but don't get your hopes too high.
I have a dd dump of the entire drive (big at 3.9Gb) that i have done much of my testing on should any one have a big enough internet connection and an ftp server (note that it does have all my music on which makes me reluctant to share it) I will see if i can get an empty dump of the drive.

[saratoga]

Copy your music off, put a file on it thats all zeros that takes up your whole free disk space, and then dump it.  Should zip down to almost nothing.

[hdragun]

the img compresses (gzip) to 2.7Gb i will try to extract the two smaller partitions though (can any one tell me how to mount a raw .img in ubuntu?)

[cool_walking_]

Code: [Select]

mount -o loop /path/to/image.img /path/to/mountpoint should work if image.img is a single filesystem.  I don't know about ripping out single partitions from an image of multiple partitions though...

[hdragun]

thats the problem i'm having at the moment (multiple partitions)
Ill try extracting it with AcetoneISO2

One other thing i thought i should mention is what the linux file comand outputs when i use it on the the ipod image:

Code: [Select]

$ file ipodnano.img
ipodnano.img: x86 boot sector, extended partition table (last)\011, code offset 0x58
x86 boot sector? does the arm chip use x86 partition tables? (i suppose it is formated using x86 machines)

[GodEater]

x86 boot sector is what the file command calls a partition table.

[mcuelenaere]

You could of course use this method, but still it would require a lot of work since you'll have to desolder the memory chip and solder it to another test board...

[mcuelenaere]

Doesn't that attack rely on getting to the memory within about a minute of power off though? You'd have to be bloody fast with that soldering iron

No, if (as I've understood) you can cool the RAM a lot (maybe -5, -10 °C) and then it will take minutes or more before it releases it's information. And if you keep cooling it down I presume that won't be a big problem.

But still, it isn't the best method and it's hard to do

[Llorean]

De-solder the RAM first, clearly, then come up with a way of connecting it in a quickly removable manner. Sheesh, do I have to think of everything for you people? :-P