DEPT. OF COMPUTER AND INFORMATION SCIENCES UNIVERSITY OF STRATHCLYDE Android Forensics Featuring Nexus One. Apurva Rustagi August 30, 2010 A thesis submitted to the Department of Computer and Information Sciences, University of Strathclyde, in part fulfillment of the regulations for the degree of Master of Science in Forensic Informatics. I declare that, in accordance with University Regulation 20.1.20, this dissertation embodies the results of my own work and that it has been composed by me. Following normal academic conventions, I have made due acknowledgement to the work of others. Signed_________________________________ Date__________ Student Number: 200963485 Abstract When Google, the world’s largest Search Company, moved into the mobile application platform business the lines between mobile forensics and conventional computer forensics became even blurrier. Until recently, most mobile phones have tried to participate in both voice and data worlds; devices where the phone function was the most important, and basic, feature and data applications were just add-ons. However, Android was built from the ground up as a data-aware device and, as such, provides a wealth of information about how it was used and, ultimately, about the user. The scope of this project is to study and investigate various techniques that can be adopted by forensic investigators in order to examine the latest Nexus One phone running on the Android operating system. The Nexus One was launched by Google on January 5, 2010. The project reviews the commercial software tool Device Seizure (Paraben Forensic Software - Device Seizure) by Paraben Corporation and also utilizes free open source tools to achieve its overall objective. Care is taken to ensure that the forensic analysis is carried out with minimum possible modifications on the phone and that the modifications are justified. Chapters 2, 3 and 4 constitute the literature review undertaken to gain a deeper understanding of smart phone forensics, the Android operating system and the Nexus One phone. The fifth chapter describes the methodology that would be followed in this project to investigate the various techniques for analysis of the phone. The acquisition and analysis methods are detailed in chapters 6, 7, 8, 9, 10 and 11. These chapters are written in a form that can be used as methodology for future examination of the Nexus One and other Android phones. A set of good practice guidelines and an overall conclusion is provided in chapter 11 to assist forensic investigators in the analysis of other Android phones. I Dedications & Acknowledgements I dedicate this thesis to my family, especially my father without whom this project would not have been possible. I would like to thank my project supervisor, Mr. Duncan Smeed, for his invaluable advice, assistance and support throughout this entire project. I am very grateful to Mr. Sotirios Terzis and Computer and Information Science Department for arranging the sponsorship of Nexus One phone for this project. I would also like to thank Ms Amber Schroader from Paraben Corporation for giving me a chance to use and review their software product Device Seizure, Ms. Jenni Willis and Mr. Ryan Black for their co-operation to get the tool working. Final thanks to Mr. Andrew Hoog from viaForensics and Mr. Matthew Pemble from Idrach Ltd. for their ideas and assistance given. II Disclaimer This dissertation project was carried out at University of Strathclyde, Glasgow, United Kingdom as a part of M. Sc. Course in Forensic Informatics. The technologies discussed in this literature, the limitations on these technologies that the technology and content owners seek to impose, and the laws actually limiting the use of these technologies are constantly changing. Thus, some of the procedures described in this literature may not work, may cause unintended harm to equipment or systems on which they are used, or may be inconsistent with applicable law or user agreements. The author disclaims responsibility for any damage or expense resulting from their use. In any event, readers should take care that their use of these procedures does not violate any applicable laws, including copyright laws, and be sure to thoroughly test any procedures before using them on actual evidence. Also, for obvious privacy reasons, personal information that is retrieved from the phone is redacted wherever necessary. Screen capture images of software used, and results of information retrieval features like Contacts and call logs have been edited as to not give information pertaining to the details of specific individuals or users. III Table of Contents 1 INTRODUCTION ............................................................................................................ 1 1.1 PROJECT BACKGROUND ............................................................................................... 1 1.2 PROJECT RESEARCH PROPOSAL.................................................................................... 2 1.2.1 Research Problem.................................................................................................... 2 1.2.2 Research Question ................................................................................................... 2 1.2.3 Research Methodology ............................................................................................ 2 1.2.4 Research Objectives ................................................................................................ 3 1.2.5 Deliverables & Notes............................................................................................... 3 2 3 INTRODUCTION TO SMART PHONES FORENSICS............................................. 4 2.1 MAKING SEARCH LEGAL .............................................................................................. 4 2.2 RULES OF EVIDENCE .................................................................................................... 5 2.3 OTHER CONSIDERATIONS ............................................................................................. 7 UNDERSTANDING ANDROID ..................................................................................... 9 3.1 UPDATE HISTORY ......................................................................................................... 9 3.2 ANDROID ARCHITECTURE .......................................................................................... 12 3.3 DATA STORAGE MECHANISMS ................................................................................... 13 3.4 FILE SYSTEM OVERVIEW ............................................................................................ 14 3.4.1 YAFFS (Yet Another Flash File System) ............................................................... 14 3.4.2 Memory Technology Devices (MTD) subsystem ................................................... 16 3.4.3 File System & Application Data Analysis ............................................................. 18 3.5 ANDROID SDK ........................................................................................................... 21 3.5.1 Android Emulator .................................................................................................. 21 3.5.2 Android Debug Bridge........................................................................................... 22 3.5.3 Fastboot ................................................................................................................. 22 3.6 ANDROID BOOTLOADER & RECOVERY MODE. ........................................................... 23 3.7 CROSS COMPILING TOOLS FOR ANDROID. .................................................................. 24 IV 3.8 4 ROOTING ANDROID .................................................................................................... 25 UNDERSTANDING THE NEXUS ONE ..................................................................... 26 4.1 SPECIFICATIONS ......................................................................................................... 26 4.2 BOOTLOADER ON NEXUS ONE.................................................................................... 29 4.3 ROOTING NEXUS ONE ................................................................................................ 29 4.4 TEST NEXUS ONE ....................................................................................................... 29 5 FORENSIC TECHNIQUES FOR ACQUISITION & ANALYSIS........................... 30 6 PARABEN DEVICE SEIZURE .................................................................................... 31 6.1 INSTALLATION............................................................................................................ 32 6.2 ACQUISITION PHASE................................................................................................... 33 6.3 RESULTS..................................................................................................................... 42 6.3.1 Contacts ................................................................................................................. 43 6.3.2 SMS & MMS History ............................................................................................. 44 6.3.3 Call History ........................................................................................................... 44 6.3.4 Other Data ............................................................................................................. 45 6.3.5 Sort & Search ........................................................................................................ 45 7 6.4 REPORTING................................................................................................................. 46 6.5 EXAMINATION OF NEXUS ONE AFTER “CLEAR STORAGE” ......................................... 46 6.6 SUMMARY .................................................................................................................. 46 ROOTING NEXUS ONE ............................................................................................... 47 7.1 UNLOCKING BOOTLOADER ON NEXUS ONE ............................................................... 47 7.2 BACKUPS USING NANDROID ...................................................................................... 48 7.2.1 Flashing Amon_Ra Recovery Image ..................................................................... 49 7.2.2 Performing Nandroid Backups Using Amon_Ra Recovery ................................... 49 7.3 MAKING CUSTOM ROM FOR NEXUS ONE. ................................................................. 50 7.4 FLASHING BOOT.IMG TO GET ROOT. ........................................................................... 52 7.5 INSTALLING BUSYBOX & NANDDUMP ....................................................................... 52 V 8 MEMORY ACQUISITION FROM ROOTED NEXUS ONE ................................... 54 8.1 DD/CAT METHOD ....................................................................................................... 55 8.2 NANDREAD METHOD ................................................................................................. 56 8.3 NANDDUMP METHOD ................................................................................................. 57 8.4 COMPARISON OF DD, NANDREAD, & NANDDUMP IMAGES ......................................... 59 8.4.1 Dd Image smaller than Nandread/Nanddump Images. Are we missing something? 59 8.4.2 Importance of OOB Data ...................................................................................... 62 9 RAW MEMORY ANALYSIS OF NEXUS ONE ........................................................ 63 9.1 DATA CARVING USING FOREMOST/SCALPEL .............................................................. 63 9.1.1 Configuring Scalpel for Android ........................................................................... 64 9.1.2 Scanning with Scalpel ............................................................................................ 66 9.2 STRING DUMP ............................................................................................................ 67 9.3 ANALYSIS OF IMAGE ACQUIRED AFTER USING “CLEAR STORAGE” ........................... 68 10 LOGICAL MEMORY ANALYSIS OF NEXUS ONE ............................................... 69 10.1 DEALING WITH NANDDUMP IMAGES .......................................................................... 69 10.1.1 Emulating MTD Devices with Nandsim Emulator............................................. 69 10.1.2 Installing YAFFS2 Kernel Module..................................................................... 70 10.1.3 Writing Nanddump Images on MTD Devices. ................................................... 72 10.2 INVESTIGATING NANDROID BACKUPS USING UNYAFFS .............................................. 72 10.3 INTERPRETING TIMESTAMPS....................................................................................... 73 10.4 EXPLORING SQLITE DATABASE FILES ....................................................................... 74 10.4.1 Connecting to the Database ............................................................................... 74 10.4.2 Viewing Database Structure .............................................................................. 75 10.4.3 Viewing Database Contents ............................................................................... 76 10.4.4 Important SQLite Databases.............................................................................. 76 10.5 METADATA FROM CAMERA IMAGES .......................................................................... 80 VI 10.6 WIFI CREDENTIALS .................................................................................................... 81 10.7 DESKTOP EVIDENCE ................................................................................................... 82 11 CONCLUSIONS & FURTHER WORK ...................................................................... 83 11.1 CONCLUSIONS ............................................................................................................ 83 11.1.1 Overview ............................................................................................................ 83 11.1.2 Good Practice Guidelines .................................................................................. 84 11.1.3 Project Achievements ......................................................................................... 85 11.1.4 Unresolved Issues .............................................................................................. 85 11.2 FURTHER WORK ......................................................................................................... 85 12 BIBLIOGRAPHY ........................................................................................................... 87 APPENDIX-A MANUAL REFERENCE PAGES................................................................ I APPENDIX-B GLOSSARY ................................................................................................. III VII List of Figures FIGURE 2-1 FLOWCHART FOR SEIZURE OF PDAS & MOBILE PHONES ......................................... 8 FIGURE 3-1: ANDROID LAYERED ARCHITECTURE ..................................................................... 12 FIGURE 3-2: ANDROID BOOTLOADER........................................................................................ 23 FIGURE 3-3: ANDROID RECOVERY MODE ................................................................................. 23 FIGURE 4-1: UNLOCKING NEXUS ONE BOOTLOADER ............................................................... 29 FIGURE 6-1: INSTALLATION OF PARABEN DEVICE SEIZURE ...................................................... 32 FIGURE 6-2: PARABEN DEVICE SEIZURE WELCOME WIZARD ................................................... 33 FIGURE 6-3: PARABEN DEVICE SEIZURE CASE INFORMATION WIZARD .................................... 34 FIGURE 6-4: ENTERING INFORMATION ABOUT THE EXAMINER ................................................. 35 FIGURE 6-5: PARABEN DEVICE SEIZURE ACQUISITION WIZARD ............................................... 36 FIGURE 6-6: CONNECTION SELECTION SCREEN......................................................................... 37 FIGURE 6-7: LIST OF DATA TYPES TO BE ACQUIRED ................................................................. 38 FIGURE 6-8: ADDITIONAL INFORMATION FOR ANDROID PHONES.............................................. 39 FIGURE 6-9: FILE SYSTEM ACQUISITION ................................................................................... 40 FIGURE 6-10: ACQUISITION RESULTS........................................................................................ 41 FIGURE 6-11: DEVICE SEIZURE ANALYSIS SCREEN ................................................................... 42 FIGURE 6-12: ANALYZING RETRIEVED CONTACTS ................................................................... 43 FIGURE 6-13: ANALYZING RETRIEVED SMS AND MMS ........................................................... 44 FIGURE 6-14: ANALYZING RETRIEVED CALL HISTORY ............................................................. 44 FIGURE 6-15: SORT & SEARCH FUNCTIONALITY ....................................................................... 45 FIGURE 7-1: UNLOCKING BOOTLOADER ON NEXUS ONE .......................................................... 47 FIGURE 7-2: LOCKED BOOTLOADER TO UNLOCKED BOOTLOADER ........................................... 48 FIGURE 7-3: AMON_RA RECOVERY MODE ............................................................................... 49 FIGURE 7-4: ANDROID KITCHEN ............................................................................................... 51 FIGURE 8-1: COMPARISON ON DD, NANDREAD & NANDDUMP RAW IMAGES ........................... 61 FIGURE 9-1: DATA CARVING OF /DATA PARTITION USING SCALPEL........................................... 66 VIII FIGURE 9-2: DATA CARVING OF /CACHE PARTITION USING SCALPEL......................................... 67 FIGURE 10-1: NANDSIM EMULATOR ......................................................................................... 69 FIGURE 10-2: CONVERTING UNIX TIMESTAMPS TO READABLE DATE/TIME ............................ 73 FIGURE 10-3: OPENING DATABASE IN SQLITE BROWSER ......................................................... 74 FIGURE 10-4: VIEW DATABASE STRUCTURE IN SQLITE BROWSER ........................................... 75 FIGURE 10-5: VIEWING DATABASE CONTENTS IN SQLITE BROWSER ....................................... 76 FIGURE 10-7: CONTENTS OF CACHED POSITION TABLE IN CACHED GEOPOSITION.DB .............. 77 FIGURE 10-6: CONTENTS OF PASSWORD TABLE ........................................................................ 77 FIGURE 10-8: CONVERTING LATITUDE AND LONGITUDE TO ACTUAL ADDRESS ....................... 77 IX List of Tables TABLE 3-1: UPDATE HISTORY OF ANDROID PLATFORM............................................................ 11 TABLE 3-2: LIST OF IMPORTANT MOUNTED PARTITIONS ON ANDROID ..................................... 18 TABLE 3-3: STRUCTURE OF /DATA DIRECTORY ......................................................................... 19 TABLE 3-4: IMPORTANT SUB-DIRECTORIES IN /DATA/DATA ...................................................... 20 TABLE 4-1: LIST OF SPECIFICATIONS OF NEXUS ONE ................................................................ 28 TABLE 10-1 LIST OF DATABASES & TABLES IN /DATA/DATA/COM.ANDROID.BROWSER/DATABASES .......................................................... 76 TABLE 10-2: LIST OF TABLES IN CONTACTS2.DB ...................................................................... 78 X 1 1.1 Introduction Project Background Android is an open source mobile device platform based on the Linux 2.6 kernel and managed by the Open Handset Alliance (Android Operating system), a group of major mobile device hardware and software vendors. Member firms include Google, HTC, Dell, Intel, Motorola, Qualcomm, Texas Instruments, Samsung, LG, T-Mobile, Nvidia, and Wind River Systems. The first Android device was released in October 2008 and by early 2010, 41 Android Devices were commercially available. This includes the Nexus One phone designed by Google and manufactured by HTC. An October 2009 report released by Gartner predicted that by 2012, Android will be the second largest smart phone provider with 18% of the market (Hamblen, 2009). Already, Android devices account for 20% of the traffic generated by smart phones (the largest being the iPhone at 55%) according to October 2009 report by AdMob (Admob, 2009). The Android’s data-aware design, combined with its mobility and "always on" feature, has allowed Android smart phones to be used as a functional mobile office. The cost of this productivity is the danger of storing sensitive data on the device. Any given Android phone is likely to contain sensitive information belonging to its owner, and some types of information that may belong to others such as email, documents, and photos. The scope of this project is to learn about Android internals and study various techniques that can be used to recover and analyze low level data from Android phones for the purpose of forensic investigations. 1 1.2 Project Research Proposal 1.2.1 Research Problem Android has become very popular and has earned a large population of consumers in a very short period of time. Android powered smart phones store large amount of data including but not limited to contacts, call logs, emails and photos. However, there are no validated frameworks to recover data from these phones. Some applications like Paraben Device Seizure can recover data from the phone. However, they are unable to retrieve deleted data from the phone and also cannot capture those parts of the file system that need root access. 1.2.2 Research Question Based on the research problem discussed above, the topic of this research would be to study and assess various techniques that can be used for forensic examination of Android phones. The main research questions that will be tackled in this project are: 1. What important pieces of data are stored in Android phones? 2. What are the different methods of acquisition of memory from the Android phones? 3. How is one method different from the other in terms of maintaining integrity and acquiring the maximum amount of data? 4. What methods can be used to analyze the memory or the data acquired from the Android phones? 1.2.3 Research Methodology This project will mainly take the form of experimental research with some help from literature review. The literature review would be done to study the existing framework of smart phone forensics and also to learn about the Android architecture and its SDK1. This would be followed by reviewing the existing software like Paraben Device Seizure to analyze the amount of information they can retrieve. Following the review of the software, experiments would be performed to acquire raw flash memory using open source tools. After the acquisition phase, raw and logical analysis of the flash file system images would be performed to interpret the data retrieved from the phone. 1 Software Development Kit 2 These experiments would be conducted on a Nexus One phone. The Nexus One phone was chosen since it is the only retail phone that comes with vanilla version of the Android Operating System i.e. without any additional manufacturer applications like HTC Sense UI by HTC. 1.2.4 Research Objectives The main objective of this study is to assess various acquisition and analysis techniques that can be used to investigate Android phones in general and the Nexus One in particular. A set of good practice guidelines would also be composed that may be used by forensic investigators for examining phones running on Android platform. Learning Outcomes After this project I hope to have gained knowledge of: 1. Existing general frameworks for conducting smart phone forensics. 2. Internals of Android architecture. 3. Android SDK and use of various tools and utilities that come with SDK. 4. Use of existing applications for conducting smart phones forensic analysis. 5. Fundamentals of Flash File Systems like YAFFS2 (Yet Another Flash File System 2). 6. Use of tools required for forensic analysis of Flash File Systems. 1.2.5 Deliverables & Notes The only deliverable needed for the M Sc project is the dissertation. However, this dissertation can also be used as a methodology to conduct the forensic analysis of the Nexus One phone. A set of good practice guidelines at the end of the report can be used as general steps needed for forensic examination of other Android phones. Please note that this report should be marked as a ‘Type 5 – Experimental’ dissertation type, as specified in the Department of Computer and Information Sciences, Guidelines for Dissertations Handbook. 3 2 Introduction to Smart Phones Forensics Smart phones are an intelligent evolution of mobile phones in a way that they can be used for purposes other than calling and messaging such as browsing the Internet and navigation through maps. The increasing memory storage and variety of applications that can be installed on these phones give them their intelligence. Along with contacts and call logs, these applications store a range of important data from GPS locations to browser history. Such data acquired from smart phones can serve as useful evidence in crime, civil and high profile cases. 2.1 Making Search Legal Like every forensic examination, it is vital that the search and seizure process of mobile phones should also be formalized and made legal. In the corporate environment, companies do not have any legal authority to examine employee’s personal devices but they can rightfully examine the devices belonging to the company. In order to verify the ownership it is necessary that companies have inventory procedures in place for mapping the unique device identification number called International Mobile Equipment Identification (IMEI) to the user of that device at a particular time. This would also help in proving the person responsible for any actions on the phone if criminal charges are filed in the court. In the law enforcement environment, it is necessary to acquire an appropriate search warrant for the mobile phone. The search warrant should specify all the information that officers intend to retrieve from the phone including, but not limited to, text messages, calendar events, photos and videos, caches, logs of recent activity, map and direction queries, map and satellite imagery, personal alarms, notes, music, email, web browsing activity, passwords and personal credentials, fragments of typed communication, voicemail, call history, contacts, information pertaining to relationships with other devices, and items of personal interest. A separate search warrant may be needed to acquire network data from cellular service providers. In most cases it might also be useful to acquire search warrant for the desktop machine that the suspect user might have used to connect with the mobile phone. 4 2.2 Rules of Evidence The Good Practice Guide for Computer Based Electronic Evidence [ACPO] (ACPO Guideline Computer Evidence) suggests the following procedures when handling cell phones: 1. No action taken by law enforcement agencies or their agents should change data held on a computer or storage media which may subsequently be relied upon in court. During the seizure of the mobile phone it is recommended to isolate the device from the network by either switching it off or by placing it in shielding bag. If the device is switched off, then accessing the device and data later may require authentication codes like SIM PIN or security codes. If the device is placed in a shielding bag, then battery life will be reduced as handset constantly tries to connect to network. Therefore immediate delivery to the examination unit is required. For devices having volatile memory, care should be taken to charge the device at regular intervals to ensure that important data is not lost. During the examination phase, shielded rooms or box may be used to isolate the device from the network. Use of jamming device is not recommended since they are illegal in many countries and may also interfere with the network outside the examination unit. Cooperation of mobile service provider may also be sought to disable the relevant subscriber account and to provide an access card type SIM that will mimic the identity of original SIM card but will not allow network access. Only validated and verified forensic tools should be used for examination wherever possible. In case, the phone model is not supported by forensic tools, the non forensic tools should be first tested in safe environment with the same model of the device so that their operation is properly understood. Use of Cable interface should be preferred followed by infrared, Bluetooth and WIFI at last. 5 There may be circumstances when reading the data will change the state of that data. For example, retrieving un-read SMS messages via the handset may result in their status changing to “Read”. Such events should be logged. It is very necessary to plan the investigation process to avoid any loss of important data. Sequence of Examination (i.e. handset vs.SIM) will depend upon a number of factors and the decision may lead to data loss. The decision on sequence will depend to some extent upon case specifics (e.g. importance of date and times), as well as the examination environment and tools available. Removing the SIM typically requires battery removal which MAY lead to loss of time and date information. Inserting a different SIM into a handset will, in most cases, result in the deletion or hiding of user data (e.g. call registers). As such, this practice should be avoided. If the handset is on, the authentication codes may be active (e.g. PIN lock on SIM and/or handset security codes) and hence handset-first examination may be preferable (otherwise entire examination is delayed). Even if the device is supported by tools, manual examination should be conducted to verify results and ensure completeness of download. 2. In circumstances where a person finds it necessary to access original data held on a computer or on storage media, that person must be competent to do so and be able to give evidence explaining the relevance and the implications of their actions. In order that above principle is complied training of seizure personnel and examiners are properly trained. Also before undertaking real case work, an examiner should have prior and recent experience of examining a device of similar functionality with the tool(s)/process to be used. 3. An audit trail or other record of all processes applied to computer-based electronic evidence should be created and preserved. An independent third party should be able to examine those processes and achieve the same result. During the seizure, it is important to photograph or video the status of exhibit. This includes any on-screen information existing on the device. During the examination, any changes occurring to the data should be noted (e.g. incoming messages.). 6 The details of all tools and products used for investigation should also be recorded with their version number. 4. The person in charge of the investigation (the case-officer) has overall responsibility for ensuring that the law and these principles are adhered to. The investigating officer in charge should ensure that seizure personnel involved should be appropriately trained. It is the responsibility of investigating officer to establish clear communication between him and the examiner. Any examinations involving loss of specific data should only be conducted after the permission of the investigating officer. An examiner can only recommend an examination strategy appropriate to the case and explain its implication to the investigating officer. The final decision however lies with the investigating officer only. 2.3 Other Considerations The examination should take into consideration any requirements to preserve other forensic evidence (DNA, fingerprints, firearms, narcotics). Seizing personnel should aim to take any other material and equipment related to the device. 7 Figure 2-1 Flowchart for Seizure of PDAs & Mobile Phones (ACPO Guideline Computer Evidence) 8 3 Understanding Android Android is an open source mobile platform based on the Linux 2.6 kernel. It is managed by Open Handset Alliance (Open Handset Alliance Homepage), a group of major mobile device hardware and software vendors. Android is not just an operating system. It is a software stack for mobile devices that includes an operating system, middleware and key applications. Like most mobile devices, many Android devices use ARM-based processors. However, Android is in process of being ported to Intel and MIPS architecture (Hoog, Android on the loose, 2010). Android uses the Bionic C-library instead of standard C-library used in traditional Linux (Android Operating system). However, the user application development for Android is done in Java and the applications run in Dalvik virtual machine (DVM). (What is Android?) 3.1 Update History Android has seen a number of updates since its original release. These updates to the base operating system typically fix bugs and add new features. 1.1 Released 9 February 2009 On 30 April 2009, the official 1.5 (Cupcake) update for Android was released. There were several new features and UI updates included in the 1.5 update:] 1.5(Cupcake) Based on Linux Kernel 2.6.27 • Ability to record and watch videos through camcorder mode • Uploading videos to YouTube and pictures to Picasa directly from the phone • A new soft-keyboard with text-prediction • Bluetooth A2DP and AVRCP support • Ability to automatically connect to a Bluetooth headset within a certain distance • New widgets and folders that can populate the Home screens • Animated screen transitions 9 On 15 September 2009, the 1.6 (Donut) SDK was released. Included in the update were: 1.6(Donut) Based on Linux Kernel 2.6.29 • An improved Android Market experience • An integrated camera, camcorder, and gallery interface • Gallery now enables users to select multiple photos for deletion • Updated Voice Search, with faster response and deeper integration with native applications, including the ability to dial contacts • Updated search experience to allow searching bookmarks, history, contacts, and the web from the home screen • Updated technology support for CDMA/EVDO, 802.1x, VPNs, and a text-to-speech engine • Support for WVGA screen resolutions • Speed improvements in searching and camera applications • Gesture framework and GestureBuilder development tool On 26 October 2009 the 2.0 (Eclair) SDK was released. Among the changes were: 2.0/2.1(Eclair) Based on Linux Kernel 2.6.29 • Optimized hardware speed • Support for more screen sizes and resolutions • Revamped UI • New Browser UI and HTML5 support • New contact lists • Better white-black ratio for backgrounds • Improved Google Maps 3.1.2 • Microsoft Exchange support • Built in flash support for Camera • Digital Zoom • MotionEvent class enhanced to track multi-touch events[44] • Improved virtual keyboard • Bluetooth 2.1 • Live Wallpapers The 2.0.1 SDK was released on 3 December 2009. The 2.1 SDK was released on 12 January 2010. 10 On 20 May 2010 the 2.2 (Froyo) SDK was released. Changes included: 2.2(Froyo) Based on Linux Kernel 2.6.32 • General Android OS speed, memory, and performance optimizations • Additional application speed improvements courtesy of JIT implementation • Integration of Chrome's V8 JavaScript engine into the Browser application • Increased Microsoft Exchange support (security policies, auto-discovery, GAL look-up, calendar synchronization, remote wipe) • Improved application launcher with shortcuts to Phone and Browser applications • USB tethering and Wi-Fi hotspot functionality • Added an option to disable data access over mobile network • Updated Market application with batch and automatic update features • Quick switching between multiple keyboard languages and their dictionaries • Voice dialing and contact sharing over Bluetooth • Support for numeric and alphanumeric passwords • Support for file upload fields in the Browser application • Support for installing applications to the expandable memory • Adobe Flash 10.1 support Tentatively scheduled for Q4 2010 launch. Confirmed new features: 3.0(Gingerbread) Based on Linux Kernel 2.6.33 or 34 • Support for WebM video playback • Improved copy–paste functionalities Unconfirmed new features: • Android Market music store • Media streaming from PC library] • Revamped UI • Support for bigger screens with up to Wide XGA (1366×768) resolution Table 3-1: Update History of Android Platform (Android Operating system) 11 3.2 Android Architecture Shown below is the overview of the Android architecture as given by Google: Figure 3-1: Android Layered Architecture (What is Android?) Linux Kernel: The Linux kernel acts as an abstraction layer between the device hardware and the user applications. It provides memory and process management, hardware drivers and other core functionality. It allows the application developers to focus on development through an application framework and its supporting libraries. Libraries: At this level up there are native libraries which are written in C and C++. Application developers have Java interfaces to call these libraries. These libraries provide needed functionalities such as graphics rendering and acceleration (Open GL), font rendering (FreeType), media support using OpenCORE and structured data storage (SQLite). Android Runtime Libraries: Android Runtime library includes Dalvik Virtual Machine. Dalvik runs dex files, which are converted at compile time from standard class and jar files. Dex Files are more compact and efficient than class file, making them as a better choice for the battery powered mobile devices with limited memory. Each user application is run in a separate Dalvik Virtual Machine (DVM) with a separate user id and process. This is one of the key mechanisms used for enforcing data security between different applications. Applications can only access the data within their DVM unless another application and the phone owner specifically allows the data to be shared. Each time an application is installed on an Android device, the user is presented with a screen to authorize the access the new application is requesting. 12 Application Framework: This is where application developers interact with Android. Using this layer, the developer has access to the devices core functionality in a simplified and structured way. A thorough documentation is available from Google on these topics at http://developer.android.com/index.html. One important concept is that of Content Providers. Content providers store and retrieve data and make it accessible to all applications. A content provider is an optional component that exposes read/write access to your application data, subject to whatever restrictions you want to impose. They are the only way to share data across applications; there's no common storage area that all Android packages can access. Android ships with a number of content providers for common data types such as audio, video, images, personal contact information, and so on. Application: This is the top layer in Android architecture. All of the application code stays at this layer. This includes inbuilt applications such as Phone and Web browser. 3.3 Data Storage Mechanisms There are various options for developers to store persistent data in Android. The choice depends on whether the data should be private to the application or accessible to other applications (and the user) and space needed by each application. The following are the available data storage options: • Shared Preferences • Internal Storage • External Storage • SQLite Databases • Network Connection Shared Preferences: The Shared Preferences class provides a general framework that allows developers to save and retrieve persistent key-value pairs of primitive data types. This data will persist across user sessions (even if the application is killed). Internal Storage: Applications can also store data as files on device’s internal storage i.e. NAND flash memory. By default, files saved to the internal storage are private to your application and other applications cannot access them (nor can the user). When the user uninstalls your application, these files are removed. 13 External Storage: All Android devices support external storage that can be used to save data as files. In most cases this is a removable media like SD card but can also be an internal nonremovable storage. Files saved to the external storage are world-readable and can be modified by the user when they enable USB mass storage to transfer files on a computer. SQLite Databases: SQLite Databases are used for structured data storage. Android uses SQLite3 databases and recovery of and from these files is a very key part of forensic analysis. The Android SDK includes a sqlite3 database tool that allows you to browse table contents, run SQL commands, and perform other useful functions on SQLite databases. Network Connections: The final data storage is via the network, i.e. the cloud. While certain investigations may require network analysis, most rely on data stored on the device. 3.4 File System Overview Like most Linux systems, there are several file systems in use on Android, many of which are used to boot and run the system. However in this project, only file systems with user data would be investigated. These include the FAT32 SD card and YAFFS2 partitions. Most Android phones come with an SD card where user can store their data. On the Nexus One the data card supplied is of 4GB capacity while the Motorola Droid comes with a 16 GB card. The card is formatted with FAT32 for interoperability with common operating systems. Some of the data stored on the card includes photos, videos, thumbnails, downloaded files, text to speech temporary files and Google Maps Navigation data as well data from many Android applications. While SD card data is very important, much of the sensitive data found on the device is located in the user data partition located in the phone’s NAND memory. This partition uses the open source file system YAFFS2 (Yet Another Flash File System 2) (YAFFS Homepage) and is one of the new challenges in Android platform for the forensic investigators. 3.4.1 YAFFS (Yet Another Flash File System) YAFFS2 was built specifically for the growing NAND memory devices and has a number of important features that address the stringent needs of this medium. It is a log structured file system, provides built in wear-leveling and error correction, is fast and has a small footprint in RAM. However, its usage prior to Android was very limited and hence there are currently no forensic tools that support this file system. Before getting into further details about the YAFFS2 file system a few key properties of NAND memory should be understood. Unlike magnetic hard drives, flash memory supports a 14 very limited number of write cycles. Hence flash aware file systems focus greatly on reducing the number of writes. When flash memory is erased, the entire block is written with 0xFF and this is the only mechanism by which a 0 can be changed to a 1. Hence when a flash gets a write cycle it only changes the bit value from 1 to 0. For example, if the current byte value is 10110011 and value 11011010 is written on it, the end result would be 10010010, the logical AND of the two values. The memory for YAFFS file system is addressed in blocks and each block contains a set number of pages called chunks. For Android Devices, each block has 64 chunks and each chunk is 2KB. Hence the size of each block is 128KB. The block also includes a 64 byte Outof Band (OOB) area which is the spare area for storing various tags and metadata. When a block is allocated for writing it is assigned a sequence which starts at 1 and increments with each new block. Data structures stored in YAFFS2 are referred to as Objects. These objects can be files, directories, symbolic links and hard links. Each chunk either stores a yaffs_ObjectHeader (object metadata) or data for the object. The yaffs_ObjectHeader tracks various information including the Object type, the parent object, a checksum of the name to speed up searching, the object name, permissions and ownership, MAC information and the size of the object if it is a file. In the 64 byte Out-of-band area, YAFFS2 stores critical information about the chunk but also shares the area with the Memory Technology Devices (MTD) subsystem. The critical YAFFS2 tags are: • 1byte: Block State (0xFF if block is good, any other value for a bad block) • 4byte: 32 bit chunk ID (0 indicates chunk is storing yaffs_ObjectHeader, else data) • 4 bytes: 32 bit object ID (similar to traditional UNIX node) • 2 bytes: Number of data blocks in this chunk (all but final chunk would be fully allocated) • 4bytes: Sequence number of this block • 3 bytes: ECC tags (in Android, handled by MTD) • 12 bytes: ECC for data (in Android, handled by MTD) If an object is changed, a new yaffs_ObjectHeader is written to flash since NAND memory can only be written once before erasing. The old data and headers still exists but are ignored in the file structure by examining the values of sequence number. Using this process complies with the guideline that blocks in NAND can never be rewritten. 15 Similarly, when a file is deleted in YAFFS, it is moved to a special, hidden “unlinked” or deleted directory. The file remains in this directory until all of the chunks in the file are erased. To achieve this, the file system tracks the number of chunks in the system for the file and when it reaches 0, the remnants of the file no longer exist. At that point, it will no longer track the object in the “unlinked” directory. On Android devices YAFFS2 does not access the NAND directly, instead interfacing through the Memory Technology Devices (MTD) subsystem. This system handles the direct interaction with the NAND and is responsible for formatting the OOB area as well as the error correction. MTD was developed since the Linux kernel did not originally support flash memory, which has very different characteristics in comparison to traditional block or character devices. When YAFFS2 is ready to write data to the NAND it makes a call to the MTD and passes the data and the OOB structure. The MTD is then responsible for writing both the data and the OOB, as well as reading; YAFFS2 does not have specific knowledge of how the data is written to NAND memory. 3.4.2 Memory Technology Devices (MTD) subsystem The Memory Technology Device subsystem was developed to provide an abstraction layer for raw flash devices. This subsystem is used when working with different flash devices like NAND, NOR, etc. Traditionally, there were only two types of devices in Linux. These were character devices and block devices. Examples of character devices are keyboards or mice from which current data could be read but operations like SEEK could not be done on them and they did not have a size attribute. Block devices, however, have fixed size and SEEK operations can be performed on them. Memory technology devices are third type of devices. Flash memory devices, like NAND, NOR, etc. come in this category. USB sticks and SD cards, although they are known as “flash”, are not MTD devices. These devices have a Flash Translation Layer (FTL) which emulates a block device and hence they can be used with conventional file systems like FAT, ext3 and ext2. 16 An MTD subsystem has the following interfaces: • MTD character devices are usually referred to as /dev/mtd0, /dev/mtd1, and so on. These character devices provide I/O access to the raw flash. They support a number of ioctl calls for erasing eraseblocks, marking them as bad or checking if an eraseblock is bad, getting information about MTD devices, etc. • The sysfs interface is relatively new and it provides full information about each MTD device in the system. This interface is easily extensible and developers are encouraged to use the sysfs interface instead of older ioctl or /proc/mtd interfaces, when possible. • The /proc/mtd proc file-system file provides general MTD information. This is a legacy interface and the sysfs interface provides more information. Android OS creates MTD device interfaces at /dev/mtd/mtdX and /dev/mtd/mtdXro. These are the interfaces that should be used for imaging the NAND file systems for analysis rather than the /dev/block/mtd interfaces. Information about MTD devices on Android can be found using /proc/mtd interface. $ cat /proc/mtd cat /proc/mtd dev: size erasesize name mtd0: 000e0000 00020000 "misc" mtd1: 00500000 00020000 "recovery" mtd2: 00280000 00020000 "boot" mtd3: 09100000 00020000 "system" mtd4: 05f00000 00020000 "cache" mtd5: 0c440000 00020000 "userdata" There are different sets of utilities that have been developed for debugging MTD devices. These utilities come in the “mtd-utils” package and contain tools like Nanddump and nandwrite to dump the NAND memory and write the data respectively. These utilities can be found at http://git.infradead.org/mtd-utils.git. However, they should be manually compiled for Android architecture on ARM platform before using them on the phone. 17 3.4.3 File System & Application Data Analysis One of the most interesting parts of any forensic analysis is the detailed examination of the file system, application and the data. Below is the listing of interesting mounted partitions on Android phones: Device Mount Point File System Type Options tmpfs /sqlite_stmt_journals Tmpfs Rw,size=4096k 0 0 /dev/block/mtdblock3 /system Yaffs2 Ro 0 0 /dev/block/mtdblock5 /data Yaffs2 Rw,nosuid,nodev 0 0 /dev/block/mtdblock4 /cache Yaffs2 Rw,nosuid,nodev 0 0 Table 3-2: List of Important Mounted Partitions on Android The sqlite_stmt_journals file system in Android replaces the swap partition in conventional Linux systems. The activity on sqlite3 databases could use this partition to perform operations quickly in RAM. Since Android devices do not have swap space, RAM memory needs to be imaged for checking any remnants of important data. The remaining partitions are all YAFFS2 (Yet Another Flash File System 2). The system partition is read only and remains unmodified by the end-user unless they gain root access. The cache directory contains cached, unlinked and deleted files. This cache directory is used for Gmail attachment previews, downloads of files containing DRM, and downloads of applications from the Market place and OTA (Over the Air) system updates. 18 The most important directory from an investigation point of view is the /data directory. The /data directory has the structure illustrated in the following table. /data /anr Debug information with timestamps from apps running in Dalvik Virtual Machine /app Application files (.apk) /dalvik-cache The .dex files (Dalvik Virtual Machine Executables) /data Subdirectory per application with associated data including preferences unstructured files and SQLite3 databases for structured data. /misc Non-application data, including information about dhcp, wifi, etc. /property Localization information including country, language, locale and time zone /system List of all applications and their permissions (packages.xml), checkin.db which lists many network, system and application events, syncmanager.db which lists results from various Gmail sync applications and several other files. Table 3-3: Structure of /data directory 19 The subdirectories in /data/data contain the data from the applications running on the phone. com.android.browser/ Contains 7 directories including web icons, Google gears data, thumbnails, full cache with file and supporting database, cookies, bookmarks, searches and user/pass/form data in clear text com.android.providers.calendar/ Sqlite3 database with full calendar information com.android.providers.downloads/ Sqlite3 database with downloads for the system. Deleted records can be found with strings or by reverse engineering the format com.android.providers.im/ Sqlite3 database with IM information include service, user/pass, groups, contacts and more. com.android.providers.telephony/ Sqlite3 data for all text messages com.google.android.apps.maps/ Google Maps search history and suggestions com.google.android.providers.gmail/ Gmail information including attachments, sender, receiver and full message com.google.android.street/ Cache of Google Maps street images com.google.android.youtube/ YouTube info Table 3-4: Important Sub-directories in /data/data 20 3.5 Android SDK One important step for any Android forensic investigation is setting up the free SDK (Software Development Kit) provided by Google. This SDK not only provides a set of tools and drivers needed by the examiner but also a full emulator (with root access) which is critical to application profiling and other forensic research. The SDK is supported in many environments including Linux Windows and OS X. The SDK needs JDK to be installed and Google recommends Eclipse environment for Android development. Eclipse IDE is recommended because the Android Developments Tools (ADT) plug-in can be used with Eclipse for faster and easier product development. Further instructions on installing the SDK can be found at http://developer.android.com/sdk/index.html. 3.5.1 Android Emulator Once the SDK and Eclipse are fully downloaded and installed, the Android Emulator - also known as Android Virtual Device (AVD) can be started. To do this, the first step is to check the list of Android Versions which are available for emulation. The command for this operation is: android list targets To create an AVD running Android 2.1 – the version that Nexus One initially ran - the following command should be given: android create avd –n af21 –t 3 The n argument specifies the name of the emulator and t corresponds to the target i.e. Android 2.1 version. To then run the emulator type the following command: emulator –avd af21 The above command would invoke an AVD running Android 2.1 and we can then interact with it via emulator, adb or other techniques. However, to connect a physical Android device to the work station, additional USB drivers should be installed. For Win XP, the drivers are located at: SDK root \usb_driver 21 3.5.2 Android Debug Bridge The Android Debug Bridge (ADB) ships with the SDK and is a very powerful tool for interacting with the device. ADB is a versatile tool for managing the state of an emulator instance or Android-powered device. It is a client-server program that includes three components: • A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plug-in and DDMS also create adb clients. • A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device. • A daemon, which runs as a background process on each emulator or device instance. Under normal circumstances, the adb daemon on the phone runs as “shell” and does not have access to the critical user data. However, some significant information can still be extracted about the phone and some information about the user. If the device has root access adb can be used to extract nearly all allocated data on the system. To use ADB on a physical device, the “USB debugging” feature needs to be enabled. This can be done on most Android devices by going into SettingsApplicationsDevelopment. 3.5.3 Fastboot Fastboot is the protocol used to update the flash file system in Android devices from a host over USB. It allows flashing of unsigned partition images. Fastboot commands can be executed on a host machine after bootloader has been started on a device connected via USB. 22 3.6 Android Bootloader & Recovery Mode. Like other Linux variations, Android also comes with its own bootloader. The first program that runs on any Android Device is its bootloader. The bootloader, technically, is not a part of Android Operating system. It is used for very low level system initialization before loading the Linux Kernel. The bootloader is able to detect certain keypresses, which can be used to make it load a “recovery” image, or put the phone into a mode where a developer can perform development tasks such as re-writing flash images, downloading and executing an alternate kernel image, etc. Figure 3-2: Android Bootloader The bootloader also gives a one click option to erase all the user data on the phone and perform a factory reset. This option can be used as one of the anti-forensic technique to wipe all the data and make forensic investigation more difficult. Bootloader in Android gives the option to enter into recovery mode. Recovery mode is mainly used to flash a signed update.zip from SD card onto the phone. Update.zip is used for packaging various .apk files at once. The case for such a file is obvious when we want to add all of the Google applications to the AOSP (Android Open Source Project) build of Android. This technique works much faster than installing one update at a time. The Recovery mode also gives the option of wiping the user data i.e. resetting phone to factory settings or wipe cache partition. This can be used by the end-users to eliminate any evidence that may be obtained through various forensic techniques. 23 Figure 3-3: Android Recovery Mode 3.7 Cross Compiling Tools for Android. There are many useful tools that can be used to debug in Android. One such tool-set is “mtdutils” package. It is a collection of tools that allows users to interact with MTD subsystem in the kernel to perform operations on FLASH devices. However, these tools should be manually compiled for Android architecture on ARM platform. Here is the step-by-step guide for cross-compiling tools for use on Android devices: 1. Configure Ubuntu (recommended version 9.04) on a separate machine and perform all the below steps on the Ubuntu machine. 2. Download the source code for Android at http://source.android.com/download 3. The source code of Android also includes a prebuilt toolchain with a compiler named arm-eabi-gcc. Include the binary for this compiler in the PATH environment variable. The following command assumes that the android source code is downloaded at $HOME/mydroid. # export PATH=$PATH:$HOME/mydroid/prebuilt/linux-x86/toolchain/armeabi-4.2.1/bin 4. Compile the complete Android source code using instructions given at http://source.android.com/source/download.html. 5. Once the Android source code has been completely built, various flags and tool-chain prefixes have to be set in order to cross compile an application and properly link it to bionic. To do this a perl script written by Andrew Ross can be used. The perl script can be downloaded from http://plausible.org/andy/agcc and should be placed in one of the directories in the PATH variable, e.g. /local/usr/bin. Now the system is ready for cross compiling tools for Android. Below are the steps to compile Nanddump from mtd-utils package. 6. MTD utils are available from MTD utils git at http://git.infradead.org/mtd-utils.git. The easiest way to get them is using gitweb “snapshot feature” (using snapshot link at the latest commit). 7. The file downloaded from the above step is then untarred. After untarring mtd-utils is folder is created under which source code of all tools including Nanddump can be found. # tar -xfz mtd-utils.git-snapshot-20081004.tar.gz 24 8. The C file nanddump.c inside mtd-utils directory can then be compiled using the following command. # agcc –o nanddump nanddump.c # arm-eabi-strip nanddump 9. The Nanddump executable can then be checked using “file” command to see if it has been compiled properly. # file nanddump Nanddump: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped 10. The Nanddump file created can then be put on the device to extract the contents of the NAND flash. 3.8 Rooting Android End-users do not have direct access to the file systems on the NAND chip. This can be a significant hindrance to the forensic investigation. It presents serious challenges to forensic investigators when they are unable to image these file systems for further investigation. A way to get around this is “Rooting”, which essentially means gaining “root” (administrator) access on the phone. It’s the equivalent of running programs as administrator in Windows, or running a command with “sudo” in Linux. Apart from direct access to file systems there are various other reasons why people choose to root their Android phones. Rooting an Android device is much like jailbreaking an iPhone. Once rooted the end user can, for example, increase the speed of the phone (through custom ROMs and overclocking), tether and install apps and widgets from the builds for other Android devices. Rooting an Android device generally involves accessing the bootloader and entering into recovery mode. The recovery mode is then used to flash custom recovery ROM images that exploit bugs in the internal Android code to gain root access. This essentially means contamination of evidence and forensic investigators should take a great deal of care while performing this step. The most popular custom ROM image is CyanogenMod image (Cyanogen). CyanogenMod is a customized, Aftermarket Firmware distribution for the popular Android phones. CyanogenMod is designed to increase performance and reliability over Android-based ROMs released by vendors and carriers such as HTC. CyanogenMod also offers features not found in these releases, such as FLAC Lossless Audio and multi-touch support. 25 4 Understanding the Nexus One The Nexus One was launched by Google on January 5, 2010. This phone is manufactured by HTC Corporation and it uses the Android open source mobile operating system. 4.1 Specifications Following is the list of technical specifications as given by Google in the Nexus One manual sheet. Physical Dimensions • • • • Height: 119mm Width: 59.8mm Depth: 11.5mm Weight: 130g with battery; 100g without battery Processor • Qualcomm QSD 8250, 1 GHz Storage • • • • Flash memory: 512MB RAM: 512MB microSD card: 4GB microSD card included (expandable to 32GB) Display • • • • 3.7-inch (diagonal) widescreen WVGA AMOLED touchscreen 800 x 480 pixels 100,000:1 typical contrast ratio 1ms typical response rate Power and Battery • • • • • • • • • • Removable 1400mAH battery Charges at 480mA from USB, at 980mA from supplied charger Talk time on 2G networks: up to 10 hours Talk time on 3G networks: up to 7 hours Standby time on 2G networks: up to 290 hours Standby time on 3G networks: up to 250 hours Internet use on 3G networks: up to 5 hours Internet use via Wi-Fi: up to 6.5 hours Video playback: up to 7 hours Audio playback: up to 20 hours 26 Cellular and Wireless • • • • • • • • • • • • • Nexus One GSM phones compatible with 3G mobile networks from AT&T (U.S.) and Rogers Wireless (Canada): 3G UMTS bands I/II/V: 2100, 1900, 850 MHz Nexus One GSM phones compatible with 3G mobile networks from T-Mobile (U.S.): 3G UMTS bands I/IV/VIII: 2100, 1700(AWS), 900 MHz All Nexus One GSM phones: HSDPA 7.2Mbps HSUPA 2Mbps GSM/EDGE 850, 900, 1800, 1900 MHz Wi-Fi 802.11b/g Bluetooth 2.1 + EDR A2DP stereo Bluetooth External buttons and Controls • • • • • • Physical Power button Physical Volume Up / Down button Tricolor, clickable trackball 4 illuminated soft buttons (Back , Menu , Home , Search ) Haptic feedback Connectors, Sensors, indicators and audio • • • • • • • • • • • • • Dock pins 3.5mm, 4-conductor, stereo headset jack SIM card slot microSD card slot Micro USB port Proximity sensor Ambient light sensor Tricolor LED next to earpiece for battery charge status Tricolor LED in Trackball for notifications Earpiece Speaker Microphone Second microphone for active noise cancellation Location • • • • Assisted global positioning system (AGPS) receiver Cell tower and Wi-Fi positioning Digital compass Accelerometer Platform • Android mobile technology platform 2.1 (Eclair) 27 • • • • • • • • 5 megapixels Autofocus from 6cm to infinity 2X digital zoom LED flash User can include location of photos from phone’s AGPS receiver Video captured at 720x480 pixels at 20 frames per second or higher, depending on lighting conditions • • • • AAC LC/LTP, HE-AACv1 (AAC+), HE-AACv2 (enhanced AAC+) Monso/stereo standard bit rates up to 160kbps and sampling rates from 8kHz to 48kHz AMR-NB 4.75-12.2kbps sampled @ 8kHz AMR-WB 9 rates from 6.60kbit/s to 23.85kbit/s sampled @ 16kHz MP3 mono/stereo 8-320Kbps constant bit rate (CBR) or variable bit rate (VBR) MIDI SMF (Type 0 and 1), DLS Version 1 and 2, XMF/Mobile XMF, RTTTL/RTX, OTA, iMelody Ogg Vorbis WAVE (8-bit and 16-bit PCM) • AMR-NB 4.75-2.2kbps sampled @ 8kHz Image Formats • • • • JPEG (encode and decode) GIF PNG BMP Video Decoders • • • H.263 MPEG-4 SP H.264 AVC Video Encoders • • H.263 MPEG-4 SP Camera and Flash Audio Decoders Audio Encoders • • • • • • • Table 4-1: List of Specifications of Nexus One (Google, 2010) 28 4.2 Bootloader on Nexus One There are two types of Google Nexus One devices: 1. Retail Version which is bought from Google Web Store or other Service Providers like Vodafone in UK. 2. Google’s holiday gift to its employees. The retail version comes with its bootloader locked but can be unlocked using fastboot tool. It should be noted that unlike Apple, Google allows you to unlock the bootloader for your phone. However, Google also warns that the warranty on the phone would be void if you Figure 4-1: Unlocking Nexus One Bootloader unlock the bootloader. 4.3 Rooting Nexus One As previously stated, a forensic investigator might have to root Nexus One to get access to the NAND file systems for some important pieces of data. However, rooting Nexus One involves unlocking its bootloader that also leads to a factory data reset. Hence, in order to root the Nexus One, its bootloader should first be unlocked. This step wipes all the user data on the phone including contacts and SMS. Only then a custom ROM image can be flashed to gain root access on the phone. Any forensic investigator thinking about rooting this device should be very careful while taking such a step and be ready to bear the consequences. 4.4 Test Nexus One Nexus One, running on Froyo FRF91 version and not rooted was used for the forensic analysis in this project. The phone was used with some moderate activities including: 1. Call, SMS, Contacts, and Calendar. 2. Gmail, Gtalk and Google Maps. 3. Web Browsing 4. Facebook and Twitter applications. 5. Android Market. 6. Wi-Fi network access 7. Images captured using camera. 8. Songs copied from Windows machine. 29 5 Forensic Techniques for Acquisition & Analysis All Android phones, including Nexus One, have different memory areas such as flash memory for RAM and ROM and external SD card. The flash memory systems are formatted with a YAFFS2 file system whereas the SD card is formatted with a FAT32 file system. Thus different forensic techniques have to be used for each memory storage type. The SD card should be removed from the phone and forensically analyzed. Since the SD card is formatted as FAT32, traditional investigation techniques should suffice. Some Android phones may have backups that hold a varying degree of data. If the device has been rooted then applications like Nandroid and Titanium Backup can provide very thorough backups. Some other applications on the Android Marketplace can also allow user to backup some of their application data including SMS and Contacts. Several commercial tools also support Android. Paraben Device Seizure will be used to review the approach used by the software and accuracy of the data it can retrieve. Next, experiments to acquire the YAFFS2 image of flash memory in the RAM will be performed. Prior to Android, use of the YAFFS2 file system was very limited. Hence there are not many forensic tools that support the YAFFS2 file system. The access to flash memory would require root access and hence the plan is to root a Nexus One at one stage. Rooting a Nexus One needs bootloader to be unlocked which wipes the user data. It is still not known if this action actually wipes the data or just de-allocates it from the file system. Hence one of the objectives of rooting the device would be to acquire the raw image and see if any remnants of the data exist. The raw images can be analyzed using Foremost/Scalpel (Foremost; Scalpel) for files like html, mp3 etc. After the above analysis the phone would again be setup to acquire the YAFFS2 file system images. Since the device would already be rooted unlocking bootloader would not be required and hence user data would not be wiped. This would be a good opportunity to analyze the live file system more closely. 30 6 Paraben Device Seizure Paraben’s Device Seizure (DS) is a Cell Phone Forensics tool that enables forensic examiners to acquire and analyze data from over 2,200 types of mobile phone - including iPhone (2G, 3G and 3GS) - PDAs, and GPS devices. Paraben Device Seizure is designed to support the full acquisition and investigation process. The DS software allows an investigator to perform the acquisition, view data in various formats (ASCII, Hex, file and data viewers, etc.), bookmark important data, export data and run various reports. The package also supports acquisition and analysis of GSM SIM Cards with the use of SIM card reader. However, the SIM card reader is not provided with the DS software, but is a part of another enhanced package called Device Seizure Toolbox. Paraben stresses their ability to perform physical acquisition vs. logical ones as it provides the ability to recover deleted files and other important information. However, Paraben currently has very limited support for Android based mobile phones. It supports only logical acquisition for Android phones and is only able to extract the following pieces of data: 1. Device Properties 2. Call History 3. Contacts 4. Messages 5. Browser History 6. File System 7. Media Store 31 6.1 Installation Paraben Corporation kindly provided me with Device Seizure v4.0 software license key to activate it. Another option of activation using Dongle is also available. A trial version can also be downloaded from their website which would give 30 day trial period and 23 executions. The installation package automatically installs drivers for most mobile phones. However, drivers for Android phones have to be manually downloaded and installed. These drivers are provided by Paraben on their website at http://support.paraben.com/drivers.html It should be noted that the license key version of DS software cannot be installed in a VMware environment. A dongle version would be needed in order to install Paraben Device Seizure in a VMware environment. Figure 6-1: Installation of Paraben Device Seizure 32 6.2 Acquisition Phase After the smooth installation, it was time to start the acquisition of data from the phone. A new case was created using screen shown as below: Figure 6-2: Paraben Device Seizure Welcome Wizard 33 The first dialog box allows examiners to enter the case information Figure 6-3: Paraben Device Seizure Case Information Wizard 34 The next dialog box allows specifying information about the examiner. Figure 6-4: Entering Information about the Examiner After the case information is entered, a confirmation dialog box showing all the information is presented. The Create Case wizard finishes after the summary of information is confirmed. Data from the phone can now be retrieved using Data Acquisition option from Tools menu. 35 The software displayed all the models it can support. For some of the devices logical and physical acquisition were supported. However, only logical acquisition is currently supported for Android. Figure 6-5: Paraben Device Seizure Acquisition Wizard After selecting the phone type, the connection type dialog box came up blank with no instructions. The phone was not connected to the system as of now because an explicit screen asking investigators to connect the phone was expected. The blank screen also did not show any type of error. Hence the acquisition wizard was started again and this time the phone was already connected. The connection type screen again showed blank. The reason for this was that the “USB Debugging” feature on the phone was not enabled. It would have been nice to see these steps outlined in the software rather than just a blank screen. 36 However after enabling the USB Debugging mode DS correctly detected the phone type with the serial number. Figure 6-6: Connection Selection Screen 37 The next step provided all the potential data that DS can acquire. This even included Browser History and Media Store along with other common data like Call history, Contacts, SMS etc. Figure 6-7: List of Data Types to be acquired 38 At the next step, all the additional information is seen. This information contains steps that should be followed on Android phones to get them working with Device Seizure. Figure 6-8: Additional Information for Android Phones It would have been very helpful if this information had been provided in the previous steps when the device type was selected as “Android (logical)”. 39 Finally the acquisition takes place and acquiring file system took most of the time. Figure 6-9: File System Acquisition The whole process of acquisition and saving the case took around one hour to complete. 40 After the case is saved, results for acquisition of each data type were shown if they were successful or not. Figure 6-10: Acquisition Results 41 6.3 Results Paraben Device Seizure did a good job in extracting the data from the phone. After the extraction is done a nice user interface was presented. This screen includes the details of acquired elements in the left pane. The bottom left pane shows properties of acquired data like phone information. It also shows the properties of the phone which includes the kernel version, CPU info and firmware id along with IMEI and other information. Figure 6-11: Device Seizure Analysis Screen On the right side there was a large area to view acquired data with appropriate viewer for each data type. For instance, the SQLite databases were presented in a Grid Format whereas there were different viewers for displaying pictures or Calendar data. 42 6.3.1 Contacts Device Seizure retrieved all contacts including people in Gtalk chat list. However, the twitter contacts were not extracted. The contact data also included pictures for which they existed. The results also contained the date a particular contact was last contacted and number of times a particular contact was contacted. Figure 6-12: Analyzing Retrieved Contacts 43 6.3.2 SMS & MMS History SMS and MMS history was also successfully retrieved except for deleted messages. The acquired data included whether the messages were read and also the service centre number through which the messages were sent Figure 6--13: Analyzing Retrieved SMS and MMS 6.3.3 Call History The software was also able to extract call history details giving the details for each call about the type (missed, outgoing or incoming). Figure 6-14: 6 Analyzing Retrieved Call History 44 6.3.4 Other Data Other types of data that were extracted included Browser history (links visited, bookmarks, search history), Media files System Settings and other files. Device Seizure was not able to extract files that needed root access e.g. files under /data/ directory. Several images from the cache were also retrieved. These images included images of albums from Amazon mp3 application and thumbnails of various deleted images. However the DS Software was not able to extract any calendar data that existed on the phone. 6.3.5 Sort & Search Sorter was another good feature provided by DS. It sorted the acquired data according to the data types such as graphics, multimedia, spreadsheets, etc. Search functionality was also built in and was quite sophisticated with options to search filenames, text and hex. The results were easy to interpret and simple to analyze. Figure 6-15: Sort & Search functionality 45 6.4 Reporting The report wizard gave various options for reporting such as CSV, HTML, PDF, text and excel format. The HTML investigative report just presented limited data like Contacts, SMS, Call History, Image results and Phone settings whereas the excel sheet format gave a more exhaustive report with details of all the acquired data. 6.5 Examination of Nexus One after “Clear Storage” A case of clearing the user data from the device is considered to see if any data can be gathered. There are various options to wipe the data from the phone. They are as follows: • Clear Storage from bootloader. • Wipe Data/Factory Reset from Recovery mode. • Wipe Cache partition from Recovery mode. When the data was wiped using one of these methods, Paraben was not able to acquire any deleted data. With user being just two clicks away from such options, it is highly probable that we would get to see many such cases of data being wiped off before it is seized. Hence further study would be an attempt to take a physical dump of the phone and analyze what data can be retrieved. 6.6 Summary Overall, Paraben Device Seizure did a good job in acquiring the important pieces of data like Contacts, SMS and MMS history, Browser history and Media files from the phone as long as the data is not deleted. That being said, it is possible to recover the thumbnails of deleted images from the cache. However, if the user has wiped all the user data using the options in bootloader or recovery mode, Paraben cannot recover any data. Paraben Device Seizure also gives options for case management like sophisticated search function and good reporting facilities. It would be good to see physical dump option for Android phones so that even deleted data can be recovered. 46 7 Rooting Nexus One Please note that this chapter assumes that the external SD card present in the phone has already been kept separate from the phone. Forensic investigation of the existing SD card can be done using conventional FAT32 analysis techniques. To proceed with the methods involved in this chapter, a new forensically wiped SD Card should be used. The minimum recommended memory size for the new SD card is 4 GB. As explained in previous chapter, physical dump or raw image of the NAND memory may be necessary to retrieve data when the user has deleted data or has used factory data reset options in bootloader or recovery mode. However, access to this memory can only be obtained if we have root access on the phone. Currently, the only way to obtain root access is to flash a custom ROM on Android. However, a pre-requisite to flash a custom ROM image is having an unlocked bootloader on Nexus One. It should be noted that unlocking bootloader was found to securely wipe all of the user data on the phone making any recovery impossible. Hence this method should not be used for forensic analysis. 7.1 Unlocking Bootloader on Nexus One The OEM Nexus One which Google gifted to it employees came with an unlocked bootloader. However the retail Nexus One which can be bought from Google Web Store or service providers like Vodafone in UK has a bootloader that is locked. The bootloader on retail Nexus One can be unlocked using fastboot tool. The steps to unlock the bootloader on Nexus One are: 1. Install the Android SDK on your forensic workstation. 2. Download and extract fastboot-windows.exe from http://www.romraid.com/paul/fastboot.zip and extract it in tools directory of android sdk. 3. Enable USB debugging mode on the phone. This can be done by going into Settings ApplicationDevelopment on the phone. 4. Connect the phone to the forensic workstation. 47 Figure 7-1: Unlocking Bootloader on Nexus One 5. Shut down the phone. 6. Power on the phone whilst holding the trackball to enter fastboot mode. 7. Run Command prompt in C:\android-sdk-windows\tools C: tools directory on your forensic workstation. 8. Type fastboot-windows.exe windows.exe oem unlock in the command prompt. C:\android-sdk-windows windows\tools>fastboot-windows.exe windows.exe oem unlock ... INFOErasing userdata... FAILED (status read failed (Too many links)) 9. On the phone a confirmation screen would appear asking if you want to unlock your bootloader to load custom OS. It also notifies that this step voids the warranty of the device and also deletes all personal data from the phone. 10. Use Volume up/down key to make the selection and press Power button to continue. cont 11. After rebooting the splash screen would show you an unlocked sign as shown below indicating an unlocked bootloader: Figure 7-2: Locked Bootloader to Unlocked Bootloader ootloader 7.2 Backups Using sing Nandroid The first st step after achieving unlocked bootloader is to create logical backups of NAND file systems. Unlocking bootloader clears the /data and /cache partition so there is nothing much that can be retrieved. But it is always a good idea to create backups whenever wheneve possible. Also the /system partition contains important application and system files which make them important for backing up. For creating nandroid backup we use Amon_Ra recovery image. This is the replacement image for Android Recovery mode. The Amon_Ra Amon_Ra recovery image is flashed on the recovery partition of the phone using fastboot. The Amon_Ra recovery image also provides additional 48 functionalities which can be found at http://forum.xda- developers.com/showthread.php?t=611829 . The latest recovery image can also be found at this page. 7.2.1 Flashing Amon_Ra Recovery Image The following steps are performed to flash the Amon_Ra recovery image on the Nexus One: 1. Copy the Recovery image to the tools subdirectory of the Android SDK on the forensic workstation so that fastboot can easily find it. 2. Boot the phone into fastboot mode by holding the trackball button while powering on. 3. Check that the fastboot detects your phone. C:\android-sdk-windows\tools>fastboot devices HT9CXP812291 fastboot 4. Flash the Amon_Ra recovery image on the recovery partition of the phone using fastboot C:\android-sdk-windows\tools>fastboot.exe flash recovery recovery-RAnexus-v1.7.0.1.img sending 'recovery' (3948 KB)... OKAY [ 0.580s] writing 'recovery'... OKAY [ 1.347s] finished. total time: 1.929s 5. Reboot the phone again into fastboot mode by holding the trackball button while it is booting. Select bootloader from the menu and then choose recovery on the second screen. The phone will now reboot into Amon_Ra recovery image. 7.2.2 Performing Nandroid Backups Using Amon_Ra Recovery After the phone has booted into Amon_Ra recovery image, the next step is to perform Nandroid backups of the NAND filesystems. However, the Amon_Ra is unable to take the backup of the following partitions: • Recovery (to avoid restoring old version). • Misc (no need to backup imo + restore issues on some phones). • Splash1+2 (no need to backup imo + restore issues on some phones). The above partitions do not contain any user data and hence not very important from investigation point of view. 49 Figure 7-3: Amon_Ra Recovery Mode To proceed with performing backups of the remaining partitions, steps are followed as below: • Choose Backup/Restore option using trackball. • Choose NAND backup and press trackball to confirm. • After the backups are complete, press VOL-DOWN button to go to the main menu and choose last option to power off the phone. The backup images are saved on SD card in the nandroid folder. This folder contains subfolders for each device from which the backup was done. The device folder contains folders for each time the backups were taken. The name of every folder is time coded and the name convention is “BCDS-yyyymmdd-hhmm”. For example if the SD card contains the backup images at M:\nandroid\HT9CXP812291\BCDS-2010722-0443, it would mean that this backup is of the device with serial number HT9CXP812291 and was taken on July 22, 2010 at 04 hours and 43 minutes. 7.3 Making Custom ROM for Nexus One. Before making a custom ROM, the Android Version and Build number should be checked on the phone. This can be found on the phone by going into Settings About phone. The test Nexus One used for this project came with Android version 2.1 and Build number ERE27. However, after release of Android Version 2.2, Google rolled out an update which updated the firmware to Android version 2.2 and Build number FRF91. A famous tool called HTC Android Kitchen developed by dsixda (xda-developers.com) can be used to make Custom ROM for Nexus One. This process of modifying or customizing an existing ROM is also known as “ROM cooking”. HTC Android Kitchen works on Ubuntu and it also needs Java6 Bin and Java6 JRE package installed. Latest version of kitchen can be downloaded from http://android.grdlock.net/index.php?&direction=0&order=&directory=ROM%20Kitchens . The zip file downloaded from the above link should be extracted and “menu” file should be run from the terminal. This will give you a nice text based interface. 50 After the Android Kitchen is successfully installed, following steps are done: 1. A total stock ROM is downloaded from http://developer.htc.com/. A total stock ROM is the original unmodified ROM that is shipped with the phone. These ROMS are supplied by manufacturers like HTC without any changes or customization. There are stock images for most build versions. Normally these files are of size 60-70 MB. Alternatively the complete ROM can be built by compiling the Android Source Kernel. However, this is out of the scope of this project. 2. Since the phone was running FRF91 build, Nexus One FRF91 system image was downloaded from above website for this project. 3. The zip package downloaded is now placed in original_update directory of Android Kitchen and option 1 “Set Working Folder from ROM” is selected. The zip package is processed and if everything is in order, the Working Folder information is shown at the end. Figure 7-4: Android Kitchen 4. After the working folder is set, Root permissions should be added to the ROM folder by choosing option 2. 5. A new ROM image with root permissions is now built using option 99 from the menu. This creates a signed zip package in the folder OUTPUT_ZIP under Android Kitchen folder for flashing. 51 7.4 Flashing boot.img to get Root. The new zip package contains new boot image, recovery images, and typically replacements for the entire system/ directory as well as other updates. In order to make minimal changes on the system the boot.img would be extracted from the custom ROM and flashed on the device. This would ensure that the system and the data partition on the device are unmodified. To do this the signed zip package created from the process outlined in section 7.3 is extracted and the boot.img file is copied to the “android-sdk-windows\tools” directory. The following steps then flash boot.img on Nexus One. 1. Reboot the device into bootloader mode by holding the trackball button. 2. Connect the device on forensic workstation and ensure it is detected. Bootloader will display “FASTBOOT USB” instead of just “FASTBOOT” to indicate USB connection. 3. To flash the boot.img the fastboot tool on forensic workstation is used again. The following command should be typed for flashing the boot partition with the boot image. C:\android-sdk-windows\tools>fastboot-windows.exe flash boot boot.img sending 'boot' (2336 KB)... OKAY writing 'boot'... OKAY 4. Once the new boot image is flashed, the phone is rebooted for new boot image to take action. 5. To confirm that the root permissions have been achieved, “adb shell” should be executed. If the root access is achieved, # prompt is received instead of usual $ prompt. 7.5 Installing BusyBox & Nanddump BusyBox is also known as the Swiss army knife of embedded Linux. BusyBox is a single multicall binary that packages the functionality of many popular standard UNIX tools. BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. Nanddump is a part of MTD-Utils toolkit. Nanddump can be used to read the contents of NAND file systems like YAFFS2 and JFFS. 52 BusyBox and Nanddump will be installed on the /system partition to avoid any contamination of evidence on the /data and /cache partitions. The following are the steps to install BusyBox and Nanddump on a rooted Android device 1. BusyBox binary can be downloaded from the following location: http://benno.id.au/android/busybox. Alternatively the source code can be downloaded from www.busybox.net and compiled using guide at http://omappedia.org/wiki/Android_Getting_Started#Installing_Busybox_Command_ Line_Tools_.28Optional.29 . 2. Place the binary in tools subdirectory of Android SDK. 3. Nanddump binary can be compiled on Ubuntu workstation using steps detailed in section 3.7 Cross Compiling Tools for Android. 4. Connect the device and start the adb shell. 5. The /system mount has to be made Read/Write so that installation can be done. C:\android-sdk-windows\tools>adb shell # mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system # exit exit 6. Copy BusyBox binary to the device. C:\android-sdk-windows\tools>adb push busybox /system/bin 1231 KB/s (1745016 bytes in 1.384s) C:\android-sdk-windows\tools>adb push nanddump /system/bin 457 KB/s (14052 bytes in 0.030s) 7. Open the adb shell again and setup and install BusyBox with following commands. Some warnings might appear complaining about missing files and directories. These warnings should be ignored. C:\android-sdk-windows\tools>adb shell # cd /system/bin cd /system/bin # chmod 0755 ./busybox chmod 0755 ./busybox # chmod 0755 ./nanddump chmod 0755 ./nanddump # busybox --install 8. Mount the /system file system again into read only mode. # mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system 9. Busybox and Nanddump are now ready for use. 53 8 Memory Acquisition from Rooted Nexus One At this point root access on Nexus One has been achieved and busybox has been installed on system partition in order to get useful UNIX utilities on the phone. Logical backups of the NAND file systems: boot, system, data and cache have been created using the Nandroid backup utility from Amon_Ra recovery image. However, logical backups can be insufficient when deleted data has to be recovered. In this chapter techniques to acquire raw images of NAND flash memory will be demonstrated. Once the raw memory is acquired data carving tools can be used for validating files and also for recovering deleted files. The NAND file systems will be imaged using /dev/mtd/mtdXro interface that is created by Android OS. Android also provides two binaries under /system/bin that can be used for imaging in additon to the Nanddump just installed. These are: • Dd. • Nandread. • Nanddump. The md5sum applet of busybox would be used to calculate md5 hashes of the image in order to verify the authenticity of the acquired images at a later stage. Before starting the acquisition it is advisable to mount /cache file system in read-only mode using the following command. # mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /cache mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /cache The /system partition is in read-only mode by default and /data partition cannot be made read-only since it is always busy. The status of each of the file systems can be confirmed using mount command as follows: # mount mount … /dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0 /dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0 /dev/block/mtdblock4 /cache yaffs2 ro,relatime 0 0 … 54 Even if the /data partition is always busy, the above commands do not disturb the integrity of the contents in the data partition. This was verified by the small test-case which is as follows: # busybox md5sum /dev/mtd/mtd5ro 6af8570cdd4a54a6c725a37616cb83a5 /dev/mtd/mtd5ro # mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /cache # busybox md5sum /dev/mtd/mtd5ro 6af8570cdd4a54a6c725a37616cb83a5 /dev/mtd/mtd5ro # mount … /dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0 /dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0 /dev/block/mtdblock4 /cache yaffs2 ro,relatime 0 0 … # busybox md5sum /dev/mtd/mtd5ro busybox md5sum /dev/mtd/mtd5ro 6af8570cdd4a54a6c725a37616cb83a5 /dev/mtd/mtd5ro The file systems should be imaged in the following order: 1. /data 2. /cache 3. /system 8.1 Dd/cat Method Following steps should be followed for imaging the file systems using Dd utility: 1. Calculate the md5 hash for /data partition. # busybox md5sum /dev/mtd/mtd5ro busybox md5sum /dev/mtd/mtd5ro fa47435129b671287718b5c5546f43cb /dev/mtd/mtd5ro 2. Use the Dd utility to image the /data partition. # dd if=/dev/mtd/mtd5ro of=/sdcard/mtd5ro.dd bs=4096 dd if=/dev/mtd/mtd5ro of=/sdcard/mtd5ro.dd bs=4096 50240+0 records in 50240+0 records out 205783040 bytes transferred in 57.648 secs (3569647 bytes/sec) 3. “cat” command can also be used to image the /data partition. # cat /dev/mtd/mtd5ro > /sdcard/mtd5ro.img cat /dev/mtd/mtd5ro > /sdcard/mtd5ro.img 55 4. Verify the authenticity of images by calculating the values of md5 hash of the acquired images. # busybox md5sum /sdcard/mtd5ro.dd busybox md5sum /sdcard/mtd5ro.dd fa47435129b671287718b5c5546f43cb /sdcard/mtd5ro.dd # busybox md5sum /sdcard/mtd5ro.img busybox md5sum /sdcard/mtd5ro.img fa47435129b671287718b5c5546f43cb /sdcard/mtd5ro.img The other partitions /cache and /system can be acquired in the same way. Typically, /cache is mapped to /dev/mtd/mtd4ro and /system is mapped to /dev/mtd/mtd3ro. This can be confirmed using the “mount” command on the device. 8.2 Nandread Method “Nandread” is another tool that can be used to image NAND file systems on Android. Following are the steps for acquiring the image of /data using the Nandread utility in Android: 1. Calculate the md5 hash for /data partition. # busybox md5sum /dev/mtd/mtd5ro fa47435129b671287718b5c5546f43cb /dev/mtd/mtd5ro 2. Use the Nandread utility to image the /data partition. # nandread -d /dev/mtd/mtd5ro -f /sdcard/mtd5ro.nand -v nandread -d /dev/mtd/mtd5ro -f /sdcard/mtd5ro.nandread -v size: 205783040 erase size: 131072 write size: 2048 oob size: 64 ecc bytes: 40 oobavail: 16 initial ecc corrected: 0 initial ecc failed: 0 initial ecc badblocks: 0 initial ecc bbtblocks: 0 total ecc corrected, 0 total ecc failed, 0 total ecc badblocks, 0 total ecc bbtblocks, 0 read 100480 pages, 1281 empty 3. Calculate the md5sum of the data partition again. # busybox md5sum /dev/mtd/mtd5ro cf7437b9105e0565b370eace8a65ea47 /dev/mtd/mtd5ro 56 4. Calculate the md5sum of the image acquired. # busybox md5sum /sdcard/mtd5ro.nand 6069ab8e64e051cb5b46f09005156b70 /sdcard/mtd5ro.nand The other partitions /cache and /system can be acquired in the same way. Typically, /cache is mapped to /dev/mtd/mtd4ro and /system is mapped to /dev/mtd/mtd3ro. This can be confirmed using “mount” command on the device. Two things should be noticed in the above procedure: • Md5sum of /dev/mtd/mtd5ro after the Nandread operation and md5sum of /dev/mtd/mtd5ro before the operation are not identical. Hence the /data partition in some way gets modified during Nandread operation. This may or may not be due to the Nandread operation itself. Other operations may also be responsible for modification of /data partition. This cannot be avoided since /data partition cannot be made read-only. However, to be on safe side Nandread operation should only be performed after Dd operation because it has been seen that /data partition is not modified during Dd operation. • Md5sum of the image acquired by Nandread and md5sum of the /dev/mtd/mtd5ro are not identical. Section 8.4 explains why the image turns out to be different. 8.3 Nanddump Method “Nanddump” tool is a part of MTD utils package. This tool, like the Nandread utility, can be used to image NAND flash file system. Here are the steps for acquiring the image of /data using Nanddump: 1. Calculate the md5 hash for /data partition. # busybox md5sum /dev/mtd/mtd5ro busybox md5sum /dev/mtd/mtd5ro 29c15e063c31a832e630de0a0897a3a3 /dev/mtd/mtd5ro 2. Use the Nanddump utility to image the /data partition. # nanddump -f /sdcard/mtd5ro.nanddump /dev/mtd/mtd5ro ECC failed: 0 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 64 Dumping data starting at 0x00000000 and ending at 0x0c440000... 57 3. Calculate the md5sum of the data partition again. # busybox md5sum /dev/mtd/mtd5ro busybox md5sum /dev/mtd/mtd5ro 9c539614846ea109086ca7061d3377e3 /dev/mtd/mtd5ro 4. Calculate the md5sum of the image acquired. # busybox md5sum /sdcard/mtd5ro.nanddump busybox md5sum /sdcard/mtd5ro.nanddump 3fd5e53d8cf9e674ce70ae3287ced202 /sdcard/mtd5ro.nanddump The other partitions /cache and /system can be acquired in the same way. Typically, /cache is mapped to /dev/mtd/mtd4ro and /system is mapped to /dev/mtd/mtd3ro. This can be confirmed using the “mount” command on the device. Two things should be noticed in the above procedure: • Md5sum of /dev/mtd/mtd5ro after the Nanddump operation and md5sum of /dev/mtd/mtd5ro before the operation are not identical. Hence the /data partition in some way gets modified during Nanddump operation. This may or may not be due to the Nanddump operation itself. Other operations may also be responsible for modification of /data partition. This cannot be avoided since /data partition cannot be made read-only. However, to be on safe side Nanddump operation should only be performed after Dd operation because it has been seen that /data partition is not modified during Dd operation. • Md5sum of the image acquired by Nanddump and md5sum of the /dev/mtd/mtd5ro are not identical. Section 8.4 explains why the image turns out to be different. 58 8.4 Comparison of Dd, Nandread, & Nanddump Images When the Dd, Nandread and Nanddump images were compared with the help of md5 hashes, they turned out to be different. # busybox md5sum /sdcard/mtd5ro.dd busybox md5sum /sdcard/mtd5ro.dd 35f389fcf21e9624b63fa552f277b62a /sdcard/mtd5ro.dd # busybox md5sum /sdcard/mtd5ro.nandread busybox md5sum /sdcard/mtd5ro.nandread 6fc645e9e427f4952e6406a0db83a10b /sdcard/mtd5ro.nandread # busybox md5sum /sdcard/mtd5ro.nanddump busybox md5sum /sdcard/mtd5ro.nanddump 66e30bf4ced0a8c7b2e00a35cbec83bd /sdcard/mtd5ro.nanddump Further investigation also showed that size of images acquired by Nandread and Nanddump tools was bigger than the size of the image acquired by Dd utility. M:\>dir mtd5ro* Volume in drive M is PHONE CARD Volume Serial Number is 9CA3-2C07 Directory of M:\ 07/27/2010 02:44 AM 212,213,760 mtd5ro.nanddump 07/27/2010 02:38 AM 212,213,760 mtd5ro.nandread 07/27/2010 02:33 AM 205,783,040 mtd5ro.Dd 3 File(s) 630,210,560 bytes 0 Dir(s) 6,506,463,232 bytes free 8.4.1 Dd Image smaller than Nandread/Nanddump Images. Are we missing something? To debug this issue, the source code of Dd, Nandread and Nanddump was inspected. After deep inspection it was found that the Dd utility does not capture the OOB (Out Of Band) bytes that exist in the YAFFS2 file system. However, Nandread and Nanddump capture these OOB bytes in the file system. Nanddump even has an option of omitting OOB bytes during imaging. This option is “-o Omit OOB data”. To demonstrate this fact, a small experiment was done to capture just 4096 bytes of the filesystem using Nandread and Dd utilities. The experiment was as follows: 1. Dd tool was used to capture 4096 bytes of /data partition. # dd if=/dev/mtd/mtd5ro of=/sdcard/mtd5ro.dd bs=4096 count=1 dd if=/dev/mtd/mtd5ro of=/sdcard/mtd5ro.dd bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes transferred in 0.002 secs (2048000 bytes/sec) 59 2. 4096 bytes of /data partition were captured using Nandread. This time Nandread utility was executed with most verbose output. The verbose output hence showed the OOB bytes existing in the 4096 bytes of total data. # nandread -d /dev/mtd/mtd5ro -f /sdcard/mtd5ro.nand -L 4096 -vvv nandread -d /dev/mtd/mtd5ro -f /sdcard/mtd5ro.nand -L 4096 -vvv size: 205783040 erase size: 131072 write size: 2048 oob size: 64 ecc bytes: 40 oobavail: 16 initial ecc corrected: 0 initial ecc failed: 0 initial ecc badblocks: 0 initial ecc bbtblocks: 0 page at 0 (56 oobbytes): 00001672 10000286 800001e3 00000096 ffffffff ffffffff ffffffff ffffffff page at 800 (56 oobbytes): 00001672 30000159 80000110 00000000 ffffffff ffffffff ffffffff ffffffff total ecc corrected, 0 total ecc failed, 0 total ecc badblocks, 0 total ecc bbtblocks, 0 read 2 pages, 0 empty 3. A Nanddump image was also created for the same 4096 bytes of /data. # nanddump -f /sdcard/mtd5ro.nanddump -l 4096 /dev/mtd/mtd5ro nanddump -f /sdcard/mtd5ro.nanddump -l 4096 /dev/mtd/mtd5ro ECC failed: 0 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 64 Dumping data starting at 0x00000000 and ending at 0x00001000... 4. The md5sum of the images acquired by Dd, Nandread and Nanddump utilities were compared. As expected the results were different. # busybox md5sum /sdcard/mtd5ro.dd f4beb4af13b6f568b6d575df15f2e875 /sdcard/mtd5ro.dd # busybox md5sum /sdcard/mtd5ro.nandread c5cbfe756edb4051faa08c6c28092a60 /sdcard/mtd5ro.nandread # busybox md5sum /sdcard/mtd5ro.nanddump 95163555b14eb011fe3df7dd25438719 /sdcard/mtd5ro.nanddump 5. The file sizes of the images acquired by Dd, Nandread and Nanddump utilities were then compared. As expected, the size of the file captured by Nandread and Nanddump was greater than the size of image made by using Dd. Also, it was found that Dd captured exactly 4,096 bytes as given in the command line arguments. Nandread and 60 Nanddump utilities on the other hand had captured a total of 4,096+64+64=4,224 bytes. M:\>dir mtd5ro* Volume in drive M is PHONE CARD Volume Serial Number is 9CA3-2C07 Directory of M:\ 07/27/2010 03:11 AM 4,224 mtd5ro.nanddump 07/27/2010 03:17 AM 4,224 mtd5ro.nandread 07/27/2010 03:16 AM 4,096 mtd5ro.dd 3 File(s) 12,544 bytes 0 Dir(s) 7,136,657,408 bytes free 6. All the images were then examined in the hex editor and the difference was found at offset 2048 and 2048+64+2048=4160 where the OOB bytes are located. It should be noted that since the Dd image is only 4096 bytes there is no offset of 4160 for file mtd5ro.dd. Figure 8-1: Comparison on Dd, Nandread & Nanddump Raw Images 7. Another useful observation was that the OOB data captured by Nandread and Nanddump were different. At first sight it can be assumed that Nandread is missing some OOB data and is just overwriting it with 0xFF. However, further in-depth analysis of the code and OOB structure of MTD devices would be needed in order to find the root cause of the above behavior. Such analysis is beyond the scope of this project and is proposed as further work. 61 8.4.2 Importance of OOB Data The OOB data is useful when the yaffs2 file system needs to be regenerated. This may be helpful in recovering deleted files logically and parsing the YAFFS2 file system. The OOB bytes are also necessary when the image needs to be mounted on another device or Nandsim emulator on linux. The use of the Nandsim emulator along with other tools for analyzing the acquired images is covered in the next chapter. 62 9 Raw Memory Analysis of Nexus One Before performing any analysis on the memory images care should be taken that the operations in this chapter are only performed on the copy of the images acquired and not on the original images. Some tools can alter the disk image during their operation thereby altering their digest. 9.1 Data Carving using Foremost/Scalpel Data carving tools like Foremost and Scalpel can be used to recover deleted information from the phone. Data Carving is the process of retrieving structured data from an unstructured image. The images acquired using the techniques documented in the previous chapter are unstructured and are just treated as big files by the computer unless they are mounted as a file system. A data carving tool scans the whole disk image and finds traces of desired files, such as images and voicemails, using file signatures that exist in file headers, footers and internal data structures. Foremost is a free open source tool that was originally developed by Special Agents Kris Kendall and Jesse Kornblum of the U.S. Air Force Office of Special Investigations. The latest version of Foremost can be downloaded from http://foremost.sourceforge.net/. Scalpel is a data carving tool that is based on Foremost but is much optimized. Scalpel is file system-independent tool and it will carve files from FATx, NTFS, ext2/3, or raw partitions. Hence this tool can also be used for yaffs2 partitions. Scalpel can be downloaded from http://www.digitalforensicssolutions.com/Scalpel/ . To use the Scalpel tool for data carving it is necessary that the structure of its configuration file is understood. The Scalpel configuration file is named as scalpel.conf. The default configuration file contains data types for several different file formats that examiners can uncomment based on their requirements. Examiners can also add additional headers and footers that identify the beginning and end of the desired data they are interested in. These additional headers might correspond to the proprietary file formats used by Android OS that aren’t present in the default configuration. To edit the default configuration the required file types are uncommented and additional file types are added as required. The format of the Scalpel configuration file is simple and very easy to understand. A single entry consists of five fields: file extension, case sensitivity, default size, header and optional footer. gif y 5000000 \x47\x49\x46\x38\x37\x61 63 \x00\x3b In the above example for a GIF image, the extension being searched for is gif and the pattern is case sensitive since “y” is specified. The next field is the default size that is used when the optional footer is not specified or when it is not found. In this example it is approximately 5MB. This is followed by the header and footer signatures. In this example the header and footer are specified in hexadecimal by using \x prefix but plain text may also be used. Here the byte pattern 4749 4638 3761 marks the beginning of the GIF file. When Scalpel finds the matching header, it will scan the data till the 5MB limit is reached or until the footer 0x003B is found. In no case, more than 5MB of data would be stored in any file that matches the above entry. 9.1.1 Configuring Scalpel for Android In this section, the configuration of scalpel.conf file will be optimized in order to get most of the relevant data using data carving on the images acquired. The important files with respect to Android and their settings are discussed below. 9.1.1.1 SQLite The SQLite databases format is widely used by Android OS to store the most critical data including, but not limited to, contacts, short messages and user dictionary. SQLite database files are generally live on the file system and further experiments would be carried out to see if the deleted SQLite files can be recovered in case the user has done factory reset on the phone. Further analysis of SQLite files such as querying instructions are covered later. db y 1000000 SQLite\x20format 9.1.1.2 AMR The AMR codec is the standard speech codec by 3GPP (3rd Generation Partnership Project). 3GPP is a collaborative standards body involved in mobile communications. The AMR codec yields high quality audio playback for voice content. Most voice mail messages would not exceed a memory size of 65KB. In cases where voicemails of larger size need to be recovered, the default size in the third field can be increased. amr y 65535 #!AMR 9.1.1.3 E-Mail Scanning the email headers is the most effective way to retrieve live and deleted email messages from the device. The NONE keyword is used to search for data without any file extensions. NONE y 1000000 64 From: 9.1.1.4 Web Pages Html pages are easy to carve since they have a definite ending. htm n 50000 <html </html> 9.1.1.5 Images Android OS uses all the three popular image formats GIF, JPG and PNG. These image formats in Scalpel can be enabled by uncommenting the corresponding entry line in the configuration file. In addition to the default formats, the following formats may also used in Android OS. png y 40960 \x89PNG This particular PNG format is used for storing small icons and Google Map tile graphics. jpg y 5000000 \xff\xd8\xff\xe1 \xff\xd9 This particular jpg format is used for storing the images captured with the phone camera. 9.1.1.6 APK Files APK files, the variant of JAR files, are Android package files used for installing various Android applications including those available from the Android market place. The “?” below indicates wild card character. apk y 5000000 \x50\x4B\x03\x04\x14 x61\x72\x73\x63??\x50\x4B\x05 9.1.1.7 Other Files In cases where a file of format other than those listed above needs to be recovered a new rule should be built to carve it out. The following are some of the methods that can be helpful when building new rules: 1. Use online resources to identify the required file format. 2. Assemble a list of possible file headers. Use all information that can be found about the file format to assemble a list of file headers that could have been used in the file you're searching for. 3. Recreate the file structure using the same software or equipment, if possible. In most cases, the first few bytes of the file header will be the same regardless of the file's contents. If you're trying to track down a file saved by a digital camera, video recorder, or other equipment, reproduce the steps to create another similar file, and examine its header. 65 9.1.2 Scanning with Scalpel After updating the configuration file, Scalpel can be executed from the command-line. Before using it on the actual images acquired, it might be useful to test the configuration file by running Scalpel to recover known file types. The image acquired by the Dd tool is tried first since the Dd image contains all of the data and the acquisition of Dd image does not change the hash of the file system as shown in the previous chapter. The results showed that there were no amr files stored in /data folder indicating that there were no voicemail messages stored in the data partition on the phone. This might be due to the reason that the SIM card used in the phone was from Orange service provider and Orange saves the voicemail on their network system for seven days with the permission of the user. However, other networks like 3 in Australia do give an option to users for downloading their voicemails. Orange also provides API for web applications that developers can use to enable users to download voicemails in mp3 format. Figure 9-1: Data carving of /data partition using Scalpel 66 The data carving from /cache partition resulted in recovery of some images in jpg and png formats. No other interesting files were found in the cache partition. Figure 9-2: Data carving of /cache partition using Scalpel When the Nanddump images were carved some additional files of sqlite3 format and jpg files were discovered. Additional investigation would be required to check whether they are false positives or contain some deleted data. 9.2 String Dump As a final resort, string dump can be extracted using the Strings tool developed by Mark Russinovich. The Windows version of Strings tool can be found at http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx. D:\forensic softwares>strings.exe e:\mtd5ro.dd > mtd5ro.stringdump The output can be large but it is useful when searching for particular conversations or any other data. Pieces of several deleted SMS, contact details and call logs were recovered using this technique. In the next chapter the logical analysis of the YAFFS2 file-system will be attempted. Also the analysis of some important files like SQLite and camera image files will be undertaken. 67 9.3 Analysis of Image Acquired After Using “Clear Storage” As an experiment raw Dd and Nanddump images were acquired after clearing user storage using the “Clear Storage” option in bootloader. These disk images were then analyzed in the WinHex hex editor and string dump was also taken using strings.exe. However, no remnants of user data were found during analysis. Hence Android uses secure wiping technique to erase user data when clear storage option is used or factory reset is done via recovery mode. This factory reset is also done when the bootloader is unlocked to root the phone. Hence unlocking bootloader and rooting the phone for forensic analysis is not recommended. . If the user has used “Clear Storage” option to wipe off the evidence, backup images can be examined if user has copied them onto an SD card using the Nandroid backup utility. In the next chapter the logical analysis of the YAFFS2 file-system will be tried. Also an analysis of Nandroid backup will be done and some important files like SQLite and camera image files will be explored. 68 10 Logical Memory Analysis of Nexus One As described in the previous chapter, raw images of file-system partitions from the Nexus One were recovered and potentially deleted SMS, contacts, call logs and emails were retrieved using the data carving method and the strings tool. The focus of this chapter will be to logically analyze the YAFFS2 file system images and exploration of some important file formats such as SQLite and image files captured using the camera on a Google Nexus One. 10.1 Dealing with Nanddump Images The YAFFS2 file-system basically contains two types of content: 1. Data contents 2. Meta-data in the form of OOB (Out Of Band). The OOB content is necessary to mount the YAFFS2 file system. Hence for mounting the YAFFS2 file-system, images acquired by Nanddump tool and Nandread tool will be used. 10.1.1 Emulating MTD Devices with Nandsim Emulator The YAFFS2 file system is unlike other conventional file systems and cannot be mounted on normal devices under /dev. It is a NAND flash file-system and hence requires MTD device for mounting. To emulate a MTD device we use the Nandsim tool that is included in the mtd-utils package. The mtd-utils package on Ubuntu can be installed using following command: apurva@ubuntu:~$ sudo apt-get install mtdutils To use Nandsim a script file named load_nandsim.sh is available when mtd-utils source code is downloaded using snapshot link from http://git.infradead.org/mtd-utils.git. 69 Figure 10-1: Nandsim Emulator To emulate an mtd device the kernel modules mtd and mtd block are introduced in the Ubuntu Kernel using the following commands: root@ubuntu:~/Downloads# modprobe mtd root@ubuntu:~/Downloads# modprobe mtdblock After the kernel modules mtd and mtdblock are loaded properly, load_nandsim.sh can be used to invoke Nandsim emulator for creating an mtd device. The Nexus One userdata partition is 196MB in size but this option is not available in the load_nandsim script. Hence an mtd device of size 256MB is chosen with 128KB erase size and page size of 2048KB. root@ubuntu:~/Downloads/mtd-utils-02ae0aa# ./load_nandsim.sh 256 128 2048 Loaded NAND simulator (256MiB, 128KiB eraseblock, 2048 bytes NAND page) To check if the above operation completed successfully it is advisable to check the /proc/mtd file. root@ubuntu:~/Downloads/mtd-utils-02ae0aa# cat /proc/mtd dev: size erasesize name mtd0: 10000000 00020000 "NAND simulator partition 0" 10.1.2 Installing YAFFS2 Kernel Module Ubuntu does not have in-built support for YAFFS2 file-system. Hence it cannot be used directly with the mount command. The way to get around this issue is to download the YAFFS2 source code and compile it manually. Following are the steps for getting YAFFS2 support on Ubuntu 9.04 operating system: 1. Download the YAFFS2 source code from http://www.aleph1.co.uk/cgi- bin/viewcvs.cgi/yaffs2.tar.gz?view=tar. 2. Untar the source code file downloaded from step 1 using the extraction utility in Ubuntu by right-clicking on the source code file and choosing “Extract here” or by the following command. root@ubuntu:~/Downloads#tar –zxvf raffs2.tar.gz 70 3. In the yaffs2 directory invoke the make command. root@ubuntu:~/Downloads# cd yaffs2 root@ubuntu:~/Downloads/yaffs2# make make -C /lib/modules/2.6.31-14-generic/build M=/home/apurva/Downloads/yaffs2 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /home/apurva/Downloads/yaffs2/yaffs_mtdif.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_mtdif2.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_mtdif1.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_packedtags1.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_ecc.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_fs.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_guts.o /home/apurva/Downloads/yaffs2/yaffs_guts.c:1712: warning: ‘yaffs_DeleteWorker’ defined but not used /home/apurva/Downloads/yaffs2/yaffs_guts.c:612: warning: ‘yaffs_VerifyTnodeWorker’ defined but not used CC [M] /home/apurva/Downloads/yaffs2/yaffs_packedtags2.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_qsort.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_tagscompat.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_tagsvalidity.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_checkptrw.o CC [M] /home/apurva/Downloads/yaffs2/yaffs_nand.o LD [M] /home/apurva/Downloads/yaffs2/yaffs2.o Building modules, stage 2. MODPOST 1 modules CC /home/apurva/Downloads/yaffs2/yaffs2.mod.o LD [M] /home/apurva/Downloads/yaffs2/yaffs2.ko make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' 4. A kernel module named yaffs2.ko would be formed once the make command completes. Now the kernel module is inserted with the following command: root@ubuntu:~/Downloads/yaffs2#insmod yaffs2.ko 5. YAFFS2 file system can then be mounted using mount command. root@ubuntu:~/Downloads/yaffs2# mount -t yaffs2 /dev/mtdblock0 /mnt root@ubuntu:~/Downloads/yaffs2# cd /mnt root@ubuntu:/mnt# ls lost+found 71 10.1.3 Writing Nanddump Images on MTD Devices. To mount the Nanddump images they are first written to the mtd devices and then mounted with yaffs2 file system. The nandwrite utility from the mtd-utils package is used for writing the mtd5ro.nanddump image to the mtd0 device. Make sure the mtd device is not mounted when you perform this operation. root@ubuntu#nandwrite –a –o /dev/mtd0 ~/Desktop/mtd5ro.nanddump The write process completes successfully. However, after this step, the mtd device did not mount as expected. The error shown is as follows: root@ubuntu:/# mount -t yaffs2 /dev/mtdblock0 /mnt mount: wrong fs type, bad option, bad superblock on /dev/mtdblock0, missing codepage or helper program, or other error In some cases useful info is found in syslog – try dmesg | tail or so When the image acquired by Nandread utility was tried, the mount went successful but contents were not visible in the mnt directory. root@ubuntu:~/Downloads# mount -t yaffs2 /dev/mtdblock0 /mnt root@ubuntu:~/Downloads/mtd-utils-02ae0aa# cd /mnt root@ubuntu:/mnt# ls lost+found The issue is still being debugged but there is no considerable progress due to very limited online support and little documentation. 10.2 Investigating Nandroid Backups using Unyaffs Nandroid backups are logical backups of the NAND flash file systems that can be restored in case the firmware on the phone breaks for some reason. Nandroid backups capture only live file system and hence it may not be possible to recover deleted data from these backups. However, some important information like Wi-Fi passwords and browser history can be recovered from these backups. Due to the high popularity of Nandroid backups, forensic investigators might frequently encounter them during the investigation of Android phones. In this section forensic analysis of nandroid backup using the Unyaffs tool will be discussed. Nandroid backups are normally stored on the external SD card used on the phone but may also be found on the desktop machines that users use for connecting their phone. The backup images are saved on SD card in the nandroid folder. This folder contains subfolders for each device from which the backup was done. The device folder contains folders for each time the backups were taken. The name of every folder is time coded and the name convention is “BCDS-yyyymmdd-hhmm”. 72 For example if the SD card contains the backup images at M:\nandroid\HT9CXP812291\BCDS-2010722-0443, it would mean that this backup is of the device with serial number HT9CXP812291 and was taken on July 22, 2010 at 04 hours and 43 minutes. The Nandroid backup tool internally uses mkyaffs2image to make backup images. Hence these backup images can be explored using the Unyaffs tool. The source code of Unyaffs can be obtained from the Google code repository. Here are the steps for compiling the source code on Ubuntu 9.10 to obtain Unyaffs executable: root@ubuntu:~/Desktop# apt-get install subversion root@ubuntu:~/Desktop# svn checkout http://Unyaffs.googlecode.com/svn/trunk/ unyaffs A unyaffs/unyaffs.h A unyaffs/unyaffs.c Checked out revision 2. root@ubuntu:~/Desktop# cd unyaffs root@ubuntu:~/Desktop/unyaffs# gcc -o unyaffs unyaffs.c The Unyaffs tool can then be used to retrieve the file system from the backup images. By default Unyaffs will extract the contents into the current directory. Hence it is advisable to make a fresh directory for each image. Here are the steps to extract the files from data.img (/data partition backup image) using Unyaffs: root@ubuntu:~/Desktop/HT9CXP812291/BCDS-20100808-2324# mkdir data root@ubuntu:~/Desktop/HT9CXP812291/BCDS-20100808-2324# cd data root@ubuntu:~/Desktop/HT9CXP812291/BCDS-20100808-2324/data# ~/Desktop/unyaffs/unyaffs ~/Desktop/HT9CXP812291/BCDS-201008082324/data.img end of image The individual files can now be analyzed by exploring the directory structure extracted from the steps above. In the next section, some important files like SQLite db files will be discussed. 10.3 Interpreting Timestamps Time stamps in Android phones are stored in UNIX time stamp format. Online UNIX time stamp converters such as one found at http://www.onlineconversion.com/unix_ti me.htm can be used to retrieve actual date and time from the UNIX time stamps. Figure 10-2: Converting UNIX Timestamps to Readable Date/time 73 10.4 Exploring SQLite Database Files The Android Operating System makes extensive use of SQLite files to store user data. Information such as contacts, call logs, browser history, user dictionary, etc. are all stored in SQLite databases. The SQLite files are created using SQLite database software which is an open source database package. SQLite files on Android phones have a .db extension. In order to view the SQLite files an appropriate tool is needed to read them. The two most popular tools to view SQLite databases are: 1. Sqlite3 command-line tool supplied with the Android SDK under “android-sdkwindows/tools/” directory. 2. SQLite Database Browser – a free, open source GUI tool for browsing SQLite databases. It is available at http://sourceforge.net/projects/sqlitebrowser/ SQLite Database Browser is used in this project since it is made for the Windows platform and is very convenient to use. 10.4.1 Connecting to the Database Any SQLite database file can be opened in the SQLite browser using menu bar option File Open Database. Once the database is opened in the browser, the contents of the file can be explored using different features in the SQLite browser. These features are discussed below. Figure 10-3: Opening Database in SQLite Browser 74 10.4.2 Viewing Database Structure When the SQLite database file is successfully opened, the first screen will present the full structure of the database. This consists of all the tables, column fields, data type of each column field and all the indexes present in the database. The column field in each table can be seen by expanding the + tab corresponding to the table name. The data type of each column field also indicates whether a particular column data is used as a primary key or not. A primary key is the column field that uniquely identifies a particular row in a table. Hence if “name” column field is used a primary key then every row would be uniquely identified by data in “name” field and no two rows would have the same data in “name” field. This screen also displays the schema of each table and index. The schema is the SQL statement that was used to construct a particular table. The schema information also gives you information about columns in each table along with their data type. Figure 10-4: View Database Structure in SQLite Browser 75 10.4.3 Viewing Database Contents The database contents can be viewed using the second tab on the “Browse Data” screen. This screen gives a drop down box consisting list of all tables. Any table can be selected and the contents with column headings are displayed in the big area below. Figure 10-5: Viewing Database Contents in SQLite Browser 10.4.4 Important SQLite Databases 10.4.4.1 Browser Data The SQLite databases for Android browser can be found in /data/data/com.android.browser/databases. The most important databases and their tables are: Database Tables browser.db Webview.db Webviewcache.db • android_metadata • bookmarks • searches • android_metadata • cookies • formurl • formdata • httpauth • password • android_metadata • cache Table 10-1 List of Databases & Tables in /data/data/com.android.browser/databases The bookmarks table in browser.db contains information about websites that have been explicitly bookmarked also in addition to the the browsing history of the user. The data includes the URL, last time visited and number of times the user visited a specific URL. The searches table lists all the entries that user entered in the address bar which were subsequently searched by the Google Search engine. 76 The most interesting table in webview.db, and perhaps in the whole of the browser data, is the password table. This table contains all passwords in clear text that user might have chosen to save using the “Remember passwords” feature in Android browser settings. Other tables contain cookies, form data and form URL. Figure 10-6: Contents of Password Table The webviewcache.db serves as a cache for the browser and contains details of recent pages like the URL, last modified date, expiry string and http status when the URL was visited. Android also saves the geographic location of the phone provided the user has given permission for this. The data about these locations can be found in CachedGeoposition.db at /data/data/com.android.browser/app_geolocation. The table CachedPosition contains location information in the form of latitude, longitude, altitude, accuracy, timestamp and other fields. Figure 10-7: Contents of Cached Position table in Cached Geoposition.db The latitude and longitude data can be converted to actual addresses using online convertors like one at http://stevemorse.org/jcal/latlon.php Figure 10-8: Converting Latitude and Longitude to Actual Address 77 10.4.4.2 Calendar Events The calendar events are stored in the calendar.db database. This database can be found at /data/data/com.android.providers.calendar/databases. The Events table in this database stores the main calendar information. The column fields in the events table are shown below. Other tables like Attendees, CalendarMetaData, CalendarAlerts and Reminders might also prove important in certain cases. 10.4.4.3 Contacts Contacts2.db under /data/data/com.android.providers.contacts/databases stores all the contact information. Settings Contains details of various web accounts like facebook and twitter synced with contacts data. Call This table contains the call log data. If the call is from unknown number then the number field contains -1. Status_updates This table contains status updates of friends from the web accounts of synced to contacts. Accounts Name of all accounts synced to contacts including Google accounts. The settings table did not contain the Google accounts. Raw_contacts This can be said as the main table containing all the contact information. Table 10-2: List of Tables in Contacts2.db The contacts2.db is a good candidate for extracting a string dump using strings.exe to retrieve deleted records and, possibly, additional information 78 10.4.4.4 SMS Data The SMS data is contained in the mmssms.db database located in /data/data/com.android.providers.telephony/databases. The SMS table mainly contains data about all SMS stored such as sender, receiver, time stamp, service centre information and type of message. A value of 1 in the type field indicates that the message is received on the phone while a value of 2 indicates that the message is sent from the phone. A simple string dump from mmssms.db using strings.exe can recover deleted records that haven’t been purged from the file. As an example it was possible to recover the following SMS that was deleted but yet remained in the mmssms.db database. D:\forensicsoftwares>strings.exe mmssms.db Strings v2.41 Copyright (C) 1999-2009 Mark Russinovich Sysinternals - www.sysinternals.com SQLite format 3 … 6Friendship is about two main things : First is to find out the similarities, The second is to respect the differences...! … 10.4.4.5 User Dictionary The user has an option to save words that are not included in the standard dictionary that comes with Android. These words are saved in user_dict.db in /data/data/com.android.providers.userdictionary/databases. The words table in user_dict.db contains all the words that user has saved while typing text messages or other types of input. 10.4.4.6 Market Applications Users have the choice of installing various applications available in Android Market. Some applications are free while others are paid software. Details of all applications installed via Android market are stored in assets.db. Table assets10 stores various kinds of information such as package name, download timestamp, installation timestamp and uninstallation timestamp. Billing details are included in a separate database called billing.db. 10.4.4.7 Facebook Friends The facebook application has its own database called fb.db for storing all facebook information including, but not limited to, messages, notifications, names and contact details of all friends and status updates. /data/data/com.facebook.katana/databases. 79 fb.db can be found in 10.4.4.8 Gmail Email The Gmail application folder contains a db file for each gmail account. The naming convention for this folder is mailstore.<gmail account>.db. For example, the folder found in this phone is mailstore.johndoe.03072010@googlemail.com.db. This file contains information such as subject, mail snippet, addresses and attachments for each mail. 10.4.4.9 Gtalk Conversations Details about the gtalk user account are stored in talk.db under /data/data/com.google.android.gsf. The details include chat messages and information about people added in gtalk. The above list, although extensive, is not a complete list of SQLite files that can be found on Android phones. Every application may have its own SQLite database and hence additional SQLite files should be searched for depending on the case that is being worked upon. 10.5 Metadata from Camera Images Meta data from camera images can give several hints about the picture taken such as the model of the camera used, actual time at which the picture was taken and also the location where the image was taken. Nexus One stores location data and embeds geographical metadata in the jpeg picture. This process is also known as “geotagging”. Geotagging can be disabled while photos are taken but a user may forget to disable or may not even realize the consequences of this feature. Exifprobe is a very good tool for extracting metadata from jpeg images. It is developed by Duane H. Hesser for Linux platform and can be downloaded from http://www.virtualcafe.com/~dhh/tools.d/exifprobe.d/exifprobe.html. The steps for using exifprobe are as follows: 1. Download the tar.gz file from the above link and extract it using the following command. root@ubuntu:~/Downloads# tar -zxvf exifprobe-2.0.1.tar.gz 2. Change directory to exifprobe-2.0.1 and install the exifprobe tool. root@ubuntu:~/Downloads/exifprobe-2.0.1# make install 80 3. Run exifprobe to extract the metadata from desired images. In the example shown below the meta-tags indicate that the image was taken from Google Nexus One camera at 20:41:26 on 13th August 2010 at a geographical location with latitude 55.52064 and longitude -4.133451 root@ubuntu:~/#exifprobe -L IMG_20100813_204127.jpg FileName = IMG_20100813_204127.jpg FileType = JPEG FileSize = 558039 JPEG.APP1 = @2:19717 JPEG.APP1.Ifd0.Make = 'Google' JPEG.APP1.Ifd0.Model = 'Nexus One' … JPEG.APP1.Ifd0.Exif.DateTimeOriginal = '2010:08:13 20:41:26' JPEG.APP1.Ifd0.Exif.DateTimeDigitized = '2010:08:13 20:41:26' … JPEG.APP1.Ifd0.Gps.VersionID = 2,2,0 JPEG.APP1.Ifd0.Gps.LatitudeRef = 'N' JPEG.APP1.Ifd0.Gps.Latitude = 55,52,0.64 JPEG.APP1.Ifd0.Gps.LongitudeRef = 'W\000' JPEG.APP1.Ifd0.Gps.Longitude = 4,13,34.51 JPEG.APP1.Ifd0.Gps.AltitudeRef =0 JPEG.APP1.Ifd0.Gps.Altitude =0 JPEG.APP1.Ifd0.Gps.TimeStamp = 19,41,9 JPEG.APP1.Ifd0.Gps.MapDatum = 'WGS-84' JPEG.APP1.Ifd0.Gps.ProcessingMethod = @586:15 # UNDEFINED JPEG.APP1.Ifd0.Gps.DateStamp = '2010:08:13' 10.6 Wifi Credentials Android stores the credentials of wifi networks used in the file called wpa_supplicant.conf. This file can be found at /data/misc/wifi. The SSID and password of all wifi networks accessed are stored in clear text in this file. This file can be viewed in a simple text editor like notepad since it is a normal text file. For example, the wpa_supplicant.conf of the Nexus One phone showed the following content. ctrl_interface=eth0 update_config=1 network={ ssid="blue87" psk="fn286slpl" key_mgmt=WPA-PSK priority=1 } 81 10.7 Desktop Evidence Being portable devices, mobile phones pose a very serious issue where possession in itself may not imply ownership. Evidence found on desktop or notebook machines can provide clues about the owner of the phone. The computer might also contain Nandroid backups which can be useful if data on the phone is wiped. Desktop evidence can be of great importance in proving the ownership of the phone if the suspect is trying to disown it. A mobile phone recovered from a suspect may have been stolen from the victim. The suspect may have wiped it to get rid of any evidence and is now using it. In this case, desktop evidence on the suspect’s machine and the victim’s computer can potentially link the suspect and the victim to a particular crime Android phones, like other USB storage devices, cause an entry into Windows Registry to be written every time it is connected. This entry can be found under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\USBSTOR\. For example, the entry for Nexus One phone with model number HT9CXP812291 was to be: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\USBSTOR\Disk&Ven_Googl e_&Prod_Inc.Nexus_One&Rev_\HT9CXP812291&0 82 11 Conclusions & Further Work This chapter presents the conclusions arising from the research and experiments undertaken throughout this project. A set of good practice guidelines is also provided to assist investigators in the forensic analysis of Android smart phones. Finally, suggestions for future work in the area of Android forensics are given. 11.1 Conclusions 11.1.1 Overview The overall goal of this project was to investigate techniques for retrieval and analysis of data from the Nexus One phone. Several techniques, such as using commercial software Paraben Device Seizure and acquiring raw images using different tools, were applied and the results were analysed. It can be concluded that most of the live data on the phone can be acquired by using commercial software such as Paraben Device Seizure. However, root access is necessary to recover deleted data from the phone. The process of gaining root access on the Nexus One phone involves unlocking bootloader which results in the wiping of user data making any further recovery impossible. However, if the phone is already rooted raw images can be acquired using Dd, Nandread and Nanddump tools. Any useful data from the raw disk images can then be recovered using file carving tools like Scalpel and utilities like strings. The live file system can also be captured using Nandroid backup and, thereafter, explored using Unyaffs. Deleted records from individual files can be recovered by taking a string dump. Data acquired from the phone can give extensive information about the user including, but not limited to contacts, sms, email messages and geographic location. Evidence of the phone being connected on desktop machine can be used to verify and prove the ownership of the phone. Using the procedures and methodology outlined for the Nexus One, other Android phones can also be investigated. However, the exact process of gaining root access might be different for different phones since each manufacturer introduces proprietary security safeguards to prohibit access to its bootloader. 83 11.1.2 Good Practice Guidelines A set of good practice guidelines, which can be used by forensic investigators for examining Android phones, is presented below: 1. As soon as the phone is found at the crime-scene, it should be seized according to the processes outlined in section 2.2 in compliance with ACPO guidelines. 2. The SD card and SIM card from the phone should be removed. Conventional FAT32 analysis techniques should be used for further investigation of data on the SD card. 3. A new forensically wiped SD card should be used for further investigation. 4. Commercial software solutions like Paraben Device Seizure should be used for acquiring live data from the phone. 5. Further examination of the phone should be done to check if its bootloader is already unlocked and if it is rooted. 6. If the phone does not have an unlocked bootloader and/or is not already rooted, further examination should not be carried out. 7. If the bootloader is already unlocked, root access can be gained on the phone. 8. Once root access on the phone is achieved, the live file system can be captured using Nandroid backup. Nandroid backups may also be found on the SD card or desktop machine to which the phone might have been connected. 9. Busybox tool should be installed on the Android /system partition for taking md5 hashes of /data system and Dd images that need to be acquired. 10. An md5 hash of /data partition should be calculated following which a Dd image should be acquired. Once the imaging is complete the md5 hash of /data partition and Dd image should be calculated again and recorded. This would verify authenticity of the image acquired and ensure compliance with ACPO principle 1 which requires that data has not been modified. 11. Data from raw image can be recovered and analyzed using file carving tools like Scalpel and utilities like strings. 12. Live file-system captured using Nandroid backups can be explored using the Unyaffs tool and individual files can be analysed using appropriate tools like sqlite browser and exifprobe. 84 11.1.3 Project Achievements The main objective of this project, namely to acquire data from the Nexus One phone and analyze it, was completed successfully. Other achievements attained through this project are outlined below: • Extensive research of Android Operating system was completed, looking specifically at the low level working of MTD technology and the YAFFS2 file system. • Experience of using the commercial software tool Paraben Device Seizure was gained. • A clear, methodological, approach and software tool-set was developed in order to perform experiments to acquire raw data from the phone. • Various free open source tools that can be used for efficient analysis of the data commonly acquired from smart phones were studied. • A set of good practice guidelines to assist forensic investigators in the examination of Android smart phones is established as a result of the work completed in this project. 11.1.4 Unresolved Issues The only issue remaining unsolved in this project was the mounting of the raw disk image as a YAFFS2 file system. This failure may be due to a difference in the version of MTD used on the phone and the version created using the Nandsim emulator. This issue is very difficult to debug since there are no logs that indicate the reason for failure. The YAFFS2 file system and MTD technology are still rather new and so support on the internet remains very limited. 11.2 Further Work In addition to debugging the outstanding issue of mounting the raw image as a YAFFS2 file system there are other areas that can be further developed for efficient analysis of the data acquired from the phone. The most obvious area of interest is the study of other phone models such as the HTC Desire and the Motorola Droid for which there is no published information regarding their forensic footprint. Methods for gaining root privileges on the phone involving minimal changes and no loss of data need to be found. This would involve the in-depth study of security features introduced by different manufacturers to prevent root access. 85 YAFFS2 file system is also very new and more study would be required in order to perform regeneration of this file system. A deeper insight in allocation and de-allocation strategies, file deleting algorithms and garbage collection procedures can help in efficient recovery of deleted data from the phone. A good understanding of call log structures, SMS records and the formats in which other data is stored in sqlite files may also prove helpful in the efficient recovery of deleted, but not yet purged, data. Much of the information can also be retrieved by developing an application that uses content providers to access the data of other applications such as Google Maps. Hence an application to retrieve these data can also be another area of development in this field. 86 12 Bibliography ACPO Guideline Computer Evidence. (n.d.). Retrieved August 17, 2010, from 7safe Web site: http://www.7safe.com/electronic_evidence/ACPO_guidelines_computer_evidence.pdf Admob. (2009). Admob Mobile Metrics Report. AdMob. Android Debug Bridge. (n.d.). Retrieved July 18, 2010, from Android Developers: http://developer.android.com/guide/developing/tools/adb.html Android Operating system. (n.d.). Retrieved August 1, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Android_operating_system Android SDK. (n.d.). Retrieved July 18, 2010, from Android Developers: http://developer.android.com/sdk/index.html Compiling for Android. (n.d.). Retrieved July 25, 2010, from Android Wiki: http://androiddls.com/wiki/index.php?title=Compiling_for_Android Cyanogen. (n.d.). CyanogenMod Homepage. Retrieved October 2010, 2010, from CyanogenMod - Android Community ROM based on FroYo: http://www.cyanogenmod.com/ Fastboot. (n.d.). Retrieved July 20, 2010, from Android Wiki: http://androiddls.com/wiki/index.php?title=Fastboot Foremost. (n.d.). Retrieved August 25, 2010, from Sourceforge: http://foremost.sourceforge.net/ Google. (2010, March 15). Nexus One user guide. Hamblen, M. (2009, October 6). Android to grab No. 2 spot by 2012, says Gartner. Retrieved August 25, 2010, from Computer World Website: http://www.computerworld.com/s/article/9139026/Android_to_grab_No._2_spot_by_2012_s ays_Gartner Hoog, A. (2010, January 26). Android on the loose. (I. Roy, Ed.) Digital Forensics Magazine (2), pp. 12-17. Hoog, A., & Gaffaney, K. (2009, June). iPhone Forensics. How to unlock the bootloader on your Nexus One. (2010, January 3). Retrieved July 23, 2010, from Android @ MoDaCo: http://android.modaco.com/content/google-nexus-onenexusone-modaco-com/299078/how-to-unlock-the-bootloader-on-your-nexus-one/ Leslie, B. (2007, November 26). Android Blogs. Retrieved July 20, 2010, from Benno's Website: http://benno.id.au/blog/?tag=android&start=10 87 Manning, C. (2010, January 18 ). How YAFFS works: the internals. Retrieved July 10, 2010, from YAFFS: http://users.actrix.co.nz/manningc/yaffs-pdfs/HowYaffsWorks.pdf Memory Technology Device (MTD) Subsystem for Linux. (n.d.). Retrieved July 5, 2010, from http://www.linux-mtd.infradead.org/doc/general.html MTD Utilities. (n.d.). Retrieved July 25, 2010, from Texas Instruments Embedded Processors Wiki: http://processors.wiki.ti.com/index.php/MTD_Utilities Open Handset Alliance Homepage. (n.d.). Retrieved August 25, 2010, from Open Handset Alliance: http://www.openhandsetalliance.com/ Paraben Forensic Software - Device Seizure. (n.d.). Retrieved August 25, 2010, from http://www.paraben.com/device-seizure.html Paraben Forensic Software - Device Seizure. (n.d.). Retrieved July 18, 2010, from Paraben Website: http://www.paraben.com/device-seizure.html Scalpel. (n.d.). Retrieved 25 2010, August, from Digital Forensics Solutions: http://www.digitalforensicssolutions.com/Scalpel/ What is Android? (n.d.). Retrieved June 20, 2010, from Android Developers: http://developer.android.com/guide/basics/what-is-android.html Wookey. (2006, July 26). YAFFS: the NAND-specific flash file system - Introductory Article. Retrieved July 8, 2010, from YAFFS: http://www.yaffs.net/yaffs-nand-specific-flash-filesystem-introductory-article YAFFS Homepage. (n.d.). Retrieved August 25, 2010, from YAFFS | A flash file system for embedded use.: http://www.yaffs.net Zdziarski, J. (2008). iPhone Forensics (1st Edition ed.). O'Reilly. 88 Appendix-A Manual Reference Pages 1. Fastboot Usage: fastboot [ <option> ] <command> commands: update <filename> flashall flash <partition> [ <filename> ] erase <partition> getvar <variable> boot <kernel> [ <ramdisk> ] flash:raw boot <kernel> [ <ramdisk> ] devices reboot reboot-bootloader options: -w -s <serial number> -p <product> -c <cmdline> reflash device from update.zip 'flash boot' + 'flash system' write a file to a flash partition erase a flash partition display a bootloader variable download and boot kernel create bootimage and flash it list all connected devices reboot device normally reboot device into bootloader erase userdata and cache specify device serial number specify product name override kernel commandline 2. Nanddump Usage: nanddump [OPTIONS] MTD-device Dumps the contents of a nand mtd partition. --help Display this help and exit --version Output version information and exit -f file --file=file Dump to file -i --ignoreerrors Ignore errors -l length --length=length Length -n --noecc Read without error correction -o --omitoob Omit oob data -b --omitbad Omit bad blocks from the dump -p --prettyprint Print nice (hexdump) -q --quiet Don't display progress and status messages -s addr --startaddress=addr Start address i 3. Nandread Usage: nandread [-d <dev>] [-f file] [-s sparesize] [-vh] -d <dev> Read from <dev> -f <file> Write to <file> -s <size> Number of spare bytes in file (default 64) -R Raw mode -S <start> Start offset (default 0) -L <len> Length (default 0) -v Print info -h Print help 4. Strings usage: strings [-a] [-b bytes] [-n length] [-o] [-q] [-s] [-u] <file or directory> -a Ascii-only search (Unicode and Ascii is default) -b Bytes of file to scan -o Print offset in file string was located -n Minimum string length (default is 3) -q Quiet (no banner) -s Recurse subdirectories -u Unicode-only search (Unicode and Ascii is default) ii Appendix-B Glossary ACPO: Association of Chief Police Officers ADB: Android Debug Bridge ADT: Android Development Tools APK: Android Package AVD: Android Virtual Device DS: Device Seizure DVM: Dalvik Virtual Machine MTD: Memory Technology Devices OOB: Out Of Band RAM: Random Access Memory ROM: Read Only Memory SDK: Software Development Kit YAFFS2: Yet Another Flash File System 2 iii