My Road to Digital Forensics Excellence

Archive for February, 2010

LNK File Testing

Posted by Paul Bobby on February 23, 2010

So have you read the Meaning of LIFE by Harry Parsonage?

Well I have, and I started testing the observations made therein. This is a very good paper, especially the section regarding ObjectIDs. I sometimes feel that they are overlooked, especially in the flavor-of-the-month timeline analysis discussions that are happening now.

However I’ve been slowly testing each observation under a number of different scenarios; let’s start with Observation Two.

Once a link file has been created for a target file with a given filename, during the lifetime of that link file, if another target file of the same name is accessed from a different location, the original file for that given filename is updated.

So, for example, create c:\test.txt, open it and add some text, then close. Double click this file in explorer, and you should get a test.txt link file created in your recent folder. Close the text file. This time create a new file on your desktop called test.txt. Open it, add some text, and then close. That test.txt link file now points to the second one.

My goal in testing was to discover if there is a way to determine if the link file is pointing to the very first target file that caused the link file to be created.

I confirmed, as Harry did, that the sequence ID of the MFT record of the link file increments whenever the link file points to a new target file with the same filename. So my hypothesis is, if the sequence ID of the MFT record is 1, then we can conclude that the link file is pointing to the first

Test setup

  1. Thumb drive formatted NTFS, write caching disabled
  2. Drive mounted to E:\, test files test.txt are present on E:\ and C:\
  3. Retrieve the File Identifier and Sequence ID of the Recent\test.txt.lnk

Test sequence

  1. Open E:\test.txt
  2. FileID/SequenceID: 89278, 20
  3. Open C:\test.txt
  4. FileID/SequenceID: 89278, 21
  5. Open E:\test.txt
  6. FileID/SequenceID: 3313, 119
  7. Open C:\test.txt
  8. FileID/SequenceID: 3313, 120
  9. Open E:\test.txt
  10. FileID/SequenceID: 3313, 121

Simply opening ‘test.txt’ from different locations causes the test.txt.lnk file to be updated and point to the new target file. What I discovered is not only does the Sequence ID get updated, but also an entirely new MFT record could be used! Not sure why. Well that blows my hypothesis out of the water.


Posted in Forensics | Leave a Comment »

File availability

Posted by Paul Bobby on February 12, 2010

I allowed my GoDaddy account to lapse, which was the location used to house my files. I still have the originals, and will update this post when I have a new location to host them.

Update: I was able to figure out how to enable upload of any file to Google Docs. All the files I link to on my blog will be hosted there.

Posted in State of Affairs | Leave a Comment »

Entropy Testing

Posted by Paul Bobby on February 10, 2010

There is an Entropy function available to Enscript programmers, and for use within Encase. This function returns a value between 0.0 and 8.0 (although not sure if those theoretical limits can be reached).

Some initial testing:

1. Truecrypt container: 7.9999999566885638

2. Unencrypted RAR file: 7.99603844812298

3. Sample office documents range from 2.2308970467726277 through  7.6206790243552032

4. Text document with 100 letter As: 0.28229218908241482

5. McAfee BUP files (ROT13): 2.9158825454109309

Okay this is all well and good, but why bother if the values are so spread? Well the reason I tested the entropy() function is because I was testing a theory related to this years DC3 cyber challenge.

One problem had two keylog.dat files, and the problem required developing a methodology to decrypt/unobfuscate them. One method I chose was to encrypt sample text files with various algorithms, calculate the entropy, and then compare the entropy value to that of the keylog files. Great theory right? I used the program Cryptool to perform the testing – and what I found is that modern encryption algorithms are very good, and produce high entropy files. Ugh.

The second problem dealt with developing a methodology to identify audio steganography. Again, I hoped that if I had the original file and the suspect file, the entropy would differ (much like a MD5 hash will differ). For example, the sample Wave file, jungle.wav has an entropy of 4.4638505523879672, and the suspect jungle.wav file provided by DC3 has an entropy of  4.4638505523879672.

Well bugger.

Posted in General Research | Leave a Comment »