Dumping Flash Content
It may sound weird to some people that we are trying to perform a flash dump at this point. After all, we've already got the firmware file, right?
It's important to understand in terms of analyzing a device, that having access to runtime environment is better than having a flash dump; having a flash dump is better than having a firmware file for upgrade; and having a firmware file is way better than having nothing.
The logic behind this is that runtime environment is, well, how the device is really working. And flash dump is an image of the system's data storage with some private data (like the hard drive of your computer). Firmware file is more like an installation image of your OS. The amount of information within them is different.
Of course, the above statement is just the reflection of a general mindset. It is not an absolute truth, as each situation has its own pros and cons. [*]
The "Hard" Way
Dumping flash usually needs to be done the "hard" way, i.e. desoldering the flash chip and reading it with compatible hardware. Usually this can be done with reasonable soldering skills and simple hardware like a raspberry pi with
wide body SOP8 chip socket and flashrom.
However, the C200 makes use of a flash chip made by XMC - a not so well known flash chip manufacturer. A raspberry pi alone will have hard a time reading the flash content and reliably (compared to dumping flash chips from Winbond or GigaDevice).
This is due to the fact that the flash chip used in the C200 can't work properly under the raw currents and voltages a raspberry pi is providing. You will thus need to use some more specific hardware to communicate with the SPI flash chip.
For example, we have to use a buspirate and an external 3.3V power supply to obtain a stable and consistent flash dump.
The Safe Way
Why is this important?
We can see that the hex value is incrementing, and it ends at 0x800000. Let's remember this for a while.
Next we can check the datasheet of the XM25QH64A flash chip used in the C200.
In the "Memory Organization" section, the datasheet contains the following information:
We can see from here that this flash chip has 8,388,608 bytes of memory capacity, and guess what? 0x800000 is exactly 8,388,608 in decimal value!
So by now we know that this information in boot log is actually telling you the physical mapping of flash memory address to its partition name.
MTD and MTDblock devices
Having the partition names in mind, we can check
/proc/mtd with command
The information in
/proc/mtd is in particular telling you what
mtd virtual device each partition of the flash chip is attached to. For example, "factory_boot" is attached to
We can also take a look at
This shows the mapping of flash partitions to
mtdblock virtual devices. [*]
Now, if we can get access to these virtual devices, then we may have a chance to directly read the contents of the flash chip!
Usually in a fully initialized Linux system, we will see these virtual devices under
/dev . However, there's currently nothing under
as we bypassed the initialization process of the C200 to get a shell. Therefore we'll have to manually create them one by one.
First of all we'll have to make
[*] . Issue command
mount -t tmpfs tmpfs /dev -o mode=0755,size=512K to mount a
/dev . After that, mounting a
mtdblock device is as simple as issuing command:
mknod /dev/mtdblockX b [major] [minor]
For example, to access "factory_boot" (mtdblock0), simply issue command
mknod /dev/mtdblock0 b 31 0 . This will make a virtual device node of
/dev . You can then access this partition of flash chip with various tools and programs in the OS.
Dumping Flash Content Into a File
Our ultimate goal here is to obtain an image of the physical flash chip content.
Now we've managed to create virtual device nodes for each partitions, the only thing left is to write all the contents of each node into a file and extract it.
However, up to now, there is no network access, and transferring 8MB of data over serial console will take forever.
Fortunately, C200 cameras have an SD card slot for storing recorded videos. We can use this feature to our advantage and dump the flash to an SD card!
fat32 formatted SD card into the slot and after a
while, the console should tell you it has detected an SD card. And if you check
/proc/partitions again, you will find two new entries : mmcblk0 and mmcblk0p1. These are the virtual device for your SD card.
To read / write to your SD card, you'll have to :
1. Create a node for mmcblk0p1.
2. Mount the node to a directory in the system.
First step is simple, we've already done it before.
mknod /dev/mmcblk0p1 b 179 1 will do the trick and create a node for us.
To achieve step 2, we can just simply mount it under
is currently writable). But for the sake of cultivating good habits, let's mount it under
Issue following command in order :
mount tmpfs /tmp -t tmpfs -o size=20633600,nosuid,nodev,mode=1777 [*]
mount -t vfat /dev/mmcblk0p1 /tmp/sdcard/
And now you will be able to read / write to your SD card under
The final step is to actually write the flash contents into a file and store it in your SD card. We can achieve this with a simple command we used again and again -
cat /dev/mtdblock0 >> /tmp/sdcard/flashdump.bin and the content of
/dev/mtdblock0 will be appended into
Loop this command through /dev/mtdblock0 to /dev/mtdblock7 and you will get a dump of the entire flash chip!
umount /tmp/sdcard to safely unmount your SD card, whose content can now be transferred to a PC.