Sei sulla pagina 1di 75

University of Derby

School of Computing & Mathematics

A project completed as part of the requirements for the


BSc (Hons) Computer Forensics and Security

entitled
Skype Forensics

By
Daniel Castle
d.castle1@unimail.derby.ac.uk
daniel_castle@hotmail.co.uk

in the years 2010 - 2014

Abstract
This project takes a look into the world of one of the most popular VoIP applications used
today Skype. The methods by which Skype transmits data over the internet and between
clients has been frequently examined, to discover any potential data leaks. An area that has
not received much attention, is that of the local data stored on computer systems by Skype.
This project takes a look into just this area, taking time to locate and examine the types of
information that can be found on the storage media of these devices. As a result of this
preliminary examination, a software tool will be developed to automate this process for future
investigations.

Page | 1

Acknowledgements
I would like to express my gratitude to all academics, family and friends that have helped me
in the process of completing this project, whether that help has come in the form of advice or
the motivation to continue, as without them, this project would not be where it is today.
Specifically, I would like to thank my parents (Sue and Andrew Castle) for their continued
support throughout, and also for checking through the written aspects to help correct any
errors.
Thank you to my brother (Joseph Castle) for taking the time to read through the entirety of the
project to ensure there were no errors.
Thank you to Miriam King for continually motivating me to work to the best of my ability.
Thanks also to Christakis Katsaras for assistance with some of the technical aspects of my
investigations.
Finally, a very special thank you to my project supervisor, Dr Olga Angelopoulou, for the
advice, guidance and support she has offered for the duration of this project, as it has been
extremely valuable.

Page | 2

Table of Contents
Abstract.......................................................................................................................................1
Acknowledgements.....................................................................................................................2
Table of Contents........................................................................................................................3
Table of Figures...........................................................................................................................4
Chapter 1 Introduction and Specification................................................................................5
1.1 Introduction.......................................................................................................................5
1.2 Aims and Objectives..........................................................................................................5
Chapter 2 Literature Review....................................................................................................6
2.1 Literature Review..............................................................................................................6
2.2 Brief Overview of How Skype Clients Connect...............................................................6
2.3 Other Research Conducted in this Area............................................................................6
2.3.1 Skype Fingerprint.......................................................................................................6
2.3.2 Client-side Skype Forensics An Overview..............................................................7
2.4 Similar Applications..........................................................................................................7
2.4.1 Xfire............................................................................................................................7
2.4.2 Google Hangouts........................................................................................................7
2.5 Exploring Windows...........................................................................................................7
2.6 Exploring Android.............................................................................................................8
2.7 Android Root Access.....................................................................................................8
2.8 Tools for examining Android Devices...............................................................................8
2.9 Application Research.........................................................................................................8
Chapter 3 - Methodology............................................................................................................9
3.1 Methodology.....................................................................................................................9
3.1.1 Manual Investigation of Windows Device..................................................................9
3.1.2 Manual Investigation of Android Devices..................................................................9
3.1.3 Application Design.....................................................................................................9
Page | 3

3.1.4 Coding of Application.................................................................................................9


3.1.5 Analysis of Application...............................................................................................9
3.1.6 Application Testing.....................................................................................................9
Chapter 4 Analysis and Design..............................................................................................11
4.1 Preliminary Investigation................................................................................................11
4.1.1 Examination of Windows Devices............................................................................11
4.1.2 Examination of Android Devices..............................................................................12
4.2 Application Design..........................................................................................................12
4.2.1 Requirements Specification......................................................................................12
4.2.2 Functionality.............................................................................................................12
4.2.3 Aesthetics..................................................................................................................12
4.2.4 Usability....................................................................................................................12
Chapter 5 Application Analysis and Experiments..................................................................14
5.1 Application Analysis........................................................................................................14
5.1.1 Application Overview...............................................................................................14
5.1.2 How the Application Works......................................................................................14
5.2 Experiments.....................................................................................................................14
5.2.1 Test Bed Systems......................................................................................................15
5.2.2 Experiment 1.............................................................................................................15
5.2.3 Experiment 2.............................................................................................................16
5.2.4 Experiment 3.............................................................................................................16
Chapter 6 Experiment Results................................................................................................17
6.1 Results of Experiment 1..................................................................................................17
6.1.1 Test System 1............................................................................................................17
6.1.2 Test System 2............................................................................................................18
6.2 Results of Experiment 2..................................................................................................18
6.2.1 Test System 1............................................................................................................18
6.2.2 Test System 2............................................................................................................20
Page | 4

6.3 Results of Experiment 3..................................................................................................20


Chapter 7 Conclusion, Improvements and Reflection...........................................................21
7.1 Conclusion.......................................................................................................................21
7.1.1 Aims and Objectives.................................................................................................21
7.1.2 Improvements and Recommendations......................................................................21
7.2 Reflection........................................................................................................................22
References/Citations.................................................................................................................23
Appendices................................................................................................................................24
Appendices (as Referenced in the Text)................................................................................24
Additional Information..........................................................................................................36

Page | 5

Table of Figures

Page | 6

Chapter 1 Introduction and Specification


1.1 Introduction
Over recent years, the methods by which people communicate with one another have changed
dramatically. From hand written letters, electronic telegraphs and telephone calls, to the
digital age of emails, instant messages and Voice over IP (VoIP) communication. Voice over
IP, or VoIP;
is a method for taking analogue audio signals, like the kind you hear when you talk
on the phone, and turning them into digital data that can be transmitted over the
Internet. (Roos and Valdes, 2012).
There are currently a variety of different VoIP clients available for use, and there are a number
of different types of VoIP client. There are applications that require users to connect to a
server to communicate, such as Teamspeak and Ventrilo, that are primarily designed to allow
for larger numbers of people to communicate with one another simultaneously. There are also
applications that work in a one-to-one style of communication (in the same manner as an
ordinary phone call). An example of this type of application is also one of the most
commonly used today, and that is Skype.
Owing to the tremendous advances in the area of VoIP in recent years, the technology has
moved on from being primarily utilised for personal use, to being widely used by many
businesses for things such as in-house telephony, meetings between multiple parties across a
number of locations and for video conferences.
Although VoIP is a very practical and, in most cases, a relatively cheap method of
communicating with multiple people, there is one key factor that is a major point of interest to
many; the security of the data being transmitted between VoIP clients.
As mentioned earlier, Skype is one of the most popular VoIP applications available, boasting a
user base of more than 299 million people around the world, as of June 2013 (Swider, 2013).
Earlier that year, it was posted in the Skype Big Blog that each day, 2 billion minutes of
Skype calls were being made (Steele, 2013). From these numbers alone, the popularity of
Skype becomes clear. Owing to this popularity, it is understandable why the security of this
application is such a sensitive area. Although the majority of users see Skype as a tool for
socialising with friends and family across large distances, it is also a tool used by businesses,
whether this be for use by technical support teams, or for meetings with managers. If a
Page | 7

conversation between a mother and her son is intercepted and viewed by an unpermitted
individual, this could be seen as a breach of the privacy of these two users, but it is unlikely
that much harm would be caused by this breach. On the other hand, if a conversation between
the managing director and the finance controller of a company were to be intercepted, it is
entirely possible that the unauthorised individual could be privy to confidential, business
critical information. Once they have obtained this knowledge, what they do with it is down to
them, whether they keep it to themselves, use it for blackmail, or sell it on to a competitor.
Given the above scenario, it is clear why a large number of people have looked into
intercepting and decrypting the data that is transmitted over a network by Skype. Although
this is an extremely important area for security to be examined, it is not the only one. As
Skype has to be installed on a computer system for it to be run, it is logical to assume that
there must be some data stored locally on the computer system in question.

1.2 Aims and Objectives


The main aim for this project is to locate and examine the artefacts left behind on computer
systems by the popular application Skype. Once any potentially useful artefacts have been
located and examined, a software tool will be developed to automatically gather the key
artefacts from the computer system in use, to assist with the examination of past Skype
communications.
To achieve this aim, four key objectives will be met:
- Research regarding how Skype works and the structure of the Skype application, both on
Windows and on Android, will be carried out, alongside research on past investigations
carried out in this field.
- Forensic artefacts left behind by Skype will be located and examined manually, both on a
Windows system and Android devices.
- A software tool will then be developed, with the ability to gather the potentially useful
artefacts left behind by Skype on a Windows computer system.
- The tool will then be tested on a number of systems, to ensure that it gathers the relevant
artefacts discovered during the manual investigation.

Page | 8

Chapter 2 Literature Review


2.1 Literature Review
Questions regarding the security of data sent and received between Skype clients are not
uncommon, with a number of investigations being carried out to see what sort of data can be
intercepted whilst it is being sent over a network. Although this is quite a popular area of
investigation, much less research has been done into data stored locally on systems running
the Skype client. Owing to the secrecy surrounding the network protocols used by Skype, and
due to the encryption methods used both whilst transmitting data over a network and storing it
on local systems, it is very difficult to intercept and utilise Skype data whilst it is being
transmitted, or to even read some data stored locally on Skype-enabled computer systems.
There are multiple reasons why this investigation is being conducted, the first of which is
purely down to curiosity as to what sort of information Skype records, stores and uses. If we
then consider the information that Skype is privy to such as the information required to
create an account, which includes our email address, forename, surname and date of birth it
can be quite concerning to think that this personal information could be stored in an insecure
manner. Although this is likely to be stored on Skypes secure servers, it is also possible that
some of this data may be used by the Skype local client, which may mean that the data is
stored locally on the users computer, in a directory created by Skype. Although this may not
seem like an issue to the majority of people, it is likely to be much easier for an unscrupulous
individual to gain access to someones personal computer and take this information from
there, rather than accessing Skypes servers, especially if the locally stored information is
stored in plaintext and not encrypted or hidden in any way.
Further to this, the Skype application for Android devices will also be examined, to discover
how it handles the same data found on a Windows computer system. If the Android
application does not encrypt or hide this data in any way, then this could mean that people are
walking around with large amounts of personal information on their person, without them
being aware that this information is accessible by any party that may gain access to their
phone.
Another reason for examining the Skype application for Android devices, is due to the
security flaw that was discovered in the application back in 2011. The Skype files that
contain personal user details were left with insecure read and write permissions, and were also

Page | 9

left unencrypted. This meant that any application could access and use these files and the data
within them. This data included;
everything from your Skype username, contacts, profile, and instant message logs to
far more sensitive information, such as your account balance, full name, date of birth,
address, phone numbers, e-mail address, your biography, and more. Also at risk is
similar data about your contacts. (Cassavoy, 2011).
The results of this investigation may be used for three key reasons. Firstly, the information
found will be used to assist in the development of a software tool that will automatically
gather any useful artefacts left behind by Skype on local systems. This could then be used to
aid in the investigation of hard drives that may have been seized by authorities, from someone
accused of committing some form of illegal activity.
Secondly, if users are aware of what kinds of information are stored by an application, they
may be more careful when using these applications. For example, if Skype text chat logs are
stored in plaintext on the local system, people will be much more careful when discussing
confidential topics, such as banking information.
Finally, if a large number of artefacts containing personal user data are easily available, this
could be shown to the Skype developers, in the hopes that it would prompt them to find
another method by which the application could handle said data, whether it be by encrypting
the relevant data or by hiding it in a more secure location on a Windows computer system.

2.2 Brief Overview of How Skype Clients Connect


This overview of how the Skype application initiates a connection is taken from the Skype IT
Administrators Guide, provided to network administrators by Skype themselves. Although it
provides enough information to allow network administrators to configure their network to
allow for Skype network interaction, Skype are very careful not to mention any specifics
about the functions of the protocols that Skype uses. Owing to both this and the encryption
systems used by Skype, it is very difficult to determine the exact details of how Skype
functions.
Skype uses a number of Peer-to-Peer nodes to connect the vast number of installations across
the world to one another. The three types of nodes defined in the Skype IT Administrators
Guide (2010) are ordinary nodes, supernodes and relay nodes. An ordinary node purely runs
the Skype client, as an everyday user would see and use it. Supernodes are ordinary nodes
with a few extra functions. They are used for tasks such as searching for the locations of
Page | 10

other nodes that users may want to connect to. Supernodes are selected at random and are not
dedicated, so a system may act as a supernode one day, but may just be an ordinary node the
next. Not all Skype-enabled systems can become a supernode, they must meet a list of
specific requirements, such as having a public IP address. Relay Nodes are used to relay
media and signalling information between nodes that otherwise cant reach each other,
normally because of firewall permissions or problems traversing NAT. It is stressed that
relay nodes are not able to view the information they are relaying, they simply pass it on to
the intended recipient.

Figure 1. Diagram taken from the Skype IT Administrators Guide (Anon, 2013), to
demonstrate the role of each node.

To establish a connection between two clients, the Skype client on the originating system will
communicate with the peer network to ensure there is connectivity. It will also check that the
outgoing UDP port is available, and what type of address translation is utilised by the network
it is running on. Once the user selects the user they wish to call, the Skype client will check a
number of standby connection paths for the one with the lowest latency and optimal
bandwidth for connecting to the Skype network. The originating client will then reach out to
a variety of supernodes on the network to try and locate the intended recipients network
Page | 11

address, as well as their associated supernodes. Once the intended receiving client has been
located, the originating client will then attempt to initialise a session with the recipient. If the
recipient is not accessible directly (due to network settings, firewall etc) then the client will
attempt to initiate a connection via the peer-to-peer network to hopefully find a connection to
the recipient that can bypass the blockage.

2.3 Other Research Conducted in this Area


2.3.1 Skype Fingerprint
The paper Skype Fingerprint (Dodge, 2008) addresses the topic of locally stored Skype data
but, although the findings are detailed, this investigation was carried out before Microsoft
acquired Skype in 2011. Microsofts acquisition of Skype brought along a myriad of changes
to the Skype client, including the method by which Skype stores data locally on computer
systems.
Much like this paper, Dodges paper focuses on;
an analysis of the information that can be gleaned from a Skype installation and use
on a client system. (Dodge, 2008).
Utilising a number of tests, Dodge checks to see if any useful information can be learned from
the Windows Registry as well as in the usual application installation locations, such as in
Program Files and the Application Data folder locations. The results of Dodges tests present
a wide variety of results. Much of the data found was either encrypted or encoded, but he was
able to find certain data that was not, such as some of the configuration settings for the
particular Skype client in use. He was also able to find data such as a summary of most recent
text-based instant messages sent, the default storage location for sent and received files, and
information regarding the current users contact list. Dodge lists the names of the files in
which he found this information, many of which do not seem to be present in the current
version of Skype (version 6.14.60.104). The reason for this is not yet apparent, and will be
investigated further.
All in all, Dodges paper does a good job of detailing the discoveries he made and the
processes by which he made these discoveries. Despite the fact that some of the results in this
paper are relatively irrelevant in the current version of Skype (such as files that no longer
exist), the locations in which a lot of his results appeared are still the same today, so these
locations may still be a useful source of information.

Page | 12

The only issue to be raised, is the method by which Dodge manufactures the Skype clients he
examines. As he is using fresh installs of the Skype client and generating data by using
Skype in a step-by-step manner (first log on, first message, first call etc), it is possible that
something was missed out of the investigation. Although using a fresh install of Skype
ensures that all the default settings are in place, this adds a manufactured twist to the
investigation. If Dodge were to carry out this base investigation, and then follow it up with an
investigation of an existing Skype account and client, the data collected would be real-world
data, making the findings more relevant to a real-life investigation into a users Skype
account.
2.3.2 Client-side Skype Forensics An Overview
The paper Client-side Skype Forensics An Overview (Creutzburg, Krger and Meiner,
2013) aims to highlight and explain the kinds of Skype user data that can be found on local
computer systems, along with the tools that can be used to access this data. The authors carry
out both a manual analysis of Skype data, and also utilise a number of widely available tools
to help locate and interpret data (Creutzburg, Krger and Meiner, 2013).
The authors begin by briefly introducing the Skype application and give an overview of what
it is, how a connection between peers is established, and the types of information that are
stored by the application itself.
The first method the authors use to analyse Skype data, is to manually search through the
Skype data files and to examine them themselves, using generic tools such as a hex editor.
Although the information presented in this section of the paper is relatively informative, it
seems to require the reader to have knowledge on the subject prior to reading. The authors
talk about the different Skype files, such as main.db, with very little explanation as to what
the file is used for, and with no explanation as to where it was found or how it was
discovered.
Although the information given during the manual analysis of Skype files is relatively brief,
the authors provide more detail on the data found whilst utilising software tools, such as
SkypeLogView and SQLiteSpy.
Overall, this paper does give some useful information regarding the personal user data stored
and utilised by Skype, but it seems to be more of a review of the software tools available,
rather than an analysis of the data that can be found, whether manually or using tools. Also,
the authors seem to have a differing definition of what a tool is. During the manual
Page | 13

investigation part of their report, the authors make reference to opening the main.db file in a
hex editor; the main.db database file, which is readable in the (hex) editor, contains
information. To the majority of people, a hex editor is a software tool, albeit one with not
much in the way of features. The authors also use a SQLite reader in their tool-assisted
section of the paper which, offers similar functionality to a hex editor it is a software tool
without much in the way of features, designed primarily for the analysis of a specific type of
database file.

2.4 Similar Applications


Although there are not many applications out there that offer the same variety of functions in
one package that Skype does, there are many that offer similar functionality, such as instant
messaging with the option for voice calls. One such application is Xfire.
2.4.1 Xfire
Xfire is an instant messaging application that is primarily used by gamers, as it offers an ingame chat interface, allowing users to communicate with friends whilst simultaneously
playing games, either by an instant messaging interface or via VoIP. A brief investigation will
be carried out to discover how Xfire stores its data as it offers very similar functionality to
that of Skype, albeit with a few missing features such as video conferencing. Also, owing to
the fact that Xfire is focussed more on the instant messaging than VoIP, it will be interesting to
compare the storage of any Xfire chat logs compared to Skype chat logs.
As with the majority of instant messaging clients, Xfire provides the option to allow for chat
logs to be created and stored on the local computer storage. Although users have the option to
enable or disable this recording of conversations, upon installation of the Xfire client, the chat
logging option is enabled by default. This can be seen by navigating to the Chat options
menu. The moment a message has been sent to or received from a contact on the users friend
list, the chat log is generated. Users are able view the chat logs for each of their individual
contacts by selecting the View Chat History option within the desired contacts chat
window. Users also have the option of deleting chat logs by selecting the Delete Chat
History option in the same location as View Chat History. Although the storage location
for these chat logs is not advertised within Xfire, a simple Google search for Xfire chat logs
storage location presents a link to a blog post on the official Xfire website that explains
exactly where to find the logs: Xfire saves your chat logs to the Application Data folder
which is tied to your Windows user account. Specifically you can access the said folder by
using shortcut %appdata%\Xfire\chatlog (GODJonez, 2009). Although this blog post was
Page | 14

created nearly 5 years ago, navigating to this directory shows that this is still the storage
location for Xfires chat logs (Appendix 1).
Within this folder, Xfire creates a separate folder for each user account that is used on the
computer system in use. Then, within the user folder, a notepad (.txt) file is created to contain
the conversations had with each individual user. If this file is then opened in notepad, or any
word processor, we are able to see the entire contents of the conversations carried out between
the two users, in plaintext (Appendix 2).
2.4.2 Google Hangouts
An application that is very similar to Skype is the relatively new Google Hangouts,
formerly known as Google Talk. Google Hangouts offers very similar functionality to that
of Skype, as it includes the options for instant messaging, video calling, video conference
calling and so on. The main difference between Google Hangouts and Skype, is that
Hangouts is a browser-based application. This means that it can be run directly from the web
browser that is currently in use, such as Google Chrome. Skype on the other hand, uses a
dedicated application that must be downloaded and installed before use.
Although Hangouts is browser-based, to enable the use of the VoIP functions, such as a video
or voice call, the user is required to install a plugin from Google, entitled
GoogleVoiceAndVideoSetup.exe. The user is prompted to install this the first time they try
and initiate or connect to a VoIP call.
The instant messaging portion of Hangouts does not require any plugins or applications to be
installed, users are able to access and use this function whenever they are on Google+. Users
do have the option to install an add-on into the Chrome browser that allows for Hangouts to
be used from anywhere, including the desktop of the computer system, without the need for
the Chrome browser to be open.
As Hangouts does not require an installation of any application by default, it is unlikely that
any instant messaging chat logs will be stored locally on the system in use. However, once
the user has installed the plugin required for VoIP calls, data is stored on the local system,
even if it is just the data left behind by this plugin.
After some investigation, the files created by the plugin were found in %AppData
%\Local\Google\Google Talk Plugin. The majority of the files in this directory and its
subdirectories do not seem to store any data relevant to the system they are installed upon, as
the Date Modified is set to a time long before the plugin was installed upon the system in
Page | 15

use. The main file that stands out is gtbplugin.log which had a Date Modified and time
that match up with the last use of Google Hangouts. Opening this file in Notepad++ reveals
that the file is completely plaintext. At the top of this file are number of records of failed
attempts for Hangouts to connect to the plugin. Scrolling to the end of the log file presents
more interesting information. This appears to be a log of successful connections of the plugin
to the Hangouts application. One line of plaintext contains information such as the username
of the account being used, the domain on which the user was logged in, and the browser that
the user was using at the time. There is also another line that lists all of the audio/video
devices connected to the system in question. On the particular system being used for this
investigation, the make and model of the connection webcam, microphone, headphones and
audio input devices were all listed.
Although there was no record of any conversation logs produced by Google Hangouts, the
information that was found may still prove useful, whether this be for a lawful investigation
or for unscrupulous means.

2.5 Exploring Windows


All the data on a Windows computer system, whether that be user created data such as
documents or data utilised by applications, is stored on a hard drive within the computer
system. The data on this hard drive is sorted into multiple directories, dependant on the type
of data, how the data is used and so on. Unlike Linux operating systems, the Windows
directory structure displays separate hard drives as separate entities (unless configured to do
otherwise by the user). Each of these drives is allocated a drive letter (C:, D:, E: etc) as the
identifier for each individual device. By default, the hard drive on which the Windows
operating system is installed is allocated the letter C. Within the C: drive, there are a
multitude of default directories that are created upon installation of Windows, the most
important of which are Program Files, Users and Windows.
The Program Files directories, (which can appear as Program Files, Program Files
(x86), or both) is the default location in which the data required by applications is stored.
The Users directory is the default location in which individual user data is stored for each
user account on the Windows system in use. For example, if there are two accounts, one
entitled John and one entitled Andrew, there will be two directories, one with the name
John and one with the name Andrew. These folders contain all the data stored on each
user account on the system, for example the contents of Johns My Documents directory.
By accessing the Users directory, an Administrator is able to view the files contained within
Page | 16

each user account. Within each individual user directory, there is a hidden folder, or a
folder/directory that is not visible by default, entitled AppData which contains the user
settings and some application data for applications used by that particular Windows user
account.
Finally, the Windows directory contains the vast majority of the data used by the Windows
operating system itself, such as the different languages available, the fonts that can be used by
the system, and programs that come with the operating system, such as the calculator.
To gain access to the majority of the above directories, the user will need to have
administrative privileges on the computer system in use or, in the case of the Users folders,
they will need to be the owner of the folder they are trying to view. For example, the user on
the account John would be able to access that accounts User folder, with or without
administrator privleges.
Any further hard drives installed within the physical system can be used for a variety of
different tasks, dependant on how the user sets them up. For the most part, the directory
structure of these extra drives will be determined by the user (Anon, Unknown C).

2.6 Exploring Android


The examination of files on an Android device is worlds away from the examination of a
Windows system. In Windows systems there can be multiple drives, each with its own root
directory (the very base of the file system for that drive, for example the first screen seen
when opening up the C: drive) that contains all of the files stored on that particular drive. As
Android is based on the Linux/UNIX operating system, the file hierarchy is relatively similar
to that found on a Linux based system, albeit with a few slight variations. Instead of having
multiple drives each with its own root directory, Androids file hierarchy is a single entity into
which all drives and directories are linked. The very top of this directory (or the root
directory) is /. Underneath / are the files and directories of the system. Unlike a
Windows system, Android has no perception of different drives, merely this sole hierarchy of
directories. Any physical drives connected to the system (internal storage, external storage
devices such as memory cards etc) are connected to a directory, to allow for this integration
into the single hierarchy (Anderson, 2013). For example, on a Samsung Galaxy S3 running
the most recent version of Android (version 4.4.2 at time of writing), navigating to the root
directory shows a number of different directories including the two connected to the two
different storage locations for the device; sdcard which represents the internally installed
memory of the device, and extSdCard which represents the MicroSD card inserted into the
Page | 17

device (Appendix 3). If the MicroSD card is removed from the device, the extSdCard
folder remains in the root directory, but the contents of it are no longer there (Appendix 4).
As all data stored and used by the Android operating system is also stored under this root
directory, it would be logical to assume that all data installed, used and generated by
applications on the device must be stored here somewhere.
Although this root directory in Android contains everything stored or installed on the device
in use, the large majority of users will not be able to, and will not need to, gain access to it.
For a user to be able to gain access to this root directory, they need to have special privileges,
or root access on the device.

2.7 Android Root Access


In the Android world, the term root access is used to refer to the access of a special user
account on the system that has system administrator privileges, allowing it access to all areas
of the device, with permissions to make changes to any file or directory. It also provides
functionality to allow certain applications to run with more permissions than they would
originally have (Hoffman, 2012).
As mentioned previously, the majority of users will not have root access on their Android
device. This is due to the fact that the large majority of manufacturers do not enable root
access by default. The reasoning for this is that with the ability to edit any file on the device,
there is also the possibility for a user to edit a file on which the system depends, potentially
breaking their device (Hoffman, 2012).
During the experiments carried out later in this project, a number of different Android devices
will be examined in the attempt to find any Skype artefacts. One of the devices being
examined, the Samsung Galaxy S3, will have root access and will be running software that
has been slightly customised compared to the Android installation as it comes from the
manufacturer. Another device to be examined, the Google Nexus 7 (2012), will not have
root access, and runs the software that the manufacturer installed upon it. The reasoning
behind this is to determine if any Skype data is available on a device with root permissions,
and if it is, to discover whether this data is also accessible on a device that does not have this
same level of elevated privileges.

2.8 Tools for examining Android Devices


There are a number of tools available online to assist with the examination of the internal files
of an Android device, such as Android Commander and Android Debug Bridge (ADB). The
Page | 18

tool that will be used during this investigation is Android Debug Bridge. Android Debug
Bridge is a tool created by the developers of Android and is included in the Android
Development Toolkit, for use by developers when creating applications or software for
Android devices. On the Android Developers website, ADB is defined as:
a versatile command line tool that lets you communicate with an emulator instance or
connected Android-powered device. It is a client-server program that includes three
components:
-

A client, which runs on your development machine. You can invoke a client from a
shell by issuing an adb command. Other Android tools such as the ADT plugin and
DDMS also create adb clients.

A server, which runs as a background process on your development machine. The


server manages communication between the client and the adb daemon running on an
emulator or device.

A daemon, which runs as a background process on each emulator or device instance.


(Android, Unknown)

Essentially, the Android Debug Bridge allows users to execute text-based commands via a
command line terminal on their computer system, and have those commands retrieve data
from the connected Android device or emulated device. Some of the commands available for
use via ADB are push which allows the user to copy a specified file from their computer
system in use to the attached Android emulator or device, pull which allows the user to
copy a specified file from the Android emulator or device to the computer system in use, and
shell which starts a remote Linux command shell on the attached emulator or device
(Android, Unknown A).
Android Debug Bridge will be used as part of this investigation to assist with the location of
any potentially useful Skype artefacts, and also to attempt to copy any of these artefacts from
the device in use. ADB will be used on two different Android devices, both with and without
root permissions, to see whether or not these permissions are required to explore the
internal file structure of an Android device.

2.9 Application Research


For the creation of the application to be made as part of this project, there were a number of
different programming languages that could have been used, including Python and Java. In
the end, the chosen language was C# (C Sharp). Although there are a number of advantages
Page | 19

to using one of the many other programming languages available, C# was chosen for a
number of reasons. The first of these reasons was due to prior knowledge. Having already
used C# in coding projects, it made sense to start off utilising this knowledge, with the
possibility of adapting the application to another coding language at a later date.
Another reason for choosing C# was for its compatibility. Despite the fact that it is designed
to be a platform independent product (Anon, Unknown D) it is primarily used with
Windows, owing to the fact that it is a Microsoft product. Also, owing to the fact that this is
the third iteration of the C-Family of programming languages, with C and C++ being the
two previous languages, there is a certain feeling of refinement to C#.
Finally, the object-oriented nature of C# (Microsoft, Unknown) made it an appealing language
to use, due to the fact that this would make it easier to modify the program in the future,
should there be any new artefacts added or discovered in Skype that may be useful.

Page | 20

Chapter 3 - Methodology
3.1 Methodology
The formal method by which this investigation will be carried out will be a qualitative format,
rather than quantitative. The reason for the decision upon this type of research method, is so
that more time can be spent in the investigation phase, allowing for more focussed results.
To begin the investigation, a Skype installation on a Windows system will be examined, in an
attempt to find any useful artefacts. Windows has been chosen as the primary operating
system for this project as it is currently the most popular operating system in use today (Anon,
2014). The first step in this examination will be to look through the most common locations
in which applications are likely to store their data, such as Program Files, Program Files
(x86), and the Application Data folder. If, or when, any useful artefacts are located, a copy of
them will be created so as to allow for closer examination of the data, using any tools required
to view them.
After the examination of the Windows installation of Skype has been completed, an
examination of an installation of Skype on two Android devices will be carried out. Android
has been chosen as the secondary operating system for this investigation as it is the most used
mobile operating system, especially in European countries (McCaskill, 2014). The devices to
be examined will be a Samsung Galaxy S3 (I9300) and a Google Nexus 7. The reason for the
examination of the Samsung Galaxy S3 is that it already has root permissions and is running
the most recent version of Android (4.4.2 at time of writing). The Google Nexus 7 has been
chosen as it is also running the most recent version of Android (4.4.2) but does not have root
permissions. The permissions on the Nexus 7 are the permissions with which the device was
granted at manufacture. Using the two devices running the same version of Android is to
ensure consistency of the files and file structure across both devices.
Once the examination of the two Android devices has been completed, the results of each will
be compared to one another, to see if the differences in permissions of the devices causes any
difference to the availability of potential Skype Artefacts.
Following on from the manual examination of both Windows and Android devices, the results
of each will be compared to one another, so as to identify whether or not certain artefacts are
available on one operating system and not another.

Page | 21

Subsequently, a software tool will be designed and developed, with the aim of it being able to
replicate the useful artefacts discovered in the previous investigation, without it causing any
modification to the original artefacts. This tool will be developed for use on Windows
systems, again because Windows is the most popular operating system in use today (Anon,
2014).
3.1.1 Manual Investigation of Windows Device
To begin the manual examination of a Windows installation of Skype, the Program Files,
Program Files (x86) and AppData directories will be examined. The examination will be
focussed around these directories because they are the key areas in which applications store
their data on Windows systems. These directories will firstly be examined for any sign
potential Skype repositories and, following on from this, any potential Skype storage
locations found will be examined more closely. Any data then found to be potentially useful
will be examined and analysed in further detail. This examination will be carried out
manually, with the use of tools required to read certain files, such as Notepad++ for
configuration files.
Once any data has been located and analysed, the locations in which this data is found will be
compared to the locations which others have found useful in the past, such as in Skype
Fingerprint (Dodge, 2008).
3.1.2 Manual Investigation of Android Devices
The first Android device to be examined will be the Samsung Galaxy S3. The reason for
examining this device first is due to the fact that it has root permissions. With root
permissions, the examination will be much more detailed, as there will be no storage areas
into which access is restricted. Utilising this elevated access, the hope is to find any Skype
artefacts available, and note down the location in which these are stored. Once this is done,
the second Android device, the Nexus 7, will be examined to see if the results found on the
Galaxy S3 can be replicated on a device with default permissions.
The first method by which the Android devices will be examined, is by utilising a generic file
explorer application from the Google Play Store. This file explorer will allow for the
examination and navigation of the files stored on the device in use. Once a file explorer is
chosen, a brief examination of the internal and external storage (if applicable) of each device
will be carried out, to see if any Skype data is stored in any obvious locations. After this brief
inspection, research will be carried out regarding the install location for applications,
alongside investigation being done to confirm the information presented in the research.
Page | 22

If possible, the Skype APK file (the installation package for the Skype Android application)
will be copied onto another computer system and decompiled using any required tools. This
should then allow for the examination of the files within the installation package in the hopes
that it will identify the locations on Android in which Skype data is stored.
3.1.3 Application Design
Using the data collected from the manual examinations of the Windows and Android devices,
a design will be formed for the creation of the proposed application. This design will consist
of plans for the functionality, aesthetics and usability of the application itself, along with
proposed methods of meeting each design requirement.
3.1.4 Coding of Application
Once the application has been designed, the coding of the application will begin. The coding
process will go through a number of stages. To begin with, a very basic user interface will be
created, purely for testing the application as it is developed. The functionality will then be
coded in a number of stages, starting off with the variables all being hardcoded, to ensure the
required function is possible. Once this has been completed and tested, the ability to add user
input variables will be added and tested. Once all the required functionality has been
implemented, then the user interface can be improved to make it easier for users to operate.
3.1.5 Analysis of Application
After the application has been completed, the code will be reviewed and analysed, so as to
ensure that it is all functioning correctly, and that no obsolete code remains from any testing
and experimentation that may occur during development.
3.1.6 Application Testing
Finally, once all coding and analyses have been completed, a number of experiments will be
carried out so as to test the completed application and to ensure that the intended functionality
is present, and also to ensure the functionality is present on computer systems running
different variations of Windows, and comprised of different hardware components.

Page | 23

ual examination of a Skype installation on a Windows System

Manual examination of a Skype installation on first Android device

Manual examination of a Skype installation on second Android Device

Comparison of Android device results

Comparison of results across operating systems

Design of software tool

Coding of software tool

Analysis of software tool

Testing of software tool

Figure 2. Waterfall model representing the methodology.

Page | 24

Chapter 4 Analysis and Design


