BitTorrent is a peer-to-peer application developed by Bram Cohen in 2001 that allows participants in a swarm to exchange pieces with each other during the downloading process. It uses metadata files known as torrents to implement the downloading of files over the internet from remote computers.
The torrent file consists of metadata written in BEncode which gives instructions to the BitTorrent client and facilitates the connection to remote computers and the downloading of files (of any size and type). The instruction information that the torrent files possess are essentially: the name of the file to be shared, the size of each piece and the number of pieces that make up the file, and the Uniform Resource Locater (URL) of a tracker. A ‘tracker' is a dedicated server that links all the peers (remotely connected computers) associated with a particular torrent file.
All participants in the swarm for a particular metainfo file are peers. A peer with all of the pieces is called a seed or a seeder. A peer that is still seeking pieces is known as a leecher, The connected individuals are collectively known as Swarm.
To distribute a file, the BitTorrent client breaks the file into several pieces of equal size according to a “metainfo” file. Members of the swarm announce which pieces they have and which pieces they want. Pieces are further divided into 16 kB “blocks” to facilitate distribution.
To
download a file using BitTorrent, a client joins a swarm of other peers
and obtains pieces of the file from other members of the swarm. The
swarm relieves the peer that hosted the initial copy of the content from
having to use anywhere near as much upload bandwidth as a conventional
file transfer.
After selecting a rare piece to download, a peer makes a direct TCP connection to another peer that has that piece and downloads the blocks that comprise the piece in sequential order. After receiving all of the blocks for the piece, the client assembles them and checks the resulting SHA1 hash against the hash recorded in the metainfo file to verify its integrity.
Some clients are able to connect to swarms via Distributed Hash Tables. These are databases that store IP addresses and User Datagram Protocol (UDP) port numbers. Each peer (i.e., each client connected) essentially becomes a tracker as they store the contact information of other clients downloading the same torrent file.
BitTorrent was not necessarily designed for privacy. Although some might confuse it with TOR, the protocols are vastly different, and the only common characteristic is that they are both used to traffic in digital contraband. It however does have legitimate uses too.
 |
| How BitTorrent Works |
Forensic Artifacts
<%SYSTEMROOT%>\Users\<Username>\AppData\Roaming\Utorrent - settings.dat
- resume.dat
- dht.dat (dht = distributed hash table)
- rss.dat
If the client is down, the above .dat files are backed up and .old is appended ad the new file extension. As stated earlier, the .dat and .torrent files are written in BEncode and can only be read with a tool capable of decoding BEncode files. One of such tools is the BEncode editor.
When viewed using the BEncode Editor, data will appear with an indicator showing the data type adjacent to each heading:
- (i) ⇒Integers
- (b) ⇒Byte strings
- (l) ⇒Lists
- (d) ⇒Dictionaries
- Byte strings: number of bytes or characters
- Integers: number of digits
- Lists and Dictionaries: number of items in the list or dictionary.
Breakdown of Entries of Forensic Importance
settings.dat
|
autostart(i) |
0 means Auto start = OFF (If Auto start is ON [which is the default settings], there will be no autostart(i) entry in settings.dat) |
|
bind_port(i) = **** |
Port used for the BitTorrent protocol. This can be any value in the range 1025 – 65000. |
|
ct_hist[#] |
Number of .torrent files created by the client (within brackets), includes path and names of files/folders used by the user to create the .torrent file. Regardless of the reasoning behind the investigation, the act of creating the torrent indicates an intent and knowledge on how to use the client which goes beyond the casual user; It may point to external media or other storage drive/directory locations that the user has hosted torrent files on. This may also show the content the user was intent on distributing using the BitTorrent network. |
|
born_on(i)=********* |
This indicates the time
and date the client program was installed. This time is in Lightweight
Directory Access Protocol (LDAP) representing the number of 100 nanoseconds interval
since 1 January, 1601 UTC. Since the LDAP time is an 18 digit number, the listed value will be appended with seven (7) zeroes (0). The Epoch
converter can easily do the conversion for you. |
|
devices |
Paired devices will be listed here with device name, USB VID&PID and serial number · auto_transfer=: 0=OFF/1=ON · usb_id: contains the USB device vendor ID (VID) and product ID (PID), along with USB device electronic serial number and possibly the device friendly name. |
|
dir_active_download(b) (only present if changed by user) |
Location set by user to save new downloads. |
|
dir_autoload(b) (only present if changed by user) |
Location set by user to autoload torrent files |
|
dir_completed_download(b) (only present if changed by user) |
Location set by user to store completed downloads |
|
dir_completed_torrents(b) (only present if changed by user) |
Location set by user to archive completed .torrent files |
|
dir_torrent_files(b) (only present if changed by user) |
Location set by user to store torrent files downloaded by the client. |
|
dir_last(b) |
This is the directory selected by the user to download a torrent file when the user added the associated .torrent file and selecting the “choose save dir” option. This entry is updated for each new .torrent file added in this manner. |
|
runs_since_born(i) |
Number of times the program started and closed since install. (updated on the close of the program). |
|
runtime_since_born_secs(i) |
Time in seconds the program has been running on the PC. |
|
search_list(b) |
List of torrent search sites used in the client toolbar. This can be added by the user to assist in locating torrents. This will open up the web browser of the user so any artifacts of its usage may be found in the internet history files. |
|
settings_saved_systime(i) |
Last time client settings were changed. This is based on Unix time – the number of seconds that have elapsed since 1 January 1970 (UTC) |
resume.dat
|
added_on(i)= |
Date and time torrent was added to the client – Unix time. |
|
completed_on(i)= |
Date and time torrent was completely downloaded or created (Unix time). This value is important forensically to show a time frame of how long the torrent has been active on the machine as well as when the subject started sharing it |
|
created_torrent(i)= |
Did this client created the listed torrent? 0 = Client did not create torrent (it was downloaded) 1 = Client created torrent. In criminal investigations, intent is usually the cornerstone of a
criminal conviction. There is no stronger way to show intent to
distribute files with a BitTorrent client than to prove the users has
created the torrent file. This client is the “parent” of all the shared
copies that may be floating among thousands of peers. |
|
download_url(b)= |
If the user added the torrent file using the ‘add torrent from url’ function, then the URL will be listed here. |
|
downloaded(i)= |
Bytes of the file downloaded so far. |
|
last_seen_complete(i)= |
Last time client was seeding the complete file. |
|
last_active(i)= |
Last time file was being actively seeded or shared from client PC (Unix time). |
|
path(b)= |
Path on the local machine where incoming files are saved. If the file was created on the client, then the path (b) will show where the seed file exists on the client PC. This entry would be of forensic significance if the user has directed specific incoming torrents to different locations. If the contraband files are kept on an external drive while “regular” files are kept on a normal system drive, this would show the locations of the files. |
|
peers6(b)= |
IP and Port numbers of peers sharing this file at time client exited (includes the client’s local and external IP, both IPV4 and IPV6). |
|
runtime(i) |
Time file has been downloading in the client (or seeding time following download). |
|
seedtime(i)= |
The total amount of time (in seconds) that the client has been seeding the completed file. An incomplete file will not register any time in this entry. |
|
started(i)= |
File status when client last exited 0 = stopped 1 = force started 2 = started 3 = running/not downloading |
|
uploaded(i)= |
Total uploaded (shared) bytes of data for that specific file. This entry will be important to show a history of sharing or distribution of contraband material on the network. |
To determine the IP addresses of each peer the client is communicating with to participate in the sharing of content, follow the procedure discussed below.
- In the peers6 field of the resume.dat file, set the 'Type' field to 'Binary' and as 'Binary' as shown in the figure below.
- Convert from Hexadecimal to Decimal to get the IP (Read the next subheading for a proper understanding of how to do this). The last 4 hex characters represent the port (represented in Big Endian).
Converting The Hex Values to Obtain IP Addresses
Copy and paste this hex data into your preferred text editor and create a new line with 36 characters each (Note that the starting 0x characters denote that the values are represented as hexadecimal and should not be included in the division of values into 36 characters each). Each line will display the IPv6 (all zeros if no IPv6 is present), followed by IPv6 port (FFFF if no IPv6), followed by the IPv4 (8 characters) and the IPv4 port (4 characters):
Taking the first 36 characters in the first line for example , we determine the IP address as follows:
- Byte string = 00000000000000000000 FFFF B071A731 6254 (18 hex bytes)
- The twenty 0s (10 hex bytes) and four Fs (2 hex bytes) in the IPV6 region signifies that there are no IPV6 address and port number.
- B071A731 (4 hex bytes) = IPV4 Address. The hex values, broken down to their byte equivalent (2 digits) and converted to decimal will reveal that specific octet of the peers IP address.
- B0₁₆ = 176₁₀
- 71₁₆ = 113₁₀
- A7₁₆ = 167₁₀
- 31₁₆ = 49₁₀
- 6254 (2 hex bytes) = IPV4 port number. This is represented as a big endian value, where the most significant value is stored at the end of the string. This requires the forensic examiner to swap the positions of the two bytes before converting the values to their decimal equivalent. This becomes 5462 in our case.
- 5462₁₆ = 21602₁₀
- Converted IP address and Port number is 176.113.167.49:21602
Therefore our derived IP address following the steps above is 176.113.167.49 and Port number is 21602. Performing an IP lookup of our derived IP address reveals that it is a Ukranian IP address with details below.
dht.dat
This contains data used by the client when connecting to the Distributed Hash Table (DHT) network for sharing contact information so users engaged in downloading the same file(s) can discover one another. In the DHT, each pair maintains a routing table of known good nodes (ie active in last 15 minutes). If no routing table exists, the client bootstraps into larger table (router.utorrent.com, router.bittorent.com, ...). IP addresses for swarm are stored in routing table. This file also stores the client's outwardly facing IP address.
|
age(i) |
Time last updated or when client shut down. This is based on Unix time – the number of seconds that have elapsed since 1 January 1970 (UTC). It is a good indicator of associating the client’s IP to a date/time. |
|
ip(b)[4] |
The
client’s routable IP address in hex (assigned by the client’s ISP) - 26 hex bytes or 52 hex digits. |
|
nodes(b)[###] |
Contains the IP addresses (IPv6 and IPv4) of each peer the client is communicating with in order to participate in the sharing of content via the BitTorrent protocol |
|
id(b)[20] |
Contains the unique ID of the client’s node, 20 hex character pairs. |
To determine the routable IP address of the client, follow the steps as shown in the figure below:
Convert the hexadecimal value to decimal as we did with the resume.dat record.
- C5 = 197
- D2 = 210
- 2F = 47
- 79 = 121
The routable IP address of the client therefore is 197.210.47.121 and this is my IP address. Performing an IP lookup of this address reveals the following details about me.
To determine the total number of peers the client is communicating with, divide the node value (ie number in square bracket) by 26 (hex bytes in the string). In our example, the number is 468 as shown below.
Dividing 468 by 26 gives the value 18. This means a total of 18 IP addresses is contained in the data. To display them, double click on the node value and follow the steps shown below:
Taking the first line for example;
- Byte string = 0A126EF1BC0D874F9AC368214BB2A8E14C8562EB3ED27CA4C8D5
- Node ID - 0A126EF1BC0D874F9AC368214BB2A8E14C8562EB
- IPV4 Address - 3ED27CA4
- Port Number - C8D5
Doing the necessary conversion to obtain the decimal equivalent of the IP address
- 3E = 62
- D2 = 210
- 7C = 124
- A4 = 164
The IP address is 62.210.124.164
rss.dat
This is the file where user configured RSS data subscriptions are stored. Popular torrent tracker websites like The Pirate Bay make the RSS subscription available to any users. The user can easily add the feed URL that the tracker lists to the RSS feeds feature in the torrent client. The rss.dat file contains a list of the feeds subscribed to, as well as a history of the torrents (or magnets) downloaded or queued for download.
It is “possible” to download files without the user's direct knowledge IF the client is using RSS Feeds. This, if being presented as a defence argument, can be investigated by a thorough forensic examination of the rss.dat files on the system.
Torrent Files
To distribute files using the BitTorrent protocol, a .torrent file will need to be created and seeded. To view the content of a .torrent file, a tool capable of decoding BEncode file (such as the BEncode editor) is required.
|
announce |
The
announce field points to the tracker of the content file(s) that we are
uploading as a torrent. This is a ‘UDP tracker protocol’. Note that the above
value of ‘announce’ is of the form · comment - Comment about the torrent file added by the creator of the torrent |
|
announce-list |
Contains a list of URLs of all trackers for this torrent |
|
info |
Contains length and path of file(s) as separate objects; one for each file. · length(i) - Length of the file in Bytes · path(b) - An array of strings which denotes the subdirectory names · name(b)[n] – name of the torrent(i.e. name of the file that is to be downloaded and not the name of the .torrent file itself) · piece length(i) - The number of bytes that each piece of the torrent file was split into (i.e. the length of one piece). It is arrived at by adding all of the file sizes, and dividing this number by 2,040 · pieces(b)[n] - Includes the complete SHA1 characters of all pieces strung together, n = total bytes of SHA1 concatenated hashes |
The figure below shows the generic layout of the content of a .torrent file.
 |
| Content of a .torrent file |
 |
| Chunk hashes |
 |
| Extracting uTorrent file information using DumpTorrent |
Registry Artifacts
The following Windows Registry entries are associated with the installation and use of μTorrent:
- NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Uninstall\uTorrent
- NTUSER.DAT\Software\BitTorrent\uTorrent
- NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ FileExts\.torrent\OpenWithList
- NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ RecentDocs\.torrent
- NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\ OpenSavePidlMRU\torrent
- USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache
Subpoena The Internet Service Provider (ISP)
Once enough evidence has been collected to establish probable cause, the investigators will present that evidence to the trier of facts to obtain a subpoena for records from the ISP associated with the unidentified suspect's IP address in an attempt to get the name and service address of the account holder. Because most ISPs use DHCP, the subpoena will typically request details about the DHCP lease.
If the logs from the ISP contain the MAC addressed associated with the DHCP lease, it will most likely be the MAC address of a router rather than the personal computer of the suspect. Nevertheless, this will usually be verified during the execution of the search warrant.
During testimony, it is important not to conflate the IP address of the router with the IP address of the device that is found to have contraband, even if it means describing how Network Address Translation to the jury.
Search Warrant of Suspect's Premises
Assuming the result of the subpoena on the ISP show that the service address is under the jurisdiction of the unit performing the investigation, they will obtain a search warrant specifying the physical address and targeting all electronic devices or digital media that could contain contraband as well as anything else that provides evidence of intent. The objective of the search warrant is to obtain evidence to be produced in a criminal trial.
Post a Comment