An evidence-based Android cache forensics model
A Case Study 1.9Experimental Setup
Download 0.49 Mb.
|
- Navigate this page:
- 1.9.1.1Android mobile phone is rooted
- 1.9.1.2Developer mode enabled
- 1.9.1.3USB debugging is enabled
- 1.9.4Acquisition of cache and data partitions
- 1.9.5Acquisition using dd
- 1.9.5.2Go to super-user mode
- 1.9.5.4Unmount the partitions
- 1.9.5.5Take image of the partitions
A Case Study1.9Experimental SetupIn order to get the app caches, applications that are widely used i.e. which has at least 1 million downloads or if the application is from a significant brand or company, are considered. Nearly 100 apps were identified and analysed for caches. The complete list of these apps is available at the Appendix-A. Out of these 100 apps, 11 apps are selected and studied in detail based on the usage of caches that are common across other apps.
Table 1 –List of Apps Studied in Detail 1.9.1AssumptionsMaking reasonable assumptions is part of every research experiment and this research is no exception. Some of the assumptions made for this research includes: 1.9.1.1Android mobile phone is rootedThere are several discussions without any consensus regarding whether to root an Android mobile phone or not, when a forensic investigation is required. There are also suggestions on how to take a raw image of internal storage including the partitions . However, for this experiment, we consider the mobile phone is rooted. 1.9.1.2Developer mode enabledWhether working on an extracted image which is booted using virtual machine or an actual mobile, without developer mode, it is not possible to enable USB debugging for it to communicate with standard Android tools like adb. Hence, developer mode will be enabled for this experiment. 1.9.1.3USB debugging is enabledAndroid tools like adb can communicate only when debugging is enabled. While other debugging methods can be used, for this experiment, USB debugging will be used for convenience. 1.9.1.4Internal storage is not encryptedEncryption is one of the biggest challenges for law enforcement agencies and forensic investigators. Mobile encryption by itself is a huge topic. However, for this experiment, the mobile considered will not use any advanced options like encrypted, which is not enabled by default. 1.9.2Hardware Used
1.9.3Cache LocationsEach of the identified caches has separate locations in the Android storage layout.
1.9.4Acquisition of cache and data partitionsMost modern methods for acquisition of caches occurs when the acquisition of mobile happens. There are two methods generally discussed for the purpose of mobile acquisition. The first method is traditionally used to take a partition image by rooting the device and using adb to take partition image. This method does not require much development skills but requires the phone to be rooted and rooting the phone does affect the operating system but potential evidence in the mobile device should remain intact and unaffected. The second method however, uses a different approach to take partition images using custom built boot images specifically for a mobile model. In this method, a boot image is developed and loaded into the mobile using the recovery console which allows the developed code to boot on the mobile and the code helps to extract forensically the information in the mobile. This method however, requires significant development skills, significant testing of the utility for a mobile model and often slow. Even though this method is promising from the forensic sense, it is not easy and not affordable given the numerous Android mobile models released each year. 1.9.5Acquisition using ddAny Android partition can be converted into an image file by using the below steps. All the below steps uses the standard tools available from Android. 1.9.5.1Connect the Android device to the computerIn order to successfully connect an Android device, Google’s Android SDK must be installed. Once installed, the Android debugging bridge, commonly referred as adb can be accessible from the platform-tools folder within the sdk. D:\ADT\sdk\platform-tools>adb devices * daemon not running. starting it now on port 5037 * * daemon started successfully * List of devices attached xxxxxxxxxxxxxx device
su root@Android:/ # 1.9.5.3List the mounted partitionsIn order to successfully take images of the partition, the partitions can be listed using the mount command. root@Android:/ # mount mount rootfs / rootfs ro,relatime 0 0 tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /acct cgroup rw,relatime,cpuacct 0 0 tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0 tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0 none /dev/cpuctl cgroup rw,relatime,cpu 0 0 /dev/block/mmcblk0p9 /system ext4 ro,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p1 /efs ext4 rw,nosuid,nodev,noatime,barrier=1,journal_async_commit,data=ordered 0 0 /dev/block/mmcblk0p12 /preload ext4 ro,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p4 /mnt/.lfs j4fs rw,relatime 0 0 /sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0 /dev/block/vold/259:3 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage= cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,discard 0 0
umount /cache root@Android:/ # umount /data umount /data failed: Device or resource busy
4K | gzip -c > /sdcard/cache.img.gz < 3276800+0 records in 3276800+0 records out 209715200 bytes transferred in 60.809 secs (3448752 bytes/sec)
64K | gzip -c > /sdcard/data.img.gz < 33554432+0 records in 33554432+0 records out 2147483648 bytes transferred in 821.632 secs (2613680 bytes/sec) Directory: wki -> images images -> Research Proposal Augmented Reality Visualization of Outdoor Environmental Corrosion Download 0.49 Mb. Share with your friends:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||