Develop Reference

How can i extract the userdata partition of my android emulator?

How can i extract the (unencrypted and complete) userdata partition of my android emulator (AVD)?
Due to some research i want to extract the userdata and system partition of my emulator. There are several possibilities to do so, yet i was unable to extract a complete and unencrypted userdata partition. I tried the following:
Extract using adb pull: adb pull /dev/block/dm-X DESTINATION_PATH. Results in being able to analyze the partition using autopsy. The image seems semi-complete as the important folders exist but are basically empty (i am using the SANS digital forensics & incident response poster to look up the most important data).
Extract using abd shell: adb shell "su root dd if=/dev/block/dm-X" > DESTINATION_PATH. The image seems corrupt. "File system is corrupt (extXfs_group_load: Group 1 descriptor block locations too large at byte offset 4128)" according to fsstat.
Access the partition via the file system: C:\Users\USER\.android\avd\EMULATED_DEVICE_NAME\userdata-qemu.img. The image seems incomplete as there are only a few folders to analyze.
What's really confusing to me are the three partitions userdata.img, userdata-qemu.img and userdata-qemu.img.qcow2 located in the folder stated in 3). According to the emulator help-page (emulator -help-disk-images), userdata.img is "the initial data partition image". userdata-qemu.img is "the persistent data partition image". There is no information about the userdata-qemu.img.qcow2. It seems that any data after the initial bootup will be saved in userdata-qemu.img.qcow2. I also tried to convert this file using qemu-img -f qcow2 -O raw userdata-qemu.img.qcow2 userdata.img to a raw file format (backing file from adb pull (method 1)), which can be analyzed using autopsy. However, the output seemes encrypted as the entropie is very high and you cannot detect any data using xxd/HxD.
I tested this on Android 11 and Android 12 rooted and emulated devices (Google Play API).
Thanks in advance!

How to mount AOSP .img files?

I generate *.img by building AOSP.
Like ramdisk.img,boot.img etc.
I want to mount this file. I'm using Ubuntu.

You cannot mount boot.img file. However you can unpack it's ramdisk.
The boot.img file contains:
ramdisk
zImage (kernel binary)
dt.img (device tree)
There is an excellent open source project: mkbootimg_tools at GitHub. You can use it to split the boot.img file and unpack the ramdisk.
Unpack boot.img:
mkbootimg_tools/mkboot boot.img boot_unpacked
To unpack system.img you first need to understand what kind of partition is it:
run:
file system.img
If you get 'Android sparse image', then you have a sparse image, meaning you need to un-sparse it before mounting:
simg2img system.img system_raw.img
Then you can mount system_raw.img simply by running:
sudo mount system_raw.img /mnt/android_sys

simg2img
Some Android images are compressed by default for some builds. This is the case for example of the HiKey960 build with lunch hikey960-eng, but not for emulator builds e.g. with lunch aosp_x86_64-eng.
You must first usesimg2img to decompress them:
simg2img system.img out.img
sudo losetup --show -f -P out.img
sudo mount /dev/loop0 /mnt/loop0
simg2img lives under ./out/host/linux-x86/bin/simg2img, and gets added automatically to PATH by lunch.
Note however that this is not the case for all the images, e.g. boot.img.
If you skip simg2img, you get the error:
NTFS signature is missing.
Failed to mount '/dev/loop3': Invalid argument
The device '/dev/loop3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
when trying to mount.
It appears that the compressed format is something that fastboot can understand.
Also mentioned at: https://stackoverflow.com/a/9675784/895245
Tested in Ubuntu 16.04 host, at branch repo init -b android-8.1.0_r1.

Make persistent changes to init.rc

