SANS Digital Forensics and Incident Response Blog

Forensically mining new nuggets of Google Chrome

I was recently creating some slides on Chrome forensics for a class I'm teaching, when I really discovered for the first time just how popular it's actually become. As of last month, according to, Chrome is not only 50% more popular than internet Explorer, but is actually neck and neck with Firefox (36.6% vs. 36.9%).

Despite this, and the fact that Chrome is actually open source, (or technically, I guess Chromium is the open-source project behind Google Chrome) there's significantly less documentation about associated forensic artifacts than there is for equivalent items in IE or even Firefox.

What has gone before...

I was able to find a number of Chrome forensics blog postings, but most dealt more-or-less exclusively with extraction of its web history:

The structure of the Chrome cache is also documented in a number of places:

And I found several tools references:

New Stuff:

The really interesting bits, though, were what I found when I really started looking at the files that Chrome puts on a system when you install and use it. According to Digital Forensics with Open Source Tools, by Cory Altheide & Harlan Carvey, Chrome files should have been located under:

  • XP: <profile>\Local Settings\Application Data\Google\Chrome\default
  • Vista/Win7: <profile>\AppData\Local\Google\Chrome\default

However, in my test install of the current version, files were placed under:

  • XP: <profile>\Local Settings\Application Data\Google\Chrome\User Data\Default
  • Vista/Win7: <profile>\AppData\Local\Google\Chrome\User Data\Default

It's a small difference, and probably version related, but makes me wonder which tools tracked it when it occurred.

In my test install, I observed ten different SQLite database files placed in the Chrome Default folder. Forensics on those is relatively straightforward, and has been covered elsewhere in some detail, so I will skip over that.

In addition to the SQLite databases, there were also nine different files of various types:

  • Bookmarks (JSON)
  • Bookmarks.bak (JSON)
  • Current Session (SNSS)
  • Current Tabs (SNSS)
  • History Provider Cache (Protocol buffers)
  • Last Session (SNSS)
  • Last Tabs (SNSS)
  • Preferences (JSON)
  • Visited Links (unknown binary format)

If you've read some of the references I cited above, you're no doubt wondering what 'Protocol Buffers' and SNSS formats are, since these are described most places as an unknown binary format. I'll lead off with my first major success. I found a reference via Google that mentioned the format of the History Provider Cache having previously been something called Pickle (Possibly related to python pickles?), but having been changed to 'protocol buffers'. A bit more Googling resulted in my finding a reference to the protoc tool, which is a compiler/packer for the protocol buffers binary structure. I downloaded and examined this utility, and discovered that the '-decode_raw' option would cause it to read in a file such as 'History Provider Cache', and would output the encapsulated data in plain text.

When I used this utility to extract data from the 'History Provider Cache' file, I got another surprise. Here's a snippet from the output:

2 {
1: 126
2: 0
3: 0
4: 12974212186000000
5: "file:///C:/Documents%20and%20Settings/John%20McCash/Local%20Settings/Temp/rninst~0/ui_data/pages/progress/index.html?distc
6: "RealNetworks"

The included long number is a Google Chrome timestamp, using the number of microseconds since 1/1/1601. The interesting thing is that I had updated my Realplayer installation a couple of days before I installed Google Chrome. I don't think I even did it using Internet Explorer, but I'm not absolutely positive. In any case, Chrome appears to have pulled some history information from another browser to pre-populate this file upon installation. This could be a forensics bonanza in the right circumstances. I certainly wouldn't have expected this behavior.

The SNSS files are unfortunately in a binary format that I haven't been able to successfully decode. It may be related to the Pickle format mentioned above. I'm not really sure. (If somebody who's more familiar with the Chromium source could chime in, I think the community would be most grateful.) But the point is that SNSS is the Magic Number or File Signature that these files lead off with, and that they're used for Chrome's Session restore functionality. This capability is similar to that implemented by IE in the files under the Recovery folder, and by Firefox in sessionstore.js. Some data can be found in text form inside these files. Also, I found a javascript application for Chrome that will allow you to read in the 'Current Tabs' or 'Last tabs', and will reopen all the tabs referenced in the file. I'm certain there's a wealth of additional information in this file, and it should be possible to carve these out of unallocated space using the file header. I'll bet there's a file length in there somewhere as well.

Sadly, the format and contents of the 'Visited Links' file still eludes me, though the name certainly suggests some level of forensic utility. This may have something to do with link coloring. Information regarding this is probably buried somewhere in the source.

Finally, the JSON format of the Bookmarks, Bookmarks.bak, and Preferences files lends them well to manual analysis, so I'll forgo detail there as well.

As always, you're welcome to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy. And please do so if you know of something useful that I've missed.


Posted April 4, 2012 at 1:02 PM | Permalink | Reply

Forensic Store

Wow, great stuff! It is rather funny that chrome often gets forgotten when discussing browsers. Its not going anywhere! Crazy how fast it has grown.

Posted April 9, 2012 at 11:47 PM | Permalink | Reply


The incorrect path looks to be an error on my part. Since this is my first certified mistake, I owe you a beer or something. ;-)
Excellent write-up, by the way.

Posted April 18, 2012 at 11:48 AM | Permalink | Reply

Tim Taylor

I use chrome and sync with my Google account on three different machines. I noticed at work the other day that some of my browsing history from home was showing up in my chrome history at work. Upon further review, it appears some, but not all of the history is part of the sync. So far I've been unable to correlate/confirm the details of what is sync'd and how to determine where an item in the history was actually created. Any idea?

Posted July 26, 2012 at 7:57 AM | Permalink | Reply


After reading this article, I wrote a set of small tools to read History, Cache, Visited Links and SNSS files.
There is a page describing the reverse engineering of SNSS format. It is still a work in progress. It is under BSD license.

Posted July 26, 2012 at 2:08 PM | Permalink | Reply


Woot!!! You rock JRB! (And I even get to pat myself on the back for my guess that SNSS format was related to pickles.)
Thanks much for the comment, and even more for the new tools!

Posted August 5, 2013 at 7:48 AM | Permalink

uday kishore

Do we have any c library to read chrome cache?. if not is there any other way to get that data using c programming?? Can i have any references for that please??

Posted July 9, 2013 at 8:06 PM | Permalink | Reply


if you google ''Parse the Google Chrome "Current Session" file' you will find that Python is used to edit or view ''.snss' files''
see also: