ArticlePDF Available

Abstract and Figures

With professional and home Internet users becoming increasingly concerned with data protection and privacy, the privacy afforded by popular cloud file synchronisation services, such as Dropbox, OneDrive and Google Drive, is coming under scrutiny in the press. A number of these services have recently been reported as sharing information with governmental security agencies without warrants. BitTorrent Sync is seen as an alternative by many and has gathered over two million users by December 2013 (doubling since the previous month). The service is completely decentralised, offers much of the same synchronisation functionality of cloud powered services and utilises encryption for data transmission (and optionally for remote storage). The importance of understanding BitTorrent Sync and its resulting digital investigative implications for law enforcement and forensic investigators will be paramount to future investigations. This paper outlines the client application, its detected network traffic and identifies artefacts that may be of value as evidence for future digital investigations.
Content may be subject to copyright.
BitTorrent Sync: First Impressions and Digital Forensic
Jason Farina
, Mark Scanlon, M-Tahar Kechadi
UCD School of Computer Science and Informatics, University College Dublin, Dublin 4, Ireland
Digital forensics
With professional and home Internet users becoming increasingly concerned with data
protection and privacy, the privacy afforded by popular cloud le synchronisation services,
such as Dropbox, OneDrive and Google Drive, is coming under scrutiny in the press. A
number of these services have recently been reported as sharing information with
governmental security agencies without warrants. BitTorrent Sync is seen as an alternative
by many and has gathered over two million users by December 2013 (doubling since the
previous month). The service is completely decentralised, offers much of the same syn-
chronisation functionality of cloud powered services and utilises encryption for data
transmission (and optionally for remote storage). The importance of understanding Bit-
Torrent Sync and its resulting digital investigative implications for law enforcement and
forensic investigators will be paramount to future investigations. This paper outlines the
client application, its detected network trafc and identies artefacts that may be of value
as evidence for future digital investigations.
ª2014 The Authors. Published by Elsevier Ltd on behalf of DFRWS. This is an open access
article under the CC BY-NC-ND license (
With home user bandwidth rising and the growth in
professional and non-professional computer power, the
volume of data created by each individual computer user is
constantly growing. For mobile users, access to this data
has long been an issue. With greater connectivity and
greater availability of access to the Internet the concepts of
high availability,off-site backupand resilient storage
have moved away from the domain solely inhabited by
large corporations and has started to become increasingly
popular with computer users and everyday data con-
sumers. Applications such as Evernote and Dropbox
leverage the decreasing cost of hard disk storage seen in
Storage as a Service (SaaS) providers, e.g., Amazon S3, to
provide data storage on the cloud to home users and
businesses alike. The main advantage of services such as
Dropbox, Google Drive, Microsoft OneDrive (formerly
SkyDrive) and Apple iCloud to the end user is that their
data is stored in a virtual extension of their local machine
with no direct user interaction required after installation. It
is also backed up by a full distributed data-centre archi-
tecture that would be completely outside the nancial
reach of the average consumer. Their data is available
anywhere with Internet access and is usually machine
agnostic so the same data can be accessed on multiple
devices without any need to re-format partitions or
wasting space by creating multiple copies of the same le
for each device. Some services such as Dropbox, also have
ofine client applications that allow for synchronisation of
data to a local folder for ofine access.
Each of the aforementioned services can be categorised
as cloud synchronisation services. This means that while
the data is synchronised between user machines, a copy of
the data is also stored remotely in the cloud. In recent
headline news, much of this data is freely available to
*Corresponding author.
E-mail addresses: (J. Farina), mark. (M. Scanlon), (M-T. Kechadi).
Contents lists available at ScienceDirect
Digital Investigation
journal homepage:
1742-2876/ª2014 The Authors. Published by Elsevier Ltd on behalf of DFRWS. This is an open access article under the CC BY-NC-ND license (http://
Digital Investigation 11 (2014) S77S86
governmental agencies without the need of a warrant or
even just cause. As a result, BitTorrent Sync (also referred to
as BTSync, BitSync or BSync), which provides much of the
same functionality without the cloud storage aspect is seen
by many as a real alternative. The service has numerous
desirable attributes for any Internet user (BitTorrent Inc,
Compatibility and Availability Clients are built for
most common desktop and mobile operating systems,
e.g., Windows, Mac OS, Linux, BSD, Android and iOS.
Synchronisation Options Users can choose whether to
sync their content over a local network or over the
Internet to remote machines.
No Limitations or Cost Most cloud synchronisation
services provide a free tier offering a small amount of
storage and subsequently charge when the user out-
grows the available space. BTSync eliminates these
limitations and costs. The only limitation to the volume
of storage and speed of the service is down to the lim-
itations of the synchronised users machines.
Automated Backup Like most competing products,
once the initial install and conguration is complete, the
data contained within specied folders is automatically
synchronised between machines.
Decentralised Technology All data transmission and
synchronisation takes place solely in a Peer-to-Peer
(P2P) fashion, based on the BitTorrent le sharing
Encrypted Data Transmission While synchronising
data between computers on different LANs (the option
exists to apply encryption for internal LAN trans-
mission), the data is encrypted using RSA encryption.
Under the BTSync API (BitTorrent Inc, 2013b), de-
velopers can also enable remote le storage encryption.
This could result in users storing their data on untrusted
remote locations for the purposes of redundancy and
secure remote backup.
Proprietary Technology The precise protocol and
operation of the technology is not openly documented
by the developer resulting in an element of perceived
security through obscurity. Of course, this requires a
signicant degree trust on behalf of users that the de-
veloperssecurity has been implemented and tested
As a result of the above, the BTSync application has
become a very popular choice for le replication and syn-
chronisation. The technology had grown to over one
million users by November 2013 and doubled to over two
million users by December 2013 (BitTorrent Inc, 2013c). The
service will be of interest to both law enforcement and
digital forensics investigators in future investigations. Like
any other le distribution technology, this interest may be
centred around recovering evidence of the data itself, of the
modication of the data or of where the data is synchron-
ised to. While the legitimate usage of the system, e.g.,
backup and synchronisation, teamwork, data transfer be-
tween systems, etc., may be of interest to an investigation,
the technology may also be a desirable one for a number of
potential crimes including industrial espionage, copyright
infringement, sharing of child exploitation material, mali-
cious software distribution, etc.
Contribution of this work
The contribution of this work includes a forensic anal-
ysis of the BTSync client application, its behaviour, artefacts
created during installation and use, and remnants left
behind after uninstallation. An analysis of the sequence of
network trafc and le I/O interactions used as part of the
synchronisation process are also provided. This informa-
tion should prove useful to digital forensic investigators
when BTSync is found to be installed on a machine under
investigation. Gaining an understanding of how BTSync
operates could aid in directing the focus of a digital inves-
tigation to additional remote machines where any perti-
nent data is replicated. Depending on the crime under
investigation, these remote machines may be owned and
operated by a single suspect or by a group sharing a com-
mon goal. While an initial analysis of the network protocol
and its operation is included below, comprehensive
network analysis is beyond the scope of this paper.
In order to understand how BTSync operates, its
important to rst understand the technologies its based
upon and how a number of similar technologies operate.
This section provides some of the required background
BitTorrent le sharing protocol
The BitTorrent protocol was designed with the aim of
facilitating one-to-many and many-to-many le transfers
as efciently as possible. The protocol is described in Bit-
Torrent Enhancement Proposal (BEP) No. 3 (Cohen,
February 2014). The main strength of the protocol is the
usage of le parts, each of which can be manipulated and
managed separately. While one part of a le downloads,
another, already downloaded part can be uploaded to a
different peer. In this way, peers can start trading parts
even before they have downloaded the entire le them-
selves. This has the benet of not only speeding up distri-
bution as each peer can nd useful information on a broad
range of potential peers but it also helps alleviate the issues
of churn(Stutzbach and Rejaie, 2006)Data Leeching
and free riding(Karakaya et al., 2009) experienced with
older protocols such as Gnutella and eDonkey. Data leech-
ing is where a user downloads an entire le in one go and
then removes the share to avoid uploading. Data churn is
the natural expansion and retraction of the network hori-
zon as peers leave and join the swarmfreely resulting in a
large variance in the availability of full versions of a le
being available from individual sources.
The overall BitTorrent network can be seen as being sub-
divided into BitTorrent swarms. Each swarm consists of a
collection of peers involved in the sharing of the same le.
The central commonality of a swarm is a unique identier
created from a SHA-1 hash of the le(s) references in the
metadata. A peer can be a member of multiple swarms as
J. Farina et al. / Digital Investigation 11 (2014) S77S86S78
multiple les are uploaded and downloaded simulta-
neously. In order to initiate download of content from a
particular swarm the user must rst download a metadata
.torrent le (or corresponding magnet URI) from an
indexing website. The BitTorrent client application running
on the users machine then interprets the metadata and
uses it to locate other peers actively participating in that
swarm using one or more of the following methods
(Scanlon et al., 2010):
1. Tracker Server Tracker servers are Internet accessible
servers that maintain a list of seeders (those peers
with 100% of a le available and as such are only
uploading data) and leechers (peers that are
beginning the process or are in the middle of the
process of downloading information from the swarm)
(Cohen, 2003). While the data transfer is in progress,
the client application will periodically report to the
tracker to update its status and to update its list of
active peers.
2. Distributed Hash Table (DHT) While the original Bit-
Torrent protocol was designed with central repositories
of peers stored on servers, clients were developed such
as Vuze and
Torrent that also stored a list of active
clients on the local machine. This common DHT allows
peers to identify peers through requesting information
from other BitTorrent clients without the requirement
for a central server (these clients serving information
from the DHT are likely not involved in the requested
swarm). Each peer record in the DHT is associated with
the swarms in which it is actively participating. The
Mainline DHT, as outlined in BEP No. 5 (Cohen, February
2014), that is used by BitTorrent and BTSync is based on
the Kademlia protocol and allows for completely
decentralised discovery of peers associated with sharing
a particular piece of content (identied by the SHA-1
hash of the content).
3. Peer Exchange (PEX) Originally, the BitTorrent protocol
did not allow for any direct communication between
peers beyond the transmission of data, but various ex-
tensions of the protocol have resulted in the removal of
this restriction. As DHT participation became commonly
supported in the major BitTorrent clients, peers started
to exchange the local peer caches. Peer Exchange is a BEP
outlined a method for when two peers are communi-
cating (sharing the data referenced by a torrent le), a
subset of their respective peer lists are shared back and
forth as part of the communication. Coupled with DHT,
PEX removes a potential vulnerability from the BitTor-
rent network by allowing for fully distributed boot-
strapping, tracking and peer discovery.
Any metadata or network control requests/responses
are transmitted using bencoding, as explained in BEP
No. 3 (Cohen, February 2014). Bencoded data consists of
dictionaries and lists consisting of key:value pairs. Each
key name and corresponding value is prepended by the
length (in bytes) followed by a colon. For example the
get_peers request message can be bencoded as
1:m9:get_peers (with the mrepresenting the key
name message).
BitTorrent Sync
BTSync is a le replication utility created by BitTorrent
Inc. and released as a private alpha in April 2013 (BitTorrent
Inc, 2013a). It is not a cloud backup solution, nor necessarily
intended as any form of offsite storage. Any data trans-
ferred using BTSync resides in whole les on at least one of
the synchronised devices. This makes the detection of data
much simpler for digital forensic purposes as there is no
distributed le system, redundant data block algorithms or
need to contact a cloud storage provider to get a list of all
trafc to or from a container using discovered credentials.
The investigation remains an examination of the local
suspect machine. However, because BTSync optionally uses
a DHT to transfer data there is also no central authority to
manage authentication or log data access attempts. A sus-
pect le found on a system may have been downloaded
from one or many sources and may have been uploaded to
many recipients.
While the paid cloud synchronisation services offer up to
1 TB of storage (Amazon S3 paid storage plan) the free ver-
sions which are much more popular with home users cap at
approximately 10 GB. The BTSync storage is limited only by
the size of the folder being set as a share (most likely limited
by the available disk space). Unless the system under
investigation is the creator of the shared folder, it is possible
that any les contained therein may have been downloaded
without the users prior knowledge of the folders contents.
The BTSync application does not feature a built in content
preview utitily. As a result, it blindly and completely syn-
chronises all content within the shared folder without any
le selection process available to the user.
Related work
At the time of publication, there are no academic pub-
lications focussing on BTSync. However, due to BTSync
sharing a number of attributes and functionalities with
cloud synchronisation services, e.g., Dropbox, Google Drive,
etc., and it is largely based on the BitTorrent protocol, there
are a number of relevant related topics of interest. This
section outlines a number of related case studies and
investigative techniques for these shared technologies.
While the specic attributes of a number of popular cloud
synchronisation services are outlined below, there is a
common generalised architecture employed by these ser-
vices. There are two main stages to this synchronisation
process, as shown in Fig. 1:
Stage 1 The local client with the source le (the seeder
in P2P terms) and the remote replication target (leecher)
both contact the server of authority belonging to the
service being used to conrm their credentials.
Stage 2 Both seeder and leecher contact the remote
storage location, usually cloud based for high availabil-
ity. The seeder uploads a full copy of each le to be
replicated and the leecher downloads a full version of
the les it nds in the cloud storage container.
At no point in the process do the clients have to talk
directly to one another. An important feature of these
J. Farina et al. / Digital Investigation 11 (2014) S77S86 S79
services is the fact that there is a full copy of the data being
stored on a remote third party server outside the control of
either client.
Forensic analysis of cloud synchronisation clients
Forensic investigation of these utilities can be chal-
lenging, as presented by Chung et al. in their 2012 paper
(Chung et al., 2012). Unless local synchronisation is
completely up to date, the full picture of the data may
reside across temporary les, volatile storage (such as the
systems RAM) and across multiple data-centres of the
service providers cloud storage facilities. Any digital
forensic examination of these systems must pay particular
attention to the method of access, e.g., usually the Internet
browser connecting to the service providers access page.
This temporary access serves to highlight the importance of
live forensic techniques when investigating a suspect ma-
chine. Cutting power to the suspect machine may not only
lose access to any currently opened documents, but would
also lose any currently stored passwords or other authen-
tication tokens that are stored in RAM. Chung et al. describe
three main forms of online storage in use by consumers:
1. Data Storage for Large Data Examples would include
the services provided by Amazon S3, Dropbox, Google
drive, etc.
2. Online Only Ofce Applications This includes services
whereby an entire productivity suite of tools is accessed
in a completely self contained online environment, e.g.,
Google Docs, Ofce 365 or Sage Online.
3. Personal Data Examples would include Evernote,
which allows users to save notes to a central store, and
Spotify, which allows playlists to be stored in the cloud
when users build their online music catalogue.
Cloud le synchronisation services
In various complementary papers on data remnants
(Quick et al., 2013a, 2013b, 2013c), Quick et al. offers an
additional approach to forensics when dealing with cloud
storage investigation. This involves access using the full
client application whether or not it has been tampered with
by the end user, e.g., perhaps an anti-forensics attempt was
made to hide data by uninstalling the application and de-
leting the synchronised folders. Each of the applications
examined stored their authentication credentials on the
local system while the client was actively connected to the
service, again highlighting the importance of live forensic
recovery techniques. It should be noted that while Dropbox
and Microsoft OneDrive appear to be very similar utilities,
there are distinct differences in the way they are intended
to be used. Dropbox (when used with the client applica-
tion) creates a local folder that synchronises any contents
stored in it with an online duplicate of that folder. By
default, Dropbox gives 2 GB of storage for free with an
option to buy additional storage. OneDrive on the other
hand is intended as a predominantly online storage facility
with an option to synchronise a copy of the les to a client
machine folder. However, this is not the default behaviour
and has to be specically enabled if used as part of the
Windows 8.1 operating system. For non-Windows 8 based
computers, the user is required to download and install the
OneDrive desktop application to enable le synchronisa-
tion across devices.
Many Cloud storage utilities provide a method of syn-
chronisation of les which involves some form of periodic
checking to determine if changes have been made to any
version being viewed locally or to compare ofine copies
with their online counterparts as soon as communication
can be re-established (network connectivity re-enabled or
the application or service restarted). For Dropbox, Drago
et al. (Drago et al., 2012) identied two sets of servers, the
control servers owned and operated by Dropbox themselves
and the storage management and cloud storage servers
hosted by Amazons EC2 and S3 services. This identication
is also veried by Wang et al. (Wang et al., 2012).
BTSync application & protocol analysis
Table 1 shows the hardware and virtual machines used
to perform an analysis on the BTSync application. The tool
was installed on all machines outlined using the default
installation parameters. A complete list of the les created
during the install process is outlined in Table 2.
Default installation includes the creation of a BTSync
folder (the location on Windows based machines is $Vol-
ume$\Documents and Settings\ [User]\BTSync). This
folder is automatically populated with three les:
1. .SyncID Stores a 20 byte unique share ID
2. .SyncIgnore A list of les in the folder or subfolder to
ignore when synchronising with remote machines.
Table 1
Hardware used in the analysis of the BitTorrent sync application.
Name Host 1: Guest 1:
OS Windows 7 PC (64 bit) Windows XP SP3
Ram 8 GB ram 512 mb RAM
Vmware Workstation 8 Bridged network adapter
Name Host 2: Guest 2:
OS Linux Debian laptop Widows XP SP3
Ram 4 GB ram 512 mb RAM
VirtualBox 4.2 Bridged network Adapter
Fig. 1. Operation of cloud le synchronisation services.
J. Farina et al. / Digital Investigation 11 (2014) S77S86S80
3. .SyncArchive (Folder) An archive to store les that
were deleted on a remote synchronised system.
These three les are created whenever any new BTSync
share is set up and are used to aid in the control of data
exchange between the nodes.
On Linux based machines, the installation directory is
wherever the userchooses to unpack theapplicationpackage.
All of the sameles are created included the hiddenfolders. In
additionthe user interface is a web GUI on localhost:8888
and the application can generate a conguration le by
running the command ./btsync ––dump-sample-config
from the terminal. If this plain text le is edited it can be used
to overwrite the username and password for the web GUI to
allow the investigator access without changing any other
BTSync client activity
The options for synchronisation and replication are set
for each share on the local machine. As shown in Fig. 2,
there are three main distinct settings determining the re-
sources used for peer discovery and the paths available for
trafc transmission. BTSync uses similar peer discovery
methods to the regular BitTorrent protocol. These methods
are outlined below:
1. LAN Discovery If the option ‘‘Search LAN’’ is
enabled the client application will start sending peer
discovery packets across the LAN utilising the multicast
address IP Port: 3838. These packets,
as displayed in Fig. 3, are sent at a frequency of one every
10 seconds for each share utilising this method.
The local peer discovery packet has a BSYNC header and
a message type of pingand includes the sending hostsIP
address, port and the 20 byte ShareID of the share being
advertised. Hosts on the LAN receiving the packet will drop
it if the ShareID is not of interest to them. Any host that has
an interest will respond with a UDP packet to the port
advertised. The response does not have a BSYNC header
present and the data eld only contains the PeerID of the
responding peer. This discovery is restricted to Path Ain
Fig. 2.
2. Tracker The option “Use Tracker” causes the client
to search for peers by requesting a peer list from the
tracker located at which was resolves
to three IP addresses:
These three IP addresses are each hosted on Amazons
EC2 cloud service. The client sends a get_peers request to
the tracker server (as can be seen in Fig. 4). When this
request is received, the clients IP addresses gets added to
the list of active peers available for that particular ShareID
on the tracker. The path to the tracker server taken by the
peers is displayed as Path Bof Fig. 2. The information keys
contained in the get_peers message are shown in Table 3.
The peer discovery response, as displayed in Fig. 5 consists
of a list of bencoded IP:Port:PeerID:ShareID entries
identifying the known peers with the same secret. Due to
the fact that the client only requests this list for a secret it
already possesses, the response from the server will always
contain at least one active peer, i.e., the requesting clients
3. Distributed Hash Table (DHT) The client can be set to
perform peer discovery using a DHT. Using this option,
Table 2
BitTorrent sync default application les.
File Purpose
$Volume$\Program Files\BitTorrent
Main Executable
$Volume$\Documents and
Data\Microsoft\Crypto\<user SID>
Private Key
$Volume$\Documents and
Data\Bittorrent Sync
Application folder
$Volume$\Documents and
Data\Bittorrent Sync\settings.dat
Conguration Settings
$Volume$\Documents and
Data\Bittorrent Sync\sync.log
Log of Synchronisation
$Volume$\Documents and
Data\Bittorrent Sync\sync.lng
Language File
$Volume$\Documents and Settings\All
Users\Desktop\BitTorrent Sync.lnk
Application Shortcut
$Volume$\Documents and Settings\All
Users\Start Menu\BitTorrent
Application Shortcut
$Volume$\Documents and Settings\All
Users\Quick Start\BitTorrent
Application Shortcut
Fig. 3. BTSync multicast Seekerpacket.Fig. 2. BTSync synchronisation options.
J. Farina et al. / Digital Investigation 11 (2014) S77S86 S81
any peer will register its details in the form of SHA-
1(Secret):IP:Port with other peers, even those that
do not participate in the swarm. Using this option a user
can avoid using any form of tracking server but they may
nd that peer discovery is slower or less complete.
4. Known Peers The nal, and least detectable, method of
peer discovery is the option to ‘‘Use Predefined
Hosts’’. The user can add a list of IP address:Port
combinations to the share preferences. This list of peers
will be contacted directly without any lookup with a
BSYNC packet containing a ping message type.
Data transfer
Similar to peer discovery methods, BTSync allows the
user to congure a number of options that affect how data
is transferred between peers:
1. No options set (Path Ain Fig. 2). The seeding host will
attempt to communicate directly with the replication
target (the leecher). This trafc is encrypted by default if
it travels outside the local LAN. There is an option in the
application preferences to enable or disable encryption
of LAN trafc as well if the user prefers.
2. If the communication between the hosts is blocked for
some reason, usually if the hosts are on different net-
works protected by rewalls or in segments or subnets
of the same LAN locked down by inbound Access Control
Lists, the option ‘‘Use Relay Server when
required’’ will allow the trafc to bypass these re-
strictions if possible (this is represented by Path Cin
Fig. 2). The relay server, located at
resolves to: ( (
These packets are sent via UDP to port 3000 and contain
pingmessages, as can be seen in Fig. 6. These ping mes-
sages contain a 20 byte PeerID and a 32 byte ShareID
derived from the secret key. After the initial handshake
with the relay server the relay negotiates the data trans-
mission session with the remote peer. This negotiation in-
volves exchange of the 16 byte nonce(a one off value
used for encryption purposes) and a map of the availability
of the le parts, as can be seen in Fig. 7. Once the handshake
is complete, the next packet contains the 160 bit public key
and the encrypted transfer of data begins. The re-
sponsibility for the actual data transfer is retained by the
individual clients and only metadata and ping packets are
sent unencrypted.
BTSync keys
When a share is created by a seeder, a master key is
generated. This is the all access, or read/write (RW), key
that allows the owner of the share to add, remove or
modify the contents of the share. The only scenario when
this key should be distributed to another peer is when that
peer is a trusted collaborator or when that peer is meant as
a secondary source of content as opposed to a backup or
repository. Read/write Keys can be recognised by the initial
character Aat the beginning of the 33 character secret
string. All keys are stored in plaintext in the bencoded block
describing the corresponding share in the sync.dat le.
From the master key, three other types of keys can be
1. Read Only The read-only (RO) key allows the receiving
user to read the data being synchronised but not to
modify or change the content on the source in any way.
If, for some reason, a le in the share is modied or
deleted on the local read-only host, its invalidate ag
in the <shareID>.db-wal le is switched from a value
of 0 to a value of 1. The result of this is that the le will no
longer be synchronised from the source, even if the
Table 3
Component elds for request packet.
Key Explanation
d: [The Entire Dictionary]
la: [IP:Port in Network-Byte Order]
m: [Message Type Header, e.g., get_peers]
peer: [Local Peer ID]
share: [Local Share ID]
e: [End]
Fig. 5. BTSync tracker response packet.
Fig. 6. BTSync relay request packet.
Fig. 4. BTSync tracker request packet.
J. Farina et al. / Digital Investigation 11 (2014) S77S86S82
version on the source is updated or the local copy is
deleted. RO keys are recognisable by the starting char-
acter Bprepended to the 32 character secret string. It
should be noted that this was originally the character R
but it was changed with post alpha releases.
2. 24 Hour The 24h key can be either a RO or RW key that
has a time limit of 24h before it expires and cannot be
used. The 24h time limit refers to the time during which
the remote peer must use the key to gain access to the
share. Once used successfully the peer will have
continued access until the share is deleted or the source
changes the authentication key. 24h keys start with the
character C. These key types are useful for security as
they are only vulnerable to a third party interception for
a limited period of time. The key stored in sync.dat is
not the 24h key, it is the corresponding, non-expiring
RW or RO equivalent.
3. Encrypted There is an encrypted key that can be
generated that creates an encrypted repository on the
remote peer. The les synchronised are stored in their
encrypted state remotely and cannot be read by the
operator of the remote machine unless they are given
the decryption key as well. This type of key is only
possible to produce if the developer API has been
installed and further analysis is outside the scope of this
paper. Investigators should be aware that an encryption
key is recognisable by the character Dat the start of the
33 character sequence.
In addition to the key strings, BTSync gives users the
option of creating a RW or RO QR code that they can scan
into a mobile application if preferred. Seeders must be very
careful about what keys they distribute and to whom they
are distributed. A RW key sent to the wrong person could
subvert the assurance of le integrity and negate many of
the benets of BTSync over a shared folder hosted at a
neutral location.
Sample keys taken from the same BTSync Share:
Sources of interest to forensic investigation
To determine what can be found without resorting to
specialist forensic utilities the BTSync application was
installed and three folders were synchronised. The default
settings were chosen at installation which include:
BTSync runs at startup.
BTSync service icon in the system tray (right click to
BTSync shortcut placed on the desktop of the All Users
BTSync added to the All Usersprole quick launch.
In order to gather sample network data, three separate
synchronisations were set up and monitored:
1. To $Volume$\Documents and Settings\[User]
\Desktop\sharedfolder from a separate Linux
laptop on the same LAN.
2. From $Volume$\Documents and Settings\[User]
\Desktop\sf2 on localhost to a separate Linux laptop
on the same LAN.
3. Performed using a secret key posted on Reddit (Reddit,
February 2014). The folder advertised itself as contain-
ing Gameboy ROMs with the read-only shared key of
application does not provide an indication as to what
size the remote folder is or what les it contains before
commencing the download.
As eachfolder was shared and assigned a secret key(either
generated locally or copied from another source) a le was
created in the folder: $Volume$\Documents and Set-
tings\[User]\Application Data\BitTorrent Sync\
with the ShareID of the folder created. This is the same share
ID found in the le .SyncID created in the share folder itself.
The name of the db les created when the shared folder
was added to BTSync consisted of the contents of the
.SyncID le (35F762999B1275C0F894F3D5FBAC7059-
F76783ED). This is the 20 byte share code that gets adver-
tised to when BTSync sends out its
get_peer message, as can be seen in Fig. 4.
As each synchronisation was run, the BTSync logle
located at $Volume$\Documents and Settings\[U-
ser]\Application Data\Bittorrent Sync\syn-
c.log is updated to record events. A sample of what this
log led contains is outlined in Table 4. The behaviour seen
in the sync.log le corresponds with that observed in the
captured network activity and the system activity recorded.
Tab le 5 presents the system activity logged during the
synchronisation process. This was performed in a monitored
session whereby a text le named sample3.txtwas created
shared to the prepared receiving folder on the repository
(leecher). The synchronization process is shown from the
point where apply was clicked on the repository. In the table
AppData is shorthand for wUser\Application Data\-
Bittorrent Sync and Share represents the path to the
folder that has been allocated to receive the data. In this
particular instance it is C:\Documents and Settings\
The shared folder is populated with the application
control les and the 20 byte shareID is written to the
Fig. 7. BTSync relay nonce exchange packet.
J. Farina et al. / Digital Investigation 11 (2014) S77S86 S83
.SyncID le.The database les are created in the User
application data folder. The lenames used for these data-
base les are the same as the ShareID stored in the
.SyncID le. .SyncIgnore is created in the share folder
and 822bytes are written to it. The data written are the
explanation of the les purpose and usage as well as a
short list of les usually generated by an Operating System.
Next the synchronization process starts with the crea-
tion of which will be renamed to
sync.dat and eventually sync.dat.old as subsequent
synchronisations take place. The <ShareID>.db-wal le
is created to act as a holding area for data to be written to
the SQLite database le of the same name. Next the data is
received and written to a synchronisation delta le in
preparation for merging into a fully synchronized text le.
File data waiting merger can be identied by the extension
!sync and !sync(X).
The registry keys outlined in Table 6 were found after
Next a le was deleted from the remote host and 10 min
were given to ensure the local host had synchronised
completely. While the le had been removed completely
from the original host, on the local host it was instead
moved from the main folder to a hidden subfolder
(.SyncArchive) and not moved to the recycle bin. It is
unknown at this time if there is any trigger or ag set that
would result in this hidden le being deleted completely off
the system. If not, then a remote host could theoretically
constantly add and remove les to a synchronisation folder
in order to deliberately occupy space on the local host with
hidden les and so perform a form of low-tech denial of
service attack by lling local storage.
BTSync does not come with any uninstaller of its own
and must be removed from the Control panel. After unin-
stall the system was rebooted to ensure that the service had
stopped running and any post uninstall clean-up had been
performed, le locks cleared etc. A number of associated
registry keys were still present, as outlined in Table 7.
In addition to this, all shared le folders used in syn-
chronisations were still present as well as the default
BTSync share created at install. The application folder was
also still present in the $Volume$\Documents and Set-
tings\[User]\Application Data folder but the syn-
c.log le had been emptied.
As well as registry keys BTSync creates several other
les that may be of interest to the forensic investigator.
These les are located in the directory $Volume$\Docu-
ments and Settings\[User]\Application Data\-
Bittorrent Sync\. The contents of each le is outlined
<40 character share ID number>[.db, .db-shm,
.db-wal] These les contribute to a SQLite3 data-
base. The database describes the contents of the share
directory corresponding to the share ID. It contains l-
enames, transfer piece registers and hash values for
each individual le and its constituent pieces. While the
.db le stores information on the schema of the database
Table 5
Example le I/O during the Clients synchronisation procedure.
Action File I/o Path
Create .SyncID 20B Share
Create <ShareID>.db AppData
Create <ShareID>.db-journal AppData
Write <ShareID>.db-journal 512B AppData
Write <ShareID>.db 3KB AppData
Delete <ShareID>.db-journal AppData
Create .SyncIgnore 822B Share
Create 822B AppData
Rename sync.dat to
450B AppData
Rename to
822B AppData
Create <ShareID>.db-wal AppData
Create sample3.txt.!sinc 33B Share
Rename sample3.txt.!sinc to
33B Share
Write sample3.txt.sync.sync1 33B Share
Rename sample3.txt.sync.sync1
Table 6
Created BTSync registry keys during installation.
HKCR \Applications BTSync.exe \shell \open \command
HKCU \Software \Classes \Applications \BTSync.exe \shell \open
HKCU \Software Microsoft \Windows \CurrentVersion \Run
HKCU \Software \Microsoft Windows \ShellNoRoam \MUICache
HKLM \SOFTWARE \Microsoft \ESENT \Process \BTSync \DEBUG
<––if debug log enabled
HKLM SOFTWARE \Microsoft \Windows \CurrentVersion \Uninstall
BitTorrent Sync
HKLM \SYSTEM \ControlSet001 Services \SharedAccess \Parameters
\FirewallPolicy \StandardProle \AuthorizedApplications \List
value: (C: \Program Files \BitTorrent Sync
\BTSync.exe:*:Enabled:BitTorrent Sync)
HKU S-1-5-21.-1003 \Software Classes \Applications \BTSync.exe
HKU \S-1-5-21.-1003 \Software \Classes \Applications \BTSync.exe
shell \open \command
HKU \S-1-5-21.-1003 \Software \Microsoft Windows \Current
Version \Run
HKU \S-1-5-21.-1003 \Software \Microsoft \Windows \ShellNo
Roam \MUICache
HKU \S-1-5-21.-1003_Classes \Applications \BTSync.exe \shell \
open \command
C: \Program Files \BitTorrent Sync \BTSync.exe
C: \Documents and Settings \All Users \Desktop \BTSync.lnk
Table 4
Sample contents of BitSync log le.
[2013-12-01 12:41:33] Loading congle version 1.1.82
[2013-12-01 12:41:33] Loaded folder \\?\wUser\BTSync
[2013-12-01 12:41:33] Loaded folder \\?\wUser\Desktop\sharefolder
[2013-12-01 12:41:33] Loaded folder \\?\wUser\Desktop\sf2
[2013-12-01 12:43:44] Got ping (broadcast: 1) from peer
(00DC0AC2F0F91921AE29FC5E8F2273828BBAC747) for share
[2013-12-01 12:43:44] Found peer for folder
00DC0AC2F0F91921AE29FC5E8F2273828BBAC747 direct:1
[2013-12-01 12:43:45] Sending broadcast ping for share
[2013-12-01 12:43:45] Requesting peers from server
[2013-12-01 12:43:45] Sending broadcast ping for share
J. Farina et al. / Digital Investigation 11 (2014) S77S86S84
the db-wal le contains bencoded entries for each le
within the share in the format:
hash:<20 byte hash>:mtime:
<timestamp of modification time>:npieces1:
owner20:<20 byte PeerID of the Seeder>:
path <path to file within share>
pvtime0:sig:<32 byte signature><filename>
settings.dat This is a bencoded le with a leguard
key (this key is a salted hash value ensuring that the le
has not been edited by another tool besides the BTSync
application itself). This le contains a log of settings for
the application including the settings used to generate
the Cryptographic keys and the registered URLs for peer
sync.dat This is a bencoded le with a leguard key.
This le lists what les have been synchronised across
the network. The directory paths and the shared secret
used can be recovered from this le. This le is perhaps
of most interest to the investigator due ot the large
amount of timestamped and option recording it con-
tains. Each share has an entry that is laid out in the
following style:
path:<full path to share folder>:
secret:<33 character Key>:
pub_key:<32 byte ShareID used in Relay
known_hosts:<contents of known hosts
peers:<list of peerIDs involved in sync>:
invites<list of swarm invites received>:
directTotal<IO direct to/from peer>:
relayTotal<IO total between peer and relay>
settings.dat.old This is the previous settings le.
BTSync rotates through two settings generations delet-
ing the old le when it is time to update with new data.
Recovering destroyed evidence
A number of the above artefacts prove that BTSync was
installed on a client machine. It is possible that some or all
of the incriminating les themselves may prove unrecov-
erable from the local hard disk due to anti-forensic mea-
sures. Should the secret be recovered for a given share, it is
possible that a synchronisation of the suspect secret will
enable the forensic investigator to recover this lost infor-
mation from any other nodes still active in the share.
Regular le system forensic analysis identifying synchro-
nisation artefacts left behind from a particular share com-
bined with this subsequent data synchronisation can prove
that the suspect machine was involved in the sharing of
incriminating material. Like any other digital investigation,
the evidence gathered from the synchronisation process
should be collected into a suitable digital evidence bag. Due
to the value of BTSync metadata in the recovery of les
stored remotely, a suitable P2P oriented evidence bag
should be selected, such as that proposed by Scanlon and
Kechadi (Scanlon and Kechadi, 2014). The after-the-fact
recovery of data from remote machines is beyond the
scope of this paper.
This paper gave a rst look at a new use for a popular
and widespread le synchronisation protocol. BTSync is
not intended to replace BitTorrent as a le dissemination
utility. However, it is still being used for this purpose. This
is facilitated though websites publicly providing shared
secrets, e.g., Reddit (Reddit, February 2014), as a form of
dead-drop. The developers of the application describe it as
an end-to-end encrypted method of transferring les
without the use of a third party staging area. The reason
for this is to try and ensure that the content and personal
details remain hidden from unauthorised access. Initial
analysis of the installation procedure identied les most
likely to be of use to a forensic examiner confronted with a
suspect live system or image running BTSync. However
while the presence of a SyncID hidden folder can explain
how a le was transferred to a system there is currently no
way known outside of the application itself to determine
the les origin or any further synchronisation points.
From an investigative perspective, the decentralised na-
ture of BTSync will always leave an avenue of gathering
information identifying nodes sharing particular content
(while providing many desirable redundancy and resil-
ience against attack).
For the digital investigator working on a case involving
BTSync, the description of the registry keys and les out-
lined can aid in identifying the content that may have been
present on the local machine. Seeing as though BTSync
Table 7
Registry keys Remaining after uninstallation.
HKCR \Applications BTSync.exe \shell \open \command
HKCU \Software \Classes \Applications \BTSync.exe \shell \open
HKCU \Software Microsoft \Windows \CurrentVersion \Run
(C: \Program Files \BitTorrent Sync \BTSync.exe/MINIMIZED)
HKCU \Software Microsoft \Windows \ShellNoRoam \MUICache
HKLM \SOFTWARE \Microsoft ESENT \Process \BTSync \DEBUG
(BTSync Rot 13 encoded¼OGap)
HKCU \Software \Microsoft Windows \CurrentVersion \Explorer
\UserAssist \75048700-EF1F-11D0-9888-006097DEACF9 \Count
Key¼HRZR_EHACNGU:P: \Qbphzragf naq Frggvatf \BFv \Qrfxgbc
HKU \S-1-5-21.-1003 \Software \Microsoft Windows \Current
Version \Explorer \UserAssist \75048700-EF1F-11D0-9888-
006097DEACF9 \Count Key¼HRZR_EHACNGU:P: \Qbphzragf naq
Frggvatf \BFv \Qrfxgbc \OGFlap.rkr
J. Farina et al. / Digital Investigation 11 (2014) S77S86 S85
merely requires any user wishing to join a particular
synchronised folder to have the key, an investigator could
also join the shared folder to download the data having
recovered the corresponding les through hard drive
analysis. Subsequent monitoring of the network commu-
nications using common tools, e.g., WireShark, tcpdump or
libpcap, can aid in the identication of other nodes syncing
the same content. In a number of investigative scenarios,
this may focus the investigation in a benecial direction
resulting in the discovery of additional pertinent evidence
or additional suspects.
Future work
From this initial analysis of the BTSync system, much
further work needs to be done. The following list amounts
to the list of areas for future investigation:
Network Analysis Identication of BTSync trafc and
subsequent analysis to determine differentiation from
standard BitTorrent trafc.
Investigation Utility A standalone application to
extract relevant information from a suspect live or
imaged machine running BTSync.
Automated Share Detection Identifying BTSync shares
advertised by BTSync clients and detecting network
activity to or from known locations.
Crawling To systematically follow connections to or
from a share and identify new connections as they are
Enumeration Identifying individual shares and all
active swarm members by the participating IP addresses
and peer identiers.
Geolocation Geolocating identied IP addresses may
prove pertinent to recovering additional evidence
regarding the suspect or may aid in the identication of
others involved.
API Analysis Testing the provisioned API to determine
what features can be leveraged to assist in forensic
Recovery of Deleted Shares In the scenario where a
suspect has securely deleted any incriminating evidence
from the local machine, the identication of trace in-
formation on the machine may result in the evidence
being recoverable from other remote hosts. Due to Bit-
Torrents reliance on regular hashing for le distribu-
tion, the resultant hashes of remotely gathered les may
be resolvable to the suspects machine.
BitTorrent Inc. BitTorrent Sync User Manual [Online; accessed February
2014],; 2013a.
BitTorrent Inc. BitTorrent Sync Developer API [Online; accessed February
2014],; 2013b.
BitTorrent Inc. BitTorrent Sync Article [Online; accessed February 2014],
million-user-mark/; 2013c.
Chung H, Park J, Lee S, Kang C. Digital forensic investigation of cloud
storage services. Digit Investig 2012;9(2):8195.
Cohen B. Incentives build robustness in bittorrent. In Proceedings of the
Workshop on Economics of Peer-to-Peer systems, Vol. 6; 2003.
pp. 6872.
Cohen B. The BitTorrent Protocol Specication and Enhancement Pro-
posals [Online; accessed February 2014],
Drago I, Mellia M, Munafo MM, Sperotto A, Sadre R, Pras A. Inside
dropbox: understanding personal cloud storage services. In: Pro-
ceedings of the 2012 ACM Conference on Internet Measurement
Conference. IMC 12. New York, NY, USA: ACM; 2012, ISBN 978-1-
4503-1705-4. pp. 48194.
Karakaya M, Korpeoglu I, Ulusoy O. Free riding in peer-to-peer networks.
Internet Comput IEEE 2009;13(2):928.
Quick D, Choo KKR. Forensic collection of cloud storage data: does the act
of collection result in changes to the data or its metadata? Digital
Investigation 2013a;10(3):26677.
Quick D, Choo KKR. Google drive: forensic analysis of data remnants.
Journal of Network and Computer Applications 2013b;40:17993.
Quick D, Choo KKR. Digital Droplets: microsoft SkyDrive forensic data
remnants. Future Generation Computer Systems 2013c;29(6):1378
Reddit. BTSecrets [Online; accessed February 2014], http://www.reddit.
Scanlon M, Kechadi MT. Digital evidence bag selection for P2P network
investigation. In: Future information technology. Springer; 2014.
pp. 30714.
Scanlon M, Hannaway A, Kechadi MT. A week in the life of the Most
Popular BitTorrent Swarms. In: 5th Annual Symposium on Informa-
tion Assurance (ASIA10); 2010.
Stutzbach D, Rejaie R. Understanding churn in peer-to-peer networks. In:
Proceedings of the 6th ACM SIGCOMM Conference on Internet
Measurement. IMC 06. New York, NY, USA: ACM; 2006, ISBN 1-
59593-561-4. pp. 189202.
Wang H, Shea R, Wang F, Liu J. On the impact of virtualization on
dropbox-like cloud le storage/synchronization services. In: Pro-
ceedings of the 2012 IEEE 20th international workshop on quality of
service, vol. 11. IEEE Press; 2012. pp. 19.
J. Farina et al. / Digital Investigation 11 (2014) S77S86S86
... • Decentralized strategy: The privacy offered by popular Cloud file synchronization and replication services is becoming the concern of the press. In fact, some services have recently been reported as sharing information with governmental security agencies without warrants [69]. To overcome these deficiencies, synchronization solutions are migrating to completely decentralized services using P2P protocols. ...
... As a result, the full data are present in every device. This replication can either be completely decentralized based on the P2P network such as bittorrent sync [69], SuperNova [103], PeerSoN [55] or can rely on third parties that manage the synchronization [73] such as Google drive and Dropbox. ...
... In the Peer-to-Peer synchronization solutions, we find for example, BittorentSync [69] which uses the libutp for data transport. The uTP protocol was developed by Bittorent to replace TCP. ...
Due to technological advancements, people are constantly manipulating multiple connected and smart devices in their daily lives. Cross-device data management, therefore, remains the concern of several academic and industrial studies. The proposed frameworks are mainly based on proprietary solutions called private or closed solutions. This strategy has shown its deficiency on security issues, cost, developer support and customization. In recent years, however, the Web has faced a revolution in developing standardized solutions triggered by the significant improvements of HTML5. With this new version, innovative features and APIs are introduced to follow business and user requirements. The main purpose is to provide the web developer with a vendor-neutral language that enables the implementation of competing application with lower cost. These applications are related neither to the used devices nor to the installed software. The main motivation of this PhD thesis is to migrate towards the adoption of standardized solutions to ensure secure and reliable cross-device data management in both the client and server side. There is already a proposed standardized Cloud Digital Safe on the server side storage that follows the AFNOR specification while there is no standardized solution yet on the client-side. This thesis is focused on two main areas : 1) the proposal of a standardized Client Digital Safe where user data are stored locally and 2) the synchronization of these data between the Client and the Cloud Digital Safe and between the different user devices. We contribute in this research area in three ways. First, we propose a Client Digital Safe based on HTML5 Local Storage APIs. We start by strengthening the security of these APIs to be used by our Client Digital Safe. Second, we propose an efficient synchronization protocol called SyncDS with minimum resource consumption that ensures the synchronization of user data between the Client and the Cloud Digital Safe. Finally, we address security concerns, in particular, the access control on data sharing following the Digital Safe requirements.
... The amount of heat emitted depends on two types: the loss of ferromagnetic hysteresis and magnetic susceptibility of superparamagnetic nanoparticles [13]. This paper focused on opening the hysteresis of magnetic materials and on explaining the characteristics of the hysteresis loop using a mathematical model (The Supreme Theory of Everything) based on the transformation of trigonometric formulas [14][15][16]. ...
... The mathematical expression for open hysteresis is described by Formula (2) [14][15][16] shown in Figure 3 c. ...
... At itis a horizontal oval ellipse. Since Formula (2) has the form cosine function 1/0, two large singulars The function y (optically, the distance of light transition in the transmitting medium) is directly proportional to the amplitude (thickness of the light-transmitting medium) and is inverse proportional to the cosine of the difference of incident and refraction angles [14]. Thus, the Supreme Theory of Everything shows no space or time, but that it is by expressions such as amplitude, frequency, and phase shift. ...
Full-text available
The problem of mathematical description for the hysteresis loop of ferromagnetic materials has been studied for a long time but unsolved until the present. Some models as particularly the Preisach model of general characters of hysteresis and the Jiles – Atherton model of ferromagnetic phenomenology, used in a wide range. But these can describe only some part of hysteresis. The eddy current generates heat in nanomagnetic materials because of hysteresis loss. Nowadays, the necessity to study hysteresis increases by nanomagnetic properties, but it is described only by magnetic domains and their changes. In this paper, the opening of the ferromagnetic hysteresis loop is shown firstly based on the trigonometric model. Finally, its confirmation is indicated by the experimental results of the CuFe2O4 compound.
... Due to the rapid advancement of the IoT, it is imperative that forensic examiners are cognisant of the different types of cloud products as well as an up-to-date understanding of the potential artefacts that could potentially be recovered to inform the IoT investigations (Hale, 2013;Quick and Choo, 2013a, 2013bMartini and Choo, 2014c;Quick et al., 2014). Depending on the cloud storage solution in use, the client device can often provide potential for alternative methods for recovery of the cloud artefacts (Farina et al., 2014;Scanlon et al., 2014a;Scanlon et al., 2014b;. Hence, in this paper, we seek to identify potential terrestrial artefacts that may remain after the use of the newer BitTorrent Sync version 2.0. ...
... Research with a technical focus generally aims to address particular challenges associated with the on-device and remote collections of data artefacts from a decentralised cloud infrastructure (Zafarullah et al., 2011;Marty, 2011;Martini and Choo, 2012;Martini and Choo, 2013;Quick et al., 2014;Dykstra and Sherman, 2013;Zawoad et al., 2013;Gebhardt and Reiser, 2013;Martini and Choo 2014c). The studies of Chung et al. (2012), Quick and Choo (2013a, 2013b, Hale (2013), Thethi andKeana (2014), Oestreicher (2014), Farina et al. (2014), , Shariati, Dehghantanha, Martini, and Choo (2015), found that metadata and other data artefacts could potentially be recovered from client devices used to access cloud services, even when the data has been erased using eraser software, such as Eraser and CCleaner (Quick and Choo, 2013a, 2013b. Quick and Choo (2013c) also determined that the act of downloading data from cloud counterparts using a web or client application does not modify the hash of the data of relevance despite changes in file creation/modification times. ...
... In to the context of our study, Farina et al. (2014) examined the potential of recovering forensic artefacts from computers (running Windows XP, Windows 7, and Linux Debian) and network capture involving the use of BitTorrent Sync (version 1.1.82), and Scanlon et al. (2014aScanlon et al. ( , 2014b presented an investigative framework for the remote collection of evidence from a decentralised file synchronisation network. ...
Cloud computing has been regarded as the technology enabler for the Internet of Things (IoT). To ensure the most effective collection of IoT-based evidence, it is vital for forensic practitioners to possess a contemporary understanding of the artefacts from different cloud services. In this paper, we seek to determine the data remnants from the use of BitTorrent Sync version 2.0. Findings from our research using mobile and computer devices running Windows 8.1, Mac OS X Mavericks 10.9.5, Ubuntu 14.04.1 LTS, iOS 7.1.2, and Android KitKat 4.4.4 suggested that artefacts relating to the installation, uninstallation, log-in, log-off, and file synchronisation could be recovered, which are potential sources of IoT forensics. We also present a forensically sound investigation methodology for BitTorrent Sync.
... In addition to remote collection of evidences, scholars also studied the potential of on-device collection of cloud artefacts such as from Evernote [50], Amazon S3 [50], Dropbox [29], [50], Google Drive [27], [50], Microsoft Skydrive [28], Amazon Cloud Drive [63], BitTorrent Sync [64], SugarSync [65], Ubuntu One [26], huBic [66], Mega [67], Syncany [24] as well as different mobile cloud apps [15], [68], [69]. Quick and Choo [27]- [29] also identified that data erasing tools such as Eraser and CCleaner could not completely remove the data remnants from Dropbox, Google Drive, and Microsoft SkyDrive. ...
...  Windows 8. which are saved in .RTF, .TXT, .DOCX, .JPG (print screen), .ZIP, and .PDF formats, providing dataset for this research experiment. Similar to previous studies [25], [28], [65], [71], we conducted a predefined set of experiments namely installation and uninstallation of the CloudMe client applications as well as uploading, downloading, viewing, deleting, unsyncing, sharing, and inactivating the sync files/folders to simulate various real world scenarios of using the CloudMe desktop and mobile client applications as well as web application using the Google Chrome client for Windows version 51.0.2704.103m. Before each experiment, we made a base snapshot of each VM workstation to serve as a control case. ...
The significant increase in the volume, variety, and velocity of data complicates cloud forensic efforts, and such (big) evidential data will, at some point, become too (computationally) expensive to be fully identified, collected, and analysed in a timely manner. Thus, it is important for digital forensic practitioners to have an up-to-date knowledge of relevant data artefacts that could be forensically recovered from the cloud product under investigation. In this paper, CloudMe, a popular cloud storage service, is studied. The types and locations of the artefacts relating to the installation and uninstallation of CloudMe client application, logging in and out, and file synchronization events from the computer desktop and mobile clients are described. Findings from this research will also help inform future development of tools and techniques (e.g., data mining techniques) for cloud-enabled big data endpoint forensics investigation.
... The paper understandably focuses on content, access records, and times of activity, but there is mention of Evernote storing references to the type of smartphone OS that created a note. Farina and Kechadi (2014) discusses artefacts left by BTSync (now Resilio Sync) but there were no artefacts reported that could be used to identify other devices that have synchronised content. ...
Full-text available
While the number and variety of devices can be problematic in a digital investigation, it is also a problem for consumers. As a result, software developers have implemented synchronisation features to assist customers handle the multitude of devices that they now use. This paper describes how these synchronisation features can be exploited as part of a digital investigation to use the results from the examination of one device to infer content of other devices. This extracted information is potentially useful in determining the devices that should have the most resources expended during an investigation to obtain the most actionable evidence in the quickest and most efficient manner.
... A typical implementation like Storj's Metadisk [13], which is a decentralised cloud storage platform. It combines existing BitTorrent Sync [14], Bitcoin and cryptography technologies. ...
In a blockchain system, consensus protocol as an incentive and security mechanism, is to ensure the participants to build the block honestly and effectively. There are different consensus protocols for blockchain, like Proof of work (PoW), Proof of Stake (PoS), Proof of Space (PoSpace), Proof of Activities etc. But most of these consensus protocols are not designed for doing some useful jobs for society because of too much competition and scalability limitation. Massive electric power and computing resources, including CPU, RAM, storage and sensors have been wasted to run blockchain network based on these consensus protocols. Current frameworks and middleware for building decentralised applications (dApps) are largely limited to simple and less useful jobs. In this paper, we present Proofware which is designed for developers to build their dApps easily with existing public/crowd-based computing resources. Under Proofware, developers can develop and test their own Proof of Useful Work (PoUW) consensus protocols. Also, rather than depending on a centralised accounting system, each dApp has an embedded currency system to keep the whole incentive system decentralised, fair, transparent, stable and sustainable. Based on Proofware, we have built a crowd based video sharing application, called OurTube, as a case study. By the OurTube example, it has shown Proofware significantly improves the productivity to build crowd-based computing system with the features of cost-effectiveness, anti-censorship, elasticity and financial sustainability.
... Nous noterons que les données dans BitTorrent, identifiées par leur empreinte, sont également immuables et ne peuvent pas être modifiées. Une telle approche est mise en oeuvre dans des outils de synchronisation comme BitSync [Farina et al. 2014] ou Syncthing [Borg 2015]. ...
Full-text available
L'informatique utilitaire a évolué au fil des années pour aboutir à ce que nous appelons aujourd'hui le Cloud Computing.Pourtant, ces infrastructures ne sont pas adaptées pour répondre aux besoins de l'Internet des Objets ayant des besoins de calculs à faible latence malgré des ressources limitées. C'est pourquoi, en 2012, Cisco a proposé le paradigme de Fog Computing, consistant à répartir des serveurs sur de nombreux sites placés près des utilisateurs. Dans cette thèse, nous cherchons à créer une solution de stockage unifiée entre les différents sites de Fog.Notre première contribution consiste à évaluer si les solutions de stockage existantes peuvent être utilisées dans un tel environnement.Nous montrons que la solution de stockage InterPlanetary FileSystem (IPFS) reposant sur un protocole similaire à BitTorrent et une table de hachage distribuée (DHT) pour localiser les données est la plus prometteuse. Toutefois, le trafic réseau inter-sites généré impacte négativement les temps de lecture. Notre seconde contribution consiste à coupler IPFS au système de fichiers distribué RozoFS pour limiter ces échanges inter-sites dans le cas d'accès à des données stockées sur le site local. Enfin, notre dernier axe de recherche vise à localiser les données grâce à un protocole reposant sur un arbre des plus courts chemins, de façon à confiner le trafic réseau et à privilégier les nœuds atteignables avec une faible latence. Grâce à de nombreuses expérimentations sur la plateforme Grid'5000, nous montrons que le couplage à un système de fichiers réduit en moyenne de 34 % les temps d'accès et que notre protocole de localisation permet un gain de 20 % du temps de localisation des données.
Full-text available
The problem of mathematical description for the hysteresis loop of ferromagnetic materials has been studied for a long time but unsolved until the present. Some models as particularly the Preisach model of general characters of hysteresis and the Jiles – Atherton model of ferromagnetic phenomenology, used in a wide range. But these can describe only some part of hysteresis. The eddy current generates heat in nanomagnetic materials because of hysteresis loss. Nowadays, the necessity to study hysteresis increases by nanomagnetic properties, but it is described only by magnetic domains and their changes. In this paper, the opening of the ferromagnetic hysteresis loop is shown firstly based on the trigonometric model. Finally, its confirmation is indicated by the experimental results of the CuFe2O4 compound.
Full-text available
Digital forensics is a rapidly growing technology for examining the contents of computers and digital devices. It raises many challenges to conventional notions of privacy because it involves a considerably more detailed search of digital data than is possible with other techniques, and it can be done surreptitiously. However, there are analogies to homes and the rights of individuals to be free from unwarranted searches and seizures in their private spaces. Even though commercial software and data comprises most of digital space, there are clearly enclaves of data that deserves to be kept private. We discuss the techniques of digital forensics and investigative targets. We identify key challenges to privacy, and outline both the legal protections and the technical protections available. Unfortunately, privacy laws are ineffective in most countries, and users need to take their own measures to protect themselves.
Full-text available
The collection and handling of court admissible evidence is a fundamental component of any digital forensic investigation. While the procedures for handling digital evidence take much of their influence from the established policies for the collection of physical evidence, due to the obvious differences in dealing with non-physical evidence, a number of extra policies and procedures are required. This paper compares and contrasts some of the existing digital evidence formats or "bags" and analyses them for their compatibility with evidence gathered from a network source. A new digital extended evidence bag is proposed to specifically deal with evidence gathered from P2P networks, incorporating the network byte stream and on-the-fly metadata generation to aid in expedited identification and analysis.
Conference Paper
Full-text available
Peer-to-Peer (P2P) file-sharing is becoming increasingly popular in recent years. In 2012, it was reported that P2P traffic consumed over 5,374 petabytes per month, which accounted for approximately 20.5% of consumer internet traffic. TV is the popular content type on The Pirate Bay (the world's largest BitTorrent indexing website). In this paper, an analysis of the swarms of the most popular pirated TV shows is conducted. The purpose of this data gathering exercise is to enumerate the peer distribution at different geolocational levels, to measure the temporal trend of the swarm and to discover the amount of cross-swarm peer participation. Snapshots containing peer related information involved in the unauthorised distribution of this content were collected at a high frequency resulting in a more accurate landscape of the total involvement. The volume of data collected throughout the monitoring of the network exceeded 2 terabytes. The presented analysis and the results presented can aid in network usage prediction, bandwidth provisioning and future network design.
Full-text available
The demand for cloud computing is increasing because of the popularity of digital devices and the wide use of the Internet. Among cloud computing services, most consumers use cloud storage services that provide mass storage. This is because these services give them various additional functions as well as storage. It is easy to access cloud storage services using smartphones. With increasing utilization, it is possible for malicious users to abuse cloud storage services. Therefore, a study on digital forensic investigation of cloud storage services is necessary. This paper proposes new procedure for investigating and analyzing the artifacts of all accessible devices, such as Windows system, Mac system, iPhone, and Android smartphone.
Conference Paper
Full-text available
Personal cloud storage services are gaining popularity. With a rush of providers to enter the market and an increasing offer of cheap storage space, it is to be expected that cloud storage will soon generate a high amount of Internet traffic. Very little is known about the architecture and the performance of such systems, and the workload they have to face. This understanding is essential for designing efficient cloud storage systems and predicting their impact on the network. This paper presents a characterization of Dropbox, the leading solution in personal cloud storage in our datasets. By means of passive measurements, we analyze data from four vantage points in Europe, collected during 42 consecutive days. Our contributions are threefold: Firstly, we are the first to study Dropbox, which we show to be the most widely-used cloud storage system, already accounting for a volume equivalent to around one third of the YouTube traffic at campus networks on some days. Secondly, we characterize the workload users in different environments generate to the system, highlighting how this reflects on network traffic. Lastly, our results show possible performance bottlenecks caused by both the current system architecture and the storage protocol. This is exacerbated for users connected far from storage data-centers. All measurements used in our analyses are publicly available in anonymized form at the SimpleWeb trace repository:
Full-text available
Free riding in peer-to-peer (P2P) networks poses a serious threat to their proper operation. Here, the authors present a variety of approaches developed to overcome this problem. They introduce several unique aspects of P2P networks and discuss free riding's effects on P2P services. They categorize proposed solutions and describe each category's important features and implementation issues together with some sample solutions. They also discuss open issues, including common attacks and security considerations.
The timely acquisition and preservation of data from cloud storage can be an issue for law enforcement agencies and other digital forensic practitioners. In a jurisdiction which has legal provisions to collect data available to a computer or device, the process may involve accessing an account to collect the data. Using three popular public cloud storage providers (Dropbox, Google Drive, and Microsoft SkyDrive) as case studies, this research explores the process of collecting data from a cloud storage account using a browser and also downloading files using client software. We then compare these with the original files and undertake analysis of the resulting data. We determined that there were no changes to the contents of files during the process of upload, storage, and download to the three cloud storage services. The timestamps of the files were also examined in relation to the files downloaded via a browser and via client software. It was observed that some of the timestamp information remained the same throughout the process of uploading, storing and downloading files. Timestamp information may be a crucial aspect of an investigation, prosecution, or civil action, and therefore it is important to record the information available, and to understand the circumstances relating to a timestamp on a file.
Cloud storage is an emerging challenge to digital forensic examiners. The services are increasingly used by consumers, business, and government, and can potentially store large amounts of data. The retrieval of digital evidence from cloud storage services (particularly from offshore providers) can be a challenge in a digital forensic investigation, due to virtualisation, lack of knowledge on location of digital evidence, privacy issues, and legal or jurisdictional boundaries. Google Drive is a popular service, providing users a cost-effective, and in some cases free, ability to access, store, collaborate, and disseminate data. Using Google Drive as a case study, artefacts were identified that are likely to remain after the use of cloud storage, in the context of the experiments, on a computer hard drive and Apple iPhone3G, and the potential access point(s) for digital forensics examiners to secure evidence.
Cloud storage services such as the popular Microsoft© SkyDrive© provide both organisational and individual users a cost-effective, and in some cases free, way of accessing, storing and disseminating data. The identification of digital evidence relating to cloud storage services can, however, be a challenge in a digital forensic investigation. Using SkyDrive as a case study, we identified the types of terrestrial artefacts that are likely to remain on a client’s machine (in the context of our experiments; computer hard drive and iPhone), and where the access point(s) for digital forensics examiners are, that will allow them to undertake steps to secure evidence in a timely fashion.
A hybrid pressure cell of pyrophyllite and magnesium oxide (HPCPM) used in large volume cubic presses is presented. In the HPCPM, a cubic frame which is made of pyrophyllite with face-centered square holes works as gaskets, and a heteromorphosis magnesium oxide works as the pressure-transmitting medium. Our experimental results indicated that the pressure-generation efficiency using the HPCPM was improved by about 40% than that using the traditional pyrophyllite pressure cell without decreasing the anvil truncation size (without sacrificing the sample volume). The HPCPM could pressurize samples of 1000 mm volume up to about 8 GPa, which is significantly higher than that available using the traditional pressure cell, which reports a highest pressure of about 6 GPa.
Powered by cloud computing, Dropbox not only provides reliable file storage but also enables effective file synchronization and user collaboration. This new generation of service, beyond conventional client/server or peer-to-peer file hosting with storage only, has attracted a vast number of Internet users. It is however known that the synchronization delay of Dropbox-like systems is increasing with their expansion, often beyond the accepted level for practical collaboration. In this paper, we present an initial measurement to understand the design and performance bottleneck of the proprietary Dropbox system. Our measurement identifies the cloud servers/instances utilized by Dropbox, revealing its hybrid design with both Amazon's S3 (for storage) and Amazon's EC2 (for computation). The mix of bandwidth-intensive tasks (such as content delivery) and computation-intensive tasks (such as compare hash values for the contents) in Dropbox enables seamless collaborationand file synchronization among multiple users; yet their interference, revealed in our experiments, creates a severe bottleneck that prolongs the synchronization delay with virtual machines in the cloud, which has not seen in conventional physical machines. We thus re-model the resource provisioning problem in the Dropbox-like systems and present an interference-aware solution that smartly allocates the Dropbox tasks to different cloud instances. Evaluation results show that our solution remarkably reduces the synchronization delay for this new generation of file hosting service.