INTRODUCTION TO MOBILE FORENSICS

FORENSIC ANALYSIS OF ANDROID APPLICATIONS

Alejandro Guerra Manzanares – alejandro.guerra@taltech.ee

THE ART OF APPLICATION ANALYSIS

 There are myriad ways an application can store, or obfuscate, its data. Different versions of the same application
may even store the same data differently.
 Developers are only limited by their imagination and Android platform restrictions to choose how to store data.
 Because of these factors, application analysis is a moving target; methods an examiner uses one day may be
completely irrelevant the next.
 The end goal of forensically analyzing an application is consistently the same: to understand what the app was
used for, and to find user data.
 Thus, forensically analyzing an application is as much of an art as it is a science.
COMMON DATA STORAGES

 There are several ways for applications to store the data. Nevertheless, the most common and used ones are:

 Internal storage: storage of app data in the phone’s internal memory.

 The internal data of all apps present on the device (either system apps or user-installed apps) is automatically saved in a subdirectory of /data/data
named after the package name.
 Data stored here is private and cannot be accessed by other applications.
 Even the device owner is prevented from viewing the files (unless they have root access).
 However, based on the requirement, the developer can allow other processes to modify and update these files.
 The internal data of each app is stored in their respective folders. The common ones are:
 Databases : SQLite and journal files
 Lib : Custom library files required by an app
 Shared_pref : XML file of shared preferences
 Cache : Files cached by app
 Files : Developer saved files

 Folders other than these are custom folders created by the app developer.
COMMON DATA STORAGES

 Shared preferences: storage of key-value pairs of primitive data types in XML format.
 Primitive data types includes Boolean, float, int, long, and string.
 Strings are stored in the Unicode Transformation Format (UTF) format.
 These files are typically stored in an application's /data/data/<AppPackageName>/shared_pref folder.
 These files can be viewed using the cat command.
 May contain relevant forensic data such as account names or even passwords.
COMMON DATA STORAGES

 SQLite databases: open source, compact, functional and popular database format used to store structured data in many
mobile systems.
 Android supports SQLite through dedicated APIs and hence developers can take advantage of it.
 They often store lot of important data handled by the application.
 SQLite databases are a rich source of forensic data.
 The SQLite files used by apps are generally stored under /data/data/<AppPackageName>/databases folder (typically using .db extension).
 This data can be viewed using tools such as DB Browser for SQLite or executing SQLite commands on the file.
 https://sourceforge.net/projects/sqlitebrowser
COMMON DATA STORAGES

 External storage: storage of data in removable media (i.e., SD cards) or non-removable storage that comes with the phone.
 In the case of a removable SD card, data could be used on other devices just by removing the SD card and inserting in any other device.
 SD cards are usually formatted with the FAT32 filesystem but other filesystems such as EXT3 and EXT4 are also being increasingly used.
 Unlike internal storage, external storage does not have strict security enforcements. Data stored here is public and can be accessed by
other applications provided the requesting apps have the necessary permissions.
 These data is available in the /sdcard directory.
 Within the SD card, data can be stored in any location.
COMMON DATA STORAGES

 Every Android application stores data on the device using one or more of the preceding data storage options.
 For example, the Contacts application would store all of the information about the contact details in the /data/data folder under its
package name.

 Note that /data/data is a part of your device's internal storage, where all of the apps are installed under normal
circumstances (only accessible on a rooted phone).
 Some application data will reside on the SD card and in the /data/data partition.
 Worth to know: Since Android 7.0 (Nougat), a new storage type called device encrypted storage was introduced to allow
apps to store certain kinds of data in this storage.
 New file paths such as misc_de, misc_ce, system_de, and system_ce can be found under the /data folder.
 On devices running Android Nougat, /data/data is not the only location where artifacts are stored.
 For instance, SMS data location on old devices: /data/com.android.providers.telephony/databases/smsmms.db and SMS data location on Nougat devices:
/user_de/0/com.android.providers.telephony/databases/smsm ms.db.
DATA STORAGES AND ACQUISITION TECHNIQUES

 All user data can be recovered using either the appropriate logical or physical techniques.
 But: not all data can be acquired logically (i.e., some folders require privileged access).
 But: not all data may be acquired physically (i.e., depends on the skills of the examiner and collection technique used).

 Thus, there is no ultimate technique or work-for-all procedure on mobile forensics.

APP ANALYSIS

 Applications are not a static object. They can, and usually do, change how they store data through updates.
 So there is no single or best procedure to analyze them all.
 Even the same application may differ significantly in sequential releases.
 Nevertheless, there are some common frameworks used by developers (specially in legitimate applications) that
