SecureArtisan

My Road to Digital Forensics Excellence

Archive for September, 2010

Verifying a Wiped Drive, Part 2

Posted by Paul Bobby on September 26, 2010

I have added my complete enscript to the My Files page. This enscript now includes GUI elements as well as a routine to precalculate the MD5 checksum of any given wiping pattern. Mismatches found across the hard drive are displayed in the console as well as bookmarked. (Note that the bookmark points to beginning of the data that is read, it doesn’t identify the bytes that are different).

Out of necessity of testing, I included a ‘selected files’ option. This way you can create custom files using a hex editor, with specific wiping patterns and verify the operation of the enscript.

Using this enscript I’ve discovered that BCWipe doesn’t make every byte on the target device equal to the wiping pattern. For some reason BCWipe likes to used bytes 0-4 as a counter. Granted the data is overwritten, but the drive doesn’t exactly contain just the wiping pattern.

Posted in EnCase | Tagged: | Leave a Comment »

Verifying a Wiped Drive

Posted by Paul Bobby on September 23, 2010

I recently had the task of verifying that a 32gig SSD had been successfully bricked by overwriting every single sector with 0xFF. A couple of quick hit approaches came to mind.

  1. Run the consecutive sectors enscript. ETA to complete was approximately 6hours with my hardware. Besides, this enscript is designed to identify patterns to discover if wiping had occurred. I already knew this so perhaps the script was overkill.
  2. Run a keyword search for [^\xFF]. The ETA for this search was 30 minutes. Not bad. The idea here is to find a search hit on anything other than the byte 0xFF.

But is there a better way? Well there’s my way but unfortunately it took the same time as #2 (hey it gave me something to blog about anyway 🙂 )

Here is the basic code block:

    // Script specific variables
    long clusterSize = 4096;
    EntryFileClass ef();
    MemoryFileClass mf();
    long fileSize;
    long filePos;
    // This hard coded value represents an MD5 checksum of 4096 bytes containing the value \xFF.
    HashClass wipeHash("6AE59E64850377EE5470C854761551EA");
    //
    // Script specific code start
    forall (DeviceClass d in c.DeviceRoot()) {
      if (ef.Open(d,0,-1)) {
        ef.SetCodePage(CodePageClass::ANSI);
        ef.Seek(0);
        fileSize = ef.GetSize();
        while (filePos < fileSize) {
          if (mf.Open(clusterSize, FileClass::WRITE)) {
            mf.SetCodePage(CodePageClass::ANSI);
            mf.WriteBuffer(ef,clusterSize);
            mf.Reset(0);
            HashClass mfHash = mf.ComputeHash(-1);
            if (mfHash.Compare(wipeHash) != 0) {
              CLog.Debug("POS: " + filePos + ":"+mfHash);
            }
            mf.Close();
          }
          filePos += clusterSize;
          ef.Seek(filePos);
        }
        filePos = 0;
      }
        else CLog.Fatal("Cannot create EntryFileClass out of "+d.Name());
    }



 











This code iterates through each attached device and calculates the MD5 hash for each 4096byte read from that device. It makes use of MemoryFileClass to store the 4096bytes that are read, and compares the MD5 hash of this memory file with the hard coded hash in line 8. If the hash value does not match, the file position is displayed in the console.

One of the gotchas of this code is line 20. Without resetting the memory file pointer to the beginning of the MemoryFileClass object I would get incorrect hash results.

The next step is to include a GUI element with this code so that it queries the user for the wiping pattern and generates the MD5 hash value to compare against.

Posted in EnCase | Tagged: | 4 Comments »

SIA Timestamps and FNA Timestamps in Action

Posted by Paul Bobby on September 2, 2010

There have been many that have pontificated over the difference between the timestamps found in the Standard Information Attribute of the MFT record and the timestamps found in the Filename Attribute of the MFT record. And much like steganography and printer spool files, it’s one of those things you read about in the fiction of everyday forensic practice, but never really experience.

Here is a repeatable experiment that you can try for yourself that shows NTFS weirdness in action as it relates to MFT timestamps.

  1. Format a test partition to NTFS (I used a custom 2gig partition, makes testing quick)
  2. Right click-create new text file – name it test101.txt
  3. Double click test101.txt and add enough random text to make it non-resident
  4. Repeat by creating a second text file – test201.txt and fill it will random text

The below screenshot shows data from Encase after this process

image

Now for the fun part

  1. Open a command prompt, and
    1. delete test201.txt
    2. rename test101.txt to test201.txt

The below screenshot shows data from Encase after this process

image

Notice the weirdness? The File Created timestamp of test201.txt is now equal to the File Created timestamp of the recently deleted test201.txt. What happened to the original timestamp of 09/01/10 16:10:27?

Let’s parse out the MFT record for test201.txt

The below are the timestamps from the Standard Information Attribute

image

They match what is displayed in Encase. And before you crucify Encase – be aware that these timestamps are in fact also used by Windows Explorer, so this is NOT an Encase-ism, it is an NTFS-ism.

The below are the timestamps from the Filename Attribute

image

Update2: Thanks to Kieth again for some further detail. I am experiencing two issues. One is the Safe Save tunneling mentioned below that explains why the File Created date remained the same. The second is standard NTFS behavior when it comes to renaming files, even on the same volume.

When renaming a file, the FNA timestamps are populated with the values from the SIA timestamps. Then the SIA timestamps are adjusted per the move process. I did not know this. Yay Kieth.

Be careful though, simply saying that the FNA created timestamp is different does not mean that deleting and renaming a file is the only scenario that can explain this behavior. I am simply using this as a repeatable demonstration that NTFS can change SIA and FNA timestamps unexpectedly.

Update: http://support.microsoft.com/kb/q172190 File Tunneling capabilities. This implements the old DOS Safe Save method – my test was done in Vista Sp2 64bit – isn’t it about time Microsoft cuts backwards compatibility somewhat?

Thanks Kieth and Jeff for the Microsoft information.

Posted in Forensics, General Research | Tagged: | Leave a Comment »

 
Design a site like this with WordPress.com
Get started