←All Posts Posted on September 25, 2015 By admin
You may have seen in recent news stories that the evidence of online piracy hunter Daniel Macek has been called into question in the Sydney Federal Court. The case concerned Dallas Buyers Club LLC taking Australian ISPs to court to get them to divulge information about users alleged to have downloaded a copyright movie.
These alleged downloads involved the use of BitTorrent. If you’re not familiar with this it allows a large file to be split up into lots of segments. These can then be downloaded from multiple sources and reassembled, speeding up transfer rates.
The criticism revolved around the interpretation of timestamp information in .pcap files. While Mr Macek’s evidence suggested these referred to the time the files were transmitted or transferred to a system by alleged infringers, he was challenged on the grounds that they actually showed when the BitTorrent files were reassembled.
So, exactly what is the issue with these timestamps?
For systems like BitTorrent to work they need to have a standard means of exchanging packets of data over the internet. These packets can be captured and saved. One of the most accepted network packet capture and exchange formats is .pcap, which is defined by libpcap for UNIX-based systems and WinPcap for Windows-based systems. There are also many wrappers for various programming languages such as Perl (Net), Python (python-libpcap), Ruby (Ruby/Pcap) and Java (Jpcap) available. These libraries have been used to create a range of both proprietary and open source tools that can be used to capture and analyse network packet captures.
For forensic purposes, .pcap files are not too much different to the standard E01 format used for forensic analyses, which stores a bit-for-bit copy of a drive. As in the case of an E01 forensic image, a .pcap file is a digital data storage container composed of captured data prefixed with a header (Global Header) and interlaced with chunks of metadata (Packet Header).
Global Header
Let’s look at these components in more detail. The Global Header contains among other metadata, the time zone indicator “thiszone”, which by default is always set to 0 to indicate GMT (UTC). Theoretically, this value can be set as UTC +10 – for example for Sydney, Australia. In this case the value of “thiszone” will be -36000. In practice, however, time stamps are always stored in GMT (UTC) format.
Packet/Frame Header
In technical network terms ‘packet’ refers to a message sent by networking protocols operating at the network layer of the OSI (Open Systems Interconnection) Reference Model. However, this term is commonly used to refer to any kind of data sent over a network.
A frame is a message that sits at a lower level of the OSI Reference Model. Again, in technical networking terms the frame belongs to data link layer. However, it is often used to refer to physical layer messages. A frame gets encapsulated (or “framed”) with extra header information by a lower-level protocol, hence its name.
The libpcap/WinPCAP library uses its own capture encapsulation header for packets (called the packet header) during the packet capture and calls it a frame. The time that gets recorded in the header timestamp is provided by the clock on the machine performing the packet capture.
Network time stamps are supplied as seconds since January 1, 1970, 00:00:00 UTC (also known as UNIX time or Epoch time), and microseconds since that, which we will omit in further calculations to simplify them.
We can examine the given frame using a hex editor. The timestamp is recorded as a Hex value 0xFB 0x15 0xF5 0x55 followed by microseconds 0x98 0x6A 0x0B 0x00.
These time_t ts_sec hex values are represented in Little-endian format (meaning that the most significant part of the data is stored last). We can then convert 0x55 0xF5 0x15 0xFF to a decimal 1442125311 number representing a number of seconds since Epoch time, and finally calculate a Human Readable Timestamp GMT/UTC: Sun, 13 Sep 2015 06:21:47. In the given example we used 010 Hex Editor with a Binary PCAP Template that does all the necessary highlighting and calculations for us.
Now, there are several important aspects that every network forensic specialist needs to be aware of. Firstly, timestamps are derived from the clock on the machine performing the packet capture. Therefore it’s important to check the accuracy and record this machine’s system time before starting the packet capture.
Secondly, time stamps are saved to the .pcap file in GMT/UTC format, which can easily be verified by examining the value of “thiszone” in the global header. For display purposes, packet capture software such as Wireshark automatically converts these timestamps into the local time of the machine used to examine the .pcap files. However UTC times can also be displayed in Wireshark by adjusting its “Column Preferences”.
Thirdly, these .pcap files can be used in network traffic reconstruction, which involves decoding raw data packets and reassembling them back to the original content, such as PDF documents or movie files. It’s important for the forensic analyst to understand the timestamps recorded in the original .pcap file and use them as reference points, to avoid any confusion or tricky questions from defence lawyers related to “transmitted”, “transferred” or “reassembled” times.
Finally, Daylight Saving Time (DST) needs to be taken into account when analysing .pcap files.
The accuracy of a timestamp depends on many factors including the performance of the system used to capture packets, its operating system, configuration, and more.
On a Microsoft Windows computer the WinPCAP library is synced with the computer clock only at the beginning of the packet capture. As a result, timestamps and the system time may differ by a few seconds or milliseconds under heavy system load, high CPU utilisation or prolonged packet captures. The Windows OS offers a range of timestamp modes with varied timestamp accuracy and precision. A user can select the timestamping mode by using the Core Kernel Library Support Routines: KeQueryPerformanceCounter and KeQuerySystemTime or by utilising the RDTSC instructions (on 32-bit systems) instead. This is achieved by modifying the following Windows registry key setting:
HKLM \ System \ CurrentControlSet \ Services \ NPF \ TimestampMode
A system restart is needed for the settings to be applied correctly after registry settings are modified.
On Linux and most POSIX systems where libpcap is used, the timestamps are supplied by the kernel. SunOS 5, AIX, and DOS based systems use the gettimeofday() function instead. Overall, regardless of the operating system type, USB connected network adapters often provide poor time stamp accuracy and special care needs to be taken when relying on evidence files generated using USB network adapters.
Although the terms GMT and UTC often get used interchangeably, there are differences between the two. GMT is an official time zone and refers to mean solar time at the Greenwich Royal Observatory in London. This system was first established in 19th century for tracking time based on the rotation of the Earth, allowing ships to set their chronometers and improving navigational accuracy.
UTC is not a time zone, it’s a time standard that utilises highly accurate atomic clocks combined with the Earth’s rotation. In UTC ‘leap seconds’ are added at irregular intervals to compensate for the Earth’s slowing rotation and deliver higher time precision.
The UTC base time is equal to zero at Greenwich and all time zones have a time offset to UTC of between -12 and +14 hours. For example, if you live in Sydney you are in a time zone ten hours earlier than UTC, so you are in time zone “+10”.
Whilst it’s generally OK to refer to GMT and UTC interchangeably in casual conversation, the use of GMT should be avoided in technical writing when dealing with highly accurate timestamps that can have a significant impact on the accuracy of a forensic analysis.