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 http://www.w3schools.com/browsers/browsers_stats.asp, 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:

Woanware's ChromeForensics tool
Nir Sofer's ChromeHistoryView &ChromeCacheView
Mandiant's Web Historian.

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
ode=R71RR1&prod=RealPlayer&ver=15.0&li=en&oem=rp15_en_us&loc=us"
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.

Forensically Mining New Nuggets of Google Chrome

What has gone before...

New Stuff:

Related Content