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!
Related
When looking at the update that was released for Android 4.2.2 (see link ), I was trying to understand the scipt file they wrote.
It contains:
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
I am new to writing such script files. I know linux has a mount command. How do the four arguments above relate to linux mount command and what do they mean ?
So android update zip file are typically written in edify script (may vary depending on what recovery image you have). Some sources for reading
http://forum.xda-developers.com/galaxy-nexus/themes-apps/tutorial-making-flashable-zips-edify-t1611615
http://forum.xda-developers.com/wiki/Edify_script_language
mount parameters are:
FS type (any supported file system)
partition type (EMMC or MTD)
partition (block device) to mount
mount point
Is there any way to dynamically view the application specific cache in Android? I'm saving images to the cache (/data/data/my_app_package/cache) and I'm 99% sure they're saving there, but not sure how long they're staying around.
When I look in the cache using the DDMS File Explorer within Eclipse, it's always empty. I've also tried examining the appropriate cache dir in ADB and again it's always empty.
Any suggestions?
You may use this command for listing the files for your own debuggable apk:
adb shell run-as com.corp.appName ls /data/data/com.corp.appName/cache
And this script for pulling from cache:
#!/bin/sh
adb shell "run-as com.corp.appName cat '/data/data/com.corp.appNamepp/$1' > '/sdcard/$1'"
adb pull "/sdcard/$1"
adb shell "rm '/sdcard/$1'"
Then you can pull a file from cache like this:
./pull.sh cache/someCachedData.txt
Root is not required.
On Android Studio you can use Device File Explorer to view /data/data/your_app_package/cache.
Click View > Tool Windows > Device File Explorer or click the Device File Explorer button in the tool window bar to open the Device File Explorer.
Documentation
Unless ADB is running as root (as it would on an emulator) you cannot generally view anything under /data unless an application which owns it has made it world readable. Further, you cannot browse the directory structure - you can only list files once you get to a directory where you have access, by explicitly entering its path.
Broadly speaking you have five options:
Do the investigation within the owning app
Mark the files in question as public, and use something (adb shell or adb pull) where you can enter a full path name, instead of trying to browse the tree
Have the owning app copy the entire directory to the SD card
Use an emulator or rooted device where adb (and thus the ddms browser's access) can run as root (or use a root file explorer or a rooted device)
use adb and the run-as tool with a debuggable apk to get a command line shell running as the app's user id. For those familiar with the unix command line, this can be the most effective (though the toolbox sh on android is limited, and uses its tiny vocabulary of error messages in misleading ways)
You can check the application-specific data in your emulator as follows,
Run adb shell in cmd
Go to /data/data/ and navigate into your application
There you can find the cache data and databases specific to your application
Question: Where is application-specific cache located on Android?
Answer: /data/data
Cached files are indeed stored in /data/data/my_app_package/cache
Make sure to store the files using the following method:
String cacheDir = context.getCacheDir();
File imageFile = new File(cacheDir, "image1.jpg");
FileOutputStream out = new FileOutputStream(imageFile);
out.write(imagebuffer, 0, imagebufferlength);
where imagebuffer[] contains image data in byte format and imagebufferlength is the length of the content to be written to the FileOutputStream.
Now, you may look at DDMS File Explorer or do an "adb shell" and cd to /data/data/my_app_package/cache and do an "ls". You will find the image files you have stored through code in this directory.
Moreover, from Android documentation:
If you'd like to cache some data, rather than store it persistently, you should use getCacheDir() to open a File that represents the internal directory where your application should save temporary cache files.
When the device is low on internal storage space, Android may delete these cache files to recover space. However, you should not rely on the system to clean up these files for you. You should always maintain the cache files yourself and stay within a reasonable limit of space consumed, such as 1MB. When the user uninstalls your application, these files are removed.
Here is the code: replace package_name by your specific package name.
Intent i = new Intent(android.provider.Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
i.addCategory(Intent.CATEGORY_DEFAULT);
i.setData(Uri.parse("package:package_name"));
startActivity(i);
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.
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/
Disk Utility in OSX easily mounts an SD Card image as a device, but not so the other img files.
I want to get the database I just created in the Android Emulator off the drive and into my osx file system.
I updated my system with qemu using macports but no combination I try succeeds. Anyone figured out how to do this?
Obviously one way I can do this is run the app on my phone than mount the phone as a USB drive. But I don't wanna. I wanna get it off the drive the emulator uses :-)
Thanks in advance, folks.
Michael
Can't you just use adb to pull the database off of the emulator? I actually just answered a similar question... here it was:
The database for a specific app lives in /data/data/[packagename]/databases
The packagename is the package you define in your manifest, for instance /data/data/org.vimtips.supacount/databases/counts.db.
You can view it with adb shell and type sqlite3 /data/data/org.vimtips.supacount/databases/counts.db
Or you can pull it from the device to look at it with a third party utility, with a command like adb pull /data/data/org.vimtips.supacount/databases/counts.db ..
Use the File Explorer in DDMS (from 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, and no adb commands either