[Motorola Droid X2] mostKnownUnknown:
Hello,

Here is something potentially useful for the devs.

I took some time the past few days to experiment a bit with my phone and work on my hexdump skills. After a few days, I came up with some interesting results which I think is worth posting.

CDT Table for Droid X2

After unpacking and experimenting a bit with the two SBF files for the DX2, I noticed an interesting pattern develop in CG3 (Code Group?). CG3 describes the CDT (Code Description Table?) which defines contents of the SBF file by each CG and where in flash memory space the CG is installed (I'd publish that too but I'm not trusting what Depacker 1.3 is telling me). I used the DX1 CDT file (found in CG31) as a reference but was hard since the format changed between the DX1 and the DX2. There is a pattern and here is what I currently have.

CDT Entry #	CDT Start Byte	CDT Name	CG#	Signed	Partition	Location within Partition	Signature Location	Exists in SBF
1 0x0010 rdl.bin ?	?	? ? ? ?
2 0x0058 ptable 2	N	? 0x00000000 - 0x000057FF - Y
3 0x00A0 cdt.bin 3	Y	mmcblk0p2 0x00000000 - 0x0007FFFF 0x0007F7FC - 0x0007FC52	Y
4 0x00E8 configtable 39	Y	? 0x00000000 - 0x002FFFFF 0x002FF7FC - 0x002FFC50	Y
5 0x0130 partitiontable 40	?	? ? ? N
6 0x0178 bootloader 42	Y	mmcblk0p1 0x00000000 - 0x002FFFFF 0x002FF7FC - 0x002FFC50	Y
7 0x01c0 mbr 45	?	? ? ? N
8 0x0208 ebb 46	?	? ? ? N
9 0x0250 microboot 47	Y	mmcblk0p1 0x00300000 - 0x0037FFFF	0x0037F7FC - 0x0037FC52	Y
10 0x0298 pds 51	N	mmcblk0p3 0x00000000 - 0x001FFFFF - N
11 0x02E0 ebr 52	?	? ? ? N
12 0x0328 sp 53	?	? ? ? N
13 0x0370 cid 54	?	? ? ? N
14 0x03B8 misc 55	?	? ? ? N
15 0x0400 logo.bin 56	N	? 0x00000000 - 0x00031FFF - Y
16 0x0448 kpanic 57	?	? ? ? N
17 0x0490 recovery 58	Y	mmcblk0p10 0x00000000 - 0x007FFFFF 0x007FF7FC - 0x007FFC52	Y
18 0x04D8 boot 59	Y	mmcblk0p11 0x00000000 - 0x007FFFFF 0x007FF7FC - 0x007FFC52	Y
19 0x0520 system 60	N	mmcblk0p12 0x00000000 - 0x1C1FFFFF - Y
20 0x0568 webtop 61	?	? ? ? N
21 0x05B0 cdrom 62	N	mmcblk0p14 0x00000000 - 0x013FFFFF - Y
22 0x05F8 cache 63	N	mmcblk0p15 0x00000000 - 0x133FFFFF - N
23 0x0640 userdata 64	N	mmcblk0p16 0x00000000 - 0x7FFFFFFF - N
24 0x0688 preinstall 65	N	mmcblk0p17 0x00000000 - 0x12BFFFFF - Y
25 0x06D0 sdcard 66	N	mmcblk1 - - N

I also tried to map the CGs to partitions in /dev/block. It some cases it was really simple especially since most of the bottom of the table is already mounted (adb shell cat /proc/partitions). The others I had to pull a data copy (e.g. adb shell su -c "dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard-ext/Dev/Partitions/mmcblk0p1.img"), copied the blocks to the computer and did hex compares for the first 0x300 or so bytes. In some cases (particularly mmcblk0p1 where the bootloader and the microboot are made one block together), two CG files are flashed onto one partition back-to-back. In that case I got a bit lucky with hex searching.

Things got more interesting when comparing SBFs of the DX2's sister phones (Atrix 4G and Photon 4G). It turns out not only the table is located in the same CG (CG3) but it also follows the same byte order. Either the names and CG numbers are slightly different (Atrix) or the table is identical to the DX2 with a few extra entries (Photon). Here is what I have.

CDT Entry #	CDT Start Byte	DX2 CDT Name	DX2 CG#	Atrix CDT Name	Atrix CG#	Photon CDT Name	Photon CG#
1	0x0010	rdl.bin	?	rdl.bin	?	rdl.bin	?
2	0x0058	ptable	2	ptable	2	ptable	2
3	0x00A0	cdt.bin	3	CDT.bin	3	cdt.bin	3
4	0x00E8	configtable	39	BCT.bin	42	configtable	39
5	0x0130	partitiontable	40	PT.bin	43	partitiontable	40
6	0x0178	bootloader	42	EBT.bin	44	bootloader	42
7	0x01c0	mbr	45	MBR.bin	45	mbr	45
8	0x0208	ebb	46	EBB.bin	46	ebb	46
9	0x0250	microboot	47	NVC.bin	47	microboot	47
10	0x0298	pds	51	PDS.bin	48	pds	51
11	0x02E0	ebr	52	EBR.bin	49	ebr	52
12	0x0328	sp	53	SP.bin	50	sp	53
13	0x0370	cid	54	CID.bin	51	cid	54
14	0x03B8	misc	55	MSC.bin	52	misc	55
15	0x0400	logo.bin	56	LOG.bin	53	logo.bin	56
16	0x0448	kpanic	57	KPA.bin	54	kpanic	57
17	0x0490	recovery	58	SOS.bin	55	recovery	58
18	0x04D8	boot	59	LND.bin	56	boot	59
19	0x0520	system	60	APP.bin	57	system	60
20	0x0568	webtop	61	OSH.bin	58	webtop	61
21	0x05B0	cdrom	62	CDR.bin	59	cdrom	62
22	0x05F8	cache	63	CAC.bin	60	cache	63
23	0x0640	userdata	64	UDA.bin	61	userdata	64
24	0x0688	preinstall	65	PIA.bin	62	preinstall	65
25	0x06D0	sdcard	66	SDC.bin	63	sdcard	66
26	0x0718	EBF.bin	64	gpt	67
27	0x0760	NVF.bin	65

Verification

One thought must be going through your head is "how is this single digit poster coming up with this stuff?" One, despite not being a true dev, I like looking at low level code and have some experience with it. Second, I encourage that someone takes the time verify my findings by replicating the methods I used as well as provide any thoughts on making low level hex analysis useful.

SBFs Used:

Droid X2: VRZ_MB870_DTN-14.8_1FF_01.sbf

Atrix 4G: OLYFR_U4_1.5.2_SIGNED.sbf

Photon 4G: 1FF-sunfire-user-2.3.4-4.5.1A-1_SUN-154_MR-3-CM-release-keys-signed-Sprint-US.sbf

Procedure

- Take a SBF file

- Unpack using Moto Android Depacker 1.3

- Open CG3 in a hex editor (Hex Fiend is free for MacOSX)

- Find the location where an ASCII name starts (e.g. 0x0178 = bootloader, see tables above)

- Exactly 0x21 bytes from the start of the name is the CG value in hex

Thoughts

This analysis comes to mind two things:

1. A "Full" SBF does not mean it has all the partitions. - There is a possibility of bricking your phone beyond belief and even an SBF may not save you.

2. The DX2 seems to be really close to its siblings (Atrix 4G and especially Photon 4G). - I hate the idea gets thrown around of "Don't use Atrix mods unless you like bricks" without any real technical explanation as to why not. I'm not saying that people tomorrow should flash Atrix SBFs onto DX2 phones. I am saying that we (the DX2 community) should be aware and work closely with the other sister communities to know EXACTLY where the differences between the two phones lie. And hopefully the communities can contribute something that everyone can benefit (i.e. DX2 and Photon 4G ports of the Atrix bootloader unlock).

I'll experiment with a few other ideas I have in mind and I'll post them as I find something. Thanks for reading.

- mostKnownUnknown