Film

Android Forensics: Simplifying Cell Phone Examinations.

Categories
Published
of 13
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Description
Edith Cowan University Research Online ECU Publications Pre Android Forensics: Simplifying Cell Phone Examinations. Jeff Lessard Champlain College Gary Kessler Edith Cowan University This article
Transcript
Edith Cowan University Research Online ECU Publications Pre Android Forensics: Simplifying Cell Phone Examinations. Jeff Lessard Champlain College Gary Kessler Edith Cowan University This article was originally published as: Lessard, J., & Kessler, G.C. (2010). Android Forensics: Simplifying Cell Phone Examinations. Small Scale Digital Device Forensics Journal, 4(1), This Journal Article is posted at Research Online. SMALL SCALE DIGITAL DEVICE FORENSICS JOURNAL VOL. 4, NO.1, SEPTEMBER 2010, ISSN# Android Forensics: Simplifying Cell Phone Examinations Jeff Lessard Champlain College Gary C. Kessler Gary Kessler Associates Edith Cowan University Authors' Note This paper was initially written during the fall of 2009 and since that time, several new versions of Android OS have been available to customers via upgrades or new phone purchases. With each new phone and firmware update, there are initial challenges to the forensic community; the fundamentals of acquiring and analyzing an image, however, have remained the same. Introduction It is hardly appropriate to call the devices many use to receive the occasional phone call a telephone any more. The capability of these devices is growing, as is the number of people utilizing them. By the end of 2009, 46.3% of mobile phones in use in the United States were reported to be smart phones (AdMob, 2010). With the increased availability of these powerful devices, there is also a potential increase for criminals to use this technology as well. Criminals could use smart phones for a number of activities such as committing fraud over , harassment through text messages, trafficking of child pornography, communications related to narcotics, etc. The data stored on smart phones could be extremely useful to analysts through the course of an investigation. Indeed, mobile devices are already showing themselves to have a large volume of probative information that is linked to an individual with just basic call history, contact, and text message data; smart phones contain even more useful information, such as , browser history, and chat logs. Mobile devices probably have more probative information that can be linked to an individual per byte examined than most computers -- and this data is harder to acquire in a forensically proper fashion. Part of the problem lies in the plethora of cell phones available today and a general lack of hardware, software, and/or interface standardization within the industry. These differences range from the media on which data is stored and the file system to the operating system and the effectiveness of certain tools. Even different model cell phones made by the same manufacture may require different data cables and software to access the phone's information. The good news is there are numerous people in the field working on making smart phone forensics easier. Already there is material available on how to conduct an examination on Blackberry phones and a growing number of resources about the iphone. However, there is a new smart phone OS on the market named Android and it will likely gain in appeal and market share over the next year. While Android initially launched with only one phone on T-Mobile, phones are now available on Sprint, Verizon and AT&T as well. Introduction to Android Android is an operating system (OS) developed by the Open Handset Alliance (OHA). The Alliance is a coalition of more than 50 mobile technology companies ranging from handset manufactures and service providers to semiconductor manufacturers and software developers, including Acer, ARM, Google, ebay, HTC, Intel, LG Electronics, Qualcomm, Sprint, and T-Mobile. The stated goal of the OHA is to accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience (OHA, 2009, n.p.). Figure 1. Android architecture (Android.com, 2009b). The basic architecture of Android is shown in Figure 1. At its core, Android OS builds are based on the Linux 2.6 kernel. When running on a hard drive, the Linux system device defaults to the first physical hard drive, or /dev/hd0. In SMALL SCALE DIGITAL DEVICE FORENSICS JOURNAL VOL. 4, NO.1, SEPTEMBER 2010, ISSN# addition, Linux only understands character and block devices, such as keyboards and disk drives, respectively. With Linux on flash, however, a Flash Transition layer provides the system device functionality. A Memory Technology Device (MTD) is needed to provide an interface between the Linux OS and the physical flash device because flash memory devices are not seen as character or block devices (Dedekind, 2009). The Android Runtime System utilizes the Dalvik virtual machine (VM), which allows multiple applications to be run concurrently as each application is its own separate VM. Android applications (the apps of today's common parlance) are compiled into Dalvik executable (.dex) files (DalvikVM.com, 2008). During a forensic examination one will be mainly concerned with the Libraries and, in particular, the SQLite databases. This is where one will find the majority of data that could be of interest in an investigation. Files can be stored on either the device's storage or on the removable secure digital (SD) memory card (Android.com, 2009b). Unlike the typical desktop operating system, data or other files created by one Android app cannot automatically be viewed by other applications by default. The VM nature of Android allows each application to run its own process. Security is permissions-based and attached at the process level by assigning user and group identifiers to the applications. Application cannot interfere with each other without being given the explicit permissions to do so (Android.com, 2009a). The security mechanisms of the Android OS could impede a forensic examination although some of the basic tools and techniques could allow investigators to recover data from the device. The first, most obvious step is to perform a traditional forensics analysis of the microsd card from the phone. This is the least effective method as it can only is access the data that apps directly store on the SD card. SD cards use the FAT32 file system and are easily imaged and examined using traditional forensics tools (including write-blocking hardware) (TalkForensics, 2009). The Android file system is Yet Another Flash File System 2 (YAFFS2). YAFFS, developed in 2002, was the first file system designed for NAND (Not-AND) flash memory devices. YAFFS2 was designed in 2004 in response to the availability of larger sized NAND flash devices; older chips support a 512 byte page size whereas newer NAND memory has 2096 byte pages. YAFFS2 is backward compatible with YAFFS (Manning, 2002). Acquiring a Physical Image of an Android Device Since Android is still an emerging OS and, forensics is in its infancy, this section will explore the steps of the analysis of an Android device. The following methods were assembled from research done and methods created by the android/htcmodding community as well as assistance from Andrew Hoog and ViaForensics. Figure 2. Sprint HTC Hero (left) and information screen of test device (right). As of July 2010, the latest version of Android available was v2.2 (Froyo) and v3.0 (Gingerbread) is expected before the end of the year. The analysis described below was performed during the fall of 2009 on a Sprint HTC Hero running Android v1.5 (aka Cupcake) (Figure 2). The Hero is a little different than a standard Android phone because HTC employs its own Sense user interface (UI) on the device, which will not be used on any Google-branded devices (HTC, 2009; Miller, 2009). While the Sense UI changes the look and feel of the device, it is uncertain how much (if any) this impacts a forensic investigation of the HTC Hero. Connecting the device via a data cable Although the data cable for the Hero is a proprietary HTC cable (ExtUSB), an ordinary mini-usb cable will work for data transfers. The HTC cable handles running music and video over USB and would be desired for consumer applications but is not required for any type of forensics analysis. Imaging the memory card Although an analysis of the removable memory of the phone has its limitation and phone system data is likely not stored to the memory card, it can still be a valuable tool. Making an image from the phone's memory card is quite simple and normal procedures for imaging a device can be used. In the analysis here, AccessData's FTK Imager v2.5.1 was employed. The phone first needs to be connected to the examination machine using a write blocker to ensure the integrity of the data. Once the phone is connected, it will prompt that the USB cable is connected and ask the user to select to copy files to/from the host computer. Another screen then appears asking the user to mount the device (Figure 3). SMALL SCALE DIGITAL DEVICE FORENSICS JOURNAL VOL. 4, NO.1, SEPTEMBER 2010, ISSN# Figure 5. FTK Imager image summary screen. Importance of rooting the device in order to obtain a dd image Figure 3. USB Connected screen. Once connected, the device will look for any necessary appropriate drivers. If issues arise, drivers are made available on HTC's website. Now in FTK Imager, go to the File pulldown menu, and select the Add Evidence open, and then choose Physical Drive. Select the drive that is appropriate to the Android device (Figure 4). Note that the device will be the same size as the memory card (in this case, there is an 8GB microsd card in the device. Figure 4. FTK Imager Drive Selection screen. Save the image by using the File, Export disk image option. Make sure to take a physical image of the entire drive rather than a logical image of the partition. In this case, \\PHYSICALDRIVE5 was selected and imaged, sending the output to a raw dd image file. (The rationale for using dd for image files is provided below.) As with any image file, be sure to verify the hash prior to any subsequent analysis (Figure 5). Note that the SD card should be put aside and not replaced in the phone. The ability to physically image memory is the holy grail of mobile device forensics. The device's memory can contain extremely valuable data, such as: the contact list, call logs, text messages, and other phone data. Additional information can also be hidden and uncovered, such as Web history, s, images viewed on the phone, passwords, and fragments of other data. Access to memory can be accomplished by rooting the phone. While the term rooting can have a negative connotation (similar to jailbreaking an iphone), it has a different meaning than is generally perceived. Rooting a device merely means to gain access to the root directory (/) and having the appropriate permissions to take root actions. The modding community -- i.e., modern day hackers (in the 1970s sense of the word) who like to modify devices beyond the intentions of the device designers or vendors -- uses the term to mean accessing the root directory/permissions and then substantially modifying the phone to increase battery life or performance, run homebrewed applications, and/or install custom firmware on the phone (Purdy, 2009). Obviously, changing the data in such a way is not forensically sound and would not be done in an investigation. Obtaining a dd image file is possible when the permissions are altered to gain access to the root directory. It is important to note that this method (at least for the Sprint HTC Hero), in its current iteration, needs to have a third party program installed on the device in order to get root permissions and likely would not be admissible in a court room setting. There are different ways to gain root permissions on other devices that do not involve adding anything to the phone but this is not the case on the Hero. The following method, then, should be viewed more of a proof of concept that could be tailored to be forensically sound if an alternate way to obtain root is found. USB Debugging In order to acquire access to the root directory, Universal Serial Bus (USB) debugging will have to be enabled on the phone. Although the default setting is disabled, going to Settings, selecting Applications, choosing Development and touching the checkbox, can turn on this function. SMALL SCALE DIGITAL DEVICE FORENSICS JOURNAL VOL. 4, NO.1, SEPTEMBER 2010, ISSN# Root access will not be possible if an examiner encounters a locked Android device that does not have USB debugging enabled. If presented with a locked device, one may either attempt the method and hope that USB debugging is currently enabled by the user or must defeat the lock screen by some other method and then enable debugging using the outlined method above. # cd /system/bin # cat sh su # chmod 4755 su Preparing the Hero for rooting The method described here is based upon descriptions at The Unlockr.com (2009) and is the result of the work of many users at the XDA Developers forum (forum.xdadevelopers.com/). The Android root access software was created by Christopher Lais at ZenThought.org. Be sure to insert a fresh SD card in the phone (do not replace the original SD card in the phone as it contains evidence that this process will alter). The first step is to set up the Android Development Tools (ADT) on the host Linux, MacOS, or Windows computer system. The ADT is part of the Android Software Development Kit (SDK) (Android Developers, 2009). For a Windows system, download the SDK ZIP file and extract the files to the host computer. The next step is to ensure that the phone and the Android development bridge (ADB) are both functioning as expected. In the Windows command line, move to the AndroidSDK folder, navigate to the tools subfolder, and run the adb devices command. If everything is working properly, a list of attached devices will show up with a corresponding serial number (Figure 6). If not presented with a list of devices, one must check that drivers are functioning properly and that USB debugging is enabled. Figure 6. Starting the Android SDK in Windows. The method necessary to obtain root is specific to each phone and OS varient. The following method was designed for the Sprint HTC Hero running OS version 1.5 and utilizes a program called AsRoot2 (ZenThought, 2009). The archive needs to be downloaded and the files extracted the files to the Tools folder and then execute the following commands (Figure 7): adb push asroot2 /data/local/ adb shell chmod 0755 /data/local/asroot2 adb shell $ /data/local/asroot2 /system/bin/sh # mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system Figure 7. Obtaining root access of the Android device in Windows. If these steps all work correctly, the examiner should now have root permissions and can image the Android device. It should be noted that there is no real indicator that root access is available; to test out if it is functioning properly, continue and try to make a dd image of the memory (per the instructions below). Creating a dd image of memory The file system of the Android device is stored in a few different places within /dev. Without the use of a traditional hard drive, the Linux kernel makes use of an MTD that allows for the embedded OS running directly on flash (SSI Embedded Systems, 2008). Although it may differ for other android phones, there are six files of interest located in /dev/mtd/ (Android-DLs.com, 2009): mtd0 handles miscellaneous tasks mtd1holds a recovery image mtd2 contains the boot partition mtd3 contains system files mtd4 holds cache mtd5 holds user data Although it is important to image each file to obtain the complete operating system, the majority of this examination will focus on the information in mtd3 and mtd5. In order to image memory, the Android SDK shell will need to again be launched. As before, navigate to the AndroidSDK\tools directory, start the shell by executing the adb shell command, and then entering the /data/local/asroot2 /system/bin/sh instruction. Once in the shell, the dd command can be used to image the memory files, using the command (Hoog, 2009a): SMALL SCALE DIGITAL DEVICE FORENSICS JOURNAL VOL. 4, NO.1, SEPTEMBER 2010, ISSN# dd if=/dev/mtd/mtd0 of=/sdcard/mtd0.dd bs=1024 The command above will make a bit-for-bit image of the mtd0 file, using a block size of 1024 bytes, and copy the image file to the SD card. Repeat this command five more times in order to image the remaining five files of interest (Figure 8). and Portable Data Format (PDF) documents were recovered, as were 12,709 BitMap (BMP), Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG), and Portable Network Graphics (PNG) images. Recovered documents Most of the recovered documents were not of a real evidentiary value. A large portion of the HTML files were advertisements and only four files were complete snapshots of Web pages (Figure 9, left). The HTML files included 28 Exchangeable Image File (EXIF) data for JPEGs; this information can be helpful to determine what specific camera took an image. Figure 8. Obtaining root access of the Android device in Windows. Note that this command will direct the output to the SD card. For this reason, it is imperative that a formatted and wiped SD card is placed into the phone and that the evidentiary SD card is put aside. It is also extremely important to not mix up the input file (if) and output file (of) parameters so as to not inadvertently destroy any data. At this point, the dd files can be analyzed using any forensics software. Be sure to use a write-blocker when accessing the files on the SD card. Examination of Memory The examination of the memory image files was performed using Access Data's Forensic Tool Kit (FTK) v1.81. FTK was selected because of its data carving and searching capabilities; since today's forensic software does not mount the YAFFS2 file system, the ability for string searches was paramount. When setting up the analysis in FTK, select options for full indexing and data carving, and add all six files for analysis. In this case, the subject phone was approximately two months old and had been used extensively for data applications. After data carving, 207 Hypertext Markup Language (HTML) Figure 9. Recovered files: Web page (left) and Google search history (right). One particularly interesting document that contained useful information was the single recovered PDF file. This file was extremely fragmented and while Acrobat Reader reported that the file was corrupt and could not be opened, FTK was able to view the contents. The file was 2 MB in size and was substantially larger than all of the other recovered documents. It contained information such as text messages, phone book information, browser history, Facebook status updates, Google search history (Figure 9, right), YouTube videos visited, and music played from the SD card. It was difficult to look through SMALL SCALE DIGITAL DEVICE FORENSICS JOURNAL VOL. 4, NO.1, SEPTEMBER 2010, ISSN# because it was so fragmented but searching the document made information easier to find. Recovered images As on a typical computer, this Android device had nearly 13,000 images, only some of which would be interesting in a forensics examination. The first noteworthy images found were the ones displayed as the phone is booting up. There are three different images: the HTC logo, a Hero splash screen, and a Sprint screen. The HTC logo screen is displayed at two points in the booting process and features the HTC logo in a beveled silver text on a reflective black background. As the phone boots, the source of light in the image changes as it pans across the logo this seems like a loading screen, indicating something is happening like a progress bar would. This logo was merely an animated GIF file. The mtd3.dd file contained images for different applications. Backgrounds for a labyrinth style game; images for bookmarks, weather, alarm clocks, keyboards, and widgets; grids for Sudoku games; and icons for check boxes, contacts, camera, and
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks