Fr

ee

This book will teach you how to perform forensic

analysis
and
investigations
using
various
Python libraries. It starts by explaining the
building
blocks
of
the
Python
programming
language, especially ctypes, in-depth, along with
how to automate typical tasks in file system analysis,
common correlation tasks to discover anomalies,
and templates for investigations. Next, we'll show
you cryptographic algorithms that can be used during
forensic investigations.
Moving on, you'll learn how to sniff on the network,
generate and analyze network flows, and perform log
correlation with the help of Python scripts and tools. You'll
get to know about the concepts of virtualization and how
virtualization influences IT forensics, and you'll discover
how to perform the forensic analysis of a jailbroken/rooted
mobile device that is based on iOS or Android.
Finally, the book teaches you how to analyze volatile
memory and search for known malware samples based
on YARA rules.

Who this book is written for

Explore the forensic analysis parameters of

different platforms such as Windows, Android,
and vSphere

P U B L I S H I N G

Leverage Python ctypes for protocol decoding

C o m m u n i t y

Examine artifacts from mobile, Skype,

and browsers

Discover how to utilize Python to improve the

focus of your analysis

Investigate volatile memory with the help of

volatility on the Android and Linux platforms

$ 39.99 US
25.99 UK

community experience distilled

pl

Semi-automatically reconstruct major parts of

the system activity and timeline

Dr. Michael Spreitzenbarth

Dr. Johann Uhrmann

If you are a network security professional or forensics

analyst who wants to gain a deeper understanding of
performing forensic analysis with Python, then this book is
for you. Some Python experience would be helpful.

What you will learn from this book

Mastering Python Forensics

Mastering Python
Forensics

Sa
m

E x p e r i e n c e

Mastering Python
Forensics
Master the art of digital forensics and analysis with Python

Prices do not include

local sales tax or VAT
where applicable

Visit www.PacktPub.com for books, eBooks,

code, downloads, and PacktLib.

D i s t i l l e d

Dr. Michael Spreitzenbarth

Dr. Johann Uhrmann

In this package, you will find:

The authors biography

A preview chapter from the book, Chapter 6 'Using Python for
Mobile Forensics'
A synopsis of the books content
More information on Mastering Python Forensics

About the Authors

Dr. Michael Spreitzenbarth holds a degree of doctor of engineering in IT security
from the University of Erlangen-Nuremberg and is a CISSP as well as a GMOB. He
has been an IT security consultant at a worldwide operating CERT for more than
three years and has worked as a freelancer in the field of mobile phone forensics,
malware analysis, and IT security consultancy for more than six years. Since the last
four years, he has been giving talks and lectures in the fi elds of forensics and mobile
security at various universities and in the private sector.

Dr. Johann Uhrmann holds a degree in computer science from the University of

Applied Sciences Landshut and a doctor of engineering from the University of the
German Federal Armed Forces. He has more than ten years of experience in software
development, which includes working for start-ups, institutional research, and
corporate environment. Johann has several years of experience in incident handling
and IT governance, focusing on Linux and Cloud environments.

Preface
Today, information technology is a part of almost everything that surrounds us.
These are the systems that we wear and that support us in building and running
cities, companies, our personal online shopping tours, and our friendships. These
systems are attractive to useand abuse. Consequently, all criminal fields such
as theft, fraud, blackmailing, and so on expanded to the IT. Nowadays, this is a
multi-billion, criminal, global shadow industry.
Can a single person spot traces of criminal or suspicious activity conducted by
a multi-billion, criminal, global shadow industry? Well, sometimes you can.
To analyze the modern crime, you do not need magnifying glasses and lifting
fingerprints off wine bottles. Instead, we will see how to apply your Python skills
to get a close look at the most promising spots on a file system and take digital
fingerprints from the traces left behind by hackers.
As authors, we believe in the strength of examples over dusty theory. This is why
we provide samples for forensic tooling and scripts, which are short enough to be
understood by the average Python programmer, yet usable tools and building blocks
for real-world IT forensics.
Are you ready to turn suspicion into hard facts?

What this book covers

Chapter 1, Setting Up the Lab and Introduction to Python ctypes, covers how to set up
your environment to follow the examples that are provided in this book. We will
take a look at the various Python modules that support our forensic analyses. With
ctypes, we provide the means to go beyond Python modules and leverage the
capabilities of native system libraries.

Preface

Chapter 2, Forensic Algorithms, provides you with the digital equivalent of taking
fingerprints. Just like in the case of classic fingerprints, we will show you how to
compare the digital fingerprints with a huge registry of the known good and bad
samples. This will support you in focusing your analysis and providing a proof of
forensical soundness.
Chapter 3, Using Python for Windows and Linux Forensics, is the first step on your
journey to understanding digital evidence. We will provide examples to detect signs
of compromise on Windows and Linux systems. We will conclude the chapter with
an example on how to use machine learning algorithms in the forensic analysis.
Chapter 4, Using Python for Network Forensics, is all about capturing and analyzing
network traffic. With the provided tools, you can search and analyze the network
traffic for signs of exfiltration or signature of malware communication.
Chapter 5, Using Python for Virtualization Forensics, explains how modern virtualization
concepts can be used by the attacker and forensic analyst. Consequently, we will
show how to find traces of malicious behavior on the hypervisor level and utilize the
virtualization layer as a reliable source of forensic data.
Chapter 6, Using Python for Mobile Forensics, will give you an insight on how to
retrieve and analyze forensic data from mobile devices. The examples will include
analyzing Android devices as well as Apple iOS devices.
Chapter 7, Using Python for Memory Forensics, demonstrates how to retrieve memory
snapshots and analyze these RAM images forensically with Linux and Android.
With the help of tools such as LiME and Volatility, we will demonstrate how to
extract information from the system memory.

Using Python for

Mobile Forensics
While forensic analysis of standard computer hardwaresuch as hard diskshas
developed into a stable discipline with a lot of reference work such as the book
File System Forensic Analysis, by Brian Carrier, Addison-Wesley Professional and our
previous chapters, there is still much debate on the techniques to analyze nonstandard hardware or transient evidence. Despite their increasing role in digital
investigations, smartphones are still to be considered non-standard because of their
heterogeneity. In all the investigations, it is necessary to follow the basic forensic
principles. The two main principles of forensic investigations are as follows:

Great care must be taken so that the evidence is manipulated or changed as

little as possible.

The course of a digital investigation must be understandable and open to

scrutiny. At best, the results of the investigation must be reproducible by
independent investigators.

The first principle, especially, is a challenge in in case of smartphones as most of

them employ specific operating systems and hardware protection methods that
prevent unrestricted access to the data on the system.

[ 111 ]

Using Python for Mobile Forensics

The preservation of data from hard disks is, in most cases, a simple and well-known
procedure. An investigator removes the hard disk from the computer or notebook,
connects it to his workstation with the help of a write blocker (for example, Tableau
TK35) and starts analyzing it with well-known and certified software solutions.
When comparing this to the smartphone world, it becomes clear that there is no such
procedure. Nearly every smartphone has its own way to build its storage in and
ongoing with this, for each smartphone, the investigator needs their own way to get
the dump of the storage. While it is very hard to get the data from a smartphone,
one can get much more data with reference to the diversity of the data. Smartphones
store, besides the usual data (for example, pictures and documents), the data such as
GPS coordinates and the position of a mobile cell that the smartphone was connected
to before it was switched off.
Considering the resulting opportunities, it turns out that it is worth the extra expense
for an investigator.
In this chapter, we will cover the following topics:

The investigative model from Eoghan Casey adopted by smartphones

The analysis of Android smartphones (manual as well as automated through

Android Data Extractor Lite (ADEL))

The analysis of iOS smartphones

The investigative model for smartphones

The Investigative Process Model by Eoghan Casey, which is also known as the
Staircase Model, provides a practical and methodical step-by-step guide to conduct
an effective digital investigation. This model is depicted as a sequence of ascending
stairs that begin at the incident alert or accusation and end at the testimony. The
steps are meant to be as generic as possible. This model tries to merge police
duties and tasks of forensic experts. The following points explain each step of the
Investigative Process Model and the difference between dealing with smartphones
and computers:

Incident Alerts or Accusation: The accusation is the start signal for the
whole process. In this phase, the sources are evaluated and detailed
inquiries are requested.

[ 112 ]

Chapter 6

Assessment of worth: In the scope of the assessment of worth, the interest

of prosecution is compared to the costs that would be incurred to prosecute
the criminal action. For companies, this often results in a decision against
prosecution (for smaller incidents, at least). The advantages of a prosecution
lie in the possible compensation, improvement of one's own security as well as
certain effect of deterrence. The disadvantages of a prosecution are the need of
resources, possible downtime during which the investigated systems cannot be
used productively, and most of the time a negative public scatter effect.

Incident or crime scene protocols: In classic criminalistics, it is often

demanded that the crime scene is spaciously closed. Eoghan Casey
expresses this as the following:
"Freeze" the evidence in place and provide "ground truth for all
activities that follow".
For different kinds of digital traces, it has to be checked on an individual
basis how the process of freezing is exactly defined. Altogether, it holds
true that the risk of changing traces has to be minimized. For smartphones,
this means that they have to be put in a Faraday bag that is connected to an
external power supply.

Identification or seizure: During a traditional impoundment, all objects and

subjects that could act as evidence are picked up. Here, it is important that no
changes are made to the evidence. In addition, the environment of evidence
might be of great relevance. Simultaneous to the impoundment, the chain of
custody starts. A recommended paper about the impoundment is the brochure,
Electronic Crime Scene Investigation: A Guide to First Responders, published by The
United States Department of Justice. This brochure provides accurate and detailed
tips for nontechnical staff. Another good source is the document, Searching and
Seizing Computers and Obtaining Electronic Evidence in Criminal Investigations,
also published by The United States Department of Justice.

Preservation: When securing the evidence, it has to be ensured that these are
not modified. This is why all the evidence is documented, photographed,
sealed, and afterwards locked away. In the case of digital evidence, this
means that copies of evidence are created first; further investigation is
done only on the copies. To prove the authenticity of copies of evidence,
cryptographic hash functions are used. Most often, this is the hardest part
in mobile phone forensics due to the fact that creating one-to-one copies is
not possible for some type of phones. We will show, in the following section,
how to create backups that can be used during the investigation.

[ 113 ]

Using Python for Mobile Forensics

Recovery: Eoghan Casey describes the retrieval as throwing out a large net. In
particular, this phase includes the retrieval of evidence that has been deleted,
hidden, masked, or made inaccessible in any other way. It is recommended
that you make use of synergies with other evidence. For example, it is
reasonable to test whether a note with passwords has been found at the crime
scene in case the encrypted data needs to be read.

Harvesting: During the analysis of evidence, a well-structured organization

with a huge amount of data that is needed. For this reason, one should first
investigate metadata instead of the real data. For example, the data can be
grouped according to the file type or access time. This directly leads to the
next phase, the reduction.

Reduction: The task of reduction lies in eliminating irrelevant data. One

can use metadata for this reason, too. For example, data can be reduced
according to the data type. A suitable scenario would be to reduce all the
data to image data, only if the accusation allows for this proceeding. The
result of this phase is according to Eoghan Casey:
The smallest set of digital information that has the highest potential
for containing data of probative value.
This means finding the smallest amount of data that has the highest
probability of being relevant and evidential. In this context, hash databases of
known files, such as The National Software Reference Library (NIST), are
helpful to exclude already known files (we have described using this library
in Chapter 2, Forensic Algorithms).

Organization and search: The aspects of organization are structuring

and enabling data for scanning. Therefore, indices and overviews are often
created or their type sorts the files in meaningful directories. This simplifies
the referencing of the data in the following steps.

Analysis: This phase includes the detailed analysis regarding the file content.
Among others, connections between data and persons have to be drawn
in order to determine the responsible person. Moreover, the evaluation
of the content and context is made according to the means, motivation,
and opportunity. In this step, experiments are helpful to determine
undocumented behavior and develop new methods. All results need to be
tested and should be testable with scientific methodology.

Reporting: The report is not only to present results but also demonstrate
how one has arrived to the stated results. For this, all considered rules and
standards should be documented. In addition, all drawn conclusions need to
be justified and alternative explanation models need to be discussed.

[ 114 ]

Chapter 6

Persuasion and Testimony: Finally, it comes to the testimony of an authority

on the subject at court. The most important aspect is the trustworthiness
of the authority. A technology averse audience or difficult analogies, for
example from the defense lawyer, can be problematic.

By looking at the previously described process, one can see only little changes
when dealing with smartphones unlike other types of evidence. However, it is very
important for an investigator to understand at what steps he has to take special care.

Android
The first mobile operating system that we will examine with the help of Python is
Android. In the first subsection, we will demonstrate how to manually examine the
smartphone, followed by an automatic approach using ADEL. Last but not least, we
will demonstrate how to merge data from the analysis to create movement profiles.

Manual Examination
The first step is getting root access to the smartphone. This is required to circumvent
internal system protections and get access to all data. Getting root access is different
for most of the phones and strongly dependent on the OS version. The best way
is creating your own recovery image and booting the phone through the built-in
recovery mode.
After getting the root access, the next step is trying to get the screen lock in plain text
as this secret is often used for different protections (for example, the screen lock can
be used as an application password for an app on the phone). Breaking the screen
lock for a PIN or password can be done with the following script:
import os, sys, subprocess, binascii, struct
import sqlite3 as lite
def get_sha1hash(backup_dir):
# dumping the password/pin from the device
print "Dumping PIN/Password hash ..."
password = subprocess.Popen(['adb', 'pull', '/data/system/
password.key', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
password.wait()
# cutting the HASH within password.key
[ 115 ]

Using Python for Mobile Forensics

sha1hash = open(backup_dir + '/password.key', 'r').readline()[:40]
print "HASH: \033[0;32m" + sha1hash + "\033[m"
return sha1hash
def get_salt(backup_dir):
# dumping the system DB containing the SALT
print "Dumping locksettings.db ..."
saltdb = subprocess.Popen(['adb', 'pull', '/data/system/
locksettings.db', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
saltdb.wait()
saltdb2 = subprocess.Popen(['adb', 'pull', '/data/system/
locksettings.db-wal', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
saltdb2.wait()
saltdb3 = subprocess.Popen(['adb', 'pull', '/data/system/
locksettings.db-shm', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
saltdb3.wait()
# extract the SALT
con = lite.connect(backup_dir + '/locksettings.db')
cur = con.cursor()
cur.execute("SELECT value FROM locksettings WHERE
name='lockscreen.password_salt'")
salt = cur.fetchone()[0]
con.close()
# convert SALT to Hex
returnedsalt = binascii.hexlify(struct.pack('>q', int(salt) ))
print "SALT: \033[0;32m" + returnedsalt + "\033[m"
return returnedsalt

def write_crack(salt, sha1hash, backup_dir):

crack = open(backup_dir + '/crack.hash', 'a+')
# write HASH and SALT to cracking file
[ 116 ]

Chapter 6
hash_salt = sha1hash + ':' + salt
crack.write(hash_salt)
crack.close()

if __name__ == '__main__':
# check if device is connected and adb is running as root
if subprocess.Popen(['adb', 'get-state'], stdout=subprocess.PIPE).
communicate(0)[0].split("\n")[0] == "unknown":
print "no device connected - exiting..."
sys.exit(2)
# starting to create the output directory and the crack file used
for hashcat
backup_dir = sys.argv[1]
try:
os.stat(backup_dir)
except:
os.mkdir(backup_dir)
sha1hash = get_sha1hash(backup_dir)
salt = get_salt(backup_dir)
write_crack(salt, sha1hash, backup_dir)

This script generates a file called crack.hash that can be used to feed hashcat to
brute force the screen lock. If the smartphone owner has used a 4-digit PIN, the
command to execute hashcat is as follows:
user@lab:~$ ./hashcat -a 3 -m 110 out/crack.hash -1 ?d ?1?1?1?1
Initializing hashcat v0.50 with 4 threads and 32mb segment-size...

Added hashes from file crack.hash: 1 (1 salts)

Activating quick-digest mode for single-hash with salt

c87226fed37977772be870d722c449f915844922:256c05b54b73308b:0420

All hashes have been recovered

Input.Mode: Mask (?1?1?1?1) [4]

Index.....: 0/1 (segment), 10000 (words), 0 (bytes)
[ 117 ]

Using Python for Mobile Forensics

Recovered.: 1/1 hashes, 1/1 salts
Speed/sec.: - plains, 7.71k words
Progress..: 7744/10000 (77.44%)
Running...: 00:00:00:01
Estimated.: --:--:--:--

Started: Sat Jul 20 17:14:52 2015

Stopped: Sat Jul 20 17:14:53 2015

By looking at the marked line in the output, you can see the sha256 hash followed by
the salt and the brute forced PIN that is used to unlock the screen.
If the smartphone user has used a gesture to unlock the smartphone, you can use a
pre-generated rainbow table and the following script:
import hashlib, sqlite3, array, datetime
from binascii import hexlify
SQLITE_DB = "GestureRainbowTable.db"
def crack(backup_dir):
# dumping the system file containing the hash
print "Dumping gesture.key ..."
saltdb = subprocess.Popen(['adb', 'pull', '/data/system/gesture.
key', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
gesturehash = open(backup_dir + "/gesture.key", "rb").readline()
lookuphash = hexlify(gesturehash).decode()
print "HASH: \033[0;32m" + lookuphash + "\033[m"
conn = sqlite3.connect(SQLITE_DB)
cur = conn.cursor()
cur.execute("SELECT pattern FROM RainbowTable WHERE hash = ?",
(lookuphash,))
gesture = cur.fetchone()[0]
return gesture
if __name__ == '__main__':
# check if device is connected and adb is running as root
[ 118 ]

Chapter 6
if subprocess.Popen(['adb', 'get-state'], stdout=subprocess.PIPE).
communicate(0)[0].split("\n")[0] == "unknown":
print "no device connected - exiting..."
sys.exit(2)
# starting to create the output directory and the crack file used
for hashcat
backup_dir = sys.argv[1]
try:
os.stat(backup_dir)
except:
os.mkdir(backup_dir)
gesture = crack(backup_dir)
print "screenlock gesture: \033[0;32m" + gesture + "\033[m""

The next thing that could be very important when looking for potentially infected
devices is a list of installed apps and their hashes to check them against AndroTotal
or Mobile-Sandbox. This can be done with the following script:
import os, sys, subprocess, hashlib

def get_apps():
# dumping the list of installed apps from the device
print "Dumping apps meta data ..."
meta = subprocess.Popen(['adb', 'shell', 'ls', '-l', '/data/app'],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
meta.wait()
apps = []
while True:
line = meta.stdout.readline()
if line != '':
name = line.split(' ')[-1].rstrip()
date = line.split(' ')[-3]
time = line.split(' ')[-2]
if name.split('.')[-1] == 'apk':
app = [name, date, time]
else:
[ 119 ]

Using Python for Mobile Forensics

continue
else:
break
apps.append(app)
return apps

def dump_apps(apps, backup_dir):

# dumping the apps from the device
print "Dumping the apps ..."
for app in apps:
app = app[0]
subprocess.Popen(['adb', 'pull', '/data/app/' + app, backup_
dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)

def get_hashes(apps, backup_dir):

# calculating the hashes
print "Calculating the sha256 hashes ..."
meta = []
for app in apps:
sha256 = hashlib.sha256(open(backup_dir + '/' + app[0], 'rb').
read()).hexdigest()
app.append(sha256)
meta.append(app)
return meta

if __name__ == '__main__':
# check if device is connected and adb is running as root
if subprocess.Popen(['adb', 'get-state'], stdout=subprocess.PIPE).
communicate(0)[0].split("\n")[0] == "unknown":
print "no device connected - exiting..."
sys.exit(2)
# starting to create the output directory
[ 120 ]

Chapter 6
backup_dir = sys.argv[1]
try:
os.stat(backup_dir)
except:
os.mkdir(backup_dir)
apps = get_apps()
dump_apps(apps, backup_dir)
meta = get_hashes(apps, backup_dir)
# printing the list of installed apps
print 'Installed apps:'
for app in meta:
print "\033[0;32m" + ' '.join(app) + "\033[m"

After executing the preceding printed script, you get the following output including
important metadata:
user@lab:~$ ./get_installed_apps.py out

Dumping apps meta data ...

Dumping the apps ...
Calculating the sha256 hashes ...

Installed apps:
com.android.SSLTrustKiller-1.apk 2015-05-18 17:11
52b4d6a1888a6514b62f6607cebf8c2c2aa4e4857319ec67b24be601db5243fb
com.android.chrome-2.apk 2015-06-16 20:50
191cd720626df38eaedf3301826e72330493cdeb8c45da4e309939cfe5633d61
com.android.vending-1.apk 2015-07-25 12:05
7be9f8f99e8c1a6c3be1edb01d84aba14619e3c67c14856755523413ba8e2d98
com.google.android.GoogleCamera-2.apk 2015-06-16 20:49
6936f3c17948c767550c206ff0ae0f44f1f4da0fcb85125da722e0c709787894
com.google.android.apps.authenticator2-1.apk 2015-06-05 10:14
11bcfcf1c853b1eb567c9453507c3413b09a1d70fd3085013f4a091719560ab6
...

[ 121 ]

Using Python for Mobile Forensics

With the help of this information, you can check the apps against online services
to know whether they are safe to use or potentially malicious. If you don't want to
submit them, then you can use the apk_analyzer.py script in combination with
Androguard to perform a quick analysis that often can reveal important information.
After getting a list of all installed apps and checking them for malicious behavior, it
can also be really helpful to get information about all partitions and mount points of
the device. This can be achieved with the following script:
import sys, subprocess

def get_partition_info():
# dumping the list of installed apps from the device
print "Dumping partition information ..."
partitions = subprocess.Popen(['adb', 'shell', 'mount'],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
partitions.wait()
while True:
line = partitions.stdout.readline().rstrip()
if line != '':
print "\033[0;32m" + line + "\033[m"
else:
break

if __name__ == '__main__':
# check if device is connected and adb is running as root
if subprocess.Popen(['adb', 'get-state'], stdout=subprocess.PIPE).
communicate(0)[0].split("\n")[0] == "unknown":
print "no device connected - exiting..."
sys.exit(2)
get_partition_info()

[ 122 ]

Chapter 6

The output of a rooted phone could look like this:

user@lab:~$ ./get_partitions.py

Dumping partition information ...

rootfs / rootfs rw,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,mode=750,gid=1000 0 0
tmpfs /mnt/asec tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,re
latime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw
,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_
alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw
,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_
alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,
nosuid,nodev,relatime,nomblk_io_submit,nodelalloc,errors=panic,data=order
ed 0 0
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,relatime,u
id=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso88591,shortname=lower,errors=remount-ro 0 0
/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,relatime,user_
id=1023,group_id=1023,default_permissions,allow_other 0 0

[ 123 ]

Using Python for Mobile Forensics

At the end of this section, we will show you how to gather more details about the
usage of the android-based smartphone. In the following example, we will use the
contacts database that also stores the phone call history. This example can easily be
adopted to get calendar entries or content from any other database of an app that is
installed on the device:
import os, sys, subprocess
import sqlite3 as lite
from prettytable import from_db_cursor

def dump_database(backup_dir):
# dumping the password/pin from the device
print "Dumping contacts database ..."
contactsDB = subprocess.Popen(['adb', 'pull', '/data/data/com.
android.providers.contacts/databases/contacts2.db',
backup_dir], stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
contactsDB.wait()

def get_content(backup_dir):
# getting the content from the contacts database
con = lite.connect(backup_dir + '/contacts2.db')
cur = con.cursor()
cur.execute("SELECT contacts._id AS _id,contacts.custom_ringtone
AS custom_ringtone, name_raw_contact.display_name_source AS display_
name_source, name_raw_contact.display_name AS display_name, name_
raw_contact.display_name_alt AS display_name_alt, name_raw_contact.
phonetic_name AS phonetic_name, name_raw_contact.phonetic_name_style
AS phonetic_name_style, name_raw_contact.sort_key AS sort_key, name_
raw_contact.phonebook_label AS phonebook_label, name_raw_contact.
phonebook_bucket AS phonebook_bucket, name_raw_contact.sort_key_alt
AS sort_key_alt, name_raw_contact.phonebook_label_alt AS phonebook_
label_alt, name_raw_contact.phonebook_bucket_alt AS phonebook_
bucket_alt, has_phone_number, name_raw_contact_id, lookup, photo_id,
photo_file_id, CAST(EXISTS (SELECT _id FROM visible_contacts WHERE
contacts._id=visible_contacts._id) AS INTEGER) AS in_visible_group,
status_update_id, contacts.contact_last_updated_timestamp, contacts.
last_time_contacted AS last_time_contacted, contacts.send_to_voicemail
AS send_to_voicemail, contacts.starred AS starred, contacts.pinned
AS pinned, contacts.times_contacted AS times_contacted, (CASE WHEN
photo_file_id IS NULL THEN (CASE WHEN photo_id IS NULL OR photo_id=0
THEN NULL ELSE 'content://com.android.contacts/contacts/'||contacts._
[ 124 ]

Chapter 6
id|| '/photo' END) ELSE 'content://com.android.contacts/display_
photo/'||photo_file_id END) AS photo_uri, (CASE WHEN photo_id IS
NULL OR photo_id=0 THEN NULL ELSE 'content://com.android.contacts/
contacts/'||contacts._id|| '/photo' END) AS photo_thumb_uri, 0 AS
is_user_profile FROM contacts JOIN raw_contacts AS name_raw_contact
ON(name_raw_contact_id=name_raw_contact._id)")
pt = from_db_cursor(cur)
con.close()
print pt

if __name__ == '__main__':
# check if device is connected and adb is running as root
if subprocess.Popen(['adb', 'get-state'], stdout=subprocess.PIPE).
communicate(0)[0].split("\n")[0] == "unknown":
print "no device connected - exiting..."
sys.exit(2)
# starting to create the output directory
backup_dir = sys.argv[1]
try:
os.stat(backup_dir)
except:
os.mkdir(backup_dir)
dump_database(backup_dir)
get_content(backup_dir)

After you have seen how to manually perform an analysis of a smartphone, we

will show you, in the upcoming section, how to perform the same actions that are
automated with the help of ADEL.

[ 125 ]

Using Python for Mobile Forensics

Automated Examination with the help of ADEL

We have developed a tool named ADEL. It was initially developed for versions 2.x
of Android but was updated to fit the needs of analysing Android 4.x smartphones.
This tool is able to automatically dump the selected SQLite database files from
Android devices and extract the contents that are stored in the dumped files. As
a further option, ADEL is able to analyse databases that were dumped manually
beforehand. This option was implemented to support smartphones where ADEL
is not able to access the filesystem of the device due to security features like locked
bootloaders. In the following sections, we describe the main tasks of ADEL and what
steps the tool actually performs.

Idea behind the system

During the development of ADEL, we primarily took into account the following
design guidelines:

Forensic principles: ADEL is intended to treat data in a forensically correct

way. This goal is achieved by the fact that activities are not conducted
directly on the phone but on a copy of the databases. This procedure
assures that the data is not modified either by the users of ADEL or by
a compromised operating system. In order to providing the proof of the
forensic correctness of ADEL, hash values are calculated before and after
each analysis to guarantee that the dumped data was not modified during
the analysis.

Extendibility: ADEL has been modularly built and contains two separate
modules: the analysis and the report module. Predefined interfaces exist
between these modules and both of them can be easily amended with the
help of additional functions. The modular structure allows you to dump and
analyse further databases of smartphones without great effort and facilitates
updates of the system in the future.

Usability: The use of ADEL is intended to be as simple as possible to allow

its use by both, qualified persons and non-experts. At best, the analysis of the
mobile phone is conducted in an autonomous way so that the user does not
receive any notification of internal processes. Moreover, the report module
creates a detailed report in a readable form including all the decoded data.
During the execution, ADEL optionally writes an extensive log file where all
the important steps that were executed are traced.

[ 126 ]

Chapter 6

Implementation and system workflow

A flow chart showing the structure of ADEL is depicted in the following figure:

ADEL makes use of Android Software Development Kit (Android SDK) to dump
database files in the investigator's machine. To extract contents that are contained
in a SQLite database file, ADEL parses the low-level data structures. After having
opened the database file that is to be parsed in the read-only mode, ADEL reads the
database header (the first 100 bytes of the file) and extracts the values for each of the
header fields. Not all, but some of the values in header fields are necessary in order
to parse the rest of the database file. An important value is the size of the pages in
the database file, which is required for parsing the B-tree structures (pagewise).
After having read the database header fields, ADEL parses the B-tree that contains
the sqlite_master table for which the first page of the database is always the
root page. The SQL CREATE statement and the page number of the B-tree root
page are extracted for each of the database tables. Additionally, the SQL CREATE
statement is further analyzed to extract the name and data type of each column of the
corresponding table.

[ 127 ]

Using Python for Mobile Forensics

Finally, the complete B-tree structure is parsed for each table, beginning at the B-tree
root page, which was extracted from the sqlite_master table. By following the
pointers of all of the interior pages, you can identify every leaf page of the B-tree.
Finally the row contents of each table are extracted from the cells that are found in
any leaf page that belongs to the same table B-tree.
In the following sections, we will address the report module and its functionalities.
In the current development state, the following databases are forensically treated
and parsed:

Telephone and SIM-card information (for example International Mobile

Subscriber Identity (IMSI) and serial number)

Telephone book and call lists

Calendar entries

SMS messages

Google-Maps

Data retrieved in this way is written to an XML file by the report module in order
to ease the further use and depiction of the data. Similar to the analysis module,
it can be easily updated regarding possible changes in future Android versions or
in underlying database schemes. Therefore, we have created different tuplefor
example, [table, row, column]to define the data that is exchanged between both
modules. If the database design changes in the future, only the tuple has to be
adapted. The report module automatically creates XML files for each data type that
is previously listed. In addition, a report is created that contains all the data extracted
from analyzed databases. With the help of an XSL file the report will be graphically
refurbished. All files created by ADEL are stored in a subfolder of the current project.
To get access to the necessary databases and system folders on the smartphone,
ADEL needs root access on the device.

Working with ADEL

After we have described what ADEL is and how it works, we will now go to the
practical part of this section and start using it. You can download ADEL from the
following URL: https://mspreitz.github.io/ADEL

[ 128 ]

Chapter 6

All you need to do is check whether the device in question is already included in
the configuration profile of ADEL that is located in /xml/phone_config.xml. If the
device is missing, there are two options on how to proceed:
1. Choose a different device with the same Android version (this will generate a
warning but it works in most of the cases).
2. Generate a new device configuration that matches the device type and
Android version of the device in question.
If you choose the second option, you can copy the configuration of an already
working device and adopt the numbers in the XML file. These numbers represent
the tables and columns of the noted database. To be a bit more precise, if you try
to adopt the SMS database, you have to check the numbers for the following tables
and columns:
<sms>
<db_name>mmssms.db</db_name>
<table_num>10</table_num>
<sms_entry_positions>
<id>0</id>
<thread_id>1</thread_id>
<address>2</address>
<person>3</person>
<date>4</date>
<read>7</read>
<type>9</type>
<subject>11</subject>
<body>12</body>
</sms_entry_positions>
</sms>

The number for the table_num tag has to be set to the number that corresponds to
the table called sms. The following numbers have to be adopted corresponding to the
columns in the sms table that are named identically. The preceding printed example
works with a Nexus 5 and Android 4.4.4. The same has to be done for all other
databases too.

[ 129 ]

Using Python for Mobile Forensics

Running ADEL against a rooted Nexus 5 with Android 4.4.4filled with test data
generates the following output:
user@lab:~$./adel.py -d nexus5 -l 4

_____
/
/
/

________

___________.____

\ \______ \ \_

_____/|

|
|

/_\

\ |

\ |

__)_ |

\|

\|

\|

/_______

/|_______ \

\____|__

/_______
\/

\/

|___

\/

\/

Android Data Extractor Lite v3.0

ADEL MAIN:

----> starting script....

ADEL MAIN:

----> Trying to connect to smartphone or emulator....

dumpDBs:

----> opening connection to device: 031c6277f0a6a117

dumpDBs:
6a117 created

----> evidence directory 2015-07-20__22-53-22__031c6277f0a

ADEL MAIN:
----> log file 2015-07-20__22-53-22__031c6277f0a6a117/log/
adel.log created
ADEL MAIN:

----> log level: 4

dumpDBs:

----> device is running Android OS 4.4.4

dumpDBs:

----> dumping all SQLite databases....

dumpDBs:

----> auto dict doesn't exist!

dumpDBs:

----> weather database doesn't exist!

dumpDBs:

----> weather widget doesn't exist!

dumpDBs:

----> Google-Maps navigation history doesn't exist!

dumpDBs:

----> Facebook database doesn't exist!

dumpDBs:

----> Cached geopositions within browser don't exist!

dumpDBs:

----> dumping pictures (internal_sdcard)....

dumpDBs:

----> dumping pictures (external_sdcard)....

dumpDBs:

----> dumping screen captures (internal_sdcard)....

dumpDBs:

----> dumping screen captures (internal_sdcard)....

dumpDBs:

----> all SQLite databases dumped

Screenlock:
----> Screenlock Hash:
6a062b9b3452e366407181a1bf92ea73e9ed4c48

[ 130 ]

Chapter 6
Screenlock:

----> Screenlock Gesture: [0, 1, 2, 4, 6, 7, 8]

LocationInfo: ----> Location map 2015-07-20__22-53-22__031c6277f0a6a117/

map.html created
analyzeDBs:

----> starting to parse and analyze the databases....

parseDBs:

----> starting to parse smartphone info

parseDBs:

----> starting to parse calendar entries

parseDBs:

----> starting to parse SMS messages

parseDBs:

----> starting to parse call logs

parseDBs:

----> starting to parse address book entries

analyzeDBs:

----> all databases parsed and analyzed....

createReport:

----> creating report....

ADEL MAIN:
----> report 2015-07-20__22-53-22__031c6277f0a6a117/xml/
report.xml created
compareHash:

----> starting to compare calculated hash values

ADEL MAIN:

----> stopping script....

(c) m.spreitzenbarth & s.schmitt 2015

In this output, you can see the name of the folder where all the data is dumped
and where the generated report can be found. Additionally, you can also see the
gesture of the screen lock that was automatically extracted and compared with
a pre-generated rainbow table, as follows:

[ 131 ]

Using Python for Mobile Forensics

Movement profiles
In addition to data about individual communications, the EU directive from 2006
also requires certain location data to be retained by network operators. Specially,
the directive requires that the following data is retained for at least six months:

Identity and exact GPS coordinates of the radio cell where the user started a
phone call

Identity and coordinates of the radio cell that was active at the beginning of a
GPRS data transmission

Time stamps corresponding to this data

This information can help investigators to create movement profiles of suspects.

Also, the information may be used to locate and monitor suspects.
Many EU member countries have implemented this directive in national laws.
However, in some countries, there has been an intensive public debate about the laws,
especially in relation to the threats to privacy. In Germany, the discussions were fueled
by a dataset provided by the German politician Malte Spitz. The dataset contained
location data over a period of six months that was preserved by his mobile network
operator under the data retention law. A German newspaper created a graphical
interface that enabled users to visually replay Spitz's detailed movements.
Overall, it is argued that retaining large amounts of data creates new risks of abuse.
Also, the requirement to store data pertaining to millions of innocent people is
out of proportion to the small number of cases in which the data is used by law
enforcement. As a result, in 2011, the German Constitutional Court dismissed the
original legislation requiring data retention. Meanwhile, the search for less invasive
techniques to analyze the movements of criminals continues.
In the recent years, many new types of mobile phones (smartphones) have flooded
the market. As they are essentially small personal computers, they offer much more
than the possibility to make phone calls and surf the Internet. An increasing number
of subscribers are using apps (mostly third-party applications that are directly
installed on their phones) and communicating with friends and family via social
networks such as Facebook, Google+, and Twitter.

[ 132 ]

Chapter 6

For performance and other reasons, mobile devices persistently store location data in
the local memory. In April 2011, it was reported that Android and iOS store sensitive
geographical data. This data, which is maintained in system cache files, is regularly
sent to platform developers. However, generating geographical data is not restricted
to the operating systemmany apps that provide location-based services also create
and store such data. For example, Benford has shown that pictures taken by an iPhone
contain the GPS coordinates of the location where the pictures were taken. Such data
is sensitive because it can be used to create movement profiles as seen in the following
figure. Unlike the location data that is retained by network operators, location data
stored on smartphones can be accessed by law enforcement via an open seizure.

Apple iOS
After we have seen how to examine an Android-based smartphone, we now want
to show you how to perform similar investigations on iOS-based devices. In the first
section, we are using a Secure Shell (SSH) connection to the device and will show
you how to get stored data from the keychain of a jailbroken iOS device.

[ 133 ]

Using Python for Mobile Forensics

In the second part of this section, we will use libimobiledevice. This library is a
cross-platform library that uses the protocols to support iOS-based devices and
allows you to easily access the device's filesystem, retrieve information about the
device and it's internals, backup/restore the device, manage installed applications,
retrieve PIM data as well as bookmarks, and so on. The most important fact is that
the iOS-based device does not have to be jailbroken in order to be used when
dealing with libimobiledevice.

Getting the Keychain from a jailbroken

iDevice
In many cases, it can be very helpful to get usernames and passwords of accounts
that the user of the iDevice was using. This kind of data is located in the iOS
keychain and can be pulled from iDevice with the help of the following script:
import os, sys, subprocess

def get_kc(ip, backup_dir):

# dumping the keychain
print "Dumping the keychain ..."
kc = subprocess.Popen(['scp', 'root@' + ip + ':/private/var/
Keychains/keychain-2.db', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
kc.communicate()

def push_kcd(ip):
# dumping the keychain
print "Pushing the Keychain Dumper to the device ..."
kcd = subprocess.Popen(['scp', 'keychain_dumper' 'root@' + ip +
':~/'],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
kcd.communicate()

def exec_kcd(ip, backup_dir):

[ 134 ]

Chapter 6
# pretty print keychain
kcc = subprocess.Popen(['ssh', 'root@' + ip, './keychain_dumper'],
stdout=subprocess.PIPE, stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
kcc.communicate()
kcc.stdout

if __name__ == '__main__':
# starting to create the output directory
backup_dir = sys.argv[1]
try:
os.stat(backup_dir)
except:
os.mkdir(backup_dir)
# get the IP of the iDevice from user input
ip = sys.argv[2]
get_kc(ip, backup_dir)
push_kcd(ip)
exec_kcd(ip, backup_dir)

In the output of the preceding script, you can also find the password of the Apple
account that the device is registered to:
Generic Password
---------------Service: com.apple.account.AppleAccount.password
Account: 437C2D8F-****-****-****-************
Entitlement Group: apple
Label: (null)
Generic Field: (null)
Keychain Data: *************************

[ 135 ]

Using Python for Mobile Forensics

Manual Examination with libimobiledevice

This library uses common iOS protocols for communication between the
investigator's machine and the connected iDevice. In order to work properly, the
device has to be unlocked and paired because, otherwise a large amount of data on
the device is still encrypted, and thus, protected.
With the help of the following script, you can create a full backup of the device
(similar to an iTunes backup). Afterwards, the script will unpack the backup and
print a hierarchical list of all files and folders in the backup. Dependent on the
size of the iDevice this script can run for several minutes.
import os, sys, subprocess

def get_device_info():
# getting the udid of the connected device
udid = subprocess.Popen(['idevice_id', '-l'], stdout=subprocess.
PIPE).stdout.readline().rstrip()
print "connected device: \033[0;32m" + udid + "\033[m"
return udid

def create_backup(backup_dir):
# creating a backup of the connected device
print "creating backup (this can take some time) ..."
backup = subprocess.Popen(['idevicebackup2', 'backup', backup_
dir], stdout=subprocess.PIPE)
backup.communicate()
print "backup successfully created in ./" + backup_dir + "/"

def unback_backup(udid, backup_dir):

# unpacking the backup
print "unpacking the backup ..."
backup = subprocess.Popen(['idevicebackup2', '-u', udid, 'unback',
backup_dir], stdout=subprocess.PIPE)

[ 136 ]

Chapter 6
backup.communicate()
print "backup successfully unpacked and ready for analysis"

def get_content(backup_dir):
# printing content of the created backup
content = subprocess.Popen(['tree', backup_dir + '/_unback_/'],
stdout=subprocess.PIPE).stdout.read()
f = open(backup_dir + '/filelist.txt', 'a+')
f.write(content)
f.close
print "list of all files and folders of the backup are stored in
./" + backup_dir + "/filelist.txt"

if __name__ == '__main__':
# check if device is connected
if subprocess.Popen(['idevice_id', '-l'], stdout=subprocess.PIPE).
communicate(0)[0].split("\n")[0] == "":
print "no device connected - exiting..."
sys.exit(2)
# starting to create the output directory
backup_dir = sys.argv[1]
try:
os.stat(backup_dir)
except:
os.mkdir(backup_dir)
udid = get_device_info()
create_backup(backup_dir)
unback_backup(udid, backup_dir)
get_content(backup_dir)

[ 137 ]

Using Python for Mobile Forensics

The final output of this script will look like the following extract:
user@lab:~$ ./create_ios_backup.py out

connected device: 460683e351a265a7b9ea184b2802cf4fcd02526d

creating backup (this can take some time) ...
backup successfully created in ./out
unpacking the backup ...
backup successfully unpacked and ready for analysis
list of all files and folders of the backup are stored in ./out/filelist.
txt

With the help of the list of files and folders, you can start the analysis of the backup
with common tools such as a plist file viewer or a SQLite browser. Searching
for Cydia App Store in this generated file can also help to identify whether the
smartphone has been jailbroken by the user or an attacker.

Summary
In this chapter, we covered the investigative process model from Eoghan Casey
and adopted it to the case of smartphones. Later, we performed an analysis of
Android smartphones in manual as well as automated ways with the help of
Python scripts and the ADEL framework. In the last section, we covered the
analysis of iOS-based smartphones.
After handling the forensic investigation of smartphones, we finished the physical
and virtual acquisition and analysis and will shift the investigation to the volatile
area of the devices in the next chapter.

[ 138 ]

Get more information Mastering Python Forensics

Where to buy this book

You can buy Mastering Python Forensics from the Packt Publishing website.
Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and most internet
book retailers.
Click here for ordering and shipping details.

www.PacktPub.com

Stay Connected: