My Road to Digital Forensics Excellence

Archive for June, 2011

Manual review of data structures

Posted by Paul Bobby on June 8, 2011

#dfirsummit has been generous this year in that they’ve provided a free live stream of the 2 days of presentations. This quick post was prompted from listening to Lee “Gervais” Whitfield, and his discussion of where to look to disprove the ‘bios clock changed’ conspiracy when it comes to disputing the evidence on your hard drive.

He indicated several locations that exhibit temporal anomalies should the clock in fact get changed. For example, thumbs.db (thumbnail databases in folders with images) stores thumbnail data sequentially – changes in the timestamps of those thumbnails may indicate time change.

He was asked, what are the Top3 places to look for for evidence of clock changes, and as #1 he mentioned Event Logs. But I don’t think for the reason why it is #1. He mentioned one event for XP and a couple of events for Vista/7 that show the clock being changed that get recorded in the event log. This is good of course, but I believe the real deal with event logs is just as with thumbs.db. Data is written to the event log sequentially – it is not ordered chronologically.

Talking Windows OS and NTFS.

Again: event logs are written to the NTFS file system, and then individual events appended to the log. If the clock changes, new events are appended to the log with these new timestamps. This is where reliance on tools such as Encase/FTK to perl scripts, to Event Log explorers, even log2timeline, that may auto-sort events for us chronologically for presentation, or at the least, our first step is to sort output chronologically. If we manually inspect the contents of the event log file with a hex editor (i.e. a raw view), and do some decoding ourselves, we can see the jump in time/anomaly clearly.

Of course what is ‘clear’ is subjective – but this is a good example of where manual review of data structures may in fact save the day rather than relying on our tools. Manual review of data sources may only be appropriate for certain scenarios, and I’m not recommending it as a daily approach; but it is something to be mindful of when trying to prove a point.

Posted in Forensics, General Research | Leave a Comment »

Encase v7 Preview #2

Posted by Paul Bobby on June 4, 2011

The new features for testing in this preview:

  1. The ability to utilize your own evidence and expanded device functionality.
  2. New Email formatting.
  3. New Bookmark functionality.
  4. New Report Templates.
  5. New Modules under Evidence Processor.

I’m going to take a look at #5 first. I believe the Evidence Processor will be one of the key features in forensic analysis for those shops that have large amounts of data to analyze and would welcome a lot of preprocessing to be accomplished prior to actual analysis.

Recall that with Encase v6, you can do a Keyword Search, Hash and signature analysis after you finish the acquisition; even without a dongle attached. The Evidence Processor in Encase v7 appears to be just that, but a lot more. It might be considered generous of Guidance to allow so much ‘stuff’ to be accomplished right up front, but I believe it falls in line with the 21st century approach to large data sets: pre-process as much as you can before the ‘human’ has to sit down and start analyzing.

Here’s a screenshot of the Evidence Processor:


For each evidence item added to your case you can acquire and/or process that evidence. If you want to process, the options in the lower window become available.

Each option is either enabled/disabled, and some of the options come with sub-dialogues. For example, Find Internet Artifacts allows you to search Unallocated or not to the more complicated sub-dialogues of the three newly added modules.

All of this pre-processing is stored in the custom database format that makes Encase v7 so different from previous versions. Once the processing is complete, the case folder structure can be copied to your analysis machine, or given to your level-3 forensic analyst, for actual analysis. It’s a neat method of operation, and remember, when you load the case, there is little lag for case open: you do not have to parse all of this pre-processed data prior to commencing actual analysis. It is all stored in database files.

If adding to the ‘Modules’ section becomes a future feature available to Enscript writers, then we have a real winner. Just imagine the numerous custom modules you would like to run against a target evidence set. Triage comes to mind as a great example of where adding modules to this Evidence Processor will deliver great benefits. Encase Enterprise? Even better. But EE is at least a year away.





Here are the sub-dialogues of the IM Parser and System Info Parser. They should be familiar to you.

image  image

The File Carver module makes use of the File Types global folder (which actually combines File Types and File Signatures in v7). Most of the ‘file types’ are listed solely by file extension, but for those that have headers, and the few that have footers, they become available in the new File Carver module dialogue to be carved during Evidence Processing.

I haven’t found any details on how HTML or Webmail files are carved. I will be testing that.

After clicking Next, you are presented with the Export File dialogue screen where you can specify file sizes for when the headers are found.image

And finally – in case you were wondering. You can add Raw Images with this preview. And here’s what a lot of you have been waiting for. I will testing this out for sure.


Posted in EnCase | 2 Comments »