I want to change the init.rc file of an android pad. But after I change it and reboot the system, the original init.rc comes back.
How can I make the change to the init.rc persistently without rebuild the system (since I don't have the source code of the system)? Or is there any way to work around?

Unpack the uramdisk using following command in host PC(Linux)
mkdir /tmp/initrc cd /tmp/initrd
sudo mount /dev/sdb1 /mnt
sdb1 is partion where uramdisk/uInitrd resides.
dd bs=1 skip=64 if=/mnt/uInitrd of=initrd.gz
gunzip initrd.gz
At this point running the command file initrd should show:
mkdir fs
cd fs
cpio -id < ../initrd
Make changes to init.rc
Pack uramdisk using following commands:
find ./ | cpio -H newc -o > ../newinitrd
cd ..
gzip newinitrd
mkimage -A arm -O linux -C gzip -T ramdisk -n "My Android Ramdisk Image" -d newinitrd.gz uInitrd-new

A number of Android devices include code to prevent root modifications to the system files. The way this is done is by using the recovery partition. On reboot, they basically restore the system partition using the recovery image. If your system is doing that then you cannot make persistent changes - the best you could do would be to hook up something to run after reboot to re-apply your change. In CyanogenMod they had hooks in the init.rc to run sdcard scripts if found. Perhaps you can create an app or widget to then launch a script to make the mods required using a setuid root script from the data partition. Without building your own ROM you are quite restricted in this area.
Possibly you could fetch the recovery image and try unpacking that, making your changes and repacking and flashing it. But make sure you can recover with fastboot before you try this.

Try this site:
http://bootloader.wikidot.com/linux:boot:android
Read the section at the bottom:
•The Android boot image: boot.img
◦Unpack, re-pack boot image: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images#Background

When an android system boots, uboot unpacks a special compressed ball of files in your boot partition called 'uRamdisk' to RAM, and defines those files to comprise the root directory of the system. uRamdisk normally contains a bunch of directories (system, data, media, etc.) that serve as mountpoints for partitions that contain the files that go in them, but also has some very basic files vital to your system, including the init binary and startup scripts like init.rc.
when you edit the init.rc, you've actually just edited the unpackaged copy of init.rc that resides in your RAM. To really change it then, you have to copy your uRamdisk, extract it, edit the init.rc from there, repackage uRamdisk and then replace the new one with the old one in /boot.
Try looking up the 'xuramdisk' and 'mkuramdisk' scripts, these make the process very simple.

Your root partition (where /init.rc lives) is a ramdisk which is unpacked from an initrd file and mounted every time your device boots. Any changes you make are to the ramdisk only, and will be lost on the next reboot.
If you can get the initrd file, you can mount it on your Linux host system, modify the files there, unmount it, and write it back to your Android.
The initrd file exists in its own partition on the device. If you can figure out which partition it is, you can grab it from the device onto your host, mount it, modify it, and write it back to the device. This is what tripler was talking about above.
In general, modifying boot.img is something that only system developers do. If you're building the entire Android system, you'll have access to the necessary source code. My workflow for this looks like this:
# Modify init.rc
m -j8 bootimage_signed
adb reboot bootloader
fastboot flash boot $OUT/boot.img
fastboot reboot

I don't know if you are still trying to do this but without knowing your exact device nobody can give you an exact answer.
Try taking a dd image of all your internal partitions and use some scripts like those included with android kitchen on xda forums. Your recovery and boot partitions will both have a ram disk but odds are you want to modify the init.rc in the boot.img not recovery, unless you only want the changes present in recovery mode.
The unyaffs thing doesn't apply to all devices and most devices have different partition layouts so you have to figure out which is boot and what type of fs it is. Maybe if you give your device specs you can get a better answer.

Please note that it may be easier for you to use an app like Scripter to run a script at boot time than modify this file.
Before following #tripler's instructions above you need a file called boot.img which can be extracted by (run on rooted Android device, untested without root):
dd if=/dev/block/platform/<someplatform>/by-name/boot of=/sdcard/boot.img
Then connect your Android to your computer and copy the boot.img file from there.
Script:
http://linuxclues.blogspot.ca/2012/11/split-bootimg-python-android.html
Here is a modified, easier to see version of tripler's instructions (assuming boot.img is in tmp):
cd /tmp
mkdir fs
# Now use the linked script above to split the boot.img file into ramdisk.gz and kernel
python split_boot_img.py -i boot.img -o parts
cd fs
gunzip -c ../parts/ramdisk.gz | cpio -id
# make changes to init.rc
At that point you will have to rebuild the boot.img back together before reflashing, which will be device-specific. Can't help you with that, sorry!

You have to edit/change the init.rc before building your Android pad file system. This is the preferred way, and always works.

How to loop mount an sdcard image in Android, not on the device/emulator

I am using an ARM full-system simulator (gem5) to run Gingerbread. The Gingerbread image was obtained from the gem5 website, but it is a standard.
Most apps of my interest need an sdcard, so I added "mount -o loop /system/sdcard " to the init.rc file on my Android image. When I boot the simulated system, the applications complain about sdcard not being present on the system.
Does Gingerbread's mount (from toolbox or busybox) support loop mounting image files?
Going by this link, it seems the busybox version used by Gingerbread does have an issue with loop mounting, but I cannot make out if that is the sole issue. If so, how do I replace the busybox version on an Android filesystem? Can I just replace the busybox binary with a newer one?

Let's say you already have a vfat partition image like /sdcard.img, in init.rc you can try adding this:
mount vfat loop#/sdcard.img /mnt/sdcard
Source: https://sourceforge.net/p/ipaq214android/blog/2012/05/mounting-loopback-device-by-initrc/

Is there a way to mount Android .img to access the AVD (Android Virtual Device) contents?

I feel a bit blind developing on an emulator for Android and not being able to see the file system on the AVD (.img).
Is there a way to mount it in Windows or Linux, so that I could at least see the file listing and maybe contents?
Bonus if it's mounted with write permissions as well.
Thank you.

You can just mount the device in Linux:
sudo mount -o loop ~/.android/avd/<myvirt>/sdcard.img <destdir>

How about "adb shell"?
This will give you a root shell (on the emulator)..

For MacOS X users:
$ hdiutil attach ~/.android/avd/Samsung_Nexus_S.avd/sdcard.img

For Windows, I just ran across the ImDisk Virtual Disk Driver
Install this utility, and you can then mount sdcard.img. There's a nice tutorial here

Yes, they can be mounted. Under Ubuntu you can mount sdcard.img via vfat and system.img and userdata-qemu.img via yaffs2. See also: "Whats Android file system ??".
Note that the file system yaffs2 is not included in the standard Ubuntu kernel. Thus, in case of Ubuntu, you have to build your own kernel with yaffs2 support before you are able to mount the system.img and the userdata-qemu.img. Alternatively, you can also take a look at the yaffs2utils which allow you to extract files from yaffs2 images or to create new image files. The advantage is that you do not have to build your own kernel for using these tools.

Another option would be to use the File Explorer in DDMS (Eclipse SDK), you can see the whole file system there and download/upload files to the desired place. That way you don't have to mount and deal with images.
I tried mounting and it's cumbersome, for example if the emulator is running you can't do it. Plus you would need to mount each image if you want to see all contents.