My Road to Digital Forensics Excellence

Archive for November, 2008

SteadyState – Test1

Posted by Paul Bobby on November 7, 2008

With Windows Disk Protection enabled, nothing should be written to the hard drive outside of the SteadyState Cache file. Is this actually the case?

I created two text files under C:\Users\pbobby\Documents. One file was called “res-text.txt”, a small text file with just enough data to keep it resident. The second was called “non-res.txt”, another text file, but this time with enough data to ensure it was non-resident.

At this point I shutdown the laptop, gracefully, and selected the Windows SteadyState option “Continue and Remove all Changes”. Following this shutdown I executed the imaging process mentioned previously.

Once completed, the laptop was allowed to boot, log in, and settle down to ensure SteadyState had finished, Superfetch had finished etc etc. No changes were made to the laptop beyond the OS simply being allowed to perform its bootup routine. The laptop was shutdown a second time, picking the same “Continue and Remove” option and reimaged once again.

For this test I have four datasets:

  • SteadyState-Baseline
  • Test-set1 (First shutdown – the cache not yet erased)
  • Test-set2 (Second shutdown – the cache erased and prepared for a new bootup)
  • Hash set, “Steadystate-Baseline” classified as “Known”

After applying the hash set to Test-set1 and Test-set2 the following differences were noted:

  1. Test-set1: C:\Boot\bootstat.dat
  2. Test-set1: C:\Cache.WDP
  3. Test-set2: C:\Boot\bootstat.dat
  4. Test-set2: C:\Cache.WDP

Furthermore, the files were different from each other on both Test-sets. This is encouraging – I expected the Windows SteadyState cache file to change, but didn’t know about bootstat.dat. I’ll have to read up on that file, as it’s something new with Vista.

These weren’t the only file system changes – Encase does not hash NTFS metafiles (although it does hash the UsnJrnl file). So let’s do that now.

  1. The $MFT is the only NTFS metafile that changes – expected considering the metadata changes to the Cache.WDP file and the bootstat.dat file.
  2. The $Logfile and the $UsnJrnl files were not changed.

What changed in the $MFT? Just the entries for cache.wdp and bootstat.dat? Time to break out UltraEdit and compare.

Oh! It turns out that only the MFT record for C:\Boot\Bootstat.dat has changed! The MFT record for Cache.WDP has not changed. And looking at the timestamp information for this file across all three data sets verifies that. Sweet. The only change in $MFT comes from bootstat.dat – maybe in Windows XP even that goes away.

This comes in handy – I can now just copy the Cache.WDP file every time I do a test instead of imaging the entire drive.

Let’s shift focus to the C:\Cache.WDP file.

To be continued….


Posted in Forensics | Leave a Comment »

SteadyState Test Setup

Posted by Paul Bobby on November 7, 2008

I’ve established the following Baseline for my SteadyState tests.

  1. Dell Laptop with 40Gbyte drive
  2. The entire drive was wiped using BCWipePD with the single byte 0x00
  3. The drive was partitioned to have a 16Gbyte “C” partition for the OS, and a 2Gbyte “D” partition. The remainder is left unused
  4. An external hard drive was prepared with two 32Gbyte FAT32 partitions for image storage
  5. Vista Professional 32bit was installed on the laptop and patched (SP1 not installed, OS not activated)
  6. SteadyState was installed with Hard Drive protection enabled

When conducting my tests, I use the following repeatable process:

  1. Ethernet cable is disconnected
  2. Laptop booted with Helix
  3. External hard drive connected and one of the partitions mounted (mount -o rw /dev/sdb1 /media/sdb1)
  4. Images are created using Linen, medium compression (generates 4Gbytes of files)

This process was followed to create a SteadyState-Baseline evidence set along with a Hash Set of the filesystem contents to be used for later comparison.

One thing of note is that Encase does not Hash NTFS metafiles, and so I use the following Enscript to Hash any file I select. (Thank you Gary Brown)

Posted in Forensics | Leave a Comment »

Windows Steadystate

Posted by Paul Bobby on November 6, 2008

This awesome piece of software is designed to simplify the process of managing shared computers. At the end of the day, a shared computer, such as at a library or university, can be in an infinite number of states. How about we keep it in the same state that the IT department knows about? – hence Windows Steadystate.

I’m interested in SteadyState for two reasons – forensic evidence present in the SteadyState Cache file, and using SteadyState as a malware testing option.

A key feature of SteadyState is called Disk Protection. Using caching technology, the Operating System writes new changes, and reads those new changes from a large static file called cache.wdp. I have found no documentation on the structure of this cache file, and requests on the MSDN forums yielded no information. If you are logged in as an Administrator, you are given the option, on Shutdown/Restart, to either commit or discard the changes. During the next bootup the changes are discarded (the cache file rewritten) or made permanent (followed by rewriting the cache.wdp file).

The key here is that even during a graceful shutdown, when the Admin says “discard changes”, the changes are still present in the cache as long as the computer is not booted up. (In Windows Vista, the changes and cache.wdp operations take effect before the log on screen is presented). The standard system monitoring tools don’t apply here (or at least I haven’t discovered it). The cache.wdp file does not get written to (at least from the perspective of tools like filemon.exe and procmon.exe). Therefore trying to reverse engineer this is going to be a challenge. I configured Process Monitor for Bootup Logging, and this persisted when I clicked “Save changes”. The results:

  • VCFCHK.exe creates c:\cache.wdp
  • VCFCHK.exe reads 512bytes, then another 512bytes, then another 512bytes
  • c:\cache.wdp is closed

VCFCHK.exe is an application in \Program files\Windows SteadyState, and “Cannot be run in Win32 mode”.

Looks like the cache.wdp file is created during each bootup.

I will be conducting a series of tests and documenting them here on this blog.

Posted in EnCase | Leave a Comment »

Encase Benchmarking

Posted by Paul Bobby on November 4, 2008

I’m about to post this to the official Encase forums.

The other day I was thinking about benchmarks; I was contemplating using Xeon processors for my new forensic examiner box versus an Extreme edition CPU. And I got to thinking – wouldn’t it be great to have some sort of forensic benchmark, specifically to Encase (since I’ll be doing my work with Encase) so that I can tell which hardware configuration is the most appropriate?

A quick search of the Encase forums showed almost no traffic concerning benchmarks save for a recent thread started by dk_mitch. He and I exchanged email, and the idea was born. I even received word from Joshua Joseph, at Guidance, expressing his interest and that their tech-support stands by to help (which is good because I’m sure they have better hardware resources then I do).


  1. The goal is to benchmark Encase, not to test if Encase is capable of performing a forensic task
  2. The goal is to run repeatable benchmarks against your hardware configuration so that you can fine-tune it for performance using a static Encase configuration
  3. The goal is to run repeatable benchmarks against Encase and the Operating System so that you can fine-tune it for performance using a static Hardware configuration.
  4. The goal is to run repeatable benchmarks against multiple versions of Encase so that you can compare the performance of features when new versions are release. The OS and Hardware configurations should remain static.

Baseline System Configuration

Part of Goal #2 is that the hardware will change as you upgrade and replace components. Are there some rudimentary criteria for the hardware configuration that “goes without saying”? Bare metal hardware only, no virtualization?

Part of Goal #3 is that the Operating System and Encase itself will change as they are fine-tuned for optimal performance on a static hardware configuration. Are there some common criteria for the OS and Encase? Windows XP SP2 and higher? No virtualization?

Part of the system configuration will be the identification of possible performance steps. For example,

  • RAID or not?
  • Readyboost if Vista?
  • Pagefile on a USB thumb drive if XP?
  • Parsecache on a separate drive?
  • SATA, SAS, SST drives? SAN (iSCSI or FDDI)?
  • Multi-cores? Multi-CPUs?
  • 32bit or 64bit OS?
  • How much RAM?

Collecting the Results

If an index of a large eText takes 30minutes on your configuration, it does us little good if that data cannot be shared along with the hardware and software configuration. Should a custom tool be written to gather this data, or make use of something like “msinfo32.exe”?

The Execution

How to automate a series of bookmarks? Should we even consider automation? It rules out the end-user from modifying the tests for sure. The benchmarks have to be protected somehow to ensure consistency of testing otherwise the data has to be thrown out.

Can we Enscript and Enpack them? This has the advantage of being able to extend the benchmarking process by wrapping newer features around the core tests being conducted.

Evidence Sets

Whatever is used for evidence sets has to be free of copyright issues and other restrictions. The evidence can be customized around the benchmarks being conducted, but at the least should be standardized and presented in EWF format. For the benchmarks involving indexing and searching, large text collections come to mind. One approach is to use an eText of the Bible – they come in different languages, Project Gutenberg publishes them free-to-use, they can be resaved in to UTF8 and UTF16 for Unicode searches, and because the Bible is organized in to chapter and verse, comparisons between the language benchmarks are easy.

A second example of evidence-set customization is to include four copies of the same eText in the same series of EWF files. Execute four searches, one for each eText, i.e. four threads, on each core, and benchmark the bottleneck as Encase jumps all around the evidence set as it conducts its four searches.

The Benchmarks

Along with customized evidence sets, the majority of the work will be to establish the core benchmarks. Do we consider standalone Encase only or do include some Enterprise Encase functionality?

Some of the more common machine-intensives tasks that come to mind:

  • Indexing and Keyword Searching
    • Non-grep
    • Grep
    • Unicode
    • Language options
    • Simultaneous searches against one file
    • Simultaneous searches against two or more separate parts of the evidence set
  • Hash Analysis
    • NTFS file system build
    • Ext3 file system build (Ubuntu)
    • Other OS installations, Solaris, Mac (HFS)
    • Does the file system being analyzed really have an effect on the hash analysis at all?
    • Different hashing algorithms (MD5 and SHA)

There’s a lot of work to be done here – hopefully a discussion will unfold.

Posted in EnCase | 1 Comment »