are worth to know and may be deemed as useful to analyze successfully most of them.
WHY APP ANALYSIS?

 1. Everything in an Android device is an application. Even standard phone functions such as contacts, calls,
and SMS are done through applications on Android devices, so even acquiring basic data requires analyzing an
application.
 2. Apps can reveal a wealth of data about the user. A person's app usage can tell you a lot about them:
where they've been (and when they were there), who they've communicated with, and even what they may be
planning in the future.
 Most phones are sold with many pre-installed applications. There is no real way of knowing which of these apps could
contain information useful for an investigation, and therefore they must all be analyzed.
 Never skip any app that would appear to have little useful data, such as games. As many popular games have a built-in chat
feature, which could provide useful information.
 Experience says that messaging applications tend to be the most valuable in a forensic analysis.
APP ANALYSIS BASICS

 Location and name

 All apps store their data in the /data/data or /data/user_de/0 (newer devices) directory by default; apps can also use the SD
card if they ask for this permission when the app is installed.
 The package name is the name of the directory for the application in one of these directories.

 Determining which apps are installed

 Way 1: Navigate to /data/data and run the ls command.
 Way 2: Pull the /data/system/packages.list file.
 This file lists the package name for every app on the device and path to its data

 Way 3: Using ADB command: adb shell pm list packages –f

APP ANALYSIS BASICS

 Determining an application last time usage

 Check /data/system/package-usage.list file
 Shows the last time that package (or application) was used. But be aware that it is not 100% reliable, app updating or receiving
notifications (even if the user does not view them) may affect the recorded time. However it is good indicator of the last apps the user
accessed.Take into account that the recorded time is in UNIX epoch time

 Unix epoch time, also known as Unix time or Posix time, is stored as the number of seconds (or milliseconds) since midnight on January
