More fun with Chrome

The Sunbelt Blog has a link here that will force Chrome to crash.

Or you can enter crash:% into your browser and do it yourself.

Good times.

Google's Chrome Browsing History, a first pass

This will be a short post. I'm sleep deprived and traveling. . .

Google Chrome debuted yesterday. So sometime this week, someone somewhere will have to do some analysis on Chrome's browser artifacts. Until someone writes a script/program to extract user history, here's one way to get some information:

Chrome saves its data files in C:\Documents and Settings\[user]\Local Settings\Application Data\Google\Chrome\User Data\Default


The following files store data in SQLite format 3:
Archived History
Cookies
History
Thumbnails
Web Data

To examine those data archived in SQLite format 3, you can run strings against the files. I found sqlite3explorer here. This does a fairly decent job of rendering the data.*


IF we open the "history" file and go to main > tables > urls and right click on



urls, we can click "show data" and the bottom right windows will populate with the data in the urls colunm.

It is important to note that Chrome will import browsing history from other web browsers, so the history contained here may not have been generated by Chrome.

Running Strings against the following files will/may reveal interesting data:
Last Session
Preferences
Current Session

Visited Links has binary data. YMMV.

* This doesn't work well on my computer unless executed by double clicking on the icon from the firefox download tab:



There are also files called:
History Index 2008-09
History Index 2008-08
(It appears that these are created daily, but this needs to be confirmed)

Pre-boot authentication bypass techniques.

Jonathan Brousard gave a talk at DefCon 16 that has not gotten much press, but his research has some interesting forensic implications. You can read the white paper at http://www.ivizsecurity.com/pdf/preboot_whitepaper.pdf.

There's a tool set available from the same site.

/dev/mem for Windows, and other bits of memory goodness.

Can "good old cgywin dd" and dcfldd access \.\\Device\PhysicalMemory? It appears that they can.

I was reading posts by Harlan Carvey and Andreas Schuster about new tools for imaging the Physical Memory in Windows this week. Some interesting stuff there. Then I stumbled across an article in Forensic Magazine by Kevin Mandia and Kris Harms, which said in part that \device\PhysicalMemory could be imaged with DCFLDD. I tried the string in the article:
DCFLDD if=\\.\PhysicalMemory of=AnyExternalDevice conv=sync,noerror and I got a big handful of fail for my efforts.

I assumed that someone else had tried this and a little googling turned up this string at forensic focus, as well as a post by on with Windows Incident Response blog that mentioned it (how did I miss that post and why can't I find it now?).

I used the /dev/mem substitution for dcfldd on an XP SP2 box and it seemed to work.

So what I'd learned so far:

1. The Mandia article has incorrect syntax.
2. You can use dcfldd to image something from /dev/mem.

It didn't seem like anyone had figured out what dcfldd was imaging though.

My next thought was, "If dcfldd can image the mysterious /dev/mem, could good old cygwin can access it?" It appears that it can.

According to these posts on the cgywin developer's list, the cygwin grabs \device\PhysicalMemory using cygwin's /dev/mem, in a manner consistent with *nix systems.

I decided to conduct a quick experiment on each. I acquired a sample of physical memory from a XP pro SP2 box:


06/20/2008 09:21 AM 1,064,648,704 dd.img
06/20/2008 09:17 AM 1,064,685,568 win32.dump
06/27/2008 11:49 AM 1,064,685,568 mdd.img
06/20/2008 09:09 AM 1,064,697,856 dcfldd.img

The same command was used for both dcfldd and dd ((DCFL)DD if=/dev/mem of=.\outfile.img conv=sync,noerror

Nothing earth shattering here, but note the file sizes.

P2P Marshall

While researching something unrelated, I tripped across P2P Marshal. Since I have not been able to get to any sort of training short of paying my own way, I did not make it to the DFRWS07 - at any rate, the tool's been out and it's free to LE.

From the website:

P2P Marshal is a tool to analyze peer-to-peer (P2P) usage on file system images. It automatically detects what P2P client programs are, or were, present, extracts configuration and log information, and shows the investigator the shared (uploaded and downloaded) files.

P2P Marshal follows forensic best practices and maintains a detailed log file of all activities it performs. It is designed to be easily extensible to support new P2P clients and networks. It has extensive search capabilities, produces reports in RTF, PDF, and HTML formats and runs on Windows-based operating systems.
Features

* Analyzes peer-to-peer network usage
* NIJ-sponsored project
* Extensible
* Forensically sound
* Version 1.0 available free to law enforcement
* Provides full analysis for: BitTorrent, LimeWire, uTorrent, and Azereus
* Detects and shows default download locations for Ares, Google Hello, and Kazaa
* Future versions will include additional client support and capabilities

Requirements

* Microsoft Windows XP or Vista Operating System
* 120M disk space free

I don't think I'll have the time to use this any time soon, but if someone else does, I would be interested to know about it.

There's also a mention in the ForensicsWiki about it.

Note to marketing: If you want to sell to cops. . .

don't use toy handcuffs in your marketing.

Talk about "push-button forensics" marketing.

Not impressive. I'd also note that the vendor claimed to have ~900 phones that it could image, but their website showed a little over 410. Hmmm.

Vista may be vulnerable to a local password bypass via firewire.

Vista vulnerable to firewire hack (via Thoughts of a Technocrat)

I've been to busy to play with these attacks, but it's on my to do list.