Wednesday, December 12, 2012

Utility to verify wipe/erase of hard drive


I was recently looking for a utility that I could use to efficiently verify the wiping of various types of hard drives. While there are many tools out there to perform a wipe or erasure of a hard disk, I really could not find many utilities that let me validate the erasure with some know technique.

For example, EnCase has a wipe disk function under the tools menu. Part of that process is to verify the wiping of the disk, but it's kind of a "black box" in that you really don't know what its doing to verify it. It either says verified or not. Many other tools do this same thing. They run some type of verification process but the technical aspects of what exactly its doing is somewhat of a mystery. I understand that there has to be  a certain amount of trust that we put into the tools we use, but we also need to validate our tools periodically.  If I plug in a drive and push a button and 30 minutes later the LCD says "wipe complete", I need to know that its doing what it says. You should be cross-validating all of your forensic tools on a periodic basis (once a year, major releases, etc.)

With the different types of drives commonly available today (magnetic spinning vs SSD), I wanted a quick, easy, understandable tool that I could use to verify the erasure of data from a drive. I wanted to use a tool where the technique used to verify it was understandable and verifiable so if I was using it to validate another tool, I was not relying on one "black box" to validate another "black box".

I finally settled on using a utility that calculated a sum of all bits on the drive. commonly referred to as a modulo sum or BSD checksum, it simply takes each byte on the disk and adds them together. at the end of the process, if your sum equals zero, then you can be assured all the input values were zero.

When searching for Windows GUI applications hat performed this checksum, I was disappointed to find only a few that performed this sum operation. Most did hashing and used algorithms that cannot be used for different sized disks.

I ultimately chose the BSD "sum" program (run in a Linux distro). One of the main reasons was the source code for that program is available via GPL and you can easily read and understand what its doing:


FILE *fp;             /* The file handle for input data* /
int ch;               /* Each character read. */
int checksum = 0;     /* The checksum mod 2^16. */

while ((ch = getc (fp)) != EOF)
  {
    ...
    checksum = (checksum >> 1) + ((checksum & 1) << 15);
    checksum += ch;
    checksum &= 0xffff;       /* Keep it within bounds. */
  }
from: http://en.wikipedia.org/wiki/BSD_checksum





Furthermore, since the source code is available, I was able to modify the code to print out the location on the disk where it read any value that was not a zero value. That way when the sum process was done, I could m, manually go to that portion of the disk and look exactly where the non-zero data was.

I would love to hear what other people are using to validate the wiping process and why?

(sorry, you have to have/create a blogger account to comment, anonymous spamming was getting out of control. You can email me your comments directly at lance (@) forensickb.com if you wish and I will add your comment.)

Wednesday, August 15, 2012

EnCase EnScript to verify LEF collection

I recently received an email from an old colleague Brian Olson. He wanted to share a recent EnScript he wrote and provide a detailed description in case others find it useful:

----------------------------------------------------------

One of the alternative methods of preserving digital evidence with EnCase is through an EnCase Logical Evidence File (LEF). Logical Evidence Files allow the examiner to preserve only the selected files from digital evidence, reducing the amount of data copied from a system while continuing to maintain the metadata and defensibility of the specific files preserved. 

LEFs are great alternatives in cases where a full disk image is not a viable option or it is not necessary to preserve the entire source device. Other EnCase products, such as eDiscovery and CyberSecurity rely on the LEF format to preserve digital evidence. Products like Symantec's Clearwell eDiscovery platform can process EnCase LEFs which helps maintain the file system metadata of the digital evidence from collection through processing and culling. An Examiner can also choose to use LEFs in situation where they are have large volume of data, such as a large file share, but only need to preserve a small portion of allocated data as evidence, like a specific user's home folder. Also, I find LEFs useful for extracting and transporting Malware, as AV will not try to clean a compressed LEF file. 

So what is a LEF and how does it work? LEFs differ from an EnCase Evidence File (E01) in that the LEF format only preserves the specific items identified by ether an Examiner or EnScript. When digital evidence is preserved into a LEF, each individual item can be MD5 HASHed and recorded. To further confuse the audience, LEFs can not only preserve files, but can also preserve data from other EnCase sources such as Records and Snapshots. For example, EnCase eDiscovery will preserve E-Mail from an e-mail source (i.e. Exchange) into a "Records LEF." 

However, there are some important things an examiner must understand about EnCase LEFs and their limitations. When EnCase preserves files into a LEF, only the allocated space of the selected files is preserved. This means the slack space or initialized space of the target files will be excluded from LEFs (possible with an EnScript?).

When EnCase verifies a LEF, it is validating the recorded MD5 HASH of each individual item with the items current HASH value, along with the CRC for each block in the LEF. There is no real HASH for the entire LEF, as we are used to seeing with full disk images. EnCase will report discrepancies through a dialog for CRC errors or by placing an astrik (*) next to the HASH in the entries pane for each item has a mismatched HASH.

Unfortunately, there is no report that an Examiner can export which explicitly says the items in a LEF passed verification and are valid. To assist with documenting the validity of of items preserved into LEFs, I've written an EnScript for verifying data collected in LEFs. The EnScript simply compares the MD5 hash of each individual file and records the results into a Date Stamped CSV file.

During the verification process, results are output to the console. A Final Report is including in the console upon completion of the job which details the specific LEFs that Passed / Failed verification.  Some known limitations of this EnScript is that it cannot verify EnCase Evidence Files (E01) or LEFs where the contents of files were excluded (Zero-Byte LEFs). 

Please send bug reports to dbrianolson (at) gmail.com

Download here (EnCase 6.18+)

Tuesday, July 31, 2012

EnCase EnScript to list and resolve all the file permissions on a drive

I recently had a need to create a list of users who had data on a disk. One of the solutions I came up with was to go through every file on the disk and look at the owner permission. Once I had the owner's SID, I wanted to get the corresponding username so I used the PsGetSid utility from Sysinternals.

To automate this, I created an EnScript wrapper to recurse through all the files on a disk, get a list of unique SIDs, then pass the SID to the PsGetSid utility, then create a Excel spreadsheet with the SID, username, total number of files that user has and the total number of bytes those files occupy.


The first time you run the EnScript it will ask where the PsGetSid executable is and then remember that for the future. The command line options are in case you are running this EnScript on a non-domain machine, but want to resolve domain SIDs. You can then specify a domain machine to query against by specifying a \\computername -u username -p password option as articulated in the psgetsid syntax help:


Usage: psgetsid [\\computer[,computer2[,...] | @file] [-u Username [-p Password]]] [account | SID]
     -u         Specifies optional user name for login to
                remote computer.
     -p         Specifies optional password for user name. If you omit this
                you will be prompted to enter a hidden password.
     account    PsGetSid will report the SID for the specified user account
                rather than the computer.
     SID        PsGetSid will report the account for the specified SID.
     computer   Direct PsGetSid to perform the command on the remote
                computer or computers specified. If you omit the computer
                name PsGetSid runs the command on the local system,
                and if you specify a wildcard (\\*), PsGetSid runs the
                command on all computers in the current domain.
     @file      PsGetSid will execute the command on each of the computers listed
                in the file.

To run:
Select (blue check) the files you want to process, then run. Once completed, the output will be in the console tab and it can then be selected and pasted into Excel (it's tab delimited). It will look similar to this:



Monday, July 23, 2012

Updated F-Response + EnCase EnScript = Powerful tool!

A little over two years ago, I was lucky enough to work with Matthew Shannon when he was beginning to develop the scripting object within the F-Response tool. At that time, I posted a proof-of-concept EnScript that used the scripting API of the F-Response tool.

Fast forward two years and the F-Response tool has only become better. Matthew has also enhanced the scripting capability of the F-Response client. These past two years have allowed people to realize the extreme power of the F-response tool when controlled through a scripting language. The COM object of the F-response tool can be controlled by almost any programming language that can "talk" COM. In my previous POC, I wrote a simple EnScript to show how to control the F-response client by installing it, starting it, connecting to it, then doing something with the target disk inside EnCase, then disconnect, stop and remove the client.

A recently updated version of my initial EnScript is provided below to demonstrate the F-Response scripting capability within EnScript and the amazing power of combining the two together. The example EnScript will connect to the specified remote host and simply search for the file named "pagefile.sys" and display some basic metadata in the console if it is found. While this example is a powerful example, your imagination is really the only limit of how you can leverage the scripting capability of the F-Response client within a scripting language, such as EnScript.



The previous version was compiled into an EnPack. This version is uncompiled and easily readable with a text editor. You can easily modify this base source code to perform additional functions.


Download here (EnCase v6) 



Monday, July 9, 2012

Safely and efficiently imaging a MacBook Air

I was reviewing some training material I put together today related to imaging MacBook Pro and MacBook Air laptops. I wanted to create a simple decision tree for the common scenarios when encountering Mac laptops. The basic breakdown was this:

  1. Remote imaging (really only used in corporate environment)
    1. Using SSH/SCP to load and start agent
  2. Locally imaging
    1. Target Disk Mode (easiest)
    2. Booting to external OS (CDROM or external hard drive) Used when device does not support TDM.
One of the discussion points was how to quickly and efficiently image the internal drive of a MacBook Air. While newer models have two USB ports (allowing an external CDROM and external HD), older models only have one. No ethernet, CDROM or firewire (TDM), so the common simple solutions are not available.

The simplest solution seems to be a large external drive that has a bootable OS on a small partition, but then a large second partition (FAT32 or NTFS) that can be used to hold the image.

Boot the MacBook Air by holding down the "option" key and selecting the listed bootable external drive. Once booted, you could use an imaging tool for that OS (OSX or linux) to image the internal drive to the external drive. 

This solution only requires a single USB port and seems to be the simplest method. Although I would recommend using a powered external drive, this should work with a bus powered USB external laptop drive as well.

Aside from pulling out the internal drive, I would be interested in hearing what other people are doing or have found to be the quickest/safest/most efficient way?


Monday, June 18, 2012

Forensic Process Lifecycle


Forensic lifecycle - DRAFT. This is not meant to be inclusive of every step or technique, but it was meant to provide a basic framework for teaching purposes. Feel free to comment below. (if the pdf does not display correctly, you can view it directly here).

Thursday, June 14, 2012

Windows 8 is coming....

Welcome back!

I wanted to write a quick post and say it was great to see so many people at CEIC this year. I have not been to CEIC the past few years, but it was great to see so many familiar faces.

I also wanted to thank so many of you that have emailed me to provide positive comments and encourage me to start posting on the blog again. I appreciate everyone's support and positive feedback.

After taking almost a year off from the blog I am ready to get back at it! I will begin posting new EnScripts and other articles that I find useful.

Thanks.

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles