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, 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¹⁾. The following tables show the CDT contents²⁾.

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)”.

You need kernel module and mtd-utils. Here you can download precompiled mtd-utils and kernel module, with sources. 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

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 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.