1st, 1970 UTC. A 10-digit value indicates it is in seconds, while a 13-digit value is indicative of a millisecond value (at least for times likely
to be found on a smartphone, as 9-digit second and 12-digit millisecond values haven't occurred since 2001).
 For instance, the value 1422206858650; Google Chrome was last used 1 billion, 422 million, 206 thousand, 858 seconds, and 650
milliseconds since midnight on January 1st, 1970.
APP ANALYSIS BASICS

 To translate UNIX epoch time to an understandable time, there are many scripts and tools available for download that can convert this
into a human-readable format.
 For instance, DCode, a free tool that can be found here: http://www.digital-detective.net/digital-forensic-software/free-tools/. Another
useful online tool is http://www. epochconverter.com/.

 In DCode, simply select Unix: Millisecond Value from the dropdown list, type in the value in the Value to Decode field, and click Decode.
The Add Bias field can be selected to convert the time into the desired timezone.
 Converting the time, we can see that Google Chrome was actually last used on January 25th, 2015 at 17:27:38.650 UTC.
APP ANALYSIS BASICS – TIME FORMATS

 Unix epoch time is frequently used on Android devices to store date/time values. But is not the only one used.
 WebKit format is used on Google Chrome.
 An example of time:13066077007826684. It appears to be very similar to Unix epoch time. But it is not the same.
 Webkit time is an epoch time, it is just based on a different starting point than Unix epoch time. Webkit epoch time is the
number of microseconds since midnight on January 1st, 1601. Once we know where the epoch begins, converting to a
recognizable format simply becomes a math problem. Dcode can be used to convert it, as shown:
APP ANALYSIS BASICS – TIME FORMATS

 Julian Date format is used in Google Keep database (in some attributes only).
 Julian dates are similar to the Linux epoch format, simply starting from a different date. The Julian date system counts the
number of days since noon on January 1st, 4713 BC.
 This online tool can be used to get the appropriate date: http://aa.usno. navy.mil/data/docs/JulianDate.php.
 To obtain the Julian date from the database, simply combine the two columns with a decimal in between, for example:

 This would correspond to the Julian date 2457042.46800000.Which corresponds to January 19 2015 at 23:13:55.2 UT.
APP ANALYSIS BASICS – SQLITE DATABASES

 SQLite databases are a widely used way to store data in Android devices (and iOS). Both active and deleted data
are usually kept in SQLite databases (i.e., freelists).
 SQLite databases are composed of tables that store records in an structured format. Each row is a record/entry
while each column specifies an specific attribute for this record.
 Journal files and Write-Ahead Logs (WAL), are like cache files associated to the main SQLite databases that can
provide useful data which is sometimes not found in the main database.
 Commercial tools usually provide SQLite viewers, but SQLite Browser is an open free tool that allows you to
explore database files with the following extensions: .sqlite, .sqlite3, .sqlitedb, .db, and .db3.
 The main advantage of using SQLite Browser is that it shows data in a table form. It allows to see the database structure,
execute SQL queries and browse data manually. The Browse Data tab allows you to see the information present in different
tables within the .db files.
 Although we will not deal with it in this course, an examiner should be able to design and execute SQL queries to
extract as much data as possible from SQLite databases. Commercial tools may be limited in their capabilities so
the examiner skills are a really important complement to overcome the tools’ limitations.
APP ANALYSIS EXAMPLES

 The following slides provide some examples of applications found in Android devices.
 For all of them it is provided the type of content found, the package name and the most interesting files within
the application folders.
 The applications analyzed are provided as general examples, the analysis of other similar applications may differ.
 Databases are not widely explained on these examples as they can consist on many tables with different
information contained of them. For the sake of brevity, just the interesting database names are reported where
these valuable tables and information are contained.
APP ANALYSIS EXAMPLES - WIFI

 Wi-Fi is not technically an application, but it is a good source of data that should be examined.
 Wi-Fi connection data is found in /data/misc/wifi/wpa_supplicant.conf
 The wpa_supplicant.conf file contains a list of access points that the user has chosen to connect to automatically (this is set
by default when a new access point is connected to).
 Access points that the user has forgotten through the device settings will not be shown. If the access point requires a
password, that is also stored in the file in plaintext. In the screenshot, the NETGEAR60 access point required a password
(ancientshoe601), while hhonors did not.

 The presence of an SSID in this file does NOT mean that this device connected to that access point.
These settings are saved to a user's Google account, and added to the device when that account is
set up. So it can only be concluded that the user connected to these access points from some Android
device, not necessarily the device being examined.
APP ANALYSIS EXAMPLES - CONTACTS & CALLS

 Contact and call logs are stored in the same database.

 Contacts do not have to be added explicitly by the user, they may be autofilled when an email is sent through
Gmail, a person is added on Google+, or many other ways.
 Package name: com.android.providers.contacts
 Interesting files inside the folder:
 /files/photos/ > contains pictures of the user contacts
 /files/profile/ > contains user’s profile picture
 /databases/contacts2.db > contains all of the information about all contacts in the user's Google account.
 /databases/calllog.db > contains all of the information about incoming, outgoing, and missed calls.

 Tables on the databases must be explored thoroughly to understand the data contained and its forensic value.
APP ANALYSIS EXAMPLES – SMS & MMS

 SMS and MMS messages are stored in the same database.

 Usually, this database is also used regardless of what application is used to send the SMS/MMS (that is, sending an
SMS through Google Hangouts will populate this database). Nevertheless, third-party apps may also record the
data in their own databases.
 Package name: com.android.providers.telephony
 Interesting files inside the folder:
 /files/ > contains attachments sent as an MMS, both sent and received.
 /databases/mmssms.db > contains all information regarding SMS and MMS messages (dates are in UNIX epoch format)
 /databases/telephony.db > contains historical data for all SIMs that have been used in the device, including the ICCID, phone number (if it
was stored on the SIM), and the MCC/MNC, which can be used to identify the network provider.
APP ANALYSIS EXAMPLES – GMAIL

 Gmail is an email service provided by Google.

 A Gmail account is often asked for, though is not required, when the device is being set up for the first time.
 Package name: com.google.android.gm
 Interesting files inside the folder:
 /cache/ > contains recent files that were attached to emails, both sent and received. These attachments are saved here even if they are not
explicitly downloaded by the user
 /databases/mailstore.<username>@gmail.com.db > contains a variety of useful information like some part of the conversations (snippets)
and information related to attachments
 /databases/databases/suggestions.db > contains terms that were searched within the application.
 /shared_prefs/ > contains XML files with relevant data about the accounts used on the application
APP ANALYSIS EXAMPLES – GOOGLE CHROME

 Google Chrome is a web browser (the default one on many devices). Chrome data contains data not just from the device itself, but from
all devices on which the user has logged into Chrome. So it is possible and very likely that data from the user browsing on their desktop
computer will be found in the databases on their phone.
 Package name: com.android.chrome
 Interesting files inside the folder:
 /app_chrome/Default/Sync Data/SyncData.sqlite3 > contain a list of data that has been synced from the user's account on the device back to Google's servers
 /app_chrome/Default/Bookmarks > plaintext file, containing information about bookmarks synced with the account (data/time in WebKit format)
 /app_chrome/Default/Cookies > stores cookie information for sites visited (depending on the site and Chrome settings)
 /app_chrome/Default/Google Profile Picture.png > is the user's profile picture
 /app_chrome/Default/History > contains the user's web history
 /app_chrome/Default/Login Data > contains login information saved in Chrome, and is synced across all devices that use the Google account
 /app_chrome/Default/Preferences > contains the Google account(s) the user has signed into Chrome with
 /app_chrome/Default/Top Sites > contains the sites that are most frequently visited, as these are shown by default when Chrome opens
 /app_chrome/Default/Web Data > contains information the user has saved in order to automatically fill in forms on websites
 /app_ChromeDocumentActivity/ > contains files with history for recent tabs that were open on the device. URLs can be recovered for sites that were visited.
 All of the files listed in the /app_chrome/Default folder, except for the one PNG file, Bookmarks, and Preferences, are SQLite databases
despite the lack of a file extension.
APP ANALYSIS EXAMPLES – GOOGLE MAPS

 Google Maps is a map/navigation application provided by Google.

 Package name: com.google.android.apps.maps
 Interesting files inside the folder:
 /cache/http/ > folder contains many files, with .0 and .1 file extensions.The .0 files are web requests for the corresponding .1 file. The .1
files are predominantly images, and can be viewed by changing their extension appropriately(either .jpg or .png files). These files were
predominantly locations near the user, not necessarily locations the user specifically searched for. This is an example of misnamed file
extensions (next slide).
 /databases/gmm_myplaces.db > contains locations saved by the user. This file syncs with the user's Google account, so these locations
were not necessarily saved using the application.
 /databases/gmm_storage.db > contains search hits and locations that were navigated to.
APP ANALYSIS EXAMPLES – GOOGLE MAPS

 CAUTION: Misnamed file extensions

 As seen previously, some files can have strange, not correct or even no extension. It is important to check the extension of
the file in order to visualize/get the contents of it properly.
 So, always verify the header of a file that can't be opened, or use automated tools, such as EnCase, to detect the
mismatched header/file extension.
 An interesting resource to verify a file's signature is http://www.garykessler.net/ library/file_sigs.html.
APP ANALYSIS EXAMPLES – FACEBOOK

 Facebook is a massively used social media application.

 Package name: com.facebook.katana
 Interesting files inside the folder:
 /files/video-cache/ > contains videos from the user's newsfeed
 /cache/images/ > contains images from the user's newsfeed, as well as profile photos of contacts. The directory contains a multitude of other
directories (variable), and each directory can contain multiple .cnt files, which are typically JPG files or other image formats.
 /databases/bookmarks_db2 > list of items that appear on the side of the user's newsfeed, such as groups and applications. Many of these bookmarks
are automatically generated by Facebook, but may also be created by the user.
 /databases/contacts_db2 > contains information about all of the user's contacts.
 /databases/ nearbytiles_db > contains locations near the user that may interest him/her. It is apparently populated constantly, even if the user does
not view the locations. It is interesting because, while it isn't a fine location (not precise), it is a rough idea of places a user has been.
 /databases/ newsfeed_db > contains data shown to the user in their newsfeed.
 /databases/ notifications_db > contains notifications sent to the user
 /databases/ prefs_db > contains application preferences
 /databases/ threads_db2 > contains messaging information
APP ANALYSIS EXAMPLES – FACEBOOK MESSENGER

 Facebook Messenger is a messaging app that implements the Facebook chat capability. It is a separate app from the main
Facebook application.
 Package name: com.facebook.orca
 Interesting files inside the folder:
 /cache/audio/ > contains audio messages sent through the application. The files have a .cnt file extension, but they are actually RIFF files.
 /cache/fb_temp/ > contains temp files for images and video sent through the application. The time until they are removed is not clear.
 /cache/image/ > contains a lot of directories, and each directory can contain multiple .cnt files. The file header should be verified on each file, as they
can be either video or image file.
 /sdcard/com.facebook.orca > folder on the SD card that contains sent images and video only. The application includes an option (disabled by default)
to download all received images/video to the device's Gallery. If this option is selected, all received images/video would be found on the SD card.
 /files/rti.mqtt.analytics.xml > contains user's Facebook UID.
 /databases/call_log.sqlite > contains a log of calls made through the application.
 /databases/contacts_db2 > contains data about contacts the user added or automatically added by the application from the phoneboojk.
 /databases/prefs_db > contains useful metadata about the app and the account.
 /databases/threads_db2 > contains data about messages.
APP ANALYSIS EXAMPLES – SNAPCHAT

 Snapchat is an image-sharing and text-messaging application. Images and videos sent will "self-destruct" after a
time limit set by the sender, from 1-10 seconds. Furthermore, if a user takes a screenshot of the image, the sender
is notified. Text chats do not have an expiration timer.
 Package name: com.snapchat.android
 Interesting files inside the folder:
 /cache/stories/received/thumbnail/ > contains thumbnails of pictures taken by the user on the device.
 /sdcard/Android/data/com.snapchat.android/cache/my_media/ > contains the full-sized images of the thumbnails. These remain even after
the time limit has expired and the recipient can no longer access them. Files in both folders may not have proper file extensions.
 /shared_prefs/com.snapchat.android_preferences.xml > contains the email address used to create an account, and the phone number of
the device registered with the account.
 /databases/tcspahn.db > contains all other information about the app's usage.
APP ANALYSIS EXAMPLES – TANGO

 Tango is a voice/text/video messaging application.

 Package name: com.sgiggle.production
 Interesting files inside the folder:
 /sdcard/Android/data/com.sgiggle.production/files/storage/appda ta/TCStorageManagerMediaCache_v2/ > contains images that were sent
and received with the application, as well as profile pictures of contacts and also ads or emojis.
 /sdcard/Android/data/com.sgiggle.production/files/storage/appda ta/conv_msg_tab_snapshots/ > contains files with a .dat extension. When
viewed in a hex editor, we were able to find snippets of conversations in plaintext.
 /files/tc.db > contains all message information.
 /files/userinfo.xml.db > contains metadata about the account, such as the user's name and phone number. Its data is Base64-encoded, like
the messages in tc.db.
 This package name seems innocuous, and could be easily overlooked by an examiner thinking it was a game. It is a clear example of why every
application should be analyzed.
APP ANALYSIS EXAMPLES – BASE64 ENCODING

 Base64 is an encoding scheme that is commonly used for data transport; it is not considered encryption because
it has a known method for decoding, and does not require a unique key to decode the data.
 Base64 contains ASCII-printable characters, but the underlying data is binary. An example of Base64-encoded data
is as follows:

 Note the equal signs on the end of our message; this is a strong indicator that data is Base64-encoded. The input
that will be encoded needs to be divisible by 3 for the math behind Base64 to work properly. If the input is not
divisible by 3, it will be padded, resulting in the equal signs seen in the output. This is important because it shows
that while the equal signs are a strong indicator of Base64, the lack of an equal sign does not mean it isn't Base64!
 You can decode data using www.base64decode.org.
APP ANALYSIS EXAMPLES – WHATSAPP

 WhatsApp is a popular chat/video messaging service.

 Package name: com.whatsapp
 Interesting files inside the folder:
 /files/Avatars/ > contains thumbnails of the profile pictures of contacts that use the app.
 /files/me > contains the phone number associated with the account.
 /files/me.jpeg > full-size version of the user's profile picture.
 /shared_prefs/RegisterPhone.xml > contains the phone number associated with the account.
 /shared_prefs/VerifySMS.xml > shows the time that the account was verified (Unix epoch format), indicating when the user first began using the app.
 /databases/msgstore.db > contains messaging data.
 /databases/wa.db > contains contact information.
 /sdcard/WhatsApp/Media/ > contains a folder for each type of media (Audio, Calls, Images, Video, and Voice Notes), and stores all attachments of that
type in the folder. Sent media is stored in the Sent directory. Received media is stored in the root of the folder.
 /sdcard/WhatsApp/Databases/ > WhatsApp makes a backup of msgstore.db nightly, and stores the backups here. So it contains historical data that
may have been deleted. The date is included in the filename, for example: msgstore-2018-12-12.1.db.crypt12. Backups are encrypted, but they can be
decrypted using the following instructions: https://andreas-mausch.de/whatsapp-viewer/.
ABOUT APPS ANALYSIS

 This presentation showed some examples of how applications usually store their data (how/where).
 Knowing that applications store data in a variety of ways (there could be even more than the ones shown here)
should help to have a better understanding of the data under examination.
 It also tries to encourage them to look harder when is not easy to find the data that an app is expected to have.
 A forensic investigator has to be able to adapt to the changing world of application analysis. Apps are constantly
updated, so an he/she has to be able to update his/her own methods and abilities in order to keep up.
THANK YOU
ALEJANDRO.GUERRA@TALTECH.EE