[This is the first part of a multi-part a guest diary written by Dr. Ali Dehghantanha]

One of the nightmares of any forensics investigator is to come across a new or undocumented platform or application during an investigation with tight deadlines! The investigator has only limited research time to detect evidences hoping not to miss any essential remnants! Fortunately there is a field of research called “Residual Data Forensic” in which researchers detect and document remnants (evidence) of forensic value of user activities on different platforms. Residual forensic researchers are usually listing minimum evidences that can be extracted by a forensics practitioner.

In one of my recent engagements, I had to investigate BitTorrent Sync version 2.0 on a range of different devices. Back then I used papers authored by Scanlon, M., Farina et al., (Refer to References 1,2,3,4) on the investigation of BitTorrent Sync (version 1.1.82). However, as a redesigned folder sharing workflow has been introduced in the newer version of BitTorrent Sync (from version 1.4 onwards), there is a need to develop an up-to-date understanding of the artefacts from the newer BitTorrent Sync applications.

In a series of diaries I am going to discuss about residual artefacts of BitTorrent Sync version 2.0 on Windows 8.1, Mac OS X Mavericks 10.9.5, Ubuntu 14.04.1 LTS, iOS 7.1.2, iPhone 4 running iOS 7.1.2 and a HTC One X running Android KitKat 4.4.4 (For a more involved reading which include experiment setup and full details of our investigation please refer to our paper titled “Forensic Investigation of P2P Cloud Storage: BitTorrent Sync as a Case Study” (Reference 5)). Please feel free to comment about any other evidences that you came across in your investigations and/or suggest other investigation approach.

This diary post explains artefacts of directory listings and files of forensic interest of BitTorrent Sync version 2.0 on Windows 8.1, Mac OS X Mavericks 10.9.5, and Ubuntu 14.04.1 LTS.

The downloaded folders were saved at %Users%\[User Profile]\BitTorrent Sync, /home/[User profile]/BitTorrent Sync, and /Users/[User Profile]/BitTorrent Sync on the Windows 8.1, Ubuntu OS, and Mac OS clients by default, respectively. Within the shared folders (both locally added and downloaded) there is a hidden ‘.sync’ subfolder. The file of particular interest stored within the subfolder is the ‘ID’ file which holds the folder-specific share ID in hex format. The share ID would be especially useful when seeking to identify peers sharing the same folder during network analysis.

When a synced file was deleted, copies of the deleted file can be recovered from the /.sync/Archive folder of the corresponding peer devices. It is important to note that the deleted files will only be kept in the archive folder for 30 days by default. Copies of the deleted files alongside the pertinent file deletion information (e.g., the original paths, file sizes, and deletion times) can be recovered from the %$Recycle.Bin%\SID folder on Windows 8.1, but the files are renamed to a set of random characters prefixed with $R and $I. On Ubuntu machine, copies of deleted files can be recovered from /home/[User Profile]/.local/share/Trash/files folder. Original file path and deletion time can be recovered from .TRASHINFO files located in /home/[User Profile]/.local/share/Trash/info/. In contrast to Windows and Ubuntu OS, examination of the Mac OSX trash folder (located at /Users/[User profile]/.Trash) only recovered copies of the deleted files. However, it is noteworthy that the findings are only applicable to the system that initiated the file deletion and as long as the recycle bin or trash folder is not emptied. A practitioner could potentially recover the BitTorrent Sync usage information from various metadata files resided in the application folder located at %AppData%\Roaming\BitTorrent Sync on Windows 8.1 and /Users/[User Profile/Library/Application Support/BitTorrent Sync on Mac OSX.

The application folder maintains a similar directory structure across multiple operating systems, and the /%BitTorrent Sync%/.SyncUser<Random number> subfolder is an identity-specific application folder that will be synchronised across multiple devices sharing the same identity. The first file of particular interest within the application folder is settings.dat which maintains a list of metadata associated with the device under investigation such as the installation path (which could be distinguished by the ‘exe_path’ entry), installation time in Unix epoch format (‘install_time’), non-encoded peer ID (‘peer_id’), log size (‘log_size’), registered URLs for peer search (‘search_list’, ‘tracker_last’ etc.), and other information of relevance. The second file of forensic interest within the application folder is the sync.dat which contains a wealth of information relating to the shared folders downloaded to the device under investigation. In particular, the device name could be discerned from the ‘device’ entry. The ‘identity’ entry records the identity name (‘name’) of the device under investigation as well as the private (‘private_keys’) and public keys (‘public_keys’) used to establish connections with other devices. A similar finding was observed for the peer identities in ‘identities’ entry. A replication of the ‘identity’ and ‘identities’ entries can be located in the local-identity-specific /%BitTorrent Sync%/.SyncUser<Random number>/identity.dat file and peer-identity-specific /%BitTorrent Sync%/.SyncUser<Random number>/identities/[Certificate fingerprint] file (with the exception of the private key) respectively. The ‘access-requests’ entry holds a list of metadata pertaining to the identities which sent folder access requests to the device under investigation such as the last used IP addresses in network byte order (‘addr’), identity names (‘name’), public keys ‘public_keys’) of the requesting identities, as well as base32-encoded temporary keys (‘invite’), requested folder IDs, requested times (‘req_time’), requested permissions (‘requested_permissions’ where 2 indicates read only, 3 indicates read and write, and 4 indicates owner), and granted permission (‘granted_permissions’).

Located within the ‘folders’ entry of the sync.dat file was metadata relating to the synced folders. It should be noted that this entry will never be empty as it will always contain at least an entry for the identity-specific /%BitTorrent Sync%/SyncUser<Random number> application folder. Amongst the information of forensic interest recoverable from the ‘folders’ entry included the folder IDs (‘folder_id’), storage paths (‘path’), the addition and last modified dates in Unix epoch format, the peer discovery method(s) used to share the synced folders, the access and root certificates keys, whether the folders have been moved to trash, and other information of relevance. Correlating the folder IDs recovered from ‘folders’ entry with the folder IDs located in /%BitTorrent Sync%/SyncUser<Random number>/devices/[Base32-encoded Peer ID]\folders\ may determine the shared folders associated with a peer device. Analysis of the access control list (‘acl’) subentry (of the ‘folders’ entry) can be used to identify the permissions of identities associated with each shared folder, such as the identity names (‘name’), public keys (‘public_keys’), signature issuers, the times when the identities were linked to a specific shared folder, as well as other information of relevance. Similar details can be located in the folder-specific /%BitTorrent Sync%/.SyncUser<Random number>/folders/[Folder ID]/info.dat file. The ‘peers’ subentry (of the ‘folders’ entry), if available, would provide a practitioner information about the peers associated with the shared folders added by the device under investigation such as the last completed sync time (‘last_sync_completed’), last used IP address (‘last_addr’) in network byte order, device name (’name’), last seen time (‘last_seen’), last data sent time (‘last_data_sent’), and other relevant information.

Another file of interest which can potentially allow a practitioner to recover the sync metadata is the /%BitTorrent Sync%/[share-ID].db SQLite3 database. This share-ID-specific database describes the content of a shared folder (including the /%BitTorrent Sync%/SyncUser<Random number> application folder) such as the shared filenames or folders (stored in the ‘path’ table field of the ‘files’ table), hashes, and transfer piece registers for the shared files or folders. Once the shared filenames or folders have been identified, a practitioner may map the details to the /%BitTorrent Sync%/history.dat file (which maintains a list of file syncing events appeared in the History of the BitTorrent Sync client application) to obtain the sync times in Unix epoch format as well as the associated device names – as shown in Figure 1.

Figure 1: History.dat file

/%BitTorrent Sync%/sync.pid file holds the last used process identifier (PID) which can be used to correlate data with physical memory remnants (e.g., mapping a string of relevance to the data resided in the memory space of investigating PID using the ‘yarascan’ function of Volatility). It is important to note that all the metadata files aforementioned are Bencoded (with the exception of the sync.pid file) and the old metadata files would have. OLD extension. Moreover, the sync.dat, settings.dat, and history.dat files are protected with a salted file guard key to ensuring that only the BitTorrent Sync application may edit the files.

When BitTorrent Sync was accessed on a Mac OS device, additional references to the client application usage can be located in the preference files located in /Users/[User profile]/Library/Preferences/. For instance, the com.apple.spotlight.plist file holds the app path and the last used time in plain text (see Figure 2). In the com.bittorrent.Sync.plist file contains supporting information for timeline analysis such as the app version, last software update check time, and last started time in Unix epoch format.

Figure 2: com.apple.spotlight.plist

Disconnecting a shared folder, it was observed that no changes were made to the peer devices, even when the option ‘delete files from this device’ was selected to permanently delete the sync files/folders from the local device. Unlinking an identity from investigated devices, it was observed that the identity-specific /%BitTorrent Sync%/.SyncUser<Random number> application folder will be deleted from the local device. However, only the identity-specific metadata will be removed from the ‘identity’ and ‘identities’ entries of the local and peer device’s settings.dat files.

Undertaking uninstallation of the Windows client application would remove synced folders from folders containing the ‘.sync’ subfolder in the directory listing. Manual uninstallation of the Linux and Mac client applications left no trace of the client application usage/installation in the directory listing, but (obviously) deleted files/folders were recoverable from the non-emptied /Users/[User profile]/.Trash folder of the Mac OSX VM investigated.

Undertaking data carving of unallocated spaces (of the file synchronisation VMs) could recover copies of synced files as well as the log and metadata files of forensic interest (e.g., sync.log, sync.dat, history.dat, and settings.dat used by the client applications). A search for the terms ‘bittorrent’, bencode keys specific to the metadata files of relevance, as well as the pertinent log entries was able to locate copies of the recovered files. The remnants remained even after uninstallation of client applications, which suggested that unallocated space is an important source for recovering deleted BitTorrent Sync or synced files.

Our next post would describe investigation of BitTorrent log files.

References

1)Scanlon, M., Farina, J. and Kechadi, M. T. (2014a) BitTorrent Sync: Network Investigation Methodology, In IEEE, pp. 21–29, [online] Available from: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6980260 (Accessed 11 March 2015).

2)Scanlon, M., Farina, J., Khac, N. A. L. and Kechadi, T. (2014b) Leveraging Decentralization to Extend the Digital Evidence Acquisition Window: Case Study on BitTorrent Sync, arXiv:1409.8486 [cs], [online] Available from: http://arxiv.org/abs/1409.8486 (Accessed 18 March 2015).

3) Scanlon, M., Farina, J. and Kechadi, M.-T. (2015) Network investigation methodology for BitTorrent Sync: A Peer-to-Peer based file synchronisation service, Computers & Security, [online] Available from: http://www.sciencedirect.com/science/article/pii/S016740481500067X (Accessed 9 July 2015).

4) Farina, J., Scanlon, M. and Kechadi, M. T. (2014) BitTorrent Sync: First Impressions and Digital Forensic Implications, Digital Investigation, Proceedings of the First Annual DFRWS Europe, 11, Supplement 1, pp. S77–S86.

5) Teing Yee Yang, Ali Dehghantanha, Kim-Kwang Raymond Choo, "Forensic Investigation of P2P Cloud Storage: BitTorrent Sync as a Case Study", (Elsevier) International Journal of Computers & Electrical Engineering, 2016.

Find out more about Dr. Ali Dehghantanha at http://www.alid.info