Internet History Examination Tools - you generally get what you pay for

My digital Life of Grime case and another ongoing case have caused me to look more closely at the tools we use to analyse internet history. Life of Grime's suspect had a penchant for the Flock browser and the other ongoing case involves Firefox 3.0.1 running on an Apple iBook. The version of Flock in use is built on Firefox 3 also. It seems to me that I am seeing Firefox as the browser of choice in the majority of my cases. I know that most available statistics still put Internet Explorer in top spot but I still maintain Firefox has overtaken IE in my cases. Certainly Firefox is (worryingly?) by far the most popular browser used to read this blog.

Now as far as the data we think of as internet history is concerned, Firefox 3.x.x stores this data in a Sqlite database, places.sqlite and sometimes additionally places.sqlite-journal. However in the wider sense internet history can also be determined from the Firefox cache because the page elements stored there contain each elements URL and associated times and dates. Firefox stores it's cache in a folder entitled Cache within the xxxxxxxx.default folder (it is possible for a user to have more than one profile -so there may be other profile names not having the word default appended). Cached items may be stored in a file by itself (albeit renamed without a file extension) or more often within cache block files (e.g. _CACHE_001_). These cache block files can contain many cached items and therefore an index file is needed to record where an item is stored in the cache. This index is called a cache map and is the file _CACHE_MAP_.

Many of us have made use of a number of free utilities to examine Firefox 3 internet history. These tools have become popular due to our mainstream, paid for, tools falling a little behind the curve and not supporting Firefox 3. These free utilities include:

• http://www.firefoxforensics.com/
• http://forensic-software.co.uk/foxanalysis.aspx
• http://www.machor-software.com/firefox_forensics
• http://www.nirsoft.net/web_browser_tools.html
• http://www.woany.co.uk/firefoxforensics/
• http://manuel.santander.name/wbf.html
  

All bar the Nirsoft tool can not parse any data out of Firefox cache. Now for me that is a problem -not necessarily with the tools, but with the methodology I am going to use in a production line forensics environment. I know there are other approaches -substituting the suspects profile into a test installation of Firefox for example but ideally I would prefer a one stop shop approach.

Regular readers will know that I work in an Encase shop and the Encase 6.15 comprehensive internet search will parse out live Firefox records from cache. However in both the cases I am working on now, the cache map file is zeroed out. In this situation Encase does not parse records still recorded within the cache block files (and for that matter neither does the Nirsoft utility).

Which brings me to NetAnalysis. As our more experienced readers will know NetAnalysis is the industry standard, tried and tested tool for the analysis of browser history and cache, particularly Internet Explorer history and cache. NetAnalysis has always supported other browser artefacts but until now not Firefox version 3. NetAnalysis 1.50 and the associated program HstEx 3 now support Firefox 3 and then some.

In both my cases I have copied out the profile folders and quickly added them to a NetAnalysis workspace using the Open all history from folder option. Because the cache map file is empty the cache is effectively deleted which is where HstEx 3 comes in. HstEx 3 is a deleted history record extractor which can locate deleted records from physical disks, raw images and new to this version, directly from Encase evidence files. In both my cases HstEx 3 was able to parse records from the cache block files that none of my other tools, including Encase 6.15, could do. The advantage of being able to run HstEx 3 directly over Encase evidence files can not be over stated. By running multiple sessions of Hstex 3, productivity can be considerably enhanced and at the same time freeing up image mounting tools for other uses.

NetAnalysis 1.50 also introduces many other new features -probably the headline one being the significantly enhanced cached web page rebuilding feature. This is very cool. Simply load in your suspects browser cache, press F6 and the workspace filters cached webpages that can be rebuilt. Double clicking on them displays the page in a viewer and within an export folder the underlying html and associated page elements can be found. Each rebuilt page folder can be copied for use in an html report for example. I can't do this feature justice here but a Digital Detective knowledge base article covers it in more detail. Other enhancements include the provision of an extensive audit log. I think this facility is anticipating the tightening of regulation here in the UK with the advent of the Forensic Science Regulator. More immediately it allows the creation of cracking contemp notes. Another notable addition is the ability to provide more information about redirect and referral URLs.

As a final thought, we all love free tools, many of them written by Harlan Carvey, Mark Woan, Tim Coakley, John Douglas and others we know and respect. But we do need to be careful - one or two of the free tools I have referred to above have been written by people who, for whatever reason, have had to obfuscate their identity. I do not doubt any of these tools, but what if a new tool was released that extracted data that none of our current tools could. If we do not know who is behind it how do we know that the said tool was not on a certain date in the future going to scour our forensic network and modify all the Encase evidence files it came across? As I said at the start you generally get what you pay for. Till next time.

