[Samsung Captivate Glide] roothorick:
My primary goal is to get to the point where we can unbrick a Glide using download mode and heimdall, no matter what the rest of the MMC looks like. A secondary goal is to learn enough about the boot process and bootloader to be able to arbitrarily change the partition table without bricking the phone.

So, this is currently our best guess as to the stock partition layout on the Glide:

DM ID | offset | DM Name | DM filename | Device file | filesystem
======|=============|=========|=================|==============|===========
2 | Special | BCT | bct.bin | |
3 | 0x200000 | PT | | |
4 | 0x280000 | EBT | bootloader.bin | |
5 | 0x480000 | EB2 | | |
6 | 0x680000 | GP1 | fusetrigger.bin | |
7 | 0xa80000 | EFS | efs.img | mmcblk0p1 | ext4
8 | 0x1680000 | APP | factoryfs.img | mmcblk0p2 | ext4
9 | 0x26e80000 | CAC | cache.img | mmcblk0p3 | ext4
10 | 0x3a680000 | IMS | | mmcblk0p4 | FAT32
11 | 0x12a700000 | MSC | | mmcblk0p5 |
12 | 0x12a900000 | UDA | data.img | mmcblk0p6 | ext4
13 | 0x1aa900000 | MDM | modem.bin | mmcblk0p7 |
14 | 0x1ab900000 | SOS | recovery.img | mmcblk0p8 |
15 | 0x1abe00000 | LNX | boot.img | mmcblk0p9 |
16 | 0x1ac600000 | OTA | | mmcblk0p10 |
17 | 0x1ace00000 | HID | hidden.img | mmcblk0p11 | ext4
18 | 0x1cce00000 | GPT | | |

I do not presently know how mmcblk0boot0 and mmcblk0boot1 factor into things. I DO know that whatever mmcblk0boot0 is, it's not accessible through mmcblk0, meaning there's something a bit weird going on in the kernel MMC driver... see the hypotheses below. The contents of mmcblk0boot1 occur THIRTEEN times in the beginning of mmcblk0, including right at 0x0. boot1 could point to any one of those, or, again, a different location entirely that's obscured by the kernel driver.

A PIT is NOT a partition table. It's a descriptor of expected partitions and their sizes. There's no offsets or anything that could describe partition locations. So when you feed Odin or Heimdall a PIT, either Odin/Heimdall or the phone itself is making up a partition table on the fly to fit the PIT. Needless to say, flashing a PIT without a bootloader and recovery is risky, even if you're flashing the same PIT twice! it appears the partition table is created in a predictable way; that's how we got the new offsets. But, I'm still way too paranoid to flash a PIT without reflashing BCT, bootloader, and either recovery or download mode in the same go.

Download mode is DEFINITELY in the MMC. Check out the strings around 0x572400. So much for the "separate ROM" theory. There's strings from the bootloader nearby as well (note to self: HOW nearby? That could be crucial...).

BCT is a special something used only by Tegra SoCs: http://http.download.nvidia.com/tegra-public-appnotes/bct-overview.html It's a safe bet there's a BCT somewhere in MMC. The BCT should, in theory, give us the precise location of the bootloader, and then some proper disassembly can happen. Assuming our offsets are correct, we now theoretically know the location of everything. Let the dumping begin! Still, picking apart a BCT sounds absolutely smashing so I'll probably do it at some point anyway.

Hypotheses that need testing:

boot0 and boot1 contain BCTs, not bootloaders. (That would explain their size.)

mmcblk0 actually begins exactly 1MB into the MMC. boot0 and boot1 are two halves of that first 1MB.

Alternately, boot0 points to the copy of the BCT that is in RAM; a leftover of the boot process. boot1 is the actual BCT from the MMC.

There are 13 (or 15) copies of the BCT at the beginning of MMC. (In the BCT partition, of course!) Is this necessary? Probably not, but I'm not gonna possibly brick a phone to gain a few KB.

Download mode is built into the bootloader, not a separate binary. Both live in EBT. The newly found offsets put the Odin strings in EB2, so BUSTED.

EBT is the bootloader and EB2 is the Odin code.