The iPod 5.5G partition table issue

[crozone]

Issue

The iPod 5.5G may fail to find valid partitions.

Description

When plugged in via USB, the iPod 5.5G presents the drive to the host as having 2048 byte logical sectors, when in reality the drive has 512 byte logical sectors.

When the iPod is formatted, the host will (usually?) create a partition table in the iPod MBR with sector offsets that assume 2048 byte sector sizes.

Then, when the bootloader is loaded by iPodLoader2 on the iPod itself, the partition table offsets will actually be 1/4 the value that they're supposed to be given 512 byte logical sectors. This invalidates the partition table, since none of the partitions will be where the MBR says they are.

This issue isn't unique to the iPod, it's is a well known "gotcha" issue with many USB->IDE/SATA drive enclosures that will often present 2K or 4K logical sectors for drives that actually use 512 logical sectors. However, the iPod 5.5G appears to be the only iPod that presents a sector size that is not 512 bytes when plugged in via USB, so it's the only model of iPod where this issue occurs.

Currently there's an undocumented hack that attempts to detect the sector size used for the MBR partition offsets:

ipodloader2/vfs.c

Lines 175 to 176 in a41ec49

	uint32 logBlkMultiplier = (iPodMBR->code[12] | iPodMBR->code[11]) / 2; // we usually find 02 00, 00 02 or 00 08 here
	if((logBlkMultiplier < 1) | (logBlkMultiplier > 4)) logBlkMultiplier = 1;

But this doesn't appear to work consistently and I cannot find any documentation as to why or how this should work. iTunes maybe creates a custom MBR and places this value here indicating the logical sector size used, but this is an unknown, and I'm not sure how the original authors derived this technique.

Potential fixes I'm brainstorming:

• Always try 1x and then 4x the partition offset, with partition peeking to verify
• Detect when we're on an iPod 5G and then try 4x and then 1x the offset, with partition peeking to verify
• Do some reverse engineering of the Apple FW to see how it handles this (because it must handle it somehow), and then do whatever it does.

[crozone]

It appears based on this 2005 discussion that the iPod's MBR has a "DBR" (DOS Boot Record, aka an MSDOS Volume Boot Record) overlaid onto it.

What I actually think this means is that Apple have embedded a DOS 2.0 BPB directly into their MBR.

This is a bit of an odd hack on Apple's part, but it explains the above code. The BPB has a 16 bit "Bytes per logical sector" value located at 0x0B (11) -> 0x0C (12). Also, apparently this value is incorrectly encoded as big-endian (always? sometimes?) - it should be little-endian as per the BPB spec, but then again, this isn't a "real" BPB, it's a weird Apple hack.

The result is that for offset 0x000B - 0x000C:

• 0x0200 = 512 byte sectors (little-endian, expected)
• 0x0002 = 512 byte sectors (big-endian, apparently incorrectly encoded)
• 0x0008 = 2048 byte sectors (big endian, apparently incorrectly encoded)

These appear to be the known cases. Unfortunately, this will only be true if the iPod was restored with iTunes, since iTunes simply writes a pre-defined firmware image to the start of the drive. Other partitioning tools don't support the BPB being in the MBR and may even misrecognise the MBR as a VBR because of its existence.

While checking this value may work okay for iTunes restored iPods, anyone who has formatted the iPod with a different partitioning tool (to remove the Apple firmware and just use Rockbox or iPod Linux) will run into issues. There must be a better way to handle this.

[EvergreenTrone]

Hey my friend did you find new solutions ? thanks