Data Reduction, revisited

I thought I'd take a moment to revisit the topic of data reduction.

What steps are you using to perform data reduction? What are you doing to sort the wheat from the chaff, as it were?

Some of the data reduction steps I'm aware of include:

• Hash sets - look for known good or known bad files
• File signature analysis - look for files whose header information doesn't match up nicely with the file extension
• File version info - parse binary files for file version info, and flag those that don't have any
• Keyword searches - depending on the case, look for files/sectors containing certain key words

Hash sets can be used to sift through those hundreds or thousands of operating system files...the ones that we know are good, and therefore we're not interested in them. You can also use hash sets to look for known bad files, as well.

What else are folks doing?

Remember the KISS principle

How often do you see someone post to a list with a question that they could have answered themselves had they bothered to test it out?

I ran across two recently...one that didn't have much of anything to do with Windows forensics at all, but applies more to human nature...

The first was a question about files changed when a system is recovered. You know, for some reason, you can't boot a system, so you pop the CD in and reinstall the operating system...in doing so, what files are altered in the process. I suggested to the original poster (OP) that he try running a 'simple' test to find out, and the response I got was the tests weren't all that simple. His reasoning was that you'd have to check every version of Windows.

Basically, it sounded to me as he was arguing himself completely out of discussion. After all, who out there knows ahead of time when they're going to have to recover their system, and runs a integrity checking tool ahead of time?

My suggestion to him was to keep the scope of the issue small...pick an exemplar system such as XP Home or Pro, and define your problem and methodology, in such a way that the testing process you use is repeatable. For example, say that all you have available is Windows XP Pro. Note the patch level (ie, service pack, any additional patches/hotfixes)...you can do with with psinfo or WMI. Run an integrity checking tool on the files in the system32 directory...use something like FCIV or md5deep (from Jesse Kornblum). Then 'recover' the system and re-run the integrity checking tool.

You may also want to get file versioning information from the binary files in the system32 directory, as well.

Correct me if I'm wrong, but to me, asking the question "are files changed when you recover a system, and if so, which ones" really doesn't do a lot to progress the community, particularly when no one's going to do any testing.

The second post had to do with PDA forensics...the OP asked if anyone had experience using dd for PDA forensics. It was kind of an odd question, as he also stated that his employer was just about to buy (or had just purchased) the Paraben product. The kicker to the post was the statement that the OP made about not finding anything on Google. A quick search turned up info at E-Evidence.info, as well as

I've got a question about a Registry value...

The other day, on one of the lists I am subscribed to, someone raised an interesting point. This issue addresses the following Registry key:

HKLM\System\ControlSet00x\Enum\IDE

Beneath this key are subkeys that are specific to IDE drives on the system. Similar to the USB storage device key, this key has device instance ID subkeys, and beneath each of those are unique instance ID subkeys. Each of these unique ID subkeys has a Registry value called "UINumber".

Now, the issue that was brought up was this...when Windows XP is installed on a system, it looks for other drives that have operating systems installed and assigns the UINumber value accordingly. Therefore, if the UINumber value for a drive is other than 0, that should indicate that XP was installed on a system with other operating systems...right?

The poster stated that he had done testing that demonstrated this assumption. What I'm looking for is any documentation regarding how the value is set. Yes, I've done some exhaustive searches on Google and at the MS site, and haven't found anything that addresses how the UINumber value is set for hard drives.

Anyone got anything?

Seltzer on Rootkits

I received a link to Larry Seltzer's new article on rootkits this morning. It's dated 20 April, so why do I mention it?

While the article comes across as a "too-little-too-late" rehash, I do think that it is important to keep these things in the mind and eye of the public. However, I think that it's important to do so with some responsibility. The article starts down that road by mentioning that, oh, yeah, by the way...for a rootkit to take hold, it first has to get on your system. Yeah, well...ok, so most normal users may not really be aware of that.

The article also mentions the Strider Ghostbuster tool from MS...but makes no mention of the fact that this tool really isn't available. Note that the article clearly states that the tool "...works by listing..."...rather than "will work" or "should work". Either way, the article easily misleads the reader.

Is there a cause for fear? Yeah, sure...without a doubt. But that fear should be tempered with knowledge. The fear should not be so much that it causes fear and paralysis...with knowledge, that fear should be akin to that nagging feeling you get when you're leaving your house in the morning. Did I remember to turn off the stove? Did I turn off the water in my sink? Did I remember to wear pants?