Rockbox Technical Forums
Rockbox Development => New Ports => Topic started by: GodEater on January 10, 2008, 01:22:09 PM
-
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.
-
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.
-
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.
-
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.)
-
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:
(http://img176.imageshack.us/img176/3127/ipodparttablesq2.jpg)
-
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.
-
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)
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.
-
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.
-
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?)
-
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...
-
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:
$ 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)
-
x86 boot sector is what the file command calls a partition table.
-
You could of course use this (http://citp.princeton.edu/memory/) 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...
-
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 :)
-
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
-
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.
Hi, I have a nano 3g (8gb). Do you have a dd command or something in mind to do this?
I get similar fdisk -l info:
----------
root@mauke:/# fdisk -l /dev/sda
Note: sector size is 4096 (not 512)
Disk /dev/sda: 7952 MB, 7952142336 bytes
245 heads, 62 sectors/track, 127 cylinders
Units = cylinders of 15190 * 4096 = 62218240 bytes
Disk /dev/sda doesn't contain a valid partition table
root@manuke:/#
----------
-
Mount your iPod, delete everything on it, then
cat /dev/zero > /mnt/sda2/newblankfile
Wait until it errors out with "cat: write error: No space left on device", and then
dd if=/dev/sda | gzip > /someplace/with/free/space/nano3g.img.gz
@hdragun: Mounting an image with multiple partitions:
http://www.jefferyfernandez.id.au/2007/06/14/mounting-partitions-that-are-within-a-disk-image/
-
I'd just delete the music, but leave the system files and folders alone.
-
Hi,
Previously my iPod Nano (3g, 8GB) had been configured on a Mac and had a bit of music on it.
I connected it to an XP machine and "restored" it.
Then connected it to my Ubuntu box and here's the new info, freshly restored with nothing added.
It times out @ 55% full on the partition(/dev/sda1) and kills the dd. Â (See below.) Â My file size limites (according to ulimit -a) are "unlimited". Hmm.
Will you still find dd of /dev/sda useful?
root@manuke:/# fdisk -l /dev/sda
Note: sector size is 4096 (not 512)
Disk /dev/sda: 7952 MB, 7952142336 bytes
217 heads, 32 sectors/track, 279 cylinders
Units = cylinders of 6944 * 4096 = 28442624 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 280 7765508 b W95 FaT32
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(0, 1, 1) logical=(0, 1, 32)
Partition 1 has different physical/logical endings:
phys=(120, 216, 32) logical=(279, 126, 32)
root@manuke:/#mount -rw /dev/sda1 /mnt
root@manuke:/#df -k
Filesystem 1K-blocks Used Available Use% Mounted on
...
/dev/sda1 7750228 20616 7729612 1% /mnt
root@manuke:/#ls -la /mnt
drwxr-xr-x 7 root root 4096 2008-03-28 14:16 .
drwxr-xr-x 22 root root 1024 2008-03-28 14:13 ..
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Calendars
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Contacts
drwxr-xr-x 6 root root 4096 2000-07-31 08:57 iPod_Control
-rwxr-xr-x     1 root root 0     2000-07-31 08:57 .metadata_never_index
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Notes
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Recordings
root@manuke:/#touch /mnt/newblankfile
root@manuke:/#ls -la /mnt
drwxr-xr-x 7 root root 4096 2008-03-28 14:16 .
drwxr-xr-x 22 root root 1024 2008-03-28 14:13 ..
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Calendars
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Contacts
drwxr-xr-x 6 root root 4096 2000-07-31 08:57 iPod_Control
-rwxr-xr-x     1 root root 0     2000-07-31 08:57.metadata_never_index
-rwxr-xr-x     1 root root 0     2008-03-28 14:26 newblankfile
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Notes
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Recordings
root@manuke:/#cat /dev/zero > /mnt/newblankfile
File size limit exceeded
root@manuke:/#ls -la /mnt
root@manuke:/#ls -la /mnt
drwxr-xr-x 7 root root 4096 2008-03-28 14:16 .
drwxr-xr-x 22 root root 1024 2008-03-28 14:13 ..
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Calendars
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Contacts
drwxr-xr-x 6 root root 4096 2000-07-31 08:57 iPod_Control
-rwxr-xr-x     1 root root 0     2000-07-31 08:57.metadata_never_index
-rwxr-xr-x     1 root root 4294967295  2008-03-28  15:43 newblankfile
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Notes
drwxr-xr-x 2 root root 4096 2000-07-31 08:57 Recordings
root@manuke:/#df -k
Filesystem 1K-blocks Used Available Use% Mounted on
...
/dev/sda1 7750228 4214920 3535308 55% /mnt
-
File size limit exceeded
D'oh, of course... FAT - the largest possible filesize is 4GB or so. Just do the "cat" command a few times with different filenames so you get a few 4GB empty files.
-
Hi All,
I restored my nano-3g again on my macbook, and refilled it with a dd from /dev/zero, then took a dd of the entire device. Â The final .gz file is 7.5 MB.
Please have a look at what I did below, and tell me if that is correct, and let me know should you be interested in the details of the file.
(some unrelated info removed to shorten the post)
Riot's Macbook:~ RiotousMonk$ df -k
Filesystem        1K-blocks   Used   Avail Capacity  Mounted on
/dev/disk0s2 Â Â Â Â Â Â 116884912 77445376 39183536 Â Â 66% Â Â /
/dev/disk1s2 Â Â Â Â Â Â Â 7765472 Â Â 41264 Â 7724208 Â Â 1% Â Â /Volumes/Riot's iPod
Riot's Macbook:~ RiotousMonk$ $ df -h
Filesystem         Size  Used  Avail Capacity  Mounted on
/dev/disk0s2 Â Â Â Â Â Â Â 111G Â Â 74G Â Â 37G Â Â 66% Â Â /
/dev/disk1s2 Â Â Â Â Â Â Â 7.4G Â Â 40M Â 7.4G Â Â 1% Â Â /Volumes/Riot's iPod
Riot's Macbook:~ RiotousMonk$ $ disktool -l
***Disk Appeared ('disk1',Mountpoint = '', fsType = '', volName = '')
***Disk Appeared ('disk1s1',Mountpoint = '', fsType = '', volName = '')
***Disk Appeared ('disk1s2',Mountpoint = '/Volumes/Riot's iPod', fsType = 'hfs', volName = 'Riot's iPod')
***Disk Appeared ('disk0',Mountpoint = '', fsType = '', volName = '')
***Disk Appeared ('disk0s1',Mountpoint = '', fsType = '', volName = '')
***Disk Appeared ('disk0s2',Mountpoint = '/', fsType = 'hfs', volName = 'Macintosh HD')
Riot's Macbook:~ RiotousMonk$ $ pdisk /dev/disk1 -dump
Partition map (with 4096 byte blocks) on '/dev/disk1'
#:         type name      length  base   ( size )
1: Apple_partition_map partition map    62 @ 1   Â
2:      Apple_HFS disk      1941368 @ 64    (  7.4G)
Device block size=4096, Number of Blocks=1941441 (7.4G)
DeviceType=0x0, DeviceId=0x0
Riot's Macbook:~ RiotousMonk$ $ ls -la /Volumes/Riot\'s\ iPod/
total 96
drwxr-xr-x  11 RiotousMonk  RiotousMonk   476 Mar 28 16:47 .
drwxrwxrwt   8 root    admin    272 Mar 28 16:56 ..
-rw-r--r--   1 RiotousMonk  RiotousMonk  6148 Mar 28 16:47 .DS_Store
d-wx-wx-wt   3 RiotousMonk  RiotousMonk   102 Mar 28 16:56 .Trashes
-rw-r--r--   1 RiotousMonk  RiotousMonk  29833 Mar 28 16:46 .VolumeIcon.icns
-rwxr-xr-x   1 RiotousMonk  RiotousMonk    0 Jul 31  2000 .metadata_never_index
drwxr-xr-x   2 RiotousMonk  RiotousMonk   68 Jul 31  2000 Calendars
drwxr-xr-x   2 RiotousMonk  RiotousMonk   68 Jul 31  2000 Contacts
drwxr-xr-x   3 RiotousMonk  RiotousMonk   102 Jul 31  2000 Notes
drwxr-xr-x   2 RiotousMonk  RiotousMonk   68 Jul 31  2000 Recordings
drwxr-xr-x   7 RiotousMonk  RiotousMonk   238 Mar 28 16:46 iPod_Control
Riot's Macbook:~ RiotousMonk$ touch /Volumes/Riot\'s\ iPod/newblankfile
Riot's Macbook:~ RiotousMonk$ ls -la /Volumes/Riot\'s\ iPod/
total 96
drwxr-xr-x  12 RiotousMonk  RiotousMonk   510 Mar 28 17:06 .
drwxrwxrwt   8 root    admin    272 Mar 28 16:56 ..
-rw-r--r--   1 RiotousMonk  RiotousMonk  6148 Mar 28 16:47 .DS_Store
d-wx-wx-wt   3 RiotousMonk  RiotousMonk   102 Mar 28 16:56 .Trashes
-rw-r--r--   1 RiotousMonk  RiotousMonk  29833 Mar 28 16:46 .VolumeIcon.icns
-rwxr-xr-x   1 RiotousMonk  RiotousMonk    0 Jul 31  2000 .metadata_never_index
drwxr-xr-x   2 RiotousMonk  RiotousMonk   68 Jul 31  2000 Calendars
drwxr-xr-x   2 RiotousMonk  RiotousMonk   68 Jul 31  2000 Contacts
drwxr-xr-x   3 RiotousMonk  RiotousMonk   102 Jul 31  2000 Notes
drwxr-xr-x   2 RiotousMonk  RiotousMonk   68 Jul 31  2000 Recordings
drwxr-xr-x   7 RiotousMonk  RiotousMonk   238 Mar 28 16:46 iPod_Control
-rw-r--r--   1 RiotousMonk  RiotousMonk    0 Mar 28 17:06 newblankfile
Riot's Macbook:~ RiotousMonk$ cat /dev/zero > /Volumes/Riot\'s\ iPod/newblankfile
cat: stdout: No space left on device
Riot's Macbook:~ RiotousMonk$ df -h
Filesystem         Size  Used  Avail Capacity  Mounted on
/dev/disk0s2 Â Â Â Â Â Â Â 111G Â Â 74G Â Â 37G Â Â 66% Â Â /
/dev/disk1s2 Â Â Â Â Â Â Â 7.4G Â 7.4G Â Â 0B Â 100% Â Â /Volumes/Riot's iPod
Riot's Macbook:~ RiotousMonk$ ls -la /Volumes/Riot\'s\ iPod/
total 15448512
drwxr-xr-x  12 RiotousMonk  RiotousMonk     510 Mar 28 17:06 .
drwxrwxrwt   8 root    admin       272 Mar 28 16:56 ..
-rw-r--r--   1 RiotousMonk  RiotousMonk     6148 Mar 28 16:47 .DS_Store
d-wx-wx-wt   3 RiotousMonk  RiotousMonk     102 Mar 28 16:56 .Trashes
-rw-r--r--   1 RiotousMonk  RiotousMonk    29833 Mar 28 16:46 .VolumeIcon.icns
-rwxr-xr-x   1 RiotousMonk  RiotousMonk      0 Jul 31  2000 .metadata_never_index
drwxr-xr-x   2 RiotousMonk  RiotousMonk      68 Jul 31  2000 Calendars
drwxr-xr-x   2 RiotousMonk  RiotousMonk      68 Jul 31  2000 Contacts
drwxr-xr-x   3 RiotousMonk  RiotousMonk     102 Jul 31  2000 Notes
drwxr-xr-x   2 RiotousMonk  RiotousMonk      68 Jul 31  2000 Recordings
drwxr-xr-x   7 RiotousMonk  RiotousMonk     238 Mar 28 16:46 iPod_Control
-rw-r--r--   1 RiotousMonk  RiotousMonk  7909588992 Mar 28 17:19 newblankfile
Riot's Macbook:~ RiotousMonk$ dd if=/dev/disk1 | gzip > /Users/RiotousMonk/Desktop/nano3g.img.gz
15531528+0 records in
15531528+0 records out
7952142336 bytes transferred in 6662.713453 secs (1193529 bytes/sec)
Riot's Macbook:~ RiotousMonk$
-
That looks fine. Just upload it somewhere. Don't attach it here on the forum, as space is very limited.
I'm not exactly sure what you mean by Ubuntu not "recognising" your iPod when formatted on OS X, but if you mean you can't mount it, your kernel probably just doesn't have HFS+ support compiled in.
-
Here is a dump from my Nano 3G 4GB:
http://www.iwdstudio.com/sansa_dev/nano3g.img.gz
-
Here is the image dump from my 8GB Â nano-3g.
http://tokyo.moro.us/nano3g_8gb.img.gz
and some pics of the innards from some kind soul.
http://www.ifixit.com/Guide/iPod/iPod-Nano-3rd-Generation
same photos + ipod classic:
http://www.appleinsider.com/articles/07/09/10/a_peek_inside_apples_new_nano_and_classic_ipods_photos.html
cost analysis of the nano-3g, with vague references to makers and spec on some of the chips - maybe useful in trying to figure out which chip is what in the above linked photos (apple branded rather than off the shelf?) : http://www.isuppli.com/news/default.asp?id=8490&m=9&y=2007
-
As an owner of an iPod Classic 80GB I could of course provide a HDD dump, but that won't help much as the firmware is clearly stored on a separate flash chip. Even if you wipe the entire hard drive, it still boots fine although it doesn't save the settings until you give it a nicely formatted FAT (or HFS) partition again, as the iTunes iPod repair program seems to do additionally to reflashing the firmware.
-
I did a "fdisk -l" on my Classic, and it came up with this:
Note: sector size is 4096 (not 512)
Disk /dev/sda: 159.8 GB, 159840301056 bytes
26 heads, 50 sectors/track, 30018 cylinders
Units = cylinders of 1300 * 4096 = 5324800 bytes
Disk identifier: 0x20202020
Device Boot Start End Blocks Id System
/dev/sda1 1 30019 156093788 b W95 FAT32
Could somebody please tell me what this actually means?
-
I did a "fdisk -l" on my Classic, and it came up with this:
Note: sector size is 4096 (not 512)
Disk /dev/sda: 159.8 GB, 159840301056 bytes
26 heads, 50 sectors/track, 30018 cylinders
Units = cylinders of 1300 * 4096 = 5324800 bytes
Disk identifier: 0x20202020
Device Boot Start End Blocks Id System
/dev/sda1 1 30019 156093788 b W95 FAT32
Could somebody please tell me what this actually means?
It means you've mounted it's hard disk in UMS mode.
-
So, I realize the firmware encryption is a huge problem.
Is the firmware for these versions stored in a separate (perhaps hidden?) partition like the earlier iPods and the Sansas?
-
My guess would be that from my "fdisk -l"...scan(?) there's only one partition on my Classic.
-
My guess would be that from my "fdisk -l"...scan(?) there's only one partition on my Classic.
No, it means that only one partition is exposed. If you could open your iPod and connect the disk to a native controller you might get a different result (or you might not).
pondlife
-
No, it means that only one partition is exposed. If you could open your iPod and connect the disk to a native controller you might get a different result (or you might not).
And unless someone does that, we don't know the answer to the question :
Is the firmware for these versions stored in a separate (perhaps hidden?) partition like the earlier iPods and the Sansas?
-
My guess would be that from my "fdisk -l"...scan(?) there's only one partition on my Classic.
No, it means that only one partition is exposed. If you could open your iPod and connect the disk to a native controller you might get a different result (or you might not).
pondlife
The partition exposed is 159.8gb, which leaves ~204mb left for Apple's Firmware. I'm guessing that would be plenty of space, considering that Rockbox (for 5g/5.5g) is under 10mb.
What do you mean by "connect to a native controller"? Actually connect the hard drive to a PC?
-
The partition exposed is 159.8gb, which leaves ~204mb left for Apple's Firmware. I'm guessing that would be plenty of space, considering that Rockbox (for 5g/5.5g) is under 10mb.
I'm not quite sure if this difference in size is caused by the 1000\1024^3 Bytes calculating problem? Or would the values differ even more in this case?
-
The partition exposed is 159.8gb, which leaves ~204mb left for Apple's Firmware. I'm guessing that would be plenty of space, considering that Rockbox (for 5g/5.5g) is under 10mb.
I'm not quite sure if this difference in size is caused by the 1000\1024^3 Bytes calculating problem? Or would the values differ even more in this case?
how would that make any difference?
-
Instead of speculating, someone should check what the actual drive capacity is in bytes.
-
Units = cylinders of 1300 * 4096 = 5324800 bytes
Done.
-
how would that make any difference?
Manufacturer says his HDD has 160GB; but calculated with 1000^3 Bytes = 1GB.
Program on computer calculates correctly with 1024^3 Bytes = 1GB
-> 160 GB [Manufacturer] ~ 149GB [Computer].
So forget about it. The difference is far beyond 204MB ::)
-
Why would Apple make it larger than 204MB? That's plenty of space for their firmware, what else could be stored here?
-
Suspend image. At least that's one theory. Firstly, their firmware is quite large on the players we're familiar with, but the fact that the 64MB RAM players have a larger firmware partition than the 32MB RAM ones suggests that it's probably there so they can hibernate the RAM of the player to disk when it goes into deep sleep or such. It's also probably a good deal of reserved space for future ideas (for example, when the iPod+Nike came out, that installed a chunk of data to the hidden partition as a resource image for the Nike hardware).
-
Given that the iPod Touch is functionally almost identical to the iPhone (which I own and therefore feel somewhat qualified to speak about), I can say that on the Touch at least the "firmware" is actually a cut down version of OSX, which runs at a great deal more disk space than the firmwares from previous iPods.
I've read in a few places that the Classic is also running something similar to this cut down version of OSX (though unfortnately I can't cite the places I saw it as I forget, and it was pretty vague there anyway).
This would likely mean that the firmware partition will be significantly larger than in previous iterations of the iPod.
Certainly on the iPhone the "System" partition where most of the OS lives is around 300MB.
-
Hi all,
I would like to help in unravelling the mysteries of the 3rd gen ipod, to make it possible to run rockbox on it. I'm not good with soldering irons, but could do some c programming :)
I investigated a bit on what is on my ipod (after I filled it with music using libgpod and gtkpod on debian linux).
Fdisk partition info has been posted before.
I find the different physical/logical partition beginnings/endings weird, but this may be caused by the device being solid state storage, and not a physical spinning disk with heads and cylinders and sectors.
I did a "find ." on the mounted partition, and found the same folders that were posted before. The "Calendars", "Contacts", and "Recordings" folders are empty, "Photos" just contains an empty subdirectory "Thumbs", and "Notes" contains a 14 byte file Instructions containing the string "<INSTRUCTIONS>" without line terminator.
The "iPod_Control" folder contains the data:
droef:/mnt/ipod# ls -l iPod_Control/
total 32
drwxr-xr-x 2 mirjam mirjam 4096 2008-03-12 22:24 Artwork
drwxr-xr-x 2 mirjam mirjam 4096 2008-05-17 14:35 Device
drwxr-xr-x 3 mirjam mirjam 4096 2007-12-01 22:01 gamedata_RW
drwxr-xr-x 4 mirjam mirjam 4096 2007-11-29 21:34 Games_RO
drwxr-xr-x 3 mirjam mirjam 4096 2007-12-01 22:01 gamestats_WO
drwxr-xr-x 2 mirjam mirjam 4096 2008-05-10 15:49 iTunes
drwxr-xr-x 16 mirjam mirjam 4096 2007-11-29 21:33 Music
drwxr-xr-x 2 mirjam mirjam 4096 2000-02-22 01:30 Tones
iPod_Control/Music contains 13 subdirs, which contain .mp3 files.
iPod_Control/Device seems interesting:
droef:/mnt/ipod# ls -l iPod_Control/Device/
total 36
-rwxr-xr-x 1 mirjam mirjam 8 2008-04-28 22:42 alarms
-rwxr-xr-x 1 mirjam mirjam 32 2000-02-22 01:30 clock
-rwxr-xr-x 1 mirjam mirjam 84 2007-12-14 19:47 PlayCounts
-rwxr-xr-x 1 mirjam mirjam 2952 2000-02-22 01:30 Preferences
-rwxr-xr-x 1 mirjam mirjam 50 2008-03-30 14:37 SysInfo
-rwxr-xr-x 1 mirjam mirjam 11081 2008-05-17 14:35 SysInfoExtended
-rwxr-xr-x 1 mirjam mirjam 107 2007-12-01 22:01 Users
droef:/mnt/ipod# file iPod_Control/Device/*
iPod_Control/Device/alarms: shell archive or script for antique kernel text
iPod_Control/Device/clock: data
iPod_Control/Device/PlayCounts: data
iPod_Control/Device/Preferences: data
iPod_Control/Device/SysInfo: ASCII text
iPod_Control/Device/SysInfoExtended: XML
iPod_Control/Device/Users: data
droef:/mnt/ipod# cat iPod_Control/Device/SysInfo
ModelNumStr: xA980
FirewireGuid: 000A27001A80AAE1
I put up the XML data file for download at:
http://koos.idefix.net/~mirjam/SysInfoExtended
Hope this helps....
-
Well from what I've read, no one actually knows what's under the hood of the encrypted OF, so until someone somewhere is able to extract the internal ROM content, or otherwise crack the encryption, no one will be able to do anything...
Nonetheless, you can count me in too for I've a 3rd gen. nano. I'm good at software/hardware understanding/disassembling, embedded systems and software development... For those interested, here is a link (http://home.gna.org/linux4nano) to the linux4nano group who are putting efforts into breaking that encryption for another project (ipodlinux in fact). If you can contribute, please talk to them. If you can't, please don't bother them ;D
-
Well have *you* contacted them and got a dump of the ROM they extracted ?
-
Hi again,
yes I have contacted them but what they have in the moment is a dump of the external flash, which is actually encrypted using the algorithm (almost certainly) present in the internal SoC ROM. I've got it here (the flash, not the internal ROM) and I can ask them if they mind me sharing it. But obviously, one can't do much with the encrypted firmware until someone somewhere finds the encryption key to be able to decrypt the firmware.
So if anyone here is an electronic expert that could help extract internal ROM content from a SoC, please, oh please get in touch with them :)
-
Well on the linux4nano site linuxstb is referring to, there are some documentation, mail archives and stuff. I've gone through most of it and apparently, RC4 was their first hypothesis but from what I understand, it was discarded after some encryption analysis... Have at look at this report (http://home.gna.org/linux4nano/download/crypto_synth-1.0.pdf) for more details.
It seems that until someone somewhere with enough knowledge (and talent) is able to tap himself on the processor chip and get the content of its internal ROM (JTAG, hardware programming protocol or something else), we are stuck...
Owh and by the way, why not stick with this thread (http://forums.rockbox.org/index.php?topic=14871.0) instead of starting a new one every now and then ;)
-
It's not much use at this point of development, but if things ever get going, I've made a scan of the iPod nano 3g 4gb. Yes, I know there's one on ifixit (http://www.ifixit.com/Parts/stream/3/large/13-1.jpg), but parts seem to be different on this one!
Product details: 4g, Model No. A1236, EMC No. 2174.
http://www.nastyprisms.com/rockbox/nano3g/logicboard_edit.jpg
http://www.nastyprisms.com/rockbox/nano3g/toshiba.jpg
-
As I am a member of the [linux4nano-dev] Mailing-List, I can say that they also plan a brute force attack on the ROM.
The 1G FLSHLOGO section only contained 0xFF's and has 9700 bytes.
The 2G FLSHLOGO has 9728 bytes (I stripped the section header).
This could be a good starting point. There's probably a key hidden in
those 28 bytes.
-
I got my hands on a 3G Nano last week, and got an lsusb -v output from it :
Bus 008 Device 015: ID 05ac:1262 Apple, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x05ac Apple, Inc.
idProduct 0x1262
bcdDevice 0.01
iManufacturer 1 Apple Inc.
iProduct 2 iPod
iSerial 3 000A27001AD79186
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 149
bNumInterfaces 3
bConfigurationValue 2
iConfiguration 4 iPod USB Interface
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 30
bInCollection 1
baInterfaceNr( 0) 1
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Microphone
bAssocTerminal 2
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 1
bSourceID 1
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 35
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 9 Discrete
tSamFreq[ 0] 8000
tSamFreq[ 1] 11025
tSamFreq[ 2] 12000
tSamFreq[ 3] 16000
tSamFreq[ 4] 22050
tSamFreq[ 5] 24000
tSamFreq[ 6] 32000
tSamFreq[ 7] 44100
tSamFreq[ 8] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x00c0 1x 192 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.01
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 208
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 2
Device Status: 0x0000
(Bus Powered)
Haven't done anything further with it yet.
-
The iPod Classic 1.0.1 firmware uses a "8702" file format which is similar to the "8900" file format used by the iPhone (http://wikee.iphwn.org/s5l8900:8900_format). There's a similar DER-encoded certificate chain, and the encryption byte is 03, which probably also implies AES-128-CBC encryption. There are two "8702" files after the FAT16 image.
I wonder if some methods used on the iPhone and iPod Touch apply.
-
I don't know if mods will be annoyed that I'm posting in a really old thread, but with the breakthrough in the Nanos I thought that this thread should be revived for the sake of Classics.
I'm talking about this:
http://home.gna.org/linux4nano/tof_victory_message.txt
From over here:
http://home.gna.org/linux4nano/
Maybe someone could contact one of the team members and ask for details about the exploits.
My Classic is currently out of service (dead hard disk and no replacements in my country) so I'll try this as soon as it's fixed (if nobody did by then).
-
The Rockbox developers who are interested in this are already well aware of this information. We've been in and out of the linux4nano guys' irc channel for the last 5 days or so. If something comes out of it (and it's still by no means certain that it will - no-one has managed to run more than a few bytes of code on these things yet) we'll be aware of it before you I imagine ;)
-
There seems to be light at the end of the tunnel regarding Rockbox on the Classic - the same "Notes" exploit that has allowed us to start running code on the 2nd Gen Nano has been confirmed to also exist on the Classic. i.e. the first third-party code has now been confirmed to run.
By attaching a serial cable to the dock connector, the boot ROM has been partially dumped (timing issues seem to exist which are preventing a full dump so far). Once this succeeds, we should have enough information to decrypt and dump the contents of the NOR flash, which in turn gives us access to the diagnostics mode code which can be used to reverse-engineer drivers.
So at least it looks like a Rockbox port can be started soon...
The iPod Classic and Nano 3G also seem very similar hardware-wise (sharing the same S5L8702 CPU), so hopefully the notes exploit can be made to work on the Nano 3G as well.
-
I've noticed there are some really cheap ($70) 6g oem boards on eBay, and the linux4nano guys do not seem to have one to brick, from what I see.
Actually, we don't even need one to brick (we've already passed that stage without bricking one :-) ), we just need testers for our code, if possible with some development skills in order to track down issues. So if any donation, we would need just a working 6G for one of the devs interested in it.
-
Actually, we don't even need one to brick (we've already passed that stage without bricking one :-) ), we just need testers for our code, if possible with some development skills in order to track down issues. So if any donation, we would need just a working 6G for one of the devs interested in it.
All of this is completely above my head. I have an 80gb Classic I can donate to a developer (with avatar). If interested, please contact me through a pm.
Edit: I suppose limiting this potential donation to just a dev w/ avatar limits the possibilities... if I could simply find someone who I can verify contributes to the Rockbox project via posts/postcount or possibly a recomendation from a notated dev, that would suffice.
This is my second day to be aware of Rockbox, but a certain amount of trust can be gained by the fact that this is a prolific open source project. I admire the effort by everyone involved.
-
IBugger is running on the iPod Nano 4G. Along with primitive drivers for: USB, I2C, Backlight, and LCD. So development can start on the Nano 4G if anybody is interested.
Source: http://l4n.clustur.com/index.php/Main_Page
-
Can someone post the latest news on ipod classic support?
What can I do to contribute? I don't know any of the low-level programming needed to rip firmware, but I can follow instructions to test things out.
Are the ipod classic 80/160, 120, and 160 all three entirely different generations within themselves, or will one rockbox edition work across all three? I'm asking because would I need to donate just an 80gig, or an 80 and a 120? As far as I know, the 160 (most recent) just takes advantage of increased platter density, unless I'm wrong. I read that you're past the point of potentially bricking an ipod, but would a donation be of any use, or are y'all not equipped to rip and decrypt the firmware?
Would cyanogen (android custom rom creator...but I can't recall if he was involved in getting root from Android) be of any assistance in this, since it's linux-based? Would shipping the ipod to a professional data recovery center, such as http://www.eprovided.com/ be useful? They charge an arm and a leg for tearing apart a hard drive for low-level recovery (or soldering a chip to a diagnostic board for the raw data), but is there any reason to do such a thing at this point, or is just cracking the encryption where the project is stuck?
Whatever the case, please post the latest news and what you need from us, the appreciative users =]
-
The lack of posts is the latest news. There's information on the wiki, but if it doesn't change that generally means the situation hasn't changed.
As well, Rockbox is not Linux based.
-
Can someone post the latest news on ipod classic support?
AFAIK the wiki is up to date. Take a look at it.
What can I do to contribute? I don't know any of the low-level programming needed to rip firmware, but I can follow instructions to test things out.
Other then programming theres not much else to do.
I read that you're past the point of potentially bricking an ipod, but would a donation be of any use, or are y'all not equipped to rip and decrypt the firmware?
The main issue is that no one is working on a port to the classic. Donating might help if you got someone interested in working on it.
-
Thanks. Donated from jon8rfc@yahoo.com!
What about an ipod classic donation?
-
A useful link (http://www.freemyipod.org/wiki/Status)
-
There's been a furious amount of activity on the iPod Classic in the past couple of months, and thanks to the valiant efforts of the freemyipod guys and our own lovely team, we have a port of Rockbox running on the iPod Classic!
The news is here: http://daniel.haxx.se/blog/2011/01/04/rockbox-seen-on-ipod-classic/
Please note, however, that a lot of things aren't implemented yet, and the install method is still rather complicated for everyday users. While the port has plugins and audio playback, there's no YUV blitting for the LCD, so Mpegplayer crashes. So please have patience and look out for announcements.
(ninja edit!)
-
Anybody meet the HDD problem? After a long term use,my classic can't get connected to the computer,the only way to solve is reformat the device...maybe there is something wrong with the HDD driver,OF works fine.
I'm using a SSD instead,and in very early rockbox build it works great,but nowadays it boot very slowly,it seems that the disk spinup time is very high....
-
I have an iPod Classic that was previously running a build from April. I just upgraded to 19f4e39-141118, and the hold switch doesn't seem to be working the same way it used to.
It still locks out the button, and still triggers a power-on, so I'm not too concerned, but it no longer turns the screen back on, or changes the hold switch icon on my WPS. Is there something I can do to restore the previous behaviour?