This script searches for and decodes bencoded files used as part of the BitTorrent peer-to-peer file sharing protocol.

These files are capable of storing two types of internal folders, dictionaries and lists, as well as numeric values and byte-strings. The latter is the type used to store text.

BitTorrent metadata ('.Torrent') files are the most common form of file that is stored in bencoded format. That said, bencoded files are also used to store configuration data for BitTorrent client applications such as uTorrent and Azureus/Vuze.

Note that a bencoded file is purely a carrier of data. Notwithstanding the fact that '.Torrent' files have a fairly well-defined structure, bencoded application-configuration-files differ from client to client. This means that it's not always possible to identify the significance of a bencoded value, nor is it always possible to identify the format in which such a value is stored. For instance, Azureus is a Java application so it stores some date/time data in Java format rather than Unix format. Azureus has also been seen to use bencoded byte-strings to store Base-64 encoded data.

The script works at two levels. It first checks to see if a file has a bencode signature. If it does, then it will attempt to decode the file. Regardless of the result, the script will then proceed to search slack space for bencoded data. If a file does not have a bencode signature, then only its slack space is processed. Unallocated space objects are searched in a similar way albeit there is no preliminary file-signature-check for obvious reasons.

When searching slack or unallocated areas the script uses a case-sensitive, ANSI GREP term of 'd#+:'. Many occurences of this term are likely to be found in a bencoded file so it only processes those hits that occur at the start of a sector, i.e. those that are likely to indicate the root bencode directory at the start of the file.

The script will only bookmark data where it believes it's been able to parse that data from beginning to end without error. This methodology may result in a number of bencode file fragments from being excluded but it does mean that the data that is recovered is more likely to be complete and easier to examine.

The user has the option to specify the bookmark folder name, the entries to process and also the bencoded value/field names that should be interpreted as UNIX dates/times (where possible). Java dates/times are not currently supported.

Note that any byte-string that has a length that is an exact multiple of 20 bytes will be treated as a hash-list containing one or more SHA-1 hash values. The byte-string will be shown as a virtual folder and each hash value will be shown as a child-object of that folder. Not only that but a SHA-1 hash will also be calculated of the entire hash-list. This enables the examiner to more easily compare a set of hash values calculated using the BitTorrent Hash List Calculator EnScript.

This version of the script interprets 'peers' and 'peers6' byte-string values as a list of peer IP-address and port-numbers usually stored by the µTorrent BitTorrent application in resume.dat configuration files. Any such value will be shown as a virtual folder containing a child-object representing each peer.

BitTorrent clients use a SHA1 hash of the 'info' dictionary as the torrent hash to uniquely identify each torrent download with peers and trackers. This script calculates this hash and bookmarks it.

With the torrent hash, a 'magnet' link can be generated for a BitTorrent client to discover peers and start downloading the torrent data. This script makes another bookmark with the magnet URL.

This script was developed for use in EnCase training. For more details, please click the following link:

• OpenText EnCase Training