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