Flock shepherds in a Life of Grime

After writing that title I am wondering if I wouldn't be better employed writing crossword clues. Back at the sausage factory I am bogged down investigating a digital Life of Grime. You probably have done a case like it - there are several hard drives in the suspect's box all with multiple partitions. Every nook and cranny is stuffed with IPoC and IVoC in a semi organised way. Almost as if all the material was neatly stored at one time until my suspect got lazy and started storing stuff on the floor, in the hall, under the table, that sort of thing. There are new folders after new folders -you don't see a New Folder (13) everyday. Not content with filling up his hard drives my suspect had also felt the need to back his stuff up to CD-R or DVD. Repeatedly.

The sheer quantity of files and folders in this case presents many problems and I thought I would share a few of them with you. Most of the problems are linked to pictures, that is the vast quantity of pictures, all of which have to be categorised and counted.

As many of my readers will know in a case like this C4P is an essential tool (going off at a tangent -googling C4P led to the discovery that c4p dot com is an online community for swingers - and now having said that we better watch out for some dodgy google ads appearing to the right ->> but hey they might improve my minuscule return from them ;-) ). C4P stores the results of categorisation, whilst the case is being worked on, in an Access database that has a 2GB file size limit. Now depending on how deeply your MDP folder is buried within your case folder structure this equates to about 1.9 million picture files. A long standing problem has been that if the c4p graphics extractor enscript carves out more than about 1.9 million picture files C4P itself would fail to create a case, due to the underlying Access database maxing out. In this case well over 2.1 million images were carved from the optical media alone and I was pleased to discover that C4P version 4.01 at least dealt with the maxing out issue fairly gracefully by creating a .c4p4 file and then a second .c4p4 file for the overspill. Case creation failed but I was subsequently able to create a new case by opening the double clicking on the first c4p4 file, which is associated with C4P. Doing this gave me a case with exactly 1,900,000 pictures which when viewed pragmatically is better than starting again. It is clear that the Access database problem will become more of a problem as main stream hard disks become bigger and bigger and I was pleased to discover that a beta version (4.03) of C4P is available that utilises an SQLite database (and whilst at it, runs happily on 64 bit boxes). This version does not limit the number of pictures you can have in one case.

In a case like this another C4P bugbear also rears its ugly head. The latest C4P graphics extractor enscript (4.03) carves out embedded thumbnails within jpgs, so for every picture file potentially you may have three carved images- the original, a thumbnail and a preview image. I am not sure why the latest script does this as a feature of earlier scripts was that it didn't carve embedded images to avoid duplication. It is that word -duplication- that is the problem. C4P will allow you to create a report directly from the program but if you need to compile statistics (how many Level 1s, 2s etc.) the report will be inaccurate. I do not use C4P for reporting and instead use the C4P Import enscript to bring back the C4P results into my Encase case. Once in Encase, sorting the C4P bookmarks by file offset provides a good indicator of how many embedded images there are. Luckily it is a fairly simple exercise to remove the duplicate bookmarking -simply selecting (blue checking) each category folder in turn and tagging selected files, and then from Entries view rebookmarking the files concerned will effectively sort out most duplication. Obviously different considerations will apply to pictures embedded into files for other reasons.

Moving away from C4P another issue in this case is establishing where the pictures came from. Obviously establishing which browsers are being used is a job that need doing and an Enscript that does just that has been written by Mark Woan over at Woanware. The WebBrowserInformationFinder enscript outputs to the console enabling you to copy and paste into your contemporaneous notes -very neat. Talking of contemp notes I use John Douglas's Case Notes - another very neat program. Looking at the problem a little wider it is worth considering some other angles to this problem, the registry contains a few pointers too, Harlan Carvey's post Browser Stuff covers this in more detail.

As it turned out my suspect used Flock as his default browser. This browser is built upon Firefox 3 and stores internet history and cache in a profile in the same way as Firefox. In the XP box I was looking at the profile folder was stored at the path C:\Documents and Settings\USER_NAME\Application Data\Flock\Browser\Profiles\xxxxxxxx.default. I have analysed this with NetAnalysis 1.50. More on NetAnalysis, Firefox 3 and the tools available to analyse this browser's artefacts in my next post.