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 [email protected] 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 T-
Mobile [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 SMS verification; No Messaging app
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
Picture with GPS info Picture N/A No Camera
Deleted Picture Picture N/A Yes Camera
Deleted Picture 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
test-facebook-
Facebook Facebook keyword No Facebook
test-evernote-
Evernote Notes keyword No Evernote
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 non- volatile 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-skype- keyword.” 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 non- volatile 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-431c-
a809-17ce6e4b4b89/content.enml
The contents of the file were:
note SYSTEM
"http://xml.evernote.com/pub/enml2.dtd"> style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> test-evernote-keyword
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-4eb7-
b743-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/[email protected], 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 [email protected]
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("
#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'] #Tends to be the same as DateTime... might remove after extensive testing pic_dt3 = exif_data['DateTimeOriginal'] #Tends to be the same as DateTime... might remove after extensive testing
##print exif_data fout.write("
#no GPS data, output nothing if "none" in str(location).lower(): fout.write("
60
fout.write("
#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("
") fout.write("| Image | Type | Date Taken | GPS Coordinates | map | Make | Model | SHA1 Hash |
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-gear- smartwatch/
[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.uni- erlangen.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.oxygen- forensic.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