Note: I have obtained the below information with great effort and difficulty. I value this information very much and thus am sharing this for other like minded developers to find.
Introduction
All Android devices use separate partitions for storing different parts of the entire system. The boot partition consists of the linux kernel, recovery partition contains the recovery binary, system partition contains the device's ROM, data partition contains all user data and cache partition contains some cache data including dalvik-cache. Partition layout files are used to determine where each specific partition, used for Android's internal tools and provide the data to tools like Online Nandroid. The linux kernel reveals this layout in different places at times, but not always. In some instances, if this layout is not revealed, Online Nandroid uses it's own manually created partition layout file at
/system/partitionlayout4nandroid.
Example (
/proc/partitions on a Google Nexus 4):major minor #blocks name
179 0 15388672 mmcblk0
179 1 65536 mmcblk0p1
179 2 512 mmcblk0p2
179 3 512 mmcblk0p3
179 4 2048 mmcblk0p4
179 5 512 mmcblk0p5
179 6 22528 mmcblk0p6
179 7 22528 mmcblk0p7
179 8 780 mmcblk0p8
179 9 780 mmcblk0p9
179 10 780 mmcblk0p10
179 11 512 mmcblk0p11
179 12 512 mmcblk0p12
179 13 512 mmcblk0p13
179 14 2048 mmcblk0p14
179 15 512 mmcblk0p15
179 16 512 mmcblk0p16
179 17 512 mmcblk0p17
179 18 512 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 860160 mmcblk0p21
179 22 573440 mmcblk0p22
179 23 13798400 mmcblk0p23
179 24 512 mmcblk0p24
179 25 495 mmcblk0p25
MTD Based Devices
MTD (Memory Technology Device) based devices have
/proc/mtd populated with the partition layout, by the linux kernel. Thus, no specific partition layout file is required by Online Nandroid, on MTD based devices.
Example (
/proc/mtd on a Sony Ericsson Xperia Pro):dev: size erasesize name
mtd0: 19000000 00020000 "system"
mtd1: 00600000 00020000 "appslog"
mtd2: 06580000 00020000 "cache"
mtd3: 1a400000 00020000 "userdata"
mtd4: 00c80000 00020000 "boot"
Note: Some buggy kernels may not populate
/proc/mtd properly. In most such cases, the underlying MTD partitions would also not be revealed by the kernel, thus proving a workaround partition layout virtually useless.EMMC Based Devices
Few EMMC (Embedded MultiMedia Card) based devices have
/proc/emmc populated with the partition layout, by the linux kernel. In this case, no specific patch file is required by Online Nandroid. However, this practice is not followed in later devices. Thus, these require patch files. A partition layout file is very similar to /proc/mtd or /proc/emmcgenerated by linux kernel. It follows the same format and the same header.
Gathering information to produce a partition layout file is trivial. It is sometimes revealed somewhere under the
/sys/devices by linux kernel. But this is not always the case. ROM and kernel developers, would, most of the time, figure this out and share this information in development threads on forums like XDA. Other times, it is easiest to obtain a copy of recovery.fstab used by stock, CWM, TWRP and other recoveries. This file is present in the recovery ramdisk and thus can be obtained from someone who has physical access to the device. Alternatively, this file is available at device repositories on Github and other places. A simple search on Google for android_device_oem_device, where oem is the name of device manufacturer such as samsung, sony, motorola,lge..., and device is the code name / technical name of the device such as mako forGoogle Nexus 4 and m0 for Samsung Galaxy S III. In addition a PIT file or a scatter file for the specific device can also be used for deducing the partition layout.
Example (Partition Layout file on an HTC Sensation XL):
dev: size erasesize name
mmcblk0p1: 0001f4 000000 "unknown"
mmcblk0p2: 000040 000000 "unknown"
mmcblk0p3: 001194 000000 "unknown"
mmcblk0p4: 000001 000000 "unknown"
mmcblk0p5: 007530 000000 "unknown"
mmcblk0p6: 0030d4 000000 "unknown"
mmcblk0p7: 000800 000000 "unknown"
mmcblk0p8: 000c00 000000 "unknown"
mmcblk0p9: 000800 000000 "unknown"
mmcblk0p10: 000400 000000 "unknown"
mmcblk0p11: 000400 000000 "unknown"
mmcblk0p12: 00222f 000000 "unknown"
mmcblk0p13: 000c00 000000 "unknown"
mmcblk0p14: 000c00 000000 "unknown"
mmcblk0p15: 000400 000000 "unknown"
mmcblk0p16: 0022fd 000000 "unknown"
mmcblk0p17: 000100 000000 "unknown"
mmcblk0p18: 000400 000000 "unknown"
mmcblk0p19: 000800 000000 "unknown"
mmcblk0p20: 000500 000000 "unknown"
mmcblk0p21: 0021fd 000000 "recovery"
mmcblk0p22: 001000 000000 "boot"
mmcblk0p23: 000100 000000 "unknown"
mmcblk0p24: 007bff 000000 "unknown"
mmcblk0p25: 0fffff 000000 "unknown"
mmcblk0p26: 000c00 000000 "unknown"
mmcblk0p27: 000c00 000000 "unknown"
mmcblk0p28: 0067fe 000000 "misc"
mmcblk0p29: 407fff 000000 "userdata"
mmcblk0p30: 08ffff 000000 "cache"
mmcblk0p31: 007eff 000000 "unknown"
mmcblk0p32: 000103 000000 "unknown"
mmcblk0p33: 8e4ffc 000000 "emmc"
MTK Based Devices
On devices based on MTK (MediaTek) chipsets, a file at
/proc/dumchar_info is populated with the partition layout, by the linux kernel. This file, however is not similar to/proc/mtd, /proc/emmc and partition layout files used by Online Nandroid. Since MTK devices use the uboot mechanism, partitions including boot and recovery, are not revealed as separate partitions, but rather accessed sequencially by size and start parameters. The dumchar_info file has this size and start parameters specified in it. This file has some other major differences in partition naming such as the boot partition is named bootimg instead of boot, data partition is named usrdata instead ofuserdata, system partition is named android instead of system and internal sd card is named fat instead emmc. Online Nandroid (since v8.0) has built-in support for MTK based devices, thus does not require separate partition layout files on MTK based devices.
Example (
/proc/dumchar_info on a Star N9770 Dual Core - MT6577):Part_Name Size StartAddr Type MapTo
preloader 0x0000000000040000 0x0000000000000000 2 /dev/misc-sd
dsp_bl 0x00000000005c0000 0x0000000000040000 2 /dev/misc-sd
mbr 0x0000000000004000 0x0000000000000000 2 /dev/block/mmcblk0
ebr1 0x0000000000004000 0x0000000000004000 2 /dev/block/mmcblk0p1
pmt 0x0000000000400000 0x0000000000008000 2 /dev/block/mmcblk0
nvram 0x0000000000500000 0x0000000000408000 2 /dev/block/mmcblk0
seccfg 0x0000000000020000 0x0000000000908000 2 /dev/block/mmcblk0
uboot 0x0000000000060000 0x0000000000928000 2 /dev/block/mmcblk0
bootimg 0x0000000000600000 0x0000000000988000 2 /dev/block/mmcblk0
recovery 0x0000000000600000 0x0000000000f88000 2 /dev/block/mmcblk0
sec_ro 0x0000000000600000 0x0000000001588000 2 /dev/block/mmcblk0p2
misc 0x0000000000060000 0x0000000001b88000 2 /dev/block/mmcblk0
logo 0x0000000000300000 0x0000000001be8000 2 /dev/block/mmcblk0
expdb 0x0000000000200000 0x0000000001ee8000 2 /dev/block/mmcblk0
android 0x0000000020100000 0x00000000020e8000 2 /dev/block/mmcblk0p3
cache 0x0000000020100000 0x00000000221e8000 2 /dev/block/mmcblk0p4
usrdata 0x0000000020100000 0x00000000422e8000 2 /dev/block/mmcblk0p5
fat 0x00000000854f8000 0x00000000623e8000 2 /dev/block/mmcblk0p6
bmtpool 0x0000000001500000 0x00000000ff9f00a8 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
Very interesting from looking at your partition layout I can see that that /dev/block/mmcblk0 contains your recovery partition. However it appears /dev/block/mmcblk0 is a combined partition that also contains many critical parts of the phones file system such u-boot, /boot, and other bootloader related components. I would recommend running the following commands as root from either ADB shell:
Code:
cd /dev/block/platform
Then from the platform directory list the contents of the directory with the "ls" command. Once you have done that you should see a platform name (Or multiple platform names) for example on my Verizon Galaxy S3 it shows:
Code:
msm_sdcc.1 msm_sdcc.3
Cd into each of the platform directories (Or if there is only one platform directory "cd" into that) and list the contents of the platform directory using the "ls" command and look to see if it list a directory "by-name". If the platform directory your in contains the "by-name" folder run the following command:
Code:
ls -l /dev/block/platform/{platform directory name here}/by-name
If that command returns an output take note of the the block number that contains the recovery partition.
Another suggestion would be to run the following command to try and isolate the recovery.img from the larger /dev/block/mmcblk0 contents:
Another suggestion would be to run the following command to try and isolate the recovery.img from the larger /dev/block/mmcblk0 contents:
Code:
dd if=/dev/block/mmcblk0 of=mnt/sdcard/recovery.img bs=1 skip=6291456 count=8257536
(bs: block size in bytes, skip: start offset of mmcblk0, seek: start offset of recovery.img)
Additionally you could try dumping the whole /dev/block/mmcblk0 partition using the command:
Code:
cat /dev/block/mmcblk0 > /mnt/sdcard/recovery.img
Let me know how the above commands work out for you 
.
.
dd command explain:
http://wiki.linuxquestions.org/wiki/Some_dd_examples
For emmc at least (and SD?) there are hidden "secure" areas. These are generally used for u-boot and other low-level boot mechanisms.
If dd can't see them, it's because the OS doesn't expose them through the device file used to access them (eg, /dev/mmcblk0). It's not a shortcoming of dd, as such.
A lot of embedded devices use these secure areas to do boot before the host operating system even gets a chance to look at the device. There'll be level 1 and level 2 boot loaders that eventually load up u-boot, which then bootstraps the host OS's kernel. After that, the host OS generally doesn't even see the "hidden" areas. That's due to honouring some part of the spec for accessing these "secure" media devices, I think. Part of that is the ARM's TrustZone (IIRC) mechanism to give confidence that the boot sequence hasn't been tampered with.
Another way that the physical contents of the flash can be hidden is if the device does stuff like wear levelling or other hardware/firmware-based mechanism for dealing with bad blocks or the like. You'd need some sort of microscope and minuscule test probes to forensically examine what's actually stored in each memory cell (or just convince the controller to give you raw access).
If you really want to write something into the secure/hidden/separated boot block of eMMC, you need to unlock it first.
- CODE: SELECT ALL
sudo su -
# echo 0 > /sys/block/mmcblk0boot0/force_ro
# dd if=/root/boot0.img of=/dev/mmcblk0boot0
But your board/eMMC will not boot if the written u-boot binary is not correct
댓글 없음:
댓글 쓰기