4.1 Preliminary Investigation
Prior to designing the application that will collect the useful Skype artefacts, a manual
investigation is to be carried out, so as to identify the locations in which files were stored, and
to determine which files were to be collected.
Unlike in Dodges paper (2008), the Skype clients used in this investigation will not be a
completely new install, and will be live clients that have been used on a daily basis for quite
some time. These accounts will be used so as to simulate the information that can be found
from the Skype client of an average user.
4.1.1 Examination of Windows Devices
With Windows being the most popular operating system in use today (Anon, 2014), the
primary operating system examined within this investigation will be a recent version of
Windows. Also, Microsoft owning Skype added to the appeal of using Windows as the
primary operating system for this investigation.
The first step of the examination on Windows was to search through the most common areas
in which Windows stores application data. Firstly, the Program Files and Program Files
(x86) folders were examined in an attempt to locate the Skype install files. Once located,
within C:\Program Files (x86)\Skype, these files were examined for any potentially useful
data. Although a large number of programs store the majority of their application data within
their Program Files folders, in the case of Skype, the files contained within this directory
were used purely for the execution of the Skype application. The only files within this
location were desktop.ini, which points to the icon file that should be used by the desktop
shortcut, and a simple text file entitled third-party_attributions which provides copyright
information for certain elements within Skype. The files contained within the subdirectories
were the executable file for the Skype update program and the Skype application itself, along
with an archive entitled login, which contains data such as emoticon images and different
languages that can be used by the application.
As the data stored within Program Files did not prove useful, the next location to be
examined was the AppData folder, stored within Windows user directories. In this particular
case, the full folder path was C:\Users\Daniel\AppData. Once in the AppData folder, the
subdirectories of Local, LocalLow and Roaming were to be examined for any Skype
data. There was a Skype directory found within Local and Roaming. The directory
Page | 25

within Local simply contains a subdirectory entitled Apps. Within this directory, is
another, entitled login, along with an .md5 file, also entitled login. The login directory
seems to contain the data extracted from the login archive found previously. The .md5 file
simply contains the md5 hash value (or the fingerprint) for the original archive.
The Skype data stored within the Roaming directory is by far the most interesting (full path:
C:\Users\Daniel\AppData\Roaming\Skype). Within this directory there are a number of
subdirectories, along with three individual files (Appendix 14). The majority of the
subdirectories, along with the individual files, do not seem to hold much in the way of useful
information. The one useful directory here is the one that uses a Skype username as the title,
which in this investigation was dcastle91.
Within the Skype user directory, there are a myriad of subdirectories and individual files. The
first directory of interest was the chatsync folder. Within this folder, there appears a
varying number of folders, each with a two character long name, that seems to be a mix of
letters and numbers. Although some of these directories contain no data, the ones that do
contain information are extremely useful. By opening the .dat files found within these folders
in Notepad++ (the name of each file is comprised of random numbers and letters), we are
presented with what seems to be large amount of encoded data (Appendix 15). Although this
was what it looked like at first glance, a more detailed examination of the text shows that
there is plaintext in places between the encoded data. This plaintext data seems to consist of
the conversation history between any users that were part of a Skype call or instant messaging
session at that particular time. For example, in one particular file being examined, the
username dcastle91 was found, along with a number of links to various different websites
(Appendix 16) that had been sent by the user.
Browsing through the remaining directories within the Skype user folder does not present any
useful data as the majority of the directories were either empty, or the files that were found
tended to be encoded.
The individual files contained in this directory are where the majority of the useful
information comes from. When opened in Notepad++, the config.xml file presented a large
amount of information about the user account being examined. Although some data, such as
the last used date/time, is encoded, there is also an extensive amount of plaintext data. For
example, one of the first noticeable pieces of information was a plaintext list of all the
usernames for the contacts in that user accounts address book. Although these usernames are
in plaintext, any usernames with a full stop within it has a random combination of two
Page | 26

characters following the full stop. One such example of this, is that john.smith becomes
john.3Asmith (name changed to protect the privacy of the user).
The config.xml file also contains a list of all video input devices connected to the system,
along with any audio input/output devices connected. This list not only shows that there are
devices present, but also gives the make and model of each device, provided that that
information is available to the system itself. The devices listed here do not always have to be
physical. For example, on the system being examined, a virtual surround sound tool is
installed. This tool is listed as an audio output device.
An additional useful piece of information found within this particular file is the file transfer
directory used by the user. Between the <FiletransferDir> tags, the full file transfer path is
listed. In this case, the path was C:\Users\Daniel\Desktop\. At the end of the document the
default file transfer directory is listed, in this case as
C:\Users\Daniel\AppData\Roaming\Skype\My Skype Received Files\.
The final file found that contains useful information is by far the most useful. The main.db
file, found within the Skype user folder, is a SQLite database file and thus must be opened
within a SQLite database editor to be viewed. In this investigation, the tool used was SQLite
Browser. Within this database file, an extensive amount of data is stored. Although a
number of sections of the database do not hold much useful data, others hold plenty.
The first section containing detailed information is the Videos table. Within this table, there
is a record of each time a video stream was initiated. Not only does this file identify when a
video stream was initiated, it also identifies a device ID for the device used, and if the video
session was a video conversation or a screen sharing session. In the cases where it was a
screen sharing session, the dimensions of the screen shared is also recorded, although this is
only the case when the user being examined has broadcast their screen, rather than viewing
another users screen.
The next useful table is that of the CallMembers table. Within this table, a record is kept of
each of the calls the user has been a part of, along with the username and display name of the
users with whom the call was initiated. Skype also keeps a record of the duration of the call,
but the timeframe used is not specified. The logical assumption for the timeframe would be
that of seconds, but this cannot be guaranteed. Finally, the CallMembers table also keeps a
record of the IP address of the other participants of the recorded conversations.

Page | 27

The Conversations table contains similar information to that already seen in previous
tables, but it also has the added record of the username and display name of anyone that the
current user has been in conversations with, even if they are not on one anothers contact lists.
The VideoMessages table is only populated if a video message is recorded and sent to
someone using the built in Skype function. If a video has been sent from the account being
examined, there is no record of the user to whom it was sent, just a confirmation that it was
sent from the user account in question. If a video has been received, the username for the user
that sent the video is displayed. Within this table, there are two sections that are most
important, the first of which is vod_path. Within this column, a URL is stored that, when
copied into a web browser, displays an online version of the video sent or received. Although
this is useful, testing showed that this link is only valid for around 24 hours, after which it is
no longer available. The other useful column is local_path which, as the name suggests,
provides the local path for any video messages sent from the computer being examined. In
this example, the location was
C:\Users\Daniel\AppData\Local\Temp\vidm1394057941.mp4. There is no local directory
for received video messages, as they are not downloaded to the local system for viewing.
The Contacts table presents a list of all the contacts within the current users address book.
The table presents both the display name and Skype username for each user. The majority of
the rest of the information displayed here is dependent on the information that each user has
entered into their Skype account details. If it has been entered, the data recorded in here
includes each users birth date, gender, spoken language, country, province, city, home
telephone number, mobile telephone number and a link to any associated websites. Although
the majority of this information is viewable on the user in questions profile, it is only
viewable by people that have been approved by the user. If an unscrupulous individual were
able to gain access to all of the above information, the potential consequences could be
disastrous for the target individual.
The Calls table displays a history of calls that the current user has been involved in. The
list keeps a record of the identity of the user hosting the call, as well as other users involved
with that particular call.
Another potentially useful table is the Transfers table. As the name suggests, this table
keeps a record of every file transfer made between users, including a record of who the
sending/receiving party was, the local file path for where the document was sent from or
saved to, and the name of the file that was sent or received.
Page | 28

Finally, the Messages table contains a record of the majority of messages sent and received
via the Skype instant messaging function, along with the users who were involved with each
message. Although the messages are stored individually rather than in conversations, the
majority of them are easy to read and to follow on from.
Although there are other files and directories stored within the Skype user folder, the data
stored within them is either encoded or does not provide much in the way of useful
information.
4.1.2 Examination of Android Devices
The first Android device to be examined was the Samsung Galaxy S3, with full root
permissions. The first stage of this examination was to simply use a file explorer application
freely available on the Google Play Store. In this case, the application used was ES File
Explorer. Upon opening the application navigating to the root directory, or /, shows the
directory structure used by Android. By simply browsing through the first few directories, a
number of files are encountered that are key for the functioning of Android, empty folders and
configuration files. Upon entering the data directory, a number of directories are located
with the word app in the title, hinting that these folders may contain application data. This
suspicion is confirmed by entering the very first folder, simply entitled app. Within this
folder, are the .apk files (installation files) for all user-installed applications on the device,
including the installation package for Skype, entitled com.skype.raider-1.apk (the full
application package name). At this point, the device was connected to a Windows computer
system so that the Skype installation package could be extracted for investigation. Using the
Android Debug Bridge application, the adb pull command was utilised to make an exact
copy of the Skype application package file. The full command used was; adb pull
/data/app/com.skype.raider-1.apk. Once the file had been copied, the aim was to examine the
files contained within the package to identify something that defined where the Skype data
would be stored.
By utilising the program 7zips extract archive feature, access was gained to a number of
different files from within the original .apk file. A lot of these files were image files of
emoticons and other images that users can send whilst using Skype. The file that was most
intriguing was the AndroidManifest.xml file stored in the root area of the file, as the name
of the file gave the impression that this would be where a large number of the core settings
would be declared, for use by the Android operating system. Upon opening this file in
Notepad++, a relatively large amount of text is displayed, but the majority of it appears to be
Page | 29

either encrypted or corrupt (Appendix 5), making the majority of the data available relatively
useless as the majority of it is unreadable. Despite this, the Search function was utilised to
try and find the term Install, but to no avail.
Owing to this, it seemed logical to try to locate a program that was able to reverse-engineer
Android application packages properly. This is where APKTool comes in. APKTool is a
community-developed tool for use in decompiling Android .apk files. In the words of the
developer;
It [APKTool] is a tool for reverse engineering 3rd party, closed, binary Android apps.
It can decode resources to nearly original form and rebuild them after making some
modifications (Tumbleson, Unknown).
Utilising APKTool, the com.skype.raider-1.apk file was fully decompiled. Although this
seemed to produce less files than when they were extracted using 7zip, the missing files did
not seem to have much relevance, as they appear to be files generated at compilation of the
.apk file. Once decompiled, the AndroidManifest.xml file was once again opened in
Notepad++. This time round, all of the data was in plaintext and organised correctly. Nothing
more than a quick glance over the code was needed to find the declaration of the install
location, featured in the second line of the code (Appendix 6). The declaration
android:installLocation=auto is the code which the Android operating system reads to
determine where to place the application files. Although it states auto, which means very
little to the average person, a page on the Android developer website details each of the three
possible variables for this declaration and defines what each of them means. The auto
variable is defined as:
The application may be installed on the external storage, but the system will install
the application on the internal storage by default. If the internal storage is full, then the
system will install it on the external storage. Once installed, the user can move the
application to either internal or external storage through the system settings.
(Android, Unknown B).
Although this defines that the data will be stored on either the internal or external storage of
the device in use, we are still unaware as to where exactly the application data is stored. A
quick search online for Android application default data storage returns a multitude of
results, consisting primarily of forums that indicate that the default storage location is
/data/data/<Package Name> (Izzy, 2013). By navigating to this location on the rooted
Page | 30

Samsung Galaxy S3, this is proven to be true (Appendix 7). By searching through the
multitude of folders for the Skype package (com.skype.raider, as defined by the title of the
.apk file located earlier), data stored and utilised by the Skype application can be found. At
first glance, the directory structure for the Skype application files on Android looks different
to that of the directory structure found during the Windows examination. This impression is
given by the first set of directories presented when accessing the com.skype.raider directory.
The directories displayed are app_webview, cache, files, lib and shared_prefs
(Appendix 8). Although the majority of these folders store encoded data, the files directory
brings up a set of files and directories similar to that found on a Windows system running
Skype (Appendix 9). Although not all the directories found on the Windows version of Skype
can be found on the Android version, the one that contained the most useful artefacts was still
present; the user account folder, in this case entitled dcastle91. Within this folder, we find a
very similar structure to that of the Windows version of Skype, with files such as main.db
being used to store the same majority of the user account information.
Once this information had been located on an Android device with full root permissions, an
investigation was to be carried out to see whether or not this data is accessible on an Android
device with the permissions set at default by the manufacturer. In this particular instance, the
device in use will be an Asus Nexus 7 2013 edition. By using the same application, ES File
Explorer, a similar approach will be taken to that as carried out on the Samsung with root
permissions. By navigating to the root of the Android storage, or /, the directories and files
stored in the root area of the device are visible (Appendix 10). However, when accessing the
required directory, data, we are presented with a blank folder, as though there is nothing
stored within it (Appendix 11). This could be for one of two reasons; either the folder is
indeed empty or, the more likely reason, the contents of the data folder are not visible to a
user with permissions lower than that of root.
To further determine whether or not the Skype application files are accessible on a device
with default permissions, the Asus Nexus 7 was connected to the same computer system as
before, and connected to Android Debug Bridge. Utilising ADBs shell command, which
allows for a Linux-style shell session to be run on the target device, the device was examined
to determine if any files in the /data/data/ were accessible. By executing the command
adb shell, a shell session is started on the Nexus 7. By using the UNIX command pwd,
which displays the working directory that the shell session is currently in, it was identified
that the current directory was /, also known as the root directory. By using the ls
command to list the contents of the directory, a list of the files and folders within the root
Page | 31

directory was shown, which displayed a list of the same files and directories seen on the
Nexus 7 via ES File Explorer (Appendix 12). Using the cd ./data command to change to
the data directory, followed by the utilisation of the ls command again to try and view the
files within that directory, a permission denied error message is produced (Appendix 13),
showing that the standard permissions on the device do not allow access to this directory,
whether when accessing it via the device or via an external connection.

4.2 Application Design


4.2.1 Requirements Specification
As stated in the aims for this project, the application to be developed is to have the
functionality of gathering the key artefacts generated by Skype, whether they are files storing
personal details or files containing important configuration information. In addition to this
base function, the application must be able to adapt to gather the files from the system it is
being run on. This section of the project will discuss the plans for the functionality, aesthetics
and the usability of the application itself.
4.2.2 Functionality
As mentioned, the main function of this application is to gather the key artefacts generated by
the Skype application. Once gathered, these artefacts must be accessible to the user of the
application, so as to assist with the investigation of computer systems with Skype installed.
The modification of any data in an investigation is known as contamination of evidence, so
investigators are restricted from working with original data. Due to this, the application will
be required to duplicate the files in question, so as to allow for examination and manipulation
of the files without fear of contamination of evidence.
Also, as mentioned previously, the default location in which Skype stores its most valuable
files is C:\Users\<WINDOWS USER>\AppData\Roaming\Skype\<SKYPE USER> where
<WINDOWS USER> and <SKYPE USER> are the usernames of the respective accounts.
Owing to this fact, the application will need to be able to adapt for use on any Windows
computer system. Without this functionality, the application would only be able to run on
systems with very specific Windows and Skype usernames. For example, if the location was
hard-coded as C:\Users\Daniel\AppData\Roaming\Skype\dcastle91, the program would
only function properly on systems with the Windows username of Daniel, and a Skype
username of dcastle91. There are two possible methods by which this can be accomplished,
the first of which is to code the application with a wildcard in the place of the Windows and
Skype usernames. This way, the program should be able to automatically detect the
Page | 32

usernames for each position, and populate them itself. The second, more feasible alternative,
and the one with which the program will be designed, is to allow the user to input the two
usernames. Not only would this be a more reasonable method to code, it also drastically
reduces the chance of the program taking data from the wrong locations. Although the
automated feature could be implemented, the risk of an error would be far too high, especially
if it were to be used in the intended situations, for example as part of an investigation for a
court case.
4.2.3 Aesthetics
The aesthetics for this application are not of major concern at this point, owing to the fact that
the only tasks carried out within the application are the input of two variables, and the
initiation of the duplication process. As this application is relatively quick to use, the
aesthetics are not something that will be focused on in detail at the present time, as the
functionality is more of a priority. The aesthetics used will be that of a default Windows
Forms application.
The idea for the general look of the application will be to have two text boxes into which the
user will be required to enter the appropriate username, as requested by text placed next to the
box. There will be a single labelled button on the application for the user to initiate the
duplication procedure. There will also be some instructions within the application, so as to
direct a first time user on how to operate the program effectively.
An additional reason for the simplistic look and feel of the application is so it feeds into the
usability.
4.2.4 Usability
The usability of the application is of relative importance, as the idea behind the application is
to make it quicker and easier for users to gain access to the required files. By designing the
application with a simple look and feel, it should make it much easier for the user to
understand and use. The addition of instructions will also assist with the usability.

Page | 33

Chapter 5 Application Analysis and Experiments


5.1 Application Analysis
5.1.1 Application Overview

Figure 3. A screenshot of the application front-end design.

In general, the creation of the application was in line with the proposed design. As stated, the
application has the functionality to accept user input for the Windows and Skype usernames,
and uses this information along with coded data to compile the target directory for the
duplicated files, along with the directory to which the files and data needs to be copied. Upon
inputting the two variables, the user simply needs to click the Click to Initiate Artefact
Duplication button for the program to combine all the relevant variables, and to copy the
Skype artefacts to the target location.
The only area where the application has differed from the plan is that it has two buttons in
place of the proposed two text boxes. The decision to use buttons in the place of text boxes
was made due to the fact that the code used to accept user input was triggering the opening of
additional text boxes, resulting in the user having to input the required data twice. By using
buttons, the user is able to click and trigger a single textbox, into which the relevant username
is entered and thus assigned to the relevant variable.
5.1.2 How the Application Works
(To see the full code, please see appendix 17.)

Page | 34

Upon running the completed application, the user is prompted to grant administrator
privileges. This access level is required so as to allow the copying of the required files from
the AppData directory. To enable the application to request the administrator privileges that it
needs, an app.manifest had to be added to the application, so as to allow the configuration
of the level of access requested upon initialisation of the tool. Once the manifest was added,
the requestedExecutionLevel variable was set to requireAdministrator. By setting this as
the access variable, the user will be prompted to grant administrator access upon running the
application each time.
Once opened, the user is presented with a set of instructions and three interactive buttons.
Upon pressing the first button to enter the relevant Windows username, the first
Micrososft.VisualBasic.Interaction.InputBox line of code is triggered, which opens an input
box window into which the user can enter the name of the Windows user. Once the user has
entered this variable and clicked OK, the inputted value is assigned to the winUser global
variable, as winUser is set to store any information input in the aforementioned input box.
Utilising the same method as above, once the user clicks the second button to enter the
relevant Skype username, the second Micrososft.VisualBasic.Interaction.InputBox line of
code is triggered. This time, the data entered into this input box is assigned to the
skypeUser global variable.
Upon clicking the final button on the page, the duplication of the Skype files is initiated. The
first action undertaken by the program at this point is to combine a number of variables to
create the file path from which, and to which, the files must be copied. Using the
Path.Combine command, the sourceDirectory1 variable (which contains the text
C:\Users\), is combined with the winUser variable, the sourceDirectory2 variable
(which contains the text AppData\Roaming\Skype\), and finally the skypeUser variable.
These combined variables make the full file path within which the Skype data is stored. An
example of this line of code would be C:\Users\Daniel\AppData\Roaming\Skype\dcastle91.
A similar action is carried out following this, with slightly different variables, so as to create
the file path to the destination to which the files will be copied. An example output of this
line of code would be C:\Users\Daniel\Desktop\Skype Artefacts.
Once the source and target directory file paths have been created, these paths are combined
with the hard coded file names of main.db and config.xml, along with the directory

Page | 35

chatsync, so as to identify which files are to be copied, and the locations into which they
should be duplicated.
Once all the file paths have been compiled, the application checks to see if the destination
directory Skype Artefacts exists in the target location. If it does not, an if statement is
used to instruct the application to create a folder in the destination directory with the name
Skype Artefacts.
Once this directory has been created, the File.Copy commands are executed, instructing the
program to copy the identified files from the specified directories into the specified target
directory.
Once the two files have been copied, the DirectoryCopy section of code is executed. This
section of code uses another if statement to check for the presence of a folder in the target
location entitled chatsync. Once again, if the folder does not exist, one is created. Once the
destination folder has been created, the file.Name variable is combined with the
destDirName variable, to create the full destination file path. Utilising the functionality of
the foreach command, the file.Name variable is populated with the name of each file
found within the chatsync folder. Another if statement is then used to create any
subdirectories found within the chatsync folder. Once these subdirectories are created, the
DirectoryCopy command is executed to copy the files from their original subdirectory
within the chatsync directory into the correct subdirectory in the target location.

5.2 Experiments
To test the developed application, two main experiments will be carried out. The first of
which will be a simple test to ensure that the files specified in the code (main.db, config.xml
and the chatsync directory/subdirectories) are generated as intended, and in the specified
location (C:\Users\<WINDOWS USER>\Desktop\Skype Artefacts).
The second experiment will be to check the MD5 hash value of the original files and a
number of the copied files, to ensure that no data has been changed in transit.
Each of these experiments will be carried out on the two test bed systems described later in
this report.
A final experiment will be carried out to ensure that the application is relatively simple to use.
This experiment will be to send the application to a third party who will test the application
and provided feedback on its usability.
Page | 36

5.2.1 Test Bed Systems


The two computer systems on which my application will be tested are as follows:
Test System 1:
The main Windows system that will be used for this experiment is comprised of the following
specifications:
Processer: AMD FX-8350 Eight-Core Processor

4.00 GHz

Installed Memory (RAM): 16.0 GB


Operating System: Windows 7 Professional 64-bit Service Pack 1
Storage Drives: Samsung SSD 840 EVO 120GB Primary Drive
Hitachi HDP725050GLA360 ATA Device (500GB)
WDC WD6402AAEX-00Y9A0 ATA Device (600GB)
Skype Version: 6.14.60.104
Skype Account Name: dcastle91
Any other Skype accounts used will be kept anonymous, to protect the privacy of the users.

Test System 2:
An alternative system to be used for testing purposes is comprised of the following
specifications:
Processor: Intel Core i5 M520 Four-Core Processer

2.40GHz

Installed Memory (RAM): 8.0 GB


Operating System: Windows 8.1 Pro 64-bit
Storage Drives: WDC WD5000BEVT-75ZAT0 (500GB)
Skype Version: 6.14.0.104
Skype Account Name: dcastle91
Any other Skype accounts used will be kept anonymous, to protect the privacy of the users.

Page | 37

5.2.2 Experiment 1
As stated, the first experiment will simply be to ensure that the target data is being copied to
the correct target directory. To ensure this is being done correctly, the file names will be
recorded, along with the original and new directories. The sizes of the files in question will
also be compared. This experiment will be carried out on Test System 1 first, followed
shortly by Test System 2. The results will be displayed in the form of a table in the next
chapter.
5.2.3 Experiment 2
The second experiment will be to generate the MD5 hash value of the original Skype artefacts
and compare this to the MD5 hash value generated by the files copied by the application. An
MD5 hash value is used to verify the integrity of a file. An algorithm is used to create a
128-bit message digest from data input (which may be a message of any length) that
is claimed to be as unique to that specific data as a fingerprint is to the specific
individual (Rouse, 2005).
The tool used to generate this MD5 hash value will be winMd5Sum, a free and open source
software tool that can be used to calculate the MD5 hash value of a given file.
5.2.4 Experiment 3
The final experiment will be one aimed at getting an outsiders perspective of the application.
As someone that is not aware of how the application should run, the tester in question is more
likely to find any bugs in the application than the developer.

Page | 38

Chapter 6 Experiment Results


6.1 Results of Experiment 1
6.1.1 Test System 1
File Name
main.db

Original File
Location
C:\Users\Daniel\AppData\Roam

File Size (KB)


1,568

config.xml

ing\skype\dcastle91\
C:\Users\Daniel\AppData\Roam

16

chatsync

ing\skype\dcastle91\
C:\Users\Daniel\AppData\Roam

455

5d1df04a848ef43d.

ing\skype\dcastle91\
C:\Users\Daniel\AppData\Roam

dat

ing\skype\dcastle91\chatsync\5d

\
Figure 4. First table of results from first experiment, carried out on Test System 1.

File Name
main.db

Copied File
Location
C:\Users\Daniel\Desktop\Skype

File Size (KB)


1,568

config.xml

Artefacts\
C:\Users\Daniel\Desktop\Skype

16

chatsync

Artefacts\
C:\Users\Daniel\Desktop\Skype

455

5d1df04a848ef43d.

Artefacts\
C:\Users\Daniel\Desktop\Skype

dat
Artefacts\chatsync\5d\
Figure 5. Second table of results from first experiment, carried out on Test System 1.

Page | 39

6.1.2 Test System 2


File Name
main.db

Original File
Location
C:\Users\Daniel\AppData\

File Size (KB)


560

config.xml

Roaming\skype\dcastle91\
C:\Users\Daniel\AppData\

12

bca48ea400f0c1ff.dat

Roaming\skype\dcastle91\
C:\Users\Daniel\AppData\

Roaming\skype\dcastle91\
944f4dc2a86f0f95.dat

chatsync\5d\
C:\Users\Daniel\AppData\

14

Roaming\skype\dcastle91\
chatsync\5d\
Figure 6. First table of results from first experiment, carried out on Test System 2.

File Name
main.db

Copied File
Location
C:\Users\Daniel\Desktop

File Size (KB)


560

config.xml

\Skype Artefacts\
C:\Users\Daniel\Desktop

12

bca48ea400f0c1ff.dat

\Skype Artefacts\
C:\Users\Daniel\Desktop

\Skype
944f4dc2a86f0f95.dat

Artefacts\chatsync\bc\
C:\Users\Daniel\Desktop

14

\Skype
Artefacts\chatsync\94\
Figure 7. Second table of results from first experiment, carried out on Test System 2.

As detailed in the results above, each of the files were copied to the correct destination
(C:\Users\Daniel\Desktop\Skype Artefacts\) and were the same size as the original files, on
both test systems. Although this implies that each file was copied across correctly, this is not a
guarantee. The experiment to check the MD5 hash sum will determine whether or not the
files are exactly the same. Had any major problems occurred when copying across the files, it
is likely that the user would be able to tell this simply by glancing at the newly copied files.
Some of the most obvious signs that the copying of a file has gone awry are that the file type
has changed or been deleted, the name is different to that of the original file, or the file is
Page | 40

simply not there. For example, if the copying of the main.db file had gone drastically
wrong, it is possible that the .db file extension would be missing, leaving the user with a file
without a file extension. If this were to happen, the user may be able to manually add the file
extension back on to the file, if they know what it is supposed to be. If this still does not
work, then the file is likely to be corrupt and unusable.

6.2 Results of Experiment 2


6.2.1 Test System 1
Original File
File Name
MD5 Hash Value
main.db
e16cd8128c2b25565c5090c643a430a2
config.xml
5ac06f844f369749f1579fa140aa2c44
0cfc123ccdae7bf7.dat
3ade9f31da6ce5c1e7288cc4498cccee
2a0a7bcb2110d4c2.dat 0473f45e041c16da393a1f5c180ed390
Figure 8. First table of results from second experiment, carried out on Test System 1.
Copied File
File Name
MD5 Hash Value
main.db
e16cd8128c2b25565c5090c643a430a2
config.xml
5ac06f844f369749f1579fa140aa2c44
0cfc123ccdae7bf7.dat
3ade9f31da6ce5c1e7288cc4498cccee
2a0a7bcb2110d4c2.dat 0473f45e041c16da393a1f5c180ed390
Figure 9. Second table of results from second experiment, carried out on Test System 1.

Page | 41

6.2.2 Test System 2


Original File
File Name
MD5 Hash Value
main.db
e3503a04767eb6fe62cec6f7b7d7dd76
config.xml
5cdcf8943a65b5b9c459a265739985cc
bca48ea400f0c1ff.dat
3d67be3c1b498f505c263aeae33875f0
944f4dc2a86f0f95.dat
acbac42f623073fccb853593a98668cf
Figure 10. First table of results from second experiment, carried out on Test System 2.

Copied File
File Name
MD5 Hash Value
main.db
e3503a04767eb6fe62cec6f7b7d7dd76
config.xml
5cdcf8943a65b5b9c459a265739985cc
bca48ea400f0c1ff.dat
3d67be3c1b498f505c263aeae33875f0
944f4dc2a86f0f95.dat
acbac42f623073fccb853593a98668cf
Figure 11. Second table of results from second experiment, carried out on Test System 2.

As detailed in the above results, the MD5 hash values for each file that was checked is the
same for both the original file and the copied file. This is precisely what the desired
functionality was for this application, as it shows that no data within any of the files has
changed at all. If even 1 byte of data had been changed within any of the files, the MD5 value
would have been different between the original and copied files.
As the MD5 hash values remain the same between the original and copied files, the possible
usages for this application have drastically increased. As mentioned previously, if any data
within original files is changed in an investigation, the data is no longer classed as admissible,
especially in a court of law. Now it has been proven that the copied data is the same as the
original data, this application could be used as part of official investigations involving the
examination of Skype files.

6.3 Results of Experiment 3


As a result of the third-party testing of the application, one key observation was made. This
was that the lack of a confirmation message that the duplication process had been started or
completed. Owing to this, the user had clicked the initiate button multiple times, which
presented an unhandled exception error, as the files already existed in the target directory.
As for usability and the functionality of the application, the third-party reported that
everything appeared to work as intended.

Page | 42

Chapter 7 Conclusion, Improvements and Reflection


7.1 Conclusion
7.1.1 Aims and Objectives
In this section, the original aims and objectives set out at the beginning of this project will be
split up individually, with an explanation of how each one was met.
The main aim for this project is to locate and examine the artefacts left behind on
computer systems by the popular application Skype. Once any potentially useful
artefacts have been located and examined, a software tool will be developed to
automatically gather the key artefacts from the computer system in use, to assist with
the examination of past Skype communications.
In order to identify the useful artefacts generated by Skype, a manual investigation was
carried out on both Windows and Android devices. The conclusion of this was that Skype, on
both operating systems, generates just a few files that contain potentially useful information,
but one file in particular holds a vast amount of information that can be utilised for both
lawful and unlawful means. The main.db folder contains vast amounts of personal user
data, such as full name, date of birth, telephone number, country of residence and so on. The
majority of this information is willingly input by users, to add to their Skype profile.
Although this information is willingly shared, the users only intend for it to be shared with the
people they have approved to be on their contact list. The main.db file that stores this data
locally on computer systems is neither encrypted or password protected. This means that
anybody with access to a computer with Skype installed, whether theirs or somebody elses,
may be able to access the personal user information of all the contacts of any Skype account
that has been used on that system. To access the file in question, the user either has to be able
to gain access to the Windows account of the Skype user, or they must have access to an
account with administrator privileges.
This same file can be found on mobile devices running the Android operating system.
Although this file can be located and accessed, this is dependent on the permissions allocated
to that particular device. If the phone is used as it comes from the manufacturer, these Skype
files are hidden away and inaccessible by users. On the other hand, if the device has been
customised to have root permissions, these important Skype files are easily accessible and
store the same information available on a Windows computer system.

Page | 43

The developed application carries out the tasks specified, and creates a copy of the original
Skype artefacts that contain potentially useful information. As verified in the experiments
carried out, the duplicate files are an exact match of the original, and do not cause any
modification to the data stored within the original files.
Research regarding how Skype works and the structure of the Skype application, both
on Windows 7 and on Android will be carried out, alongside research on past
investigations carried out in this field.
At the very beginning of this project, extensive research was carried out regarding the
functionality of Skype, on both operating systems, and on previous papers written on similar
topics. Combining the research carried out in all three of these areas led to an understanding
regarding how Skype functions, and where each operating system stores important application
data.
Forensic artefacts left behind by Skype will be located and examined manually, both
on a Windows system and Android devices.
A detailed manual investigation was carried out on the Skype applications for both Windows
and Android, which lead to the identification of a number of files utilised by Skype. This then
lead to a detailed examination of all the files found, a few of which were identified to contain
potentially useful information.
A software tool will then be developed that will gather the potentially useful artefacts
left behind by Skype running on a Windows computer system.
Once the artefacts had been identified, a software tool was developed with the functionality of
being able to create an exact duplicate of these artefacts, without modifying the original files
in any way.
The tool will then be tested on a number of systems, to ensure that it gathers the
relevant artefacts discovered during the manual investigation.
The software tool was finally tested on two different computer systems, one running Windows
7, and one running Windows 8.1, so as to ensure functionality on multiple systems, rather than
just the system used to develop the application.
7.1.2 Improvements and Recommendations
If this project were to be carried out again, there are a number of recommendations that could
be made, so as to improve the outcomes of the project.
Page | 44

Firstly, research into real-world situations in which an examination of Skype data has been
used could be carried out. This way, it gives a concrete reasoning as to why this project is
important and how it could help change the outcome of these types of digital examinations.
Also, the Skype application for Windows could be reverse engineered, so as to identify a
number of key items, such as where Skype saves particular data, how particular data is
encoded, where data is saved and so on.
For the application itself, a number of recommendations could be made. Firstly, the inclusion
of catch commands to prevent application errors would be highly useful. With the use of
these commands, a serious application error resulting in a software crash could be avoided. It
would also allow for a clearer explanation to the user as to why something went wrong.
Secondly, there could be the inclusion of an option to allow the user to modify the drive that
the application searches. As it is, the application is currently hard-coded to search the C:
drive for Skype files, with no option for the user to change this.
There are also a number of changes that could be made to the front end of the application, to
make it more user friendly. The first of these is to use text input boxes instead of buttons so
as to allow the user to enter the data directly, rather than clicking a button to prompt the input
box to appear. Secondly, the use of pop-up boxes to inform the user when the duplication
procedure has completed would also be of some benefit, otherwise the user is unaware that
the procedure has started or completed. Thirdly, the option to allow the user to specify the
target directory for the files would be beneficial.
The final, and arguably the most useful, recommendation, would be to configure the
application for use across multiple operating systems. Adding compatibility with operating
systems such as Android, iOS and Mac OS X would be extremely beneficial to people tasked
with investigating Skype clients.

7.2 Reflection
Throughout this project, there were both positive factors that helped with the development of
skills, but also negative factors that caused difficulties.
A few of the difficulties that were encountered were related to the research that needed to be
conducted in order to make this project possible. Due to the fact that this type of investigation
is not one that has been carried out to any major degree in the past, it was relatively difficult
to find any recently conducted, publicly available research that addressed the questions raised,
and ultimately answered, throughout this paper.
Page | 45

Another difficulty came in the form of finding published materials that clarified the different
methods of encoding utilised by the Skype application, whether it be during the transmission
of data, or the storage of data on the local system. Owing to this, a large amount of encoded
data was overlooked in the investigation, as there was no feasible method of decoding it.
A number of the difficulties within this project were encountered during the coding of the
software tool. The first of these difficulties, was the lack of knowledge of the C#
programming language. Although the basics of C# were known, an extensive amount of
research and self-teaching needed to be carried out, so as to enable the creation of the required
application.
A selection of the other coding-related difficulties encountered within this project were
mainly centred around finding the correct line of code to carry out the desired task.
Specifically, the copying of the chatsync directory. Although the File.Copy command
worked sufficiently for the individual files that needed to be copied, it was not able to copy
the entire directory needed. Due to this, additional research had to be carried out to find the
DirectoryCopy code.
Although the above stated difficulties were considered to be negative points at the time, they
ultimately resulted in the biggest development of the skills used throughout this project.
Owing to the difficulty with the coding, the knowledge of the C# programming language has
been developed drastically, specifically in the areas of reading, writing and analysis of code.
This project has also helped with the development of time management skills, as it has
become clear how vital effective management of time is, especially when it comes to
managing a project with as much potential for development as this one.

Page | 46

References/Citations
Anderson, B. (2013). Android News for Costa Rica, Understanding the Android File
Hierarchy. [Online]. Available at: http://www.all-things-android.com/content/understandingandroid-file-hierarchy (Accessed: 6 February 2014).
Android. (Unknown A). Android Developers, Android Debug Bridge. [Online]. Available at:
http://developer.android.com/tools/help/adb.html (Accessed: 15 January 2014).
Android. (Unknown B). Android Developers, <manifest>. [Online]. Available at:
http://developer.android.com/guide/topics/manifest/manifest-element.html (Accessed: 3
March 2014).
Anon. (2010). Skype IT Administrators Guide, Skype for Windows version 4.2. [Online].
Available at: http://download.skype.com/share/business/guides/skype-it-administratorsguide.pdf (Accessed: 15 November 2013).
Anon, (2014). NetMarketShare, Desktop Operating System Market Share. [Online]. Available
at: http://www.netmarketshare.com/operating-system-market-share.aspx?
qprid=10&qpcustomd=0 (Accessed: 1 April 2014).
Anon. (Unknown C). University of West Georgia, Understand Director Structure (Windows).
[Online]. Available at: http://www.westga.edu/its/index_5327.php (Accessed: 20 December
2013).
Anon. (Unknown D). Cprogramming, Whats the point of C#? [Online]. Available at:
http://www.cprogramming.com/tutorial/csharp.html (Accessed: 10 February 2014).
Cassavoy, L. (2011). TechHive, Skype for Android Security Flaw: What You Need To Know.
[Online]. Available at:
http://www.techhive.com/article/225382/Skype_for_Android_Security_Flaw_Wha__You_Ne
ed_to_Know.html (Accessed: 9 February 2014).
Creutzburg, R. Krger, K. Meiner, T. (2013). Client-side Skype Forensics An Overview.
[Online]. Available at: https://www.researchgate.net/publication/258332808_Clientside_Skype_forensics_an_overview (Accessed: 7 January 2014).
Dodge, R C. (2008). Skype Fingerprint, 1 (1) pp. 1-6 IEEE Xplore [Online]. Available at:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?

Page | 47

reload=true&tp=&arnumber=4439184&queryText%3Dskype+forensic (Accessed: 3
November 2013).
GODJonez (Alias). (2009). GODJonezs Workshop, Chat Logging. [Online]. Available at:
http://www.xfire.com/blog/theblog/707444 (Accessed: 30 November 2013).
Hoffman, C. (2012). How-To Geek, How to Root Your Android Device & Why You Might
Want To. [Online]. Available at: http://www.howtogeek.com/115297/how-to-root-yourandroid-why-you-might-want-to/ (Accessed 6 February 2014).
Izzy (Alias). (2013). StackExchange, Android Enthusiasts Where Android apps store data?
[Online]. Available at: http://android.stackexchange.com/questions/47924/where-androidapps-store-data (Accessed: 3 March 2014).
McCaskill, S. (2014). TechWeekEurope, Android Remains UKs Most Popular Mobile OS.
[Online]. Available at: http://www.techweekeurope.co.uk/news/android-kantar-world-panelcomtech-137288 (Accessed: 1 April 2014).
Microsoft. (Unknown). Microsoft Developer Network, Why Use C#. [Online]. Available at:
http://msdn.microsoft.com/en-us/library/aa664274%28v=vs.71%29.aspx (Accessed: 10
February 2014).
Roos, D. Valdes, R. (2012). HowStuffWorks, How VoIP Works. [Online]. Available at:
http://computer.howstuffworks.com/ip-telephony.htm (Accessed: 15 November 2013).
Rouse, M. (2005). SearchSecurity, Definintion MD5. [Online]. Available at:
http://searchsecurity.techtarget.com/definition/MD5 (Accessed: 7 April 2014).
Steele, E. (2013). Skype Big Blog, Thanks for Making Skype a Part of Your Daily Lives 2
Billion Minutes a Day! [Online]. Available at: http://blogs.skype.com/2013/04/03/thanks-formaking-skype-a-part-of-your-daily-lives-2-billion-minutes-a-day/ (Accessed: 2 December
2013)
Swider, M. (2013). techradar, Microsoft highlights 299M Skype users, 1.5B Halo games
played. [Online]. Available at: http://www.techradar.com/news/software/operatingsystems/xbox-live-upgrade-includes-300-000-servers-600-times-more-than-its-debut-1161749
(Accessed: 2 December 2013).
Tumbleson, C. (Unknown). Android-APKTool, Project Home. [Online]. Available at:
https://code.google.com/p/android-apktool/ (Accessed: 3 March 2014).
Page | 48

Page | 49

Appendices
Appendices (as Referenced in the Text)

Appendix 1. Screenshot of the contents of the Xfire Chatlog folder.

Appendix 2. Screenshot of the contents of an Xfire chat log file.

Appendix 3. A screenshot showing the Android root directory, with the two storage drives
circled.

Page | 50

Appendix 4. Screenshot showing the difference in Android with a MicroSD card inserted and
extracted.

Appendix 5. AndroidManifest.xml Extracted with 7zip

Appendix 6. AndroidManifest.xml Decompiled with APKTool

Page | 51

Appendix 7. Android Application Data Storage

Appendix 8. Skype Android Application Data

Appendix 9. Windows and Android Skype File Comparison

Page | 52

Appendix 10. Contents of Nexus 7 Root Directory, Using ES File Explorer

Appendix 11.Empty /Data Directory as Shown in ES File Explorer

Page | 53

Appendix 12. Contents of Nexus 7 Root Directory, Displayed via ADB

Appendix 13. Permission Denied Accessing /data via ADB

Appendix 14. Contents of the C:\Users\Daniel\AppData\Roaming\Skype Directory

Page | 54

Appendix 15. Encoded chatsync data.

Appendix 16. Plaintext amongst encoded data (some information obscured for privacy)

Page | 55

Appendix 17. Application code


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.IO;

namespace File_Copy_Application_1
{
public partial class Form1 : Form
{

string winUser = ""; // Global variables declared at the head of the code, ensuring availability to all required classes. Values to be determined by user input
string skypeUser = "";

public Form1()
{
InitializeComponent();
}

private void button2_Click(object sender, EventArgs e) // Actions to be taken upon click


of Windows Username button
{
winUser = Microsoft.VisualBasic.Interaction.InputBox("Enter Windows Username Here",
"Enter Windows Username", "Insert Text Here", -1, -1); // Visual basic code used to prompt for
user input. Assigns user input to winUser variable

Page | 56

private void button3_Click(object sender, EventArgs e) // Actions to be taken upon click


of Skype Username button
{
skypeUser = Microsoft.VisualBasic.Interaction.InputBox("Enter Skype Username Here",
"Enter Skype Username", "Insert Text Here", -1, -1); // Visual basic code used to prompt for
user input. Assigns user input to skypeUser variable
}

private void button1_Click(object sender, EventArgs e) // Actions to be taken upon click


of button to initiate duplication process
{
// Names of the files to be copied
string fileName = "main.db";
string fileName1 = "config.xml";
string fileName2 = "chatsync";
// Variables assigned parts of file locations, to allow for the combination user input
string sourceDirectory1 = @"C:\Users\";
string sourceDirectory2 = @"AppData\Roaming\Skype\";
string targetDirectory1 = @"C:\Users\";
string targetDirectory2 = @"Desktop\Skype Artefacts";

// Combining of directory paths with user input to create full file paths
string sourceDirectory = Path.Combine(sourceDirectory1, winUser, sourceDirectory2,
skypeUser);
string targetDirectory = Path.Combine(targetDirectory1, winUser, targetDirectory2);

// Combining of file paths with file names, to identify files to be copied, and the location
for them to be copied to
string sourceFile = Path.Combine(sourceDirectory, fileName);
string destFile = Path.Combine(targetDirectory, fileName);

Page | 57

string sourceFile1 = Path.Combine(sourceDirectory, fileName1);


string destFile1 = Path.Combine(targetDirectory, fileName1);

string sourceFile2 = Path.Combine(sourceDirectory, fileName2);


string destFile2 = Path.Combine(targetDirectory, fileName2);

// If target directory does not exist, create it


if (!Directory.Exists(targetDirectory))
{
Directory.CreateDirectory(targetDirectory);
}

// Copy files main.db and config.xml to target destination


File.Copy(sourceFile, destFile, true);
File.Copy(sourceFile1, destFile1, true);

// Copy chatsync directory from Skype files to target destination


{
DirectoryCopy(sourceFile2, destFile2, true);
}

private static void DirectoryCopy(


string sourceDirName, string destDirName, bool copySubDirs)
{
DirectoryInfo dir = new DirectoryInfo(sourceDirName);
DirectoryInfo[] dirs = dir.GetDirectories();

// If target directory does not exist, create it


if (!Directory.Exists(destDirName))
{

Page | 58

Directory.CreateDirectory(destDirName);
}

FileInfo[] files = dir.GetFiles();

foreach (FileInfo file in files)


{
string filePath = Path.Combine (destDirName, file.Name); // Combine destDirName
and file.Name variables to create full filepath and assign to filePath variable
file.CopyTo(filePath, false); // Copy files to directory assigned to filePath variable
}

// Copy all subdirectories to target location


if (copySubDirs)
{

foreach (DirectoryInfo subdir in dirs)


{
string temppath = Path.Combine (destDirName, subdir.Name);
DirectoryCopy (subdir.FullName, temppath, copySubDirs);
}
}
}

// Classes to allow additional functionality to be added to labels etc


private void label1_Click(object sender, EventArgs e)
{

private void label2_Click(object sender, EventArgs e)


{

Page | 59

private void Form1_Load(object sender, EventArgs e)


{

private void label1_Click_1(object sender, EventArgs e)


{

private void label2_Click_1(object sender, EventArgs e)


{

}
}

Page | 60

Additional Information

Appendix 18. Ethical Approval Form

Request for ethical approval for students on taught programmes


Please complete this form and return it to your supervisor as advised in your
module handbook. Feedback on your application will be via your supervisor or coordinator.

Your Name:

Daniel Castle

Student ID:

100147680

Unimail address:

d.castle1@unimail.derby.ac.uk

Other contact
information
Programme name

F490 - Computer Forensic Investigation

and code
Module name and

6CC995 Independent Studies

code
Name of supervisor

Olga Angelopoulou

Name of co-ordinator
Title of proposed research study

Skype Forensics

Supervisor Comments
Are the ethical implications of the proposed

Yes

No

research adequately described in this


application?
Page | 61

Does the overall study have low, moderate or

Low

high risk in terms of ethical implications?

High

Does the study method describe a process of

Yes

Moderate
No

research that is ethically sound?

Signatures
The information supplied is, to the best of my knowledge and belief, accurate. I
clearly understand my obligations and the rights of the participants. I agree to act
at all times in accordance with University of Derby Policy and Code of Practice on
Research Ethics:
http://www.derby.ac.uk/research/ethics-and-governance/research-ethics-and-governance

Signature of applicant
Date of submission by applicant
Signature of supervisor
Date of signature by supervisor
For Committee Use

Reference Number (Subject area initials/year/ID number)

Date received Date approved .


Signed

Comments

Page | 62

1. What is the aim of your study? What are the objectives for your study?

The aim of my study is to forensically locate and analyse the artefacts left behind by the
application Skype, whether these be files created at installation, or whether they are
temporary files left behind as Skype is used to communicate with other users. Once
located and analysed, I will compare the artefacts left behind on two different operating
systems.

- Firstly, I will research how Skype works and the structure of the Skype application, both
on Windows 7 and on Android.

- Secondly, I will examine any forensic artefacts left behind by Skype, and will compare
the results of the artefacts on Windows 7 and Android.

- Thirdly, I will develop a software tool that will gather any artefacts left behind by Skype.

- I will then test my tool, to ensure that it gathers all the artefacts I found whilst searching
manually.

- I will then present the results of my investigations in the form of a report.

2. Explain the rationale for this study (refer to relevant research literature in your
response).

Skype is a popular application used by millions of people all over the world to
communicate via video chat, voice chat and instant messaging. A large amount of
investigation into the network traffic of Skype has been carried out. These investigations
Page | 63

range from a detailed analysis of Skype traffic (Bonfiglio et al, 2007), to investigating
methods of detecting, blocking and prioritizing Skype traffic (Chan and Leung, 2007).

Although a large number of papers have been published regarding Skypes use of and
presence on networks, there does not seem to be as much research carried out
regarding the artefacts left behind on a local system after Skype has been used. Dodge
(2008) has carried out such an investigation in which he analyses Skype artefacts left
behind on a computer system running Windows XP, in both the system registry and the
locations to which the registry points. The research I will carry out will start off similarly
(using a Windows 7 system), but I will continue to also analyse an Android device, to see
what artefacts may be left behind on this alternate operating system, and whether or not
they match up to the ones left behind on a Windows system.

Once I have examined any Skype artefacts left behind on the storage media of each
device, I plan to capture and analyse the data in the volatile memory of the system whilst
Skype is in use, similar to the research carried out by Simon and Slay (2010).

The reasoning behind carrying out this research, is to see how secure, or otherwise,
Skype user data is on the systems in use. As stated by Chan and Leung (2007),
Skypes payload is encrypted from end to end, making it difficult for Skype network
traffic to be intercepted by an unauthorised person. I will analyse the artefacts locally
stored on computer systems to see if the same can be said for this data.

References:

Bonfiglio, D., Mellia, M., Meo, M., Rossi, D. (2009) Detailed Analysis of Skype Traffic,
IEEE Transactions on Multimedia, 11(1), pp, 117-127.

Chan, Y.Y., Leung, C.M. (2007) Network Forensic On Encrypted Peer-to-Peer VoIP

Page | 64

Traffics and The Detection, Blocking, and Prioritisation of Skype Traffics, pp, 1-6.

Dodge, R.C. (2008) Skype Fingerprint, Proceedings of the 41st Hawaii International
Conference on System Sciences, pp, 1-6.

Simon, M., Slay, J. (2010) Recovery of Skype Application Activity Data From Physical
Memory, 2010 International Conference on Availability, Reliability and Security, pp, 1-6.

3. Provide an outline of study design and methods.

To begin my investigation, I will look at a Skype installation on a Windows 7 computer system. I will look
for Skype data that is visible without the use of any specialist tools or software, to see if any contact details
are easily accessible without the need of logging in to a user account.
Once I have located any possible artefacts on a Windows 7 system, I will widen my search to see if any
data is available on other systems, both on Desktop and Mobile devices (such as Android, iOS, Windows
RT etc).
After doing these initial investigations, I will use specialist Forensic Software to examine the storage
devices of each of the devices used to see if I can locate any further artefacts.
Once I have discovered the locations of all the artefacts left behind by Skype, I will design a software tool
that will gather these artefacts automatically. Once designed, I plan to develop this software for use.

4. Research Ethics
PROPOSALS INVOLVING HUMAN PARTICIPANTS MUST ADDRESS QUESTIONS 5
- 11.

Does the proposed study entail ethical considerations

Yes (please delete as

appropriate) If you are unsure please seek advice before submitting this form.

If No provide a statement below to support this position.


Page | 65

If Yes move on to Question 5.

5. Please provide a detailed description of the study sample, covering selection, sample profile,
recruitment and if appropriate, inclusion and exclusion criteria.
As my investigation includes looking for artefacts left behind by Skype, it is possible that conversation logs
and personal details of users on my personal contact list may be discovered. Although personal information may be found, this information will not be published specifically, but will merely be mentioned as an
example, rather than giving any specifics (e.g. no email addresses will be shared, but will be referred to as
an email address).

6. Are payments or rewards/incentives going to be made to the participants? No


If so, please give details below.
7. Please indicate how you intend to address each of the following ethical
considerations in your study. If you consider that they do not relate to your study
please say so.
Guidance to completing this section of the form is provided at the end of the
document.
a. Consent
As I am not going to use any specific personal details in my project, I do not believe consent will be required.
b. Deception
As no specific details will be provided, deception will not be a problem in my project.
c. Debriefing
As I am not going to use any specific personal details in my project, I do not believe debriefing will be required.
d. Withdrawal from the investigation
As I am not going to use any specific personal details in my project, there will be
no need for anyone to withdraw from the investigation
e. Confidentiality
All user details will be anonymised throughout my project.
f. Protection of participants
All user details will be anonymised throughout my project.
g. Observation research
Page | 66

No observation research will be carried out


h. Giving advice
No advice will be given to any users involved in this project.
i. Research undertaken in public places
No research will be carried out in public places
j. Data protection
All user data will be kept confidential, and will not be published in my project.
k. Animal Rights
Animals play no part in my project, so animal rights will not be a problem.
l. Environmental protection
Nothing within my project will affect the environment.
8. Are there any further ethical implications arising from your proposed research?
No
If your answer was no, please explain why.
No user information will be shared throughout this investigation, it will merely be referred
to by what it is, for example email address or username.

9. Have / do you intend to request ethical approval from any other


body/organisation? No
If Yes please give details
10. What resources will you require? (e.g. psychometric scales, IT equipment, specialised software, access to specialist facilities, such as microbiological containment laboratories).
-

Windows 7 Computer Systems

Android Device

Encase Forensic Software

11. What study materials will you use? (Please give full details here of validated
scales, bespoke questionnaires, interview schedules, focus group schedules etc
and attach all materials to the application)

Page | 67

I will not be using any of the above study materials as part of my project. The only tools
and resources I will use will be technical tools and software, as well as the technical
equipment mentioned above.

Which of the following have you appended to this application?


Focus group questions

Psychometric scales

Self-completion questionnaire

Interview questions

Other debriefing material

Covering letter for participants

Information sheet about your research

Informed consent forms for participants

study
Other (please describe)

PLEASE SUBMIT THIS APPLICATION WITH ALL APPROPRIATE DOCUMENTATION

Advice on completing the ethical considerations aspects of a


programme of research

Consent
Informed consent must be obtained for all participants before they take part in your
project. The form should clearly state what they will be doing, drawing attention to
anything they could conceivably object to subsequently. It should be in language that the
person signing it will understand. It should also state that they can withdraw from the
study at any time and the measures you are taking to ensure the confidentiality of data. If
children are recruited from schools you will require the permission, depending on the
school, of the head teacher, and of parents. Children over 14 years should also sign an
individual consent form themselves. If conducting research on children you will normally
also require Criminal Records Bureau clearance. You will need to check with the school if
they require you to obtain one of these. It is usually necessary if working alone with
children, however, some schools may request you have CRB clearance for any type of
research you want to conduct within the school. Research to be carried out in any
institution (prison, hospital, etc.) will require permission from the appropriate authority.

Covert or Deceptive Research

Page | 68

Research involving any form of deception can be particularly problematical, and you
should provide a full explanation of why a covert or deceptive approach is necessary, why
there are no acceptable alternative approaches not involving deception, and the scientific
justification for deception.

Debriefing
Debriefing is a process of reflection once the research intervention is complete, for
example at the end of an interview session. How will participants be debriefed (written or
spoken feedback)? If they will not be debriefed, give reasons. Please attach the written
debrief or transcript for the oral debrief. This can be particularly important if covert or
deceptive research methods are used.

Withdrawal from investigation


Participants should be told explicitly that they are free to leave the study at any time
without jeopardy. It is important that you clarify exactly how and when this will be
explained to participants. Participants also have the right to withdraw their data in
retrospect, after you have received it. You will need to clarify how they will do this and at
what point they will not be able to withdraw (i.e. after the data has been analysed and
disseminated).

Protection of participants
Are the participants at risk of physical, psychological or emotional harm greater than
encountered ordinary life? If yes, describe the nature of the risk and steps taken to
minimise it.

Observational research
If observational research is to be conducted without prior consent, please describe the
situations in which observations will take place and say how local cultural values and
privacy of individuals and/or institutions will be taken into account.

Giving advice

Page | 69

Students should not put themselves in a position of authority from which to provide advice
and should in all cases refer participants to suitably qualified and appropriate
professionals.

Page | 70

Research in public places


You should pay particular attention to the implications of research undertaken in public
places. The impact on the social environment will be a key issue. You must observe the
laws of obscenity and public decency. You should also have due regard to religious and
cultural sensitivities.

Confidentiality/Data Protection
You must comply with the Data Protection Act and the University's Good Scientific
Practice http://www.derby.ac.uk/research/policy-and-strategy This means:

It is very important that the Participant Information Sheet includes information on


what the research is for, who will conduct the research, how the personal
information will be used, who will have access to the information and how long
the information will be kept for. This is known as a 'fair processing statement.'

You must not do anything with the personal information you collect over and
above that for which you have consent.

You can only make audio or visual recordings of participants with their consent
(this should be stated on the Participant Information sheet)

Identifiable personal information should only be conveyed to others within the


framework of the act and with the participant's permission.

You must store data securely. Consent forms and data should be stored
separately and securely.

You should only collect data that is relevant to the study being undertaken.

Data may be kept indefinitely providing its sole use is for research purposes and
meets the following conditions:

The data is not being used to take decisions in respect of any living individual.

The data is not being used in any which is, or is likely to, cause damage and/or
distress to any living individual.

You should always protect a participant's anonymity unless they have given their
permission to be identified (if they do so, this should be stated on the Informed
Consent Form).

Page | 71

All data should be returned to participants or destroyed if consent is not given


after the fact, or if a participant withdraws.

Animal rights.
Research which might involve the study of animals at the University is not likely to involve
intrusive or invasive procedures. However, you should avoid animal suffering of any kind
and should ensure that proper animal husbandry practices are followed. You should show
respect for animals as fellow sentient beings.

Environmental protection
The negative impacts of your research on the natural environment and animal welfare, must
be minimised and must be compliant to current legislation. Your research should
appropriately weigh longer-term research benefit against short-term environmental harm
needed to achieve research goals

Page | 72

Appendix 19. Gantt Chart showing the progress of the project

Page | 73

Appendix 20. Table of Events


Task Name

Duration

Start

Finish

General research
around project area for 5 days

Wed 02/10/13 Tue 08/10/13

proposal
Proposal of project
Research on project re-

1 day

Wed 09/10/13 Wed 09/10/13

129 days Thu 10/10/13

Tue 08/04/14

4 days

Fri 11/10/13

Wed 16/10/13

Thu 24/10/13

Tue 29/10/13

57 days

Sat 02/11/13

Sun 19/01/14

Methodology draft

13 days

Wed 22/01/14 Fri 07/02/14

Final methodology

10 days

Fri 14/02/14

Thu 27/02/14

28 days

Thu 05/12/13

Sat 11/01/14

17 days

Sat 08/03/14

Mon 31/03/14

Application Design

17 days

Thu 20/02/14

Fri 14/03/14

Coding of application

6 days

Fri 14/03/14

Fri 21/03/14

Application testing

4 days

Fri 21/03/14

Wed 26/03/14

Experiments

3 days

Thu 27/03/14

Mon 31/03/14

4 days

Sat 29/03/14

Wed 02/04/14

Conclusion

2 days

Mon 07/04/14

Tue 08/04/14

Improvements

1 day

Tue 08/04/14

Tue 08/04/14

Reflection

2 days

Tue 08/04/14

Wed 09/04/14

Formatting and layout

1 day

Thu 10/04/14

Thu 10/04/14

lated areas
Draft Approval Form
Completed
Final Approval Form

Completed and Submit- 4 days


ted
Draft of literature review

Manual investigation of
Windows devices
Manual investigation of
Android devices

Results analyses and


write up

Page | 74