Google Chrome stores the browser history in a SQLite database, not unlike Firefox. Yet the structure of the database file is quite different.
Chrome stores its files in the following locations:
There are two different versions of Google Chrome for Linux, the official packets distributed by Google, which stores its data in the google-chrome directory and the Linux distributions version Chromium.
The database file that contains the browsing history is stored under the Default folder as “History” and can be examined using any SQLlite browser there is (such as sqlite3). The available tables are:
The most relevant tables for browsing history are the “urls” table that contains all the visited URLs, the “visits” table that contains among other information about the type of visit and the timestamps and finally the “downloads” table that contains a list of downloaded files.
If we examine the urls table for instance by using sqlite3 we can see:
And the visits table:
So we can construct a SQL statement to get some information about user browser habit:
This SQL statement extracts all the URLs the user visited alongside the visit count, type and timestamps.
If we examine the timestamp information from the visits table we can see they are not constructed in an Epoch format. The timestamp in the visit table is formatted as the number of microseconds since midnight UTC of 1 January 1601, which other have noticed as well, such as firefoxforensics.
If we take a look at the schema of the downloads table (.schema downloads) we see:
And examine the timestamp there (the start_time) we can see that it is stored in Epoch format.
There is one more interesting thing to mention in the “visits” table. It is the row “transition”. This value describes how the URL was loaded in the browser. For full documentation see the source code of “page_transition_types” or in a shorter version the core parameters are the following:
The transition variable contains more information than just the core parameters. It also stores so called qualifiers such as whether or not this was a client or server redirect and if this a beginning or an end of a navigation chain.
When reading the transition from the database and extracting just the core parameter the variable CORE_MASK has to be used to AND with the value found inside the database.
I’ve created an input module to log2timeline to make things a little bit easier by automating this. At this time the input module is only available in the nightly builds, but it will be released in version 0.41 of the framework.
An example usage of the script is the following:
The script reads the user name from the directory path the history file was found and then reads the database structure from the History file and prints out the information in a human readable form (this output is in mactime format). To convert the information found here in CSV using mactime
