EXAMINING ANDROID PRIVACY USING DIGITAL FORENSICS
A Project
Presented to the faculty of the Department of Computer Science
California State University, Sacramento
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
Computer Science
by
Jason Landsborough
Fall
2013
© 2013
Jason Landsborough
ALL RIGHTS RESERVED
ii
EXAMINING ANDROID PRIVACY USING DIGITAL FORENSICS
A Project
by
Jason Landsborough
Approved by:
__________________________________, Committee Chair
Isaac Ghansah, Ph.D.
__________________________________, Second Reader
Behnam Arad, Ph.D.
____________________________
Date
iii
Abstract
of
EXAMINING ANDROID PRIVACY USING DIGITAL FORENSICS
A Project
by
Jason Landsborough
Portable devices, such as those that run Android, allow people to do much more than ever before.
Users of these devices can receive and respond to email when away from their computers.
Pictures taken on GPS enabled devices can store location data, so users know where a picture was
taken. Users can take a picture and immediately upload it somewhere. Specialized third-party
apps extend the functionality of these devices even further, adding to the types of data being used
and stored on the device. With all this new data comes risk. Because data can be stored, it can
also be retrieved.
This project covers many types of data acquisition methods for an Android device, to determine
what information can be retrieved. All of the methods were free to use, and could be used by an
untrusted third-party, such as a thief. Data was acquired from a T-Mobile G2x, an Android
smartphone, consisting of data created for the project, as well as data that already existed on the
device. The data consisted of: email messages, text messages, a phone call log entry, pictures, a
calendar event, location data, a Skype instant message, a Facebook Post, and an Evernote note.
An email message, two text messages, and two pictures, were deleted to determine if these could
be recovered.
iv
Using the various methods used in this project, most of the data was retrieved. Portable devices
are susceptible to being lost or stolen. Because of this and the results of this project, where
confidentiality is warranted, additional security measures should be taken to protect the data.
Approved by:
__________________________________, Committee Chair
Isaac Ghansah, Ph.D.
____________________________
Date
v
Student: Jason Landsborough
I certify that this student has met the requirements for format contained in the University
format manual, and that this project is suitable for shelving in the Library and credit is to
be awarded for the project.
__________________________, Graduate Coordinator ___________________
Nikrouz Faroughi, Ph.D.
Date
Department of Computer Science
vi
ACKNOWLEDGEMENTS
I would like to thank Dr. Issac Ghansah for helping to define and refine this project, as well as for
offering suggestions and advice throughout the project to make this project better.
I would also like to thank Dr. Behnam Arad for being the second reader, as well as for the advice
given to me throughout my time as a Master’s student.
vii
TABLE OF CONTENTS
Page
ACKNOWLEDGEMENTS ........................................................................................................... vii
LIST OF TABLES ......................................................................................................................... xii
LIST OF FIGURES ...................................................................................................................... xiii
Chapter
1. INTRODUCTION. ...................................................................................................................... 1
1.1 Digital Forensics .................................................................................................................... 1
1.2 Android .................................................................................................................................. 1
1.2.1 Android Architecture ...................................................................................................... 2
1.2.2 Android Apps .................................................................................................................. 3
1.2.3 Android App Environment.............................................................................................. 4
1.3 Privacy Issues ........................................................................................................................ 4
1.4 Motivation for Project ............................................................................................................ 5
1.5 Related Work ......................................................................................................................... 5
1.5.1 Android App Permission................................................................................................. 5
1.5.2 Bootimg........................................................................................................................... 6
1.5.3 Bypassing Lock Screens ................................................................................................. 6
1.6 Objectives .............................................................................................................................. 8
2. SYSTEM SETUP....................................................................................................................... 10
viii
2.1 Phone Hardware and Operating System .............................................................................. 10
2.2 Target Data Creation ............................................................................................................ 11
2.2.1 Apps Used for Target Data Creation............................................................................. 11
2.2.2 Target Data.................................................................................................................... 11
2.2.3 Tools and Methods ........................................................................................................ 17
3. FORENSIC ACQUISITIONS, ANALYSIS AND RESULTS.................................................. 20
3.1 SD Card Acquisition with dd ............................................................................................... 20
3.1.1 Acquiring SD Card Data ............................................................................................... 20
3.1.2 Setup in Autopsy Browser ............................................................................................ 21
3.1.3 Examining Data in Autopsy Browser ........................................................................... 22
3.1.4 Summary of Results Using this Method ....................................................................... 29
3.2 USB Drive Acquisition with dd ........................................................................................... 29
3.2.1 Acquiring USB Data ..................................................................................................... 29
3.2.2 Examining Data in Autopsy Browser ........................................................................... 30
3.2.3 Summary of Results Using This Method ...................................................................... 31
3.3 Forensic App ........................................................................................................................ 32
3.3.1 App Setup...................................................................................................................... 32
3.3.2 Examining Forensic App Results .................................................................................. 34
3.3.3 Summary of Results Using this Method ....................................................................... 35
3.4 Oxygen Forensic Suite ......................................................................................................... 36
ix
3.4.1 Acquiring Data Using Oxygen Forensic Suite .............................................................. 36
3.4.2 Examining Data Acquired Using Oxygen Forensic Suite............................................. 37
3.4.3 Summary of Results Using this Method ....................................................................... 40
3.5 adb pull ................................................................................................................................ 40
3.5.1 adb Setup....................................................................................................................... 41
3.5.2 Acquiring Data Using adb............................................................................................. 41
3.5.3 Examining adb pull Contents ........................................................................................ 42
3.6 Root adb pull ........................................................................................................................ 43
3.6.1 Rooting the Phone ......................................................................................................... 43
3.6.2 Examining the Results of adb pull as Root ................................................................... 44
3.6.3 Summary of Results Using this Method ....................................................................... 50
3.7 Root adb dd .......................................................................................................................... 51
3.7.1 Acquiring Data Using dd Through adb shell ................................................................ 51
3.7.2 Examining Results of dd as Root .................................................................................. 51
3.7.3 Summary of Results Using this Method ....................................................................... 52
4. CONCLUSION .......................................................................................................................... 53
4.1 Summary .............................................................................................................................. 53
4.2 What Android Users Should Know ..................................................................................... 54
4.3 Advantages and Disadvantages of Methods Used ............................................................... 54
4.4 Future Work ......................................................................................................................... 55
x
4.4.1 Other Devices................................................................................................................ 55
4.4.2 SQLite Deleted Data Recovery ..................................................................................... 56
4.4.3 Other Apps .................................................................................................................... 56
4.4.4 Network Attacks ........................................................................................................... 56
4.4.5 Factory Reset ................................................................................................................ 56
Appendix A .................................................................................................................................... 57
References ...................................................................................................................................... 62
xi
LIST OF TABLES
Tables
Page
Table 1 - Phone Specifications ...................................................................................................... 10
Table 2 - Data used ........................................................................................................................ 11
xii
LIST OF FIGURES
Figures
Page
Figure 1 - Android Architecture [4] ................................................................................................. 3
Figure 2 - Finding the device ......................................................................................................... 20
Figure 3 - Hash comparison of image and source .......................................................................... 21
Figure 4 - Add image to Autopsy .................................................................................................. 22
Figure 5 - Deleted picture of Ducati .............................................................................................. 23
Figure 6 - Deleted picture of New York Stock Exchange ............................................................. 24
Figure 7 - Picture of solid state drives ........................................................................................... 25
Figure 8 - Output file of picture-gps-parser script ......................................................................... 27
Figure 9 - Location data displayed in Google Maps ...................................................................... 28
Figure 10 - Interface for AFLogical............................................................................................... 33
Figure 11 - SMS message with "verification" keyword................................................................. 34
Figure 12 - Target call log data ...................................................................................................... 35
Figure 13 - Extracting data using Oxygen Forensic Suite ............................................................. 37
Figure 14 - Primary case window for Oxygen Forensic Suite ....................................................... 38
Figure 15 - Target calendar event with keyword “geckos”............................................................ 39
Figure 16 - Target SMS message with keyword "Zooey" ............................................................. 40
Figure 17 - Result for "adb devices" command ............................................................................. 41
Figure 18 - Rooting the phone ....................................................................................................... 44
Figure 19 - Accounts.db................................................................................................................. 45
Figure 20 - Facebook friend data in fb.db...................................................................................... 47
Figure 21 - Target location data in search_history.db ................................................................... 48
Figure 22 - Target Skype data with keyword "test-skype-keyword" in main.db ........................... 49
xiii
Figure 23 - Target email data with keyword "Woot" in mailstore.USERNAME@gmail.com.db 50
Figure 24 - Uninstalled apps’ deleted directories .......................................................................... 52
xiv
1
CHAPTER 1
INTRODUCTION
1.1 Digital Forensics
Digital forensics is a field that involves the acquisition of data off of a digital device for the
purpose of performing some investigation involving the target digital device. The investigators
are commonly law enforcement (to find evidence for a court case), or members of a company’s
IT department (to determine the cause and/or extent of a problem or attack).
The digital devices that are of concern to forensic investigators are devices that store data. The
ultimate aim is to recover the data as accurately as possible while maintaining the integrity of the
source of the data. This is usually achievable with non-volatile data such as that found on a hard
disk drive, but is usually difficult or impossible with volatile data such as system memory or
network data. Therefore, recovery of such volatile data involves live acquisition.
1.2 Android
Android is a mobile Operating System developed by Google that runs on a Linux kernel. It was
first available to consumers on September 23, 2008 on a phone offered by the cellular provider TMobile [1]. That phone was the HTC G1, otherwise known as the G1, or commonly referred to
as the Google phone until other Android-based smartphones became available. Android is also
commonly used as the Operating System on tablet devices. Android can also be found running
on other devices such as wearable devices like wrist watches [2] and Google’s upcoming Glass
[3], a wearable device that looks like eyeglasses.
2
1.2.1 Android Architecture
The Android architecture is divided into 5 layers: the Linux kernel, libraries, Android runtime
environment, application framework, and application layer (Figure 1) [4]. The Linux kernel
contains device drivers and the lowest level system routines. The libraries layer consists of
libraries that add support for existing protocols and frameworks like SQlite (a lightweight
database), Webkit (web browser engine), and Secure Sockets Layer (for secure network
communication). The Android runtime contains the core Android libraries and the Dalvik Virtual
machine, which apps (applications), run on. The application framework contains various parts
needed by an Android app such as resource managers and content providers, which manage and
provide access to various types of data. The last layer is the application layer, which consists of
the various apps that run on the system, many of which are accessible by the user, such as the
phone, web browser, and any custom apps the user downloads.
3
Figure 1 - Android Architecture [4]
1.2.2 Android Apps
Apps provide functionality beyond what is offered by the Android Operating System. Some of
these apps are frequently included with a particular device, such as the Phone or Contacts
applications for phones, but they do not necessarily come on all Android devices, such as a tablet
which does not have the capability to make calls. Whether or not a stock Android app is
included, omitted, or replaced on the device is a decision that is left up to the device
manufacturer. The power of these devices is largely due to apps that are not included with the
device, or third-party apps. Most of these apps are made by developers who do not work on the
Android Operating System but use the Android Software Development Kit (SDK) [5].
4
1.2.3 Android App Environment
Apps run in a somewhat contained environment. Android apps run on a special Java virtual
machine called Dalvik that is designed to run on programs on a slower CPU device with a small
amount of RAM while running on a battery [6]. Apps are used for a large range of different
purposes, such as Voice Over Internet Protocol (VOIP) communication, Social networking, micro
blogging, note taking, location tracking, calendar scheduling, and using e-mail. In many of these
cases, if not all, information is being created and stored. Apps can store data several ways, four
of which are common. One way is to save data to a file. The second is to use a SQLite database,
a very lightweight and portable database. The third is to use a content provider, which allows
data to be available across apps. The fourth is to save data to a server or servers, more commonly
referred to as the cloud.
1.3 Privacy Issues
Smartphones, such as those that run the Android Operating System have the potential to store
large amounts of information. A standard cell phone might only store contact information, text
messages, call logs, and pictures. Android cellphones typically also store email messages,
calendar information, Global Positioning System data, and most importantly app data. These
apps have a wide range of functionality and may store a wide range of data as a result.
Many people, including the author, use smartphones to run applications to perform tasks such as
reading and sending email, GPS navigation, web browsing, and social networking which are
typically performed on other devices. Some businesses are also starting to adopt mobile devices,
such as tablets, to handle orders and payment processing. Some data being saved by users of
these devices may be considered sensitive, or even secret. For example, if someone were to take
5
pictures of the inside of their house, the camera app settings may be saving the GPS coordinates
to the picture metadata. If someone came across the phone and found the picture and decided that
picture looked like something they would want to steal, then they could easily obtain the
coordinates of the phone owner’s home using the metadata from the picture.
1.4 Motivation for Project
The security implications of mobile computing devices were major motivating factors for this
work. Mobile devices, due to their nature of being portable, can be easily lost or stolen. Due to
this, a lot of potentially sensitive information is vulnerable to someone who comes across the
phone, either intentionally, such as stealing the device, or accidently, such as finding it in a taxi
cab.
1.5 Related Work
Due to its popularity, a lot of work is being done using Android. This section describes a small
selection of related work.
1.5.1 Android App Permission
Android relies on a system of permissions, such as access to text messages or access to the
Internet, to protect the device and data from malicious apps. Unfortunately these permissions are
not always clear to the user or cover a wide range of features, and many users just ignore the
permissions that an app is requesting. Researchers at the University of Maryland, and the
University of California, Los Angeles, have developed a system to run application packages
6
through and produce a new package with more refined permissions [7]. With this, users who pay
attention to app permissions will have a much better idea of what is being used by the app.
1.5.2 Bootimg
Android devices contain boot or recovery partitions. These partitions do not store any user data.
Researchers at Carnegie Mellon University demonstrated a custom boot image, or bootimg, to
take advantage of this [8]. The boot image was then able to capture data off the phone to be
examined later.
1.5.3 Bypassing Lock Screens
Android users who want to limit access to their phone can use one of several types of lock
screens. There are usually three types of lock screens available. The first is the pattern swipe,
and typically consists of nine circles which the user swipes through to create a pattern that
contains at most all nine points. The second is a passphrase at least 4 characters in length that
consists only of the digits zero through nine. The last is an alpha-numeric passphrase at least four
characters in length that consists of digits, letters, symbols, or a combination of the three.
1.5.3.1 Smudge Method
The smudge method takes advantage of the fact that fingers tend to be greasy and screens tend to
be glossy. As someone uses their device, a trace of their interaction is left behind on the glass in
the form of a greasy finger smudge. If someone has not used their phone much since unlocking
it, most of that smudge trail would be left intact, so it would then be possible to determine the
pattern used to unlock the phone. This could also be used with the passphrase methods, but
7
would be more difficult because order and frequency of the characters would most likely not be
obvious.
1.5.3.2 Brute Force Method
In an episode of the online video show called Hak5, Darren Kitchen demonstrated a brute force
method to bypass a 4 digit PIN [9]. He used a device known as the USB Rubber Ducky, which
acts like a USB keyboard, but is able to be pre-programmed with a script to execute a series of
keystrokes. Connecting this to an Android phone allows a script to brute force search all possible
combinations to eventually unlock the phone.
1.5.3.3 adb Methods
A user by the username m.sabra posted a guide on XDA-Developers.com [10], a popular forum
for Android developers. In this post, m.sabra posted two methods of bypassing the pattern lock
on Android devices. Both methods require that USB debugging is turned on, and both require the
device to be rooted. On the phone for this project, only the second method worked, as the first
required a tool that was not installed. The second method deletes the key file for the lock pattern.
To do this with a device connected to a computer with a USB cable, the following commands
were used:
adb shell rm /data/system/gesture.key
And:
adb reboot
The first command deletes the key. The second command reboots the phone. Once the phone
rebooted, the pattern lock screen was displayed, but any pattern was able to unlock the phone.
From then on, the pattern lock was not displayed.
8
1.5.3.4 Freezing Method
Newer versions of Android allow a device to be encrypted. Although the device used in this
project is too old to utilize the encryption feature, it is worth mentioning. Tilo Müller, Michael
Spreitzenbarth, and Felix C. Freiling created a tool to recover encryption keys and passphrases
from the device’s RAM [11]. To do this, the phone needs to be frozen so that the RAM contents
are not lost once it is no longer powered. Once cold enough, the device is rebooted and the
FROST tool is loaded. The tool will recover the encryption key while the RAM contents are still
present.
1.6 Objectives
This project involves the hypothetical situation where someone loses control of their phone. The
goal is to find out what information can be retrieved from the phone using several methods of
acquiring data. Here we assume that the hypothetical person who finds the phone is not a
member of government, law enforcement, or organized crime, and therefore would not have
access to a sophisticated forensic toolkit, legitimately or illegitimately, but would instead be
limited to what can be done using freeware and Open Source Software.
There were some initial expectations going into the project. The first was that everything on the
SD card can be recovered. It was also expected that some data would not be available unless the
phone was rooted. Last, it was expected that some of the test data may not be recoverable due to
obfuscation, such as through encryption or alternate encodings, or data being stored in the cloud.
9
The report is organized as follows. In Chapter 2, the project setup is discussed, including with the
device used and what data was used for the project. Chapter 3, the methods and results are
explained. Chapter 4 concludes this report and indicates future work.
10
CHAPTER 2
SYSTEM SETUP
2.1 Phone Hardware and Operating System
The phone used for this project was an older smartphone, The LG G2x [12], released in 2011.
The phone has been discontinued, because newer, better phones are available. The version of
Android it is running is 2.3.4, running on Linux Kernel 2.6.32.9. The build number is GRJ22.
The phone specifications are as shown in Table 1 below.
Table 1 - Phone Specifications
Processor
NVIDIA Tegra2 1GHz Dual-Core
RAM`
512 MB
Internal Memory
8 GB
SD card slot
Up to 32 GB microSD
Display
4” - 480x800 pixels
Camera
8 Megapixel
Operating System
Android 2.2 (upgradable to 2.3)
The phone had a 16 GB microSD card in the microSD slot located behind the back panel near the
battery. It had a pattern lock set up to restrict access. USB debugging was disabled, which
should be the default setting on a device, as it is typically used for app development. After
creating the target data, the SIM (Subscriber Identity Module) card was removed and the phone
was put into airplane mode so that the battery drained slower, but mostly so that no network
connections were active.
11
2.2 Target Data Creation
To aid in finding information, new data was entered into the phone for the project, or existing
data on the phone was used. Some data was suspected to not be recoverable, either due to it not
being stored on the phone, or obfuscated in some way that would not be obvious. Some data was
purposely deleted to determine if the deleted data could be recovered.
2.2.1 Apps Used for Target Data Creation
The apps used to create the target data were a combination of apps that came with the phone and
some third-party apps. The apps used that came with the phone were: Gmail, Messages (used for
SMS messages), Phone, Camera, Calendar, and Google Maps. Third-party apps that were used
were: Skype, Facebook, and Evernote.
2.2.2 Target Data
Table 2 shows the data that was used. The table shows each piece of target data that was being
used in the project, the category or type of data it is, any keywords that could be used in a search,
whether or not it was deleted, as well as the app that was used to create or access the data.
Table 2 - Data used
Target Data
Category
Keyword
Deleted?
App
Email Message 1 Email
Woot
No
Gmail
Email Message 2 Email
keystr;
Yes
Gmail
SMS Message 1
verification;
No
Messaging app
SMS
12
SMS Message 2
SMS
snowboarding;
Yes
Messaging app
SMS Message 3
SMS
Zooey;
No
Messaging app
SMS Message 4
SMS
compressed/blurry;
Yes
Messaging app
Phone calls
Phone
Steffani
No
Phone app
info
Picture
N/A
No
Camera
Deleted Picture
Picture
N/A
Yes
Camera
with GPS info
Picture
N/A
Yes
Camera
Calendar
Calendar
Geckos
No
Calendar
Location Data
Maps
Arlington
No
Maps
Skype Data
VOIP
test-skype-keyword;
No
Skype
No
Facebook
No
Evernote
Picture with GPS
Deleted Picture
test-facebookFacebook
Facebook
keyword
test-evernote-
Evernote
Notes
keyword
13
2.2.2.1 Email Messages
Email target data was created or accessed using the included Gmail app, version 2.3.6. Two
pieces of email data were used in the project. The first contained the word “Woot” used in an
email received shortly before the project. The email was not deleted, but left in the inbox. The
Gmail app seems to keep email in the inbox cached in case the device loses its network
connection. If the message was cached and saved to the phone’s non-volatile memory, then it
was expected to be recoverable.
The second email message was one containing the word “keystr,” which was deleted after
viewing the message on the phone. Similarly, if the message was saved to the phone’s nonvolatile memory, then it may be recoverable.
Email messages were recovered using the methods detailed in sections 3.6 and 3.7.
2.2.2.2 SMS Messages
SMS (Short Message Service) message target data was accessed using the included Messaging
app, version 2.3.4. A total of four messages were chosen to try to find, two of which were sent,
two received, and one of each was deleted. The first was a text message received on February 6,
2013 that contained the word “verification.” This message was not deleted. The second message
was received December 12, 2012 which contained the word “snowboarding.” This message was
deleted. The third message was sent on December 4, 2012 and contained the word “Zooey.”
This message was not deleted. The fourth message was sent on December 1, 2012 and contained
the combination of two words: “compressed/blurry.” This message was deleted.
14
It was expected that the messages that were not deleted could be found, as all text messages are
stored on the phone. It was unknown if the deleted messages could be recovered, as it was
unknown how they were stored.
SMS messages were recovered using the methods detailed in sections 3.3, 3.4, 3.6, and 3.7.
2.2.2.3 Phone Call Log
The phone call data was created using the included Phone app, version 2.3.4. The phone data
consists of data saved as part of the call log, for a call received from Steffani on January 31, 2013.
It was expected that the call log data could be recovered, as they are available without a network
connection, and are available to other applications.
The phone call log was recovered using the methods detailed in sections 3.3, 3.4, 3.6, and 3.7.
2.2.2.4 Pictures
The pictures were created using the included Camera app, version 1. Three pictures were taken
on the phone at various times throughout regular use of the phone and were used for this project.
The first picture is of two solid state drives taken on September 11, 2012 in the author’s
apartment in Sacramento. GPS was on when this picture was taken, so location data was saved.
The second picture used was of a Ducati motorcycle that was under a staircase to stay out of the
rain that day, which was March 18, 2012. GPS was off when this picture was taken, so no
location data was saved. This picture was deleted shortly before starting the project. The third
picture is of the New York Stock Exchange, which was taken on June 17, 2012. GPS was on
when this picture was taken. This picture was deleted shortly before starting the project. It was
15
expected that all the pictures could be recovered, because they were stored on the microSD card,
due to a configuration option through the camera app.
Pictures were recovered using the methods detailed in sections 3.1, 3.2, 3.4, 3.5, and 3.6.
2.2.2.5 Calendar Event
The calendar event was accessed using the included Calendar app, version 2.3.4. The event was a
reminder that stated “Feed Geckos,” which occurred multiple times a week. The event was not
deleted. It was expected that the event could be recovered, as calendar events were available
even when a network connection is not present.
The calendar event was recovered using the methods detailed in sections 3.4, 3.6, and 3.7.
2.2.2.6 Location Data
Location data was created using the included Maps app, version 6.14.3. The areas used were
destinations used in the Maps app to get directions to. For example, the author was in Arlington,
Virginia earlier in the year, so the goal was to find if any of that data was still available. A
backup plan was to find out whether any location data for Sacramento, California could be found.
Some difficulty was expected in finding this information, as it would likely be kept as longitude
and latitude coordinates, rather than a city name, so a keyword search might not be effective.
Location data was recovered using the methods detailed in sections 3.6, and 3.7.
16
2.2.2.7 Skype Data
Skype data was created using the third-party Skype app, version 3.1.0.6458. In this, a text
message was sent to the account running the app on the phone with the keyword “test-skypekeyword.” If a log is kept on the phone, that keyword would help find it.
Skype data was recovered using the methods detailed in sections 3.6 and 3.7.
2.2.2.8 Facebook Data
Facebook data was created using the third-party Facebook app, version 2.2. A post was created
which contained the keyword “test-facebook-keyword.” If this was cached on the phone’s nonvolatile memory, then it would be recoverable. This was unlikely to be the case, because the app
did not work without a network connection.
The target Facebook data was not recovered, but other Facebook data was recovered using the
methods detailed in sections 3.6 and 3.7.
2.2.2.9 Evernote Data
Evernote data was created using the third-party Evernote app, version 4.5.4. In this a new note
was created that contained the keyword “test-evernote-keyword.” If Evernote saved notes for
offline viewing on the phone’s non-volatile memory, then it would be recoverable. Because notes
were available without a network connection, this was most likely the case.
Evernote data was recovered using the methods detailed in sections 3.2, 3.4, 3.5, 3.6, and 3.7.
17
2.2.3 Tools and Methods
For this project, methods were used involving tools that were freely available. Some of these
may be familiar to anyone who has done digital forensics on personal computers before, and
some are Android specific, but in both cases they did not cost anything. Two of the tools, adb
and the forensic app, were mentioned by Andrew Hoog in his book [13]. The most significant
tools are described in this section.
2.2.3.1 Operating Systems
This project involved using tools that run on two Operating Systems. The majority of the work
was done using Ubuntu 12.04, a popular Linux distribution. Some tools required a Windows
Operating System. For these tools, Windows 7 was used.
2.2.3.2 dd
The command dd is available on most UNIX-like Operating Systems, including the Ubuntu
distribution used for this project. The dd command has several different purposes [14], but for
the purpose of this project, it was used to obtain a copy of a file system, including deleted files,
and save that copy to a file, or disk image, to be examined later using other tools. The copy
obtained this way is considered to be a physical copy, as it is a bit for bit copy identical to the
source.
2.2.3.3 Autopsy Browser
The Autopsy browser is a graphical user interface for The Sleuth Kit [15]. Autopsy allows a user
to examine disk images, such as those obtained using dd. It supports keyword search to quickly
18
find strings in files, file type sorting, and indicates if a file was deleted. Autopsy runs on Linux,
OS X, and Windows. For this project, it was used on Ubuntu. The version used was 2.24.
2.2.3.4 adb
The Android Debug Bridge (adb) is a tool that allows the user to perform various tasks on an
Android phone that is connected to a computer [16]. The adb tool is included with the Android
SDK [5]. For the purposes of this project, the adb tool was used to pull files from the device and
run command line tools using the phone’s shell. For this project, it was used on Ubuntu.
2.2.3.5 Forensic App
The company viaForensics offers a tool for Android forensics called AFLogical [17]. This tool is
an Android app that runs on the phone and retrieves non-deleted data and saves it to the SD card.
A free, but limited, version of the app is available as the AFLogical Open Source Edition. This
version only supports MMS/SMS, contacts, and call logs. A Law Enforcement version is
available and supports retrieval of more data, such as browser bookmarks and calendar events,
but is only available to law enforcement and government. The Open Source Edition was used,
version 1.5.2_OSE.
2.2.3.6 Oxygen Forensic Suite
Oxygen forensic is a commercial forensic product specifically for mobile devices. They offer a
free version of their software [18]. The free version will retrieve device information, contact and
call information, messages (email, MMS, and SMS), calendar information, and files. The tool
19
only runs on Windows. For this project, the tool was used on Windows 7. The version used was
5.1.2.153.
2.2.3.7 SuperOneClick
SuperOneClick is a freeware tool for easily rooting an Android device [19]. Rooting enables the
user to use the phone with elevated privileges, so that restricted files are accessible. It roots a
device by using exploits for that particular device, along with the adb tool. The tool does not
support rooting of all devices, and has not been updated since 2010, so it may not work on newer
phones. The tool runs on Windows. For this project, the tool (version 2.3.3), was used on
Windows 7.
2.2.3.8 SQLite Database Browser
Many apps use SQLite databases to store data. A free tool for easily viewing data in a database is
SQLite Database Browser [20]. It displays data in a spreadsheet like format with columns and
rows, so that the data is easy to see. The tool runs on Linux, OS X, and Windows. It was used on
Ubuntu for this project.
20
CHAPTER 3
FORENSIC ACQUISITIONS, ANALYSIS AND RESULTS
3.1 SD Card Acquisition with dd
The first method attempted was acquisition of the microSD card. On many Android phones,
including the one used in this project, the microSD card is easily removable. Because the
microSD card is removable, it is treated as an external drive. Once removed, the device can be
connected to a computer and the data can be retrieved using the same method used on other
external drives, such as USB drives.
3.1.1 Acquiring SD Card Data
The microSD card was removed from the phone and inserted into a microSD card adapter and
mounted on the Ubuntu system. The microSD card auto mounted at /media/34F5-15E1. Using
the mount command with no parameters and looking for the mount point, the device location
could be found from the output (as seen in figure 2), /dev/mmcblk0p1.
Figure 2 - Finding the device
From here, dd was used as follows:
sudo dd if=/dev/mmcblk0p1 of=/home/jason/sd.dd
21
The command dd allowed acquisition of a physical copy of the SD card and save it to a file. The
command sudo allowed dd to run with root privileges, which are needed to use dd on the device.
The parameter if=/dev/mmcblk0p1 indicates that /dev/mmcblk0p1 is the input file. Linux treats
devices like files, which is why this was able to work. The parameter of=/home/jason/sd.dd
copied the device file to /home/jason/sd.dd. Once dd is finished, the sd.dd image is identical to
the microSD card. To test this, a cryptographic hash function can be used. For example, as seen
in figure 3, using the sha1sum function, available on many Linux systems, on both the device and
the image file the same SHA1 hash was produced. A single bit difference would produce a very
different hash value.
Figure 3 - Hash comparison of image and source
3.1.2 Setup in Autopsy Browser
After starting the Autopsy executable in a terminal window, the output contains instructions on
how to access the Autopsy browser interface. The application creates a standalone web server on
the local machine on port 9999. To access the Autopsy interface, a web browser was directed to
http://localhost:9999/autopsy.
A new case was created and the image file, sd.dd, was added, as shown in figure 4.
22
Figure 4 - Add image to Autopsy
Once the image was loaded, Autopsy could then be used to examine the data imaged from the
microSD card.
3.1.3 Examining Data in Autopsy Browser
Using the file analysis option, a button at the top of the page, displayed the files and folders in the
image as they exist on the microSD card. Clicking through the files, only files that were stored to
the SD card were found, as expected. Although some apps were stored on the SD card, no data
for those apps were stored there. Music was also stored on the SD card. The only target data
stored on the SD card were the pictures taken with the camera app.
23
After navigating to the folder where the pictures were stored, /DCIM/Camera, all pictures were
represented. This list of results also included deleted pictures, indicated with red text. Scrolling
down, looking through the dates, the oldest picture used for target data was found, this picture
was the first deleted picture. As seen in the figure 5, once the link with the filename was clicked
on, additional details are available. The middle frame offers different ways of viewing the data,
but the default was to view a thumbnail of the picture. As shown, the deleted picture is of the
Ducati motorcycle stored under a staircase. Because the picture had been deleted, the text in the
result frame above is in red. Clicking the export link in the middle frame allowed a copy of the
picture to be obtained.
Figure 5 - Deleted picture of Ducati
24
Following the same steps, the second deleted picture was found as shown in figure 6. The picture
is of the New York Stock Exchange.
Figure 6 - Deleted picture of New York Stock Exchange
The last picture found, as shown in figure 7, was not deleted. This was the picture taken of the
solid state drives.
25
Figure 7 - Picture of solid state drives
All three of these pictures were exported the same way to recover the original image files. If the
camera app was configured to store to the phone’s memory, these pictures would not have been
recoverable using this method. It is very likely on most current Android phones that pictures
taken with the camera are stored on the SD card, as the memory included in many phones is very
limited. As flash memory gets cheaper, and the internal memory used in smartphones increases,
it will no longer be necessary to use an external storage medium like SD cards.
3.1.3.1 Finding GPS Information in the Pictures
The picture of the New York Stock Exchange and the picture of the solid state drives were both
taken with the GPS enabled. As a result, GPS location data was added to the EXIF
26
(Exchangeable Image File Format) [21] data. EXIF is a standard for storing additional image
metadata, such as camera used, time and date taken, exposure, etc.
There are many tools to extract EXIF information from a picture. Jeffrey’s Exif viewer [22] is an
example of a free online tool. Most of the tools handle a single picture at a time. If someone is
going through a lot of pictures, the process can become tedious.
To solve this, a search for ways to extract latitude and longitude coordinates from a picture was
performed and one result was a python script written by Eran Sandler [23] for extracting the
information from a single picture. The code was posted for anyone to use as long as attribution
was given. Using this as the base, the script [24] was extended. The most important change is
the ability to handle a directory of files including subdirectories. The results are then saved to a
HTML file represented in a table. The date taken, GPS coordinates, make and model were all
extracted from the EXIF data in Eran Sandler’s script. This data was included in the table. A
link to the image was also included, so the image can be viewed easily in the web browser. The
file type is also determined, but currently only supports files with a jpeg or jpg extension. A
SHA1 hash is also calculated and displayed in the table.
A link to Google Maps with the latitude and longitude coordinates is also included in the output.
To determine how the URL (Uniform Resource Locator) is formed, the author went to Google
Maps and entered a sample location in the search bar:
loc: 0, 0
27
This brought up the location on the map. Using the share button, a URL to get back to this point
on the map was generated. After trial and error of removing any unnecessary data, it was
determined that the URL to view specific point on the map used the following format:
https://maps.google.com/maps?f=q&q=loc:X,Y
Where X and Y are the latitude and longitude coordinates. With this, the script could provide a
link to the coordinates on Google Maps that belong to the coordinates extracted in the script. The
script was run as follows:
python picture-gps-parser.py -t
/home/jason/Desktop/pictures/ -f sd_pictures
Running the three pictures through the script produced the output HTML seen in figure 8.
Figure 8 - Output file of picture-gps-parser script
28
The middle picture is the picture of the Ducati with no GPS info, so the coordinates None, None
are displayed and a link to Google Maps is not present. GPS data was obtained from the other
two pictures. The first picture is the one taken of the New York Stock Exchange. The link to
Google Maps displays the location, as seen in figure 9. The coordinates put me inside the
building, but the picture was actually taken outside in the middle of the street closer to the corner,
since the street was blocked off by temporary concrete barricades and police cars.
Figure 9 - Location data displayed in Google Maps
In both cases, the location data was accurate enough to find roughly where the pictures were
taken, but not accurate enough to find the exact position the picture was taken from. The
locations were at least a hundred feet off. This may be an accuracy limitation from the GPS
antennae.
29
3.1.4 Summary of Results Using this Method
The data that was stored on the SD card was very limited. It mostly consisted of pictures and
music. Using the Autopsy browser, all three pictures were recovered. Location data was
recovered from the two pictures that had location data. No additional interesting information was
recovered, but depending on how the user uses the SD card, there could be additional data of
interest. This method can be used even if the Android device uses a screen lock.
3.2 USB Drive Acquisition with dd
Android phones are typically powered by a standard USB cable. The phone used for this project
uses a standard Micro-USB cable. Android also supports connecting a device to a computer over
that USB cable to be used as a storage device to easily move files between the two. Having done
USB drive acquisitions with dd in the past, the author decided to see if it would work with the
Android phone as a USB device.
3.2.1 Acquiring USB Data
Accessing the phone in USB mode requires screen access to the phone. After connecting the
phone to the computer, a button on a screen that pops up is required. If a lock screen is present,
then this method will not work, unless the lock is bypassed.
Once connected, the process of acquiring data was almost identical to the SD card acquisition.
Because an SD card is being used, two removable devices were mounted, one for the phone
memory, and one for the SD card. Using the mount points as a guide, the mount command
displayed the device file for both removable devices. From these, images were obtained using dd.
30
A new case was created in Autopsy, and both these images were added.
3.2.2 Examining Data in Autopsy Browser
The data for the SD card image was identical to the image retrieved directly from the SD card.
As a result, all target data that was found using the previous method was also found in this
method.
The data acquired from the phone memory was limited, which was expected. The only piece of
target data that was found on this image was the Evernote target data. The file was found using a
keyword search for the string “test-evernote-keyword.” The data was stored in an XML file. The
location for the file was:
/Evernote/user-6858932/notes/78e/78e3c4a9-6e38-431ca809-17ce6e4b4b89/content.enml
The contents of the file were:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ennote SYSTEM
"http://xml.evernote.com/pub/enml2.dtd"><en-note
style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;"><div>
test-evernote-keyword</div></en-note>
The data was clearly saved as plain text. Another deleted copy of the file was found in a draft
folder:
31
/Evernote/user-6858932/notes/_11/411dabe8-127f-4eb7b743-d2d830917338/draft/content.enmltemp
Some data other than target data was found that was interesting and worth mentioning.
For example, during regular use of the phone, an alarm app called Alarm Clock Xtreme was used.
This app kept a log of all alarm events. This was found at:
/AlarmClockXtreme/log.txt
Deleted music files, which were deleted after being transferred to the SD card, were found at:
/amazonmp3
Some PDF files, such as travel itinerary, had been downloaded at various times to the phone and
later deleted. These files were found as undeleted files at:
/.Trash-1000/files/
Information for these files, including deletion date was located at:
/.Trash-1000/info/
3.2.3 Summary of Results Using This Method
This method recovered all the pictures found in the previous method, as the data acquired was
identical to the previous step. So, if the phone screen is unlocked, then the SD card removal is
not necessary. This may not be the case on different devices, or on different versions of Android,
however. Evernote target data was retrieved using this method. What is of concern is that files
were moved to trash instead of being actually deleted. If sensitive information was downloaded,
it may be recoverable there.
32
3.3 Forensic App
This next method takes advantage of a data sharing feature available to Android apps. Apps that
need to share data with other apps typically do so using what is called a Content Provider. What
is being taken advantage of here is that a lot of data on the device use these Content Providers.
The reason why is actually very simple. For example, all text messages are stored on the phone.
If a user found a better app for sending and receiving text messages, this new app needs access to
these text messages and needs to store new ones. Using a Content Provider solves this problem.
As a result, it enables easy access to a lot of data.
The Forensic app used in this method was the Open Source Edition of viaForensics AFLogical.
To use the app, the screen needs to be unlocked, as it requires user interaction on the device itself.
3.3.1 App Setup
The app was downloaded from viaForensics’ website [17]. Because the phone was in airplane
mode, the app could not be installed directly from the phone. The tool adb was used to install the
app. Although adb is explained in more detail in a later method, the command used was:
adb install AFLogical-OSE_1.5.2.apk
Android apps are contained in apk packages. The app can then be started on the phone (note:
access to the phone screen is required).
33
Figure 10 - Interface for AFLogical
Once the app is started, the user is presented with the screen shown in figure 10. The Open
Source Edition only supports call logs, contact info, as well as MMS and SMS data. The Law
Enforcement Edition supports many more types of data, such as calendar events and browser
bookmarks. Once the desired data types are selected, the user can press the capture button. This
saves data to the phone memory, which in most cases would not be desirable.
34
3.3.2 Examining Forensic App Results
The results are saved into a folder on the phone’s internal memory named forensics. A subfolder
is named after the date and time that the capture took place. Inside this folder are many files.
The text data is stored in csv, or comma-separated values, files. A single file called info.xml
which stored lots of information about the phone and apps installed on it.
The SMS.csv file contained all text messages on the phone. The target data was easily found
under the body section, as shown in figure 11. Unfortunately the connection between messages is
hard to determine. A script may be needed to sort through all the rows and create a timeline
between the two addresses. Also, the format used for the date field is not clear. Initially this was
thought to be UNIX time, but doing a conversion resulted in a date in the year 44,804. The other
text message that was not deleted was also in this file.
Figure 11 - SMS message with "verification" keyword
35
The CallLog Calls.csv file contained a list of all calls made and received on the phone. Finding
the particular call log was difficult as the date/time formatting was the same. To narrow the
results down, the call log duration was used, which was a minute and ten seconds, and resulted in
the call log entry using that as shown in figure 12. The duration field is represented in seconds.
Figure 12 - Target call log data
3.3.3 Summary of Results Using this Method
The forensic app was able to recover the data it supported that was not deleted. It was able to
recover the call log and text messages that were not deleted. The date time stamp used is unclear,
so using that to find data was not helpful. For the app to be useful, someone who wants to use
this tool would probably be better off creating a script to parse the data, rather than do it
manually. Because the types of data recovered by this app were minimal, the data was sorted
through manually. For data preservation, it would be better if the data was stored on the SD card.
After examining the file structure in later methods using adb, it is likely because the phone
36
memory partition that is accessible to normal users is mounted as “sdcard,” where the actual SD
card is mounted as “_ExternalSD.” The app may actually save to SD cards on other devices, but
the configuration for this phone prevented that.
This particular app required use of the phone’s screen to run the app. It may be possible to install
an app that requires no user interaction and just copies data to the SD card. The adb tool has a
command for running an application on a device with adb enabled that is connected to a
computer.
3.4 Oxygen Forensic Suite
A free version of Oxygen Forensic suite is available on their website [18]. This tool simplifies
the data retrieval and examination process, making it very easy to use. Although free, it did
require registering so the key could be emailed. The Forensic Suite software was installed on
Windows 7.
3.4.1 Acquiring Data Using Oxygen Forensic Suite
After connecting the phone, clicking on a button to connect a new device, and clicking next a
couple times, the included Oxygen Forensic Extractor did all the work. The Extractor, shown
running in figure 13, supports rooting the device, to obtain more information, but that feature is
only available to those who have the full analyst version, so the option was greyed out.
37
Figure 13 - Extracting data using Oxygen Forensic Suite
3.4.2 Examining Data Acquired Using Oxygen Forensic Suite
The data obtained is displayed and organized nicely in the primary window. As shown in figure
14, many options were disabled with the free license that was used. Clicking on the Calendar
under “Organizer,” displayed a list of all calendar events.
38
Figure 14 - Primary case window for Oxygen Forensic Suite
Using the filter text box in the upper right corner of the window, a filtered list for “geckos”
displayed all calendar events with that word in it. Selecting an event and clearing the filter text
box showed the event in the list of all events, as shown in figure 15.
39
Figure 15 - Target calendar event with keyword “geckos”
The process was repeated for text messages by selecting the Messages option. Two out of four
messages were retrieved. The filtered results for one of these messages can be seen in figure 16.
The two messages that were not retrieved had been deleted. It found one out of three pictures.
The pictures it did not find had been deleted. It also was able to recover the XML file that
contained the keyword for the Evernote target data.
40
Figure 16 - Target SMS message with keyword "Zooey"
3.4.3 Summary of Results Using this Method
The Oxygen Forensic Suite was able to recover a lot of data that was not deleted. It recovered all
non-deleted data found in previous steps: the two text messages, phone call log, one picture, and
the Evernote note. It also found target data for the calendar event, which no previous method
recovered.
3.5 adb pull
The adb, or Android Debug Bridge, tool is included with the Android SDK [5]. The tool is useful
for developers as files and apps can be moved to and from the device easily. For this method, the
access to files on the device is utilized. To use this method, USB debugging must be enabled, or
would require screen access to the device to then enable USB debugging.
41
3.5.1 adb Setup
To enable adb on an Android device, USB debugging needs to be enabled. The option is usually
under a development options area. On the phone used for the project, it was under Applications,
then under Development. Once this is enabled, the connection can be tested using the command
“adb devices” as shown in figure 17. If successful, the serial number of the connected device
should be displayed. If the device is connected and detected but some issue was encountered, the
serial number will be replaced with question marks. If the device is not detected, nothing will
show up in the list of devices.
Figure 17 - Result for "adb devices" command
If the device was successfully detected and shows the serial number, then the next step is to
acquire the data.
3.5.2 Acquiring Data Using adb
A shell on the phone can be used with the command:
adb shell
Using the ls command displays the directory listing. Using those results, the cd command can be
used to try changing to subdirectories on the phone. Because the phone has not been rooted and
the shell is not running with higher privileges, most of the directories could not be accessed.
42
To copy files from the phone to the host computer, the command “adb pull” can be used from the
host computer's shell or command prompt. For example, to copy the directory mnt and its
contents the following command can be used:
adb pull /mnt
This will save all the files into the current working directory on the host computer. Unfortunately
it was not so easy and required a lot of trial and error. For example, some subdirectories in a
given directory could be accessed and others could not. If a subdirectory was not accessible, the
pull command would receive an error and stop. Whenever this happened, pull was attempted on
individual subdirectories with occasional success.
During the trial and error process, it was discovered that the contents of the phone memory and
SD card memory that were recovered with the USB drive method are both mounted under
/mnt/sdcard/. The actual microSD card contents are under /mnt/sdcard/_ExternalSD/. The reason
for this is unknown, but it was confusing and worth mentioning.
3.5.3 Examining adb pull Contents
Due to being a limited user and using the pull command, only a limited amount of data could be
retrieved. The only target data found was the one picture that was not deleted and the Evernote
target data. No new target data was recovered using this method. Because pull is only copying
files and not the filesystem, no deleted content could be recovered.
43
3.6 Root adb pull
It is possible to obtain elevated privileges with an Android device. With these higher privileges,
more data can be accessed, which is utilized in this method.
3.6.1 Rooting the Phone
Rooting, or obtaining superuser access, can be done on most, if not all, Android devices.
Typically this is done by taking advantage of some vulnerability. A developer who goes by the
username shortfuze created a utility [19] that automates the process on many devices.
Unfortunately the last update was in 2010, so it may not work on newer devices.
The utility runs on Windows. It uses adb, which it includes, so USB debugging must be enabled
for the utility to work. Once a phone is connected, all it requires is clicking the “Root” button
(see figure 18) and wait for it to finish. The process will reboot the phone.
44
Figure 18 - Rooting the phone
Once done, a new app called Superuser will be installed, and root can be obtained through adb.
As in the previous method, adb pull can be used to acquire data. The difference, however, is that
now errors will not occur due to permissions.
3.6.2 Examining the Results of adb pull as Root
The data extracted using adb pull as root was much more extensive. For the most part, the extra
data included system level files that are not relevant to this project. However, it did produce a
copy of the data directory, which contains data for many apps. The single picture that was not
45
deleted was also recovered using this method and was found in the same place mentioned in
earlier methods.
The first item that stood out was a database found under /data/system/accounts.db. Using the
SQLite Database browser, the data was displayed in rows and columns that made it easy to see, as
shown in figure 19. Under the accounts table, account names and what looked like password
hashes were displayed. This was not part of the target data, but was worth mentioning, as these
values may lead to recovery of the actual password through an offline brute force search.
Figure 19 - Accounts.db
The next database examined was for calendar data. This was found under
/data/data/com.android.providers.calendar/databases/calendar.db. Here the calendar event
database entry for “Feed Geckos” was found, as seen in a previous method. This was stored in
the “Events” table.
Call log data was found in the /data/data/com.android.providers.contacts/databases/contacts2.db
database file. The call log was under the “calls” table.
46
A database file located at /data/data/com.android.providers.downloads/databases/downloads.db
contained a list of all files that have been downloaded under the “downloads” table. Although
this was not part of the target data, it was worth mentioning.
The two SMS messages that were not deleted were found under
/data/data/com.android.providers.telephony/databases/mmssms.db. They were found under the
“sms” table.
The Facebook target data was not found, but other items worth mentioning were found. The
database located at /data/data/com.facebook.katana/databases/bookmarks.db. Under the
“bookmarks” table lists all groups that the author belonged to. The database file under
/data/data/com.facebook.katana/databases/fb.db contained some data for picture posts. Under the
“photos” table, previous posts that included a picture were found. In that same database under the
“friends_data” table included friend information that included user id, first and last name, cell
phone number, email address, and birthday. A screenshot of this is shown in figure 20. The
content has been marked out to protect others’ privacy. Private messages to a single user can be
found under the “messages” table in the database file located at
/data/data/com.facebook.katana/databases/threads_db2.
47
Figure 20 - Facebook friend data in fb.db
Location data was recovered from the database file located at
/data/data/com.google.android.apps.maps/databases/search_history.db. Under the “suggestions”
table were places searched for using the Google Maps app, as shown in figure 21. There were
two Google Latitude databases that were empty. Had Google Latitude been used, location data
would likely be stored there.
48
Figure 21 - Target location data in search_history.db
49
The Skype chat log was found under /data/data/com.skype.raider/files/jal-test/main.db. Under the
“Messages” table, entries are stored for all messages sent and received, as shown in figure 22.
There was no Skype data prior to starting the project, so few entries were created.
Figure 22 - Target Skype data with keyword "test-skype-keyword" in main.db
Email messages are stored under
/data/data/com.google.android.gm/databases/mailstore.USERNAME@gmail.com.db, where
USERNAME is the username associated with the email account. Under the “conversations”
table, a small number of messages were present, as shown in figure 23. These were messages in
the inbox and contained the target email that was not deleted.
50
Figure 23 - Target email data with keyword "Woot" in mailstore.USERNAME@gmail.com.db
3.6.3 Summary of Results Using this Method
This method was able to recover email messages, SMS messages, a picture, a calendar event,
location data, and a Skype chat log. Deleted files were not recovered using this method, as files
were copied, not the entire filesystem. Also, the target Facebook data was not recovered, but
other data, including other posts that were made, were recovered. A hex viewer was used to try
to find fragments of data that still existed as unused space in the database file. Unfortunately this
was not the case. As mentioned in the Frequently Asked Questions page [25], if SQLITE
51
SECURE DELETE or VACUUM is used, then recovery is impossible. This may have been the
case.
3.7 Root adb dd
The command dd is available on Android, but without root privileges, is very limited. With root
access, dd can be used to obtain physical copies of filesystems that are mounted on the system.
3.7.1 Acquiring Data Using dd Through adb shell
Once a shell is opened on the Android phone using adb shell, the steps were similar to those in
previous methods where dd were used. The mount command was used to find device files. For
example, the data partition used /dev/block/mmcblk0p7. Before using dd to acquire the data, a
new microSD card was inserted into the phone. With this, dd images can be saved to the SD card
and easily moved. To use dd to obtain the data partition the following command was used:
dd if=/dev/block/mmcblk0p7
of=/sdcard/_ExternalSD/data.dd
The files can be pulled using adb pull, or mounted as a USB drive and copied. From here, the
files were added to the Autopsy browser and examined.
3.7.2 Examining Results of dd as Root
Because dd was used, deleted files could be recovered. In the data partition image, deleted
directories of uninstalled apps were found under the data directory, as shown in figure 24. Some
of these directories were displayed, but could not be accessed. None of these were particularly
interesting or involved target data, however.
52
Figure 24 - Uninstalled apps’ deleted directories
Some of the directories that contained the databases had deleted journal files. Most of these were
empty. The few that were recoverable had none of the deleted target data. All database files
found in the previous method were also recoverable using this method.
3.7.3 Summary of Results Using this Method
Almost all of the target data found using adb pull as root was also found in this method. The only
data that was not recovered were the pictures, as they were stored on the microSD card that was
removed to put in the new microSD card. Had these pictures been on the phone memory, which
is the case for users who do not put in an SD card, they would have been recoverable.
53
CHAPTER 4
CONCLUSION
4.1 Summary
The goal of this project was to determine what data can be retrieved from an Android device. An
Android phone, the T-Mobile G2x, was used for this project. Data was selected from data that
existed on the phone already, as well as new data that was created just for the project. This data
consisted of: email messages, text messages, a phone call log, some pictures, a calendar event,
various location data, a Skype instant message, a Facebook post, and a note created in Evernote.
Deleted data was also used in this project. The deleted data consisted of an email message, two
text messages, and two pictures.
Data was retrieved using various methods. These methods were: acquiring data directly from the
microSD card, acquiring data from the phone connected to a computer as an external USB drive,
acquiring data through a forensic Android app, acquiring data through a free version of a
commercial forensic suite, acquiring data through adb pull, acquiring data through adb pull after
the phone was rooted, and finally acquiring data through adb using dd on the phone after it was
rooted. The methods that acquired the most of the target data were the last two that used adb after
the phone was rooted. This was because most of the data used for this project was stored in
SQLite database files located in a restricted partition. The deleted email message, and text
messages were not recovered using any method. This was likely due to a configuration option in
SQLite. The Facebook post was not recovered either. This was potentially due to it not having
been saved to the device in the first place. Although the target Facebook post was not recovered,
other information and posts, which included pictures, were.
54
4.2 What Android Users Should Know
So what does this mean to users? First, users should know that most of the data on the phone is
vulnerable to someone who is sufficiently knowledgeable and motivated to obtain that data. At
the very least, a screen lock of some kind should be used, knowing that it only offers little
protection. If it is not being used, USB debugging should be disabled. Utilizing device
encryption on newer devices is better, although still vulnerable to methods, such as using the
FROST tool. In cases where confidentiality is warranted, such as in corporations or government
agencies, caution should be used when using portable devices. If possible, use or create apps that
ensure data security through strong encryption or by not storing data to the device.
4.3 Advantages and Disadvantages of Methods Used
The methods used in this project fell into two categories, logical and physical. Logical methods
merely copied files or data. The logical techniques used were the two methods that relied on adb
pull, as well as the forensic app. The free version of the Oxygen Forensic Suite also used a
logical acquisition method, but may be capable of physical acquisition in the full, paid version.
An advantage of these methods is that they are easy to perform. The methods can also be used
when a device is not rooted. The disadvantage is that these methods do not recover deleted files.
Physical methods acquire data how it exists on the storage medium, by copying all data from the
partition, not just files. This results in a bit for bit copy. This can typically be done by acquiring
the entire partition. This way the deleted files can also be acquired. The physical techniques
used in this project involved the use of the tool dd. The advantage of these methods is that the
deleted files can be recovered using dd. The primary disadvantage is that it requires a lot of
storage space for the resulting image files, as they constitute an identical copy of a partition,
55
including files, deleted files, and unused space. For this project, when dd was used through the
Android phone, it required root privileges. On a device that has not been rooted, the method will
not work.
Because only the microSD card is removable, acquisition of data becomes difficult. If the screen
lock cannot be bypassed in time, and USB debugging is not enabled, the only method that will
work is to use dd to image the SD card. If USB debugging is enabled, then adb can be used.
With only adb debugging enabled, it may be possible to root the device. Then, the screen lock
settings can be manipulated or deleted, and then any method can be used. This is an unlikely
scenario, as most users should have USB debugging disabled. Alternately, if the screen can be
bypassed another way, then USB debugging can be enabled, leading to more methods that can be
used.
4.4 Future Work
This project was a good learning opportunity, and while working on this project, ideas for future
work and improvements have emerged.
4.4.1 Other Devices
The sample size used in this project was, admittedly, small. This decision was due to time and
money. The project can be improved by trying these methods on other devices, specifically
newer devices, to determine what can be acquired from those devices, and if the methods work.
56
4.4.2 SQLite Deleted Data Recovery
Recovering deleted data stored in SQLite databases was not possible for this project. It would be
good to know when and how this can be done, and whether it can ever be done on an Android
device.
4.4.3 Other Apps
Only a few third-party apps were used as sources of data in this project. With all the possible
apps available, and new apps being created every day, there are more opportunities to examine
the data stored by these apps.
4.4.4 Network Attacks
These devices spend all or some of their time on networks. It would be interesting to know what
network based attacks can be used on these devices. If access can be granted through one of
these attacks, what kind of data can be retrieved?
4.4.5 Factory Reset
Android devices usually have an option to perform a factory reset. Using this option and
obtaining a physical copy of the partitions would reveal if the data is overwritten or not.
57
APPENDIX A
Source code for picture-gps-parser.py [24]
#
# Description: Parses EXIF data on pictures to get GPS location data. Outputs an HTML file containing
#
# By: Jason Landsborough
# Last updated: 06/28/13
#
# Forked from script (get_lat_lon_exif_pil.py) posted by Eran Sandler, here: https://gist.github.com/erans/983821
#
# Parameters:
-r
-- (Optional) Enable recursion
#
-t DIRECTORY_NAME
-- (Optional) Parse files in DIRECTORY_NAME
#
-o OUTPUT_DIRECTORY -- (Optional) Specify the directory OUTPUT_DIRECTORY for the
output file
#
-f OUTPUT_FILE
-- (Optional) Ouput file as OUTPUT_FILE.html
#
import os
import datetime
from PIL import Image
from PIL.ExifTags import TAGS, GPSTAGS
import hashlib
import sys
### GLOBAL VARIABLES AND CONFIG OPTIONS ###
global_target = os.getcwd() #Default is same directory current working directory
global_recursion = 0
#1 to enable
0 to disable
global_output_dir = os.getcwd()
#Default is same directory current working directory
global_output_file = "out.html" #gets overridden with time-stamp-named file
#from "get_lat_lon_exif_pil.py" by Eran Sandler (https://gist.github.com/erans/983821)
def get_exif_data(image):
"""Returns a dictionary from the exif data of an PIL Image item. Also converts the GPS Tags"""
exif_data = {}
info = image._getexif()
if info:
for tag, value in info.items():
decoded = TAGS.get(tag, tag)
if decoded == "GPSInfo":
gps_data = {}
for t in value:
sub_decoded = GPSTAGS.get(t, t)
gps_data[sub_decoded] = value[t]
exif_data[decoded] = gps_data
else:
exif_data[decoded] = value
return exif_data
def _get_if_exist(data, key):
58
if key in data:
return data[key]
return None
def _convert_to_degress(value):
"""Helper function to convert the GPS coordinates stored in the EXIF to degress in float format"""
d0 = value[0][0]
d1 = value[0][1]
d = float(d0) / float(d1)
m0 = value[1][0]
m1 = value[1][1]
m = float(m0) / float(m1)
s0 = value[2][0]
s1 = value[2][1]
s = float(s0) / float(s1)
return d + (m / 60.0) + (s / 3600.0)
def get_lat_lon(exif_data):
"""Returns the latitude and longitude, if available, from the provided exif_data (obtained through get_exif_data
above)"""
lat = None
lon = None
if "GPSInfo" in exif_data:
gps_info = exif_data["GPSInfo"]
gps_latitude = _get_if_exist(gps_info, "GPSLatitude")
gps_latitude_ref = _get_if_exist(gps_info, 'GPSLatitudeRef')
gps_longitude = _get_if_exist(gps_info, 'GPSLongitude')
gps_longitude_ref = _get_if_exist(gps_info, 'GPSLongitudeRef')
if gps_latitude and gps_latitude_ref and gps_longitude and gps_longitude_ref:
lat = _convert_to_degress(gps_latitude)
if gps_latitude_ref != "N":
lat = 0 - lat
lon = _convert_to_degress(gps_longitude)
if gps_longitude_ref != "E":
lon = 0 - lon
return lat, lon
#end of get_lat_lon_exif_pil.py functions
#Function:
get_from_file(current_file)
#Parameters:
current_file - Path to a file
#Description:
Checks if current_file is an image, if so, tries to extract EXIF data from it
#
def get_from_file(current_file):
59
#Check if the file is an image (currently only jpegs, need to test other files if they support EXIF)
if ".jpeg"in current_file.lower() or ".jpg" in current_file.lower():
fout.write("<tr>")
f = open(current_file)
path = os.path.abspath(current_file);
print "f:" + str(f)
#get full path for file so it can be used for as html link to view image in the browser
filename = os.path.basename(path)
#get file hash
sha1 = hashlib.sha1()
try:
sha1.update(f.read())
finally:
f.close()
sha1hash = sha1.hexdigest()
print "f:" + str(f)
#Open image, extract EXIF, and output results
try:
#write row
##IF MORE TYPES ARE ADDED, change this to determine filetype
filetype = "jpeg"
img = Image.open(current_file)
exif_data = get_exif_data(img)
location = get_lat_lon(exif_data)
#check if EXIF data exists, if not skip the file
if(exif_data != {}):
make = exif_data['Make']
model = exif_data['Model']
pic_dt = exif_data['DateTime']
pic_dt2 = exif_data['DateTimeDigitized']
DateTime... might remove after extensive testing
pic_dt3 = exif_data['DateTimeOriginal']
same as DateTime... might remove after extensive testing
#Tends to be the same as
#Tends to be the
##print exif_data
fout.write("<td><a href=\""+path+"\">"+filename+"</a></td>")
fout.write("<td>" + filetype + "</td>")
fout.write("<td>" + pic_dt + " ("+pic_dt2+") ("+pic_dt3+")"+ "</td>")
fout.write("<td>" + str(location[0]) + ", " + str(location[1]) + "</td>")
#no GPS data, output nothing
if "none" in str(location).lower():
fout.write("<td></td>")
else:
#GPS data, link to coordinates on google maps
fout.write("<td><a
href=\"https://maps.google.com/maps?f=q&q=loc:"+ \
str(location[0]) + "," + str(location[1])
+"\">Google Maps</a></td>")
fout.write("<td>" + make + "</td>")
fout.write("<td>" + model + "</td>")
fout.write("<td>" + sha1hash + "</td>")
else:
print "No EXIF data for " + current_file + ", not processing picture further"
except IOError:
print "Unable to open file (" + path + "). This might be due to missing/corrupted EXIF
data. Skipping"
60
fout.write("</tr>") #end table row
#get date and time
now_time = datetime.datetime.now()
now_dt = now_time.strftime("%Y-%m-%d_%H-%M")
#look for command line arguments
if(len(sys.argv) != 1):
print str(len(sys.argv))
print str(sys.argv)
#check for recursion
if('-r' in sys.argv):
print "Recursive traversal enabled"
global_recursion = 1
#check for target dir
if('-t' in sys.argv):
target_index = sys.argv.index('-t')
temp_global_target = sys.argv[target_index + 1]
#check if valid directory
if(os.path.isdir(temp_global_target)):
global_target = temp_global_target
print "Target directory: " + str(global_target)
else:
print "Invalid target directory"
exit()
#no target directory specified, make sure global_target is actually a directory
else:
#check if valid directory
if(not os.path.isdir(global_target)):
print "Invalid target directory"
exit()
#check for output directory
if('-o' in sys.argv):
target_od = sys.argv.index('-o')
temp_gtd = sys.argv[target_od + 1]
#check if valid directory
if(os.path.isdir(temp_gtd)):
global_output_dir = temp_gtd
print "Output Directory: " + str(global_output_dir)
else:
print "Invalid output directory"
exit()
else:
#check if valid directory
if(not os.path.isdir(global_output_dir)):
print "Invalid output directory"
exit()
#check for output filename
if('-f' in sys.argv):
target_file = sys.argv.index('-f')
global_output_file = sys.argv[target_file + 1]
else:
global_output_file = "images_" + now_dt
61
#open output file
fout = open(global_output_dir + "/" + global_output_file + ".html", "w")
#write initial HTML code to file
fout.write("<HTML><BODY>")
fout.write("<table border=\"1\">")
fout.write("<tr><b><td>Image</td><td>Type</td><td>Date Taken</td><td>GPS
Coordinates</td><td>map</td><td>Make</td><td>Model</td><td>SHA1 Hash</td></b></tr>")
#if recursion
if(global_recursion == 1):
#for all files in the current directory and subdirectories
for curdir, thedir, files in os.walk(global_target):
for thefile in files:
get_from_file(curdir + "/" + thefile)
#if no recursion
elif(global_recursion == 0):
#for all files in the current directory and subdirectories
for thefile in os.listdir(global_target):
get_from_file(global_target + "/" + thefile)
#if bad recursion option
else:
print "Unknown recursion option"
#add last of HTML code and close file
fout.write("</table>")
fout.write("</BODY></HTML>")
fout.close()
62
REFERENCES
[1] - J. Rubio, (2011, Dec.) “The History of Android,” IGN. [Online]. Available:
http://www.ign.com/articles/2011/12/23/the-history-of-android
[2] - B. Cha (2013, Sept.) “Samsung Takes Wraps Off Galaxy Gear Smartwatch,” All Things D.
[Online]. Available: http://allthingsd.com/20130904/samsung-takes-wraps-off-galaxy-gearsmartwatch/
[3] - (2013, Aug) “Glass Development Kit,” Google Developers. [Online] Available:
https://developers.google.com/glass/gdk
[4] - “Android Architecture,” Embedded Linux Wiki. [Online]. Available:
http://elinux.org/Android_Architecture
[5] - “Android SDK,” Android Developers [Online]. Available:
https://developer.android.com/sdk/index.html
[6] - D. Bornstein, “Dalvik VM internals,” Google I/O 2008. [Online]. Available:
https://sites.google.com/site/io/dalvik-vm-internals
[7] - A. Fogel, J. S. Foster, J. Jeon, K. K. Micinski, T. Millstein, N. Reddy, J. A. Vaughan, “Dr.
Android and Mr. Hide: Fine-grained Permissions in Android Applications,” Proceedings of the
second ACM workshop on Security and privacy in smartphones and mobile devices (SPSM ‘12),
pp. 3-5, 2012.
[8] - N. Christin, T. Vidas, C. Zhang, “Toward a general collection methodology for Android
Devices,” Digital Investigation, vol. 8, pp. 14-24, August 2011
[9] - D. Kitchen (2012, Dec.) “Hak5 1217 - Hack any 4-digit Android PIN in 16 hours with a
USB Rubber Ducky” Hak5. [Online]. Available: http://hak5.org/episodes/hak5-1217
[10] - “[GUIDE][HOW-TO]Crack android pattern lock!” XDA-Developers [Online]. Available:
http://forum.xda-developers.com/showthread.php?t=1800799
63
[11] - T. Müller, M. Spreitzenbarth, and F. Freiling (2012, Oct.) “FROST” Friedrich-Alexander
University of Erlangen-Nuremberg. [Online]. Available: https://www1.informatik.unierlangen.de/frost
[12] - “LG G2X P999” LG. [Online]. Available: http://www.lg.com/us/cell-phones/lg-P999-g2x
[13] - A. Hoog “Logical Techniques” in Android Forensics, 1st ed. Waltham, MA: Elsevier,
2011, pp. 218-228
[14] - “dd invocation” GNU Coreutils. [Online]. Available:
https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html
[15] - “Autopsy” Sleuthkit. [Online]. Available: http://www.sleuthkit.org/autopsy/
[16] - “Android Debug Bridge” Android Developers [Online]. Available:
https://developer.android.com/tools/help/adb.html
[17] - “AFLogical” viaForensics [Online]. Available:
https://viaforensics.com/resources/tools/android-forensics-tool/
[18] - “Free Oxygen Forensic Suite” Oxygen Forensics [Online]. Available: http://www.oxygenforensic.com/en/download/freeware
[19] - “SuperOneClick” shortfuse [Online]. Available: http://shortfuse.org/?page_id=2
[20] - “SQLite Database Browser” Sourceforge [Online]. Available:
http://sourceforge.net/projects/sqlitebrowser/
[21] - “EXIF and related resources” EXIF.org. [Online]. Available: http://www.exif.org/
[22] - J. Friedl “Jeffrey’s Exif viewer” regex.info. [Online]. Available: http://regex.info/exif.cgi
[23] - E. Sandler “Get Latitude and Longitude from EXIF using PIL” Github Gist [Online].
Available: https://gist.github.com/erans/983821
[24] - J. Landsborough “picture-gps-parser” Github [Online]. Available:
https://github.com/jlandsborough/picture-gps-parser
64
[25] “SQLite Frequently Asked Questions” sqlite.org [Online]. Available:
https://www.sqlite.org/faq.html#q20