Revision as of 04:59, 21 September 2011 by XVilka (Talk | contribs)

Jump to: navigation, search

Milestone partitions

Just like a desktop computer's hard disk, the Milestone's Flash RAM is divided in partitions called CG's (Code or Content Groups). The list of CG's in a system is called CDT (Code Description Table?), and it is analogous to the partition table on a PC. The CDT itself is stored in a CG.

During the firmware flashing process, [sbf|a SBF file] that contains one or more CG's is used to update the Flash RAM contents accordingly. The CDT table (which is located within CG31) determines which NAND parts have to be checked for signatures. It is very different from the Droid's, of course (See here for a copy of the Droid's CDT table). The following tables show the CDT contents (compiled by [mbm] and vekexasia based on raw data and on OpenEZX Wiki. Reformatted by karmapolis.).

CDT Table of Milestone / Titanium


CDT Table of Droid X

Link Name Signed? CG_num CG_name signature_type start_addr((comment by [mbm]: "subtract the base address from the signature start/end to get the offsets in the mtd files")) end_addr base_addr sig_start_addr sig_end_addr
mbr Yes (OMAP security) 64 mbr 0 0x00000000 0x00020000
mbmloader.img Ramloader Yes (OMAP security) 63 mbmloader 0 0x00020000 0x00040000
mbm.img Motorola Boot Manager Yes (Motorola CSF/HAB) 30 mbm 0 0x00080000 0x00100000
mbmbackup.img MBM backup (identical to MBM) no 55 mbmbackup 0 0x00100000 0x00180000
ebr ebr No 65 ebr 0 0x00180000 0x00200000
bploader.img Baseband software boot loader No 56 bploader 0 0x00200000 0x00280000
cdt.bin MEM_MAP / CDT Table Yes 31 cdt.bin 1 0x00280000 0x00300000
pdsfs.img Yaffs2 image mounted as /etc/pds No 38 pds 0 0x00300000 0x00700000
lbl Linux Boot Loader Yes 34 lbl 1 0x00700000 0x00780000
lbl_backup.img LBL Backup Yes 57 lbl_backup 1 0x00800000 0x00900000
cid No 43 cid 0 0x02580000 0x02600000
sp No 41 sp 0 0x00900000 0x00b00000
devtree Yes 61 devtree 1 0x00b00000 0x00b80000
devtree_backup Yes 62 devtree_backup 1 0x00b80000 0x00c00000
logo.bin Boot Logo Yes 42 logo.bin 0 0x00800000 0x00900000
misc.img Yes 44 misc 0 0x02500000 0x02580000
boot.img Android boot image Yes 35 boot 1 0x01000000 0x01400000
bpsw baseband/gps sw Yes 45 bpsw 2 0x00b20000 0x00ee0000
recovery Android Recovery Yes 47 recovery 1 0x01400000 0x01900000
cdrom No((checked once right after flashing image from SBF)) 33 cdrom 5 0x01900000 0x02500000
system.img Android /system No((checked once right after flashing image from SBF)) 39 system 5 0x02a00000 0x01420000
cache Android /cache No 40 cache 0 0x0cc80000 0x13680000
userdata Android /data No 37 userdata 0 0x20000000 0x40000000
kpanic kernel panic dump No 53 kpanic 0 0x02600000 0x02a00000

> **Note(*)** > cg41(sp)isn't signed (it's seen from cdt), but it contains some interesting stuff: > 1) copy of cdt from offset 0x14. > 2) some records for every code group with 5th signature type: cdrom (started from offset 0x60000), system (0x80000), cust (0xa0000). these records contain signature, cg description from cdt and some other unknown info. every element of sp has header that contains strings (or may be values) like rrrA, ip*2, CDTV, OTVV, etc). these headers are built with mbm and the whole sp code group seems to be filled with mbm. > (according to cdt…sp has a signature, but the signature_type is 0. we don't know if mbm will check) (signature_type 0 means means that code group isn't checked by mbm, btw logo.bin also haven't signature. Every cdt description that contains starting address, contains also signature adresses. But you can check sp or logo.bin - these cgs doesn't contain any signature on the address from cdt.) > 3) type 1 signatures on CGs are checked on each boot by mbm > 4) comment by yakk regarding the meaning of type 5 signature for CGs: "ramdld stores special mark to sp code group after flashing system and mbm checks signature during first boot after flashing and reset that mark, and store some info (the signature itself in moto format, and some other)".

Extracting partitions

Method, which use right ecc correction

You need kernel module and mtd-utils. Here you can download precompiled mtd-utils and kernel module, with sources. File:Mtd-utils.tar.bz2

insmod mtd_dumpall.ko
echo "0 64" > /proc/mtd_dumpall
cat /proc/mtd_dumpall > /tmp/mtd0.bin

The result is in ASCII format where ^d[^:]+ denotes data lines and ^o[^:]+ denotes OOB data. Each data line have 0x20 ASCII hex.

To transform them to binary:

grep ^d | xxd -r -c 0x20 > out.bin

or just try use nanddump directly

janneg_'s kernel module

After booting into Linux, some of these partitions are available through MTD devices (/dev/mtd*). But other partitions are not available because the Linux kernel provided by Motorola does not map them into MTD devices. janneg_ has created a kernel module File:Mtd-hack.c that maps them all, thus enabling us to extract anything from the Milestone's Flash. You can try a precompiled binary here if you don't want to compile it yourself.


There's a tool called MotoMagX Backup that is used on MotoMagX phones to retrieve the CGs from the phone via USB, and even though Milestone is NOT a MotoMagX phone it has several similarities with that technology. This tool, MotoMagxBackup v0.01, has been tested with the Milestone by MauiMauer. The tool recognizes the Milestone connected via USB, sends the ramloader program that is run in the phone's RAM, but then the phone locks up and needs to have its battery removed (phone return ERR: 0x85 - which means unknown command).

Milestone RAMDLDs don't have READ command handler that is used by MMBackup. The MBM itself has that handler, but it doesn't work and hangs the phone if use it with correct parameters.