Right after unboxing my S650, before even booting into normal mode I wanted to clone the preloaded firmware. This device is my first personally owned android smartphone and I wanted to make sure I have a backup of the original state before tinkering or flashing a custom ROM. The rules, as implied by the above statement, were the following:
- Flashing a custom recovery was not allowed.
- The use of third party applications other than those that come preloaded on the Mediatek device was not allowed, as installing those would have 'tainted' the original state.
- Linux only. Running any M$ Windows tool was strictly out of scope.
- More of an unfortunate circumstance than a rule, but I did not have an external microSD card handy, so I had to rely using the internal storage.
I would not position myself as an android expert in any way, as this almost my first encounter of a modern android device. Trying to make use of the skills I have, I have taken a Linux centric approach. After all, my smartphone is just an ARM based mini computer with embedded NAND flash storage running Linux...
Before my phone arrived, I read a few articles on how a full backup could be taken, how recovery works and what the boot process of an android devices is like. This post is not going to cover these basics. My first idea was to boot my phone using a custom recovery image stored on my thinkpad, without actually flashing the recovery image. This involves rebooting the device into bootloader mode and connecting it to my thinkpad via USB.
Factory mode, Bootloader, fastboot and recovery
Having initiated the first boot with the power & volume up buttons pressed, I was confronted with a Chinese menu, which turned out to be not the recovery mode, but the factory mode with options similar to the following:
工厂模式 完整测试 单项测试 测试报告 清除e MMC 版本信息 重启手机
The only familiar character sequence 'eMMC' suggested that option was responsible for wiping the whole internal storage, while the default selection would reboot the phone. A couple of days later I found a forum post that contained translation of these (or very similar) menu items.
The phone was connected to my thinkpad via a USB cable, but I did not have connectivity to the device, although I would have expected some sort of connection via the Android SDK.
After this, I rebooted into recovery mode via power, volume up & volume down buttons and realised that the stock recovery also does not provide any means to connect to the device from my thinkpad.
Finally I could reboot the device into bootloader mode (also known as fastboot mode). I had to start up the device normally, select 'Media device (MTP)' when configuring the mode of USB connection and enable USB debugging. I have found that 'Camera (PTP)' or 'Mass storage' modes do not allow the execution of Android De bug Bridge (adb) commands.
Once the device was connected, which I confirmed via adb devices, I could reboot the device into bootloader mode via adb reboot bootloader. The devices rebooted and printed that it entered fastboot mode. I confirmed that the output of adb devices does not list the device as ready for connection (as the device was in bootloader mode), and that fastboot devices outputs that the device is present and in fastboot mode.
From within bootloader mode, the command fastboot boot custom-recovery.img is should boot a custom recovery without actually flashing it. I my case, however, the device printed it downloaded the image successfully but I was left with a 'Booting ...' message and a frozen device, that did not do anything for twenty minutes, even did not respond to the power button.
I took out the battery, reinserted it an everything was back to normal. I thought the recovery image I tried to boot was not built for this phone or maybe it was corrupted, so I tried it with multiple images that were told to work with my S650. Nor the CWM, nor the TWRP image seemed to work. I had to take an alternative approach.
Backing up manually, using the shell
Eventually, I rebooted to normal mode and worked towards my goal via adb shell which gave me shell access so I could make use of my linux experience. Some commands essentially require root access - note that rooting an S650 is not covered in this post, but the ability to gain root access is assumed.
First of all, I had to discover how the eMMC storage was partitioned and which parts I need to take a backup of.
$ cat /proc/partitions
major minor #blocks name
7 0 10290 loop0
253 0 524288 zram0
179 0 7597184 mmcblk0
179 1 1 mmcblk0p1
179 2 10240 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 6144 mmcblk0p4
179 5 1048576 mmcblk0p5
179 6 131072 mmcblk0p6
179 7 3145728 mmcblk0p7
179 8 3202688 mmcblk0p8
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
$ cat /proc/dumchar_info
Part_Name Size StartAddr Type MapTo
preloader 0x0000000001400000 0x0000000000000000 2 /dev/misc-sd
mbr 0x0000000000080000 0x0000000000000000 2 /dev/block/mmcblk0
ebr1 0x0000000000080000 0x0000000000080000 2 /dev/block/mmcblk0p1
pro_info 0x0000000000300000 0x0000000000100000 2 /dev/block/mmcblk0
nvram 0x0000000000500000 0x0000000000400000 2 /dev/block/mmcblk0
protect_f 0x0000000000a00000 0x0000000000900000 2 /dev/block/mmcblk0p2
protect_s 0x0000000000a00000 0x0000000001300000 2 /dev/block/mmcblk0p3
seccfg 0x0000000000020000 0x0000000001d00000 2 /dev/block/mmcblk0
uboot 0x0000000000060000 0x0000000001d20000 2 /dev/block/mmcblk0
bootimg 0x0000000000600000 0x0000000001d80000 2 /dev/block/mmcblk0
recovery 0x0000000000c00000 0x0000000002380000 2 /dev/block/mmcblk0
sec_ro 0x0000000000600000 0x0000000002f80000 2 /dev/block/mmcblk0p4
misc 0x0000000000080000 0x0000000003580000 2 /dev/block/mmcblk0
logo 0x0000000000300000 0x0000000003600000 2 /dev/block/mmcblk0
ebr2 0x0000000000080000 0x0000000003900000 2 /dev/block/mmcblk0
expdb 0x0000000000a00000 0x0000000003980000 2 /dev/block/mmcblk0
android 0x0000000040000000 0x0000000004380000 2 /dev/block/mmcblk0p5
cache 0x0000000008000000 0x0000000044380000 2 /dev/block/mmcblk0p6
usrdata 0x00000000c0000000 0x000000004c380000 2 /dev/block/mmcblk0p7
fat 0x00000000c37a0000 0x000000010c380000 2 /dev/block/mmcblk0p8
bmtpool 0x0000000001500000 0x00000000febf00a8 2 /dev/block/mmcblk0
Part_Name:Partition name you should open;
Size:size of partition
StartAddr:Start Address of partition;
Type:Type of partition(MTD=1,EMMC=2)
MapTo:actual device you operate
As it could be seen, most of the relevant data is on /dev/block/mmcblk0 and there are critical areas on the flash storage that are not mapped to any partition. An obvious solution was to use the almightly dd command and calculate proper count and skip parameters based on the output above.
It should be noted that the content of the preloader that is mapped to /dev/misc-sd is directly available under /dev/preloader.
dd if=/dev/preloader of=preloader
dd if=/dev/block/mmcblk0 of=mbr.img bs=1024 count=512 skip=0
dd if=/dev/block/mmcblk0 of=ebr1.img bs=1024 count=512 skip=512
dd if=/dev/block/mmcblk0 of=pro_info.img bs=1024 count=3072 skip=1024
dd if=/dev/block/mmcblk0 of=nvram.img bs=1024 count=5120 skip=4096
dd if=/dev/block/mmcblk0 of=protect_f.img bs=1024 count=10240 skip=9216
dd if=/dev/block/mmcblk0 of=protect_s.img bs=1024 count=10240 skip=19456
dd if=/dev/block/mmcblk0 of=seccfg.img bs=1024 count=128 skip=29696
dd if=/dev/block/mmcblk0 of=uboot.img bs=1024 count=384 skip=29824
dd if=/dev/block/mmcblk0 of=bootimg.img bs=1024 count=6144 skip=30208
dd if=/dev/block/mmcblk0 of=recovery.img bs=1024 count=12288 skip=36352
dd if=/dev/block/mmcblk0 of=sec_ro.img bs=1024 count=6144 skip=48640
dd if=/dev/block/mmcblk0 of=misc.img bs=1024 count=512 skip=54784
dd if=/dev/block/mmcblk0 of=logo.img bs=1024 count=3072 skip=55296
dd if=/dev/block/mmcblk0 of=ebr2.img bs=1024 count=512 skip=58368
dd if=/dev/block/mmcblk0 of=expdb.img bs=1024 count=10240 skip=58880
dd if=/dev/block/mmcblk0 of=android.img bs=1024 count=1048576 skip=69120
dd if=/dev/block/mmcblk0 of=cache.img bs=1024 count=131072 skip=1117696
dd if=/dev/block/mmcblk0 bs=1024 count=3145728 skip=1248768 | gzip > usrdata.img.gz
#dd if=/dev/block/mmcblk0 of=fat.img bs=1024 count=3202688 skip=200192
#dd if=/dev/block/mmcblk0 of=bmtpool.img bs=1024 count=21504 skip=4173760.1640625
A final note on the last few commands
At the time of taking the backup, I did not have an external sdcard, so I had to use the FAT partition of the device, which was 3GB in size. Obviously, as an immediate consequence, the related line is commented out, as trying to write the image of the FAT partition to the FAT partition itself would not be the brightest idea, would it? The content of this partition can be simply accessed and copied over to a PC by selecting USB connection mode 'Storage device'.
Further, backing up the usrdata partition, which in size is similar to the partition to which the backup was stored, needed a small trick. Given that the partition was almost empty (confirmed via df), I gzipped the image on the fly to make sure, and ended up with a 315MB compressed image.
I did not find much information on bmtpool. It is not mapped to a partition and has a start address which is not aligned to 512 bytes, so it could not be properly backed up via Windows based SP FlashTool according to multiple sources. Actually, nobody seems to have missed the contents of this section.
Tinkering with the raw backups
Some of the backed up files represent the raw copy of whole partitions, these can be directly loop-mounted on linux. Others such as boot.img or recovery.img need another approach.
Based on my experience with initramfs and kernel images, I initially tried to uncompress them via gunzip and cpio, but looking at them via a hex editor revealed that these are amended by a special header. I have quickly googled up a perl script from clockworkmod which was built for unpacking recovery images, but soon it turned out that MT6582 MediaTek devices use a special format that can be unpacked via this script.
Just out of curiosity, I studies the directory structure of the boot and recovery images and confirmed that my smartphone is indeed just a special linux device...
Restoring manually
Restoring is straightforward. Use the same dd commands, but swap the value of if and if, and replace skip with seek. And do make sure to slightly modify the command for usrdata.img.gz, using gunzip. This one is left as an exercise for the reader.
