Timestamps in PyFlag
Introduction
Timestamps are often critical in computer forensic examinations. There are many ways to represent time and it is essential that the investigator understands how his/her tools operate. This paper discusses how timestamps are stored in PyFlag. It also discusses some of the features of pyflag which can aid an investigation of data from multiple sources with differing timezones.
Timestamps in Forensics
Forensics involves detailed analysis of time data, ... etc
Filesystem Differences
Daylight Savings Time
Time in PyFlag
All timestamps in PyFlag are stored in a TIMESTAMP field in mysql. Mysql describes the TIMESTAMP field as follows:
TIMESTAMP values are stored in UTC, being converted from the current time zone for storage, and converted back to the current time zone upon retrieval. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different than the value you stored. This occurs because the same time zone was not used for conversion in both directions.
Furthermore:
The MySQL server maintains several time zone settings:
...
* Per-connection time zones. Each client that connects has its own time zone
setting, given by the session time_zone variable.
How it Works
PyFlag utilises this mysql functionality as described below:
All times are TIMESTAMP fields (ie. UTC internally in mysql)
- When cases are created, a timezone is associated with the case. The default value is the local timezone of the analysts workstation. This can be changed using the "Case Management/Configure Case" report.
All database handles retrieved for that case have their timezone set to the case timezone. Hence all times displayed in the PyFLAG gui appear in the case timezone. The case timezone can be changed at any time except while loading/scanning. Note that the case timezone may be different from the evidence timezone (see below), and hence dates displayed may not reflect the local time of an event at the location in which it took place.
Whenever a data source is added (e.g. an iosource or a log file):
- The analyst is prompted for an evidence timezone (the default is the analysts local timezone). This describes the local timezone in which the evidence was collected. For example, for a disk image of a windows or unix workstation, it should be the same as the system timezone on that system.
- The evidence timezone is stored in pyflag and associated with that datasource.
- As the VFS and other tables are populated by the Filesystem drivers and Scanners
The drivers/scanners MUST convert dates to case timezone before inserting them into database TIMESTAMP fields.
Many types of data (e.g. most filesystems) use UTC timestamps already, so this conversion is simply from UTC to case timezone, the evidence timezone is not relevant. For sources which give date in 'unixtime' format it is even easier as these can be added using the 'from_unixtime' database function. As unixtime is unambiguous UTC, the data will be stored correctly by the database regardless of the current case timezone.
Some data sources (e.g. Zip files) store times in local (evidence) time. These must be converted from evidence timezone to case timezone. The evidence timezone is inherited from the VFS node where the data is found, usually this is the same as the evidence timezone specified when loading an iosource. It is worth noting that if times in evidence are stored as localtime in a zone which employs daylight savings, the times may be ambiguous!!
It is up to the scanner to know if dates that it finds are UTC or evidence local (or some other zone) and make the appropriate conversion to case timezone for entry into the database. PyFlag uses the python dateutils package to make this conversion easy.
How to configure PyFlag for Timezone support
We need to tell mysql how to handle different timezones. This information is stored in the mysql database and is used internally by mysql. By default the only timezone which mysql knows about is SYSTEM (i.e. use the system timezone). We can use the timezone data on the system to know about different timezones. Mysql has a utility which parses the system timezone data and converts it into the required SQL for configuring mysql:
shell> mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Now PyFlag is able to display the full list of timezones your system supports.
