[Motorola Droid X2] mostKnownUnknown:
Yeah. Sorry if this seems a bit overwhelming. I'd figure to get the data out there first and generate some thoughts. Here's a little bit of background.

So memory in your phone is broken up into a number of partitions. This is much like how you would break up your hard drive into a number of partitions if you plan to install multiple OSes on to your computer. Instead, partitions on your phone are there to organize the data into groups for certain functionality.

If you have adb running, you can verify what partitions you have by running "adb shell cat /proc/partitions":

./adb shell cat /proc/partitions
major minor #blocks name

179 0 7804416 mmcblk0
179 1 3584 mmcblk0p1
179 2 512 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 1 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 1024 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 460800 mmcblk0p12
179 13 512 mmcblk0p13
179 14 20480 mmcblk0p14
179 15 315392 mmcblk0p15
179 16 2097152 mmcblk0p16
179 17 307200 mmcblk0p17
179 18 4574208 mmcblk0p18
179 32 7774208 mmcblk1
179 33 7773184 mmcblk1p1

Some partitions (particularly the bottom of the table) are easy to figure out since they are mounted when the operating system is run and you can open its file structure (usually with root).

./adb shell mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p12 /system ext3 rw,relatime,data=ordered 0 0
/dev/block/mmcblk0p16 /data ext3 rw,nosuid,nodev,noatime,nodiratime,data=ordered 0 0
/dev/block/mmcblk0p15 /cache ext3 rw,nosuid,nodev,noatime,nodiratime,data=ordered 0 0
/dev/block/mmcblk0p3 /pds ext3 rw,nosuid,noexec,relatime,data=ordered 0 0
/dev/block/mmcblk0p17 /preinstall ext3 ro,noatime,nodiratime,data=ordered 0 0

However, most of the partitions are not in a file format that you can mount. And it's hard to figure out that the partition is used for. Since access to the partitions are located in "/dev/block/", I've begun pulling partition images from the phone and trying some low level hex/byte analysis with our SBF's CG data.

For example, in the table from my first post, CG42 (bootloader) and CG47 (microboot) get flashed onto the same memory partition (mmcblk0p1). This has some weird complications which we need to be aware of. Both CG42 and CG47 are already signed. So when I analyzed mmcblk0p1, there are actually two sets of signature data in that partition. I'm not sure what the consequences are for messing with a double-signed partition but at least it's information that we can be aware of now.

As for the bootloader, I actually doubt we can do a direct port of the Atrix unlocker. I don't think it's a memory addressing issue (since most of the partitions have a fixed size and are filled with 0xFF blank data at the end if necessary). I think I'll be getting around the signature checking. If you open any of the bootloader unlock SBFs from Atrix's Project Pudding, all of them are signed and the signatures are not the same between the unlockers for Atrix ATT vs. Atrix Bell. Wasn't the unlock SBFs a leak from Moto's development servers? If so, since it came from Moto, I severely doubt that Moto would use the same private key between carriers, let alone between phones.

As a whole, I plan to learn as much about my phone as possible even if I need to delve down into byte data and assembly code. If we want an unlocked bootloader, I'm going to at least try to do something about it rather than sit on my butt and pray to the phone gods. If anything, we'll learn something new about this phone which is at least something since there is so little DX2 data out there.