XOR entire file or selected text

XOR is a common and simple symmetric encryption algorithm. It is commonly used by malware to 'hide' certain identifiable information in a data file or executable. It is a very simple algorithm, so there is very little processing power needed to quickly encrypt or decrypt data, making it a popular technique.

Some software vendors also use it to 'obfuscate' data. Norton Antivirus uses it to store identified malware files in the quarantine folder. When Norton AV detects a virus, it will XOR the virus with a constant key and then place it in the quarantine folder. I had previously written an EnScript to extract files from the quarantine folder in Norton version 7.5 so they could be examined in their native form. Norton also stores its logs encrypted using XOR (most versions). I wrote this EnScript specifically so I could quickly decrypt Norton logs within EnCase when doing an investigation so I could see what kind of virus activity had recently taken place, but then I quickly found other uses for the EnScript.

The EnScript allows you to simply highlight (highlight, not check) a file in the table pane (upper right) of EnCase and then supply a hex value as the XOR key.



You can have the resulting XOR data displayed in the console, or if dealing with binary data, such as with a malware executable, you can have the data written to a local file that you can then examine with some other 3rd party tool.

Download here (EnCase v6)

Export IE Internet History from unallocated for use with 3rd party processors

A user recently contacted me about an old v4 EnScript that was used to export Internet Explorer Internet history from Unallocated so it could be processed with NetAnalysis. She asked if I would update the EnScript to work with v6 since she explained that she used NetAnalysis with almost every case and they have become accustomed to the output.

I have updated the EnScript to work with V6. Simply select (blue check) and file(s) you wish to search for IE Internet History (Unallocated, pagfile.sys, hiberfil.sys, etc.) and then run. If any history is found, it will be exported to a file that can then be parsed by NetAnalysis (or other 3rd party tool).

Download Here

Ghost - Part Deux - How to detect its use

I decided to keep going a little farther with my research and see what I could come up with to detect ghost was used either in the past or to make an image that was being provided to an examiner. Plus, I had already shot half my weekend, so why not finish the whole thing off!

The first thing I will mention is the "fingerprint" that ghost can leave behind. A reader left a comment asking about using "-FNF" command line switch when making an image so that the ghost application does not mark the hard drive(s). I did not use the "-FNF" switch at any time when I made any of my images and as long as I used the "-IR" switch, an exact duplicate was made of the source disk each time and ghost did not modify the original hard drive. BUT, I was asked at the time ghost started up if I wanted to mark the hard drives with the following screen:



I answered "Continue without marking drives".

A hash baseline was taken of the source drive before ghost was ever used and the before and after hashes of the source remained constant regardless if I used the "-FNF" command line switch or not. When I did specify the "-FNF" switch, I was still prompted with the screen above. As long as I answered "Continue without marking drives" The original remained untouched.

By answering "OK" to the screen above, ghost DOES MARK ALL DRIVES it detects! Now obviously the source drive would most likely be connected via some type of write-blocking device so ghost would not be able to write this change to the source, but it may mark other drives connected to your system that you don’t want marked. If you do answer "OK" a "fingerprint" is placed one sector prior to the volume boot sector, typically at physical sector 62:



Once marked, ghost will stop asking the question at startup if you would like to mark the drives. I have not yet deciphered the “fingerprint” data written to this sector yet, but it appears the first dozen or so bytes remained constant between different markings, but the rest of the data changed each time I marked the drive, indicating some type of possible date stamp. When creating the image using the "-IR" command line option, if the source drive is marked, then the destination image will be marked as well.

The second part of my testing involved looking at how ghost copied files from one drive to a destination drive, either directly or through a ghost image file. If ghost was used with the "-IR" command line switch then ghost leaves everything in the same place as the original. My main focus was inspecting the changes with the default option of ghosting a source drive and then restoring it out to another drive like a typical user or IT professional would do. When I created a ghost image of a source drive and then restored that image, all the internal file system creation dates remained unchanged from the source's timestamps.



Looking at the screenshot above you can see the timestamps of the internal file system objects from the original drive have carried over to the ghost copy. This was true if I made a disk to disk image or a partition to partition image.

The only obvious artifact that ghost was used is the file extents field. The file extents field indicates how the file is fragmented. You can see in the original that the "Unallocated Clusters" object represents all of the unallocated clusters across the logical volume. In the source, there are 700+ "patches" of unallocated sprinkled around the drive. In the new ghost image, there are only three. The first is a small area consisting of 16 sectors immediately following the $AttrDef internal file. Then there is a large gap immediately following the $MFT, which is considered the "MFT zone" and is usually about 12.5% of the volume size. This area is reserved for use by the MFT as it grows. Immediately after the MFT zone are all the other remaining files on the volume, with no unallocated gaps in between them. Not all files are contiguous on the ghost image, but there are no files with unallocated before or after, except the ones I mentioned. The following screenshot is of the original source drive showing obvious signs of fragmentation:



Here is another contrasting example by viewing the file extents of the Unallocated Clusters object:



The newly ghosted drive only has the three aforementioned areas of unallocated space. There are still files present on the newly created ghost image that have multiple file extents (fragmented), but there are far fewer than on the source drive. This screenshot is of the drive that received the ghost image:



Summary:
Although there are a few indicators such as the presence of the "fingerprint" that indicated ghost has "marked" that drive at some point in the past, there is no surefire way to detect the use of ghost with certainty. As indicated above, the lack of unallocated area being fragmented around the drive would certainly be suspicious, but as the system gets used after a ghost image was restored, the system will begin to fragment like before, and so it will depend on the timing of the seizure. I would certainly look at the timestamps on the internal file system files, coupled with the date in the registry as to when the OS was installed to give me an idea of how long that file system and OS have been operating and then compare that with the absence of file fragmentation to help support the idea ghost was used.

Video demonstratinig adding an uncompressed ghost image file (.gho) into EnCase and then manually adding the VBR to have EnCase parse the volume then you can image like any other device.

Ghost as a forensic tool

If you have not figured it out yet, I read several forensic listservs (great way to learn and kill half my weekend ;) and I often find myself picking a topic I read about on one of the listservs and then blogging about that topic.

So this weeks topic is about using Symantec's Ghost utility as a forensic tool. The ghost utility has been around for many years and is most commonly known for and used by IT professionals to create baseline images of workstations and servers for quick deployment. I doubt that at its inception, that ghost was ever designed to be used as a forensic tool. But somewhere along the way, Symantec added some functionality into the ghost utility to make "forensic" copies of hard drives specifically for law enforcement purposes.

Many years ago I remember going to training and hearing that ghost was an unacceptable tool to use to create a 'forensic' copy as it did not create an 'exact' image and changed a few bytes so you would never get the same hash as the original. I remember performing an exercise and creating a ghost image and comparing the hash values of the original and the ghost image to see that they did not match. As I mentioned, somewhere along the development path of the ghost utility, the ability to make an exact forensic copy was included. The best I can tell, it started with ghost v5.1, circa 1999. From the "Whats new.txt" included with that version:

"-ID (Image Disk) is similar to -IA (Image All), but also
copies the boot track, as above, extended partition
tables, and unpartitioned space on the disk. When looking
at an image made with -ID, you will see the unpartitioned
space and extended partitions in the list of partitions.
The -ID switch is primarily for the use of law enforcement
agencies who require 'forensic' images."

Then in Ghost 2002, the command line switch "-IR" was included:
"-IR The image raw switch copies the entire disk, ignoring the partition table. This is useful when a disk does not contain a partition table in the standard PC format, or you do not want partitions to be realigned to track boundaries on the destination disk. Some operating systems may not be able to access unaligned partitions. Partitions cannot be resized during restore and you need an identical or larger disk."

(ftp://ftp.symantec.com/public/english_us_canada/products/ghost/manuals/ghost2002.pdf)

So what do these command line options do and which is appropriate to use?
I have tested several image files created using the various ghost command line switches and here is a summary:

-ID
This command line option appears by description to create a bit-level image (they call it a sector-by-sector) and it in fact does. If an hard drive image is created using the "ghost -ID" switch, then a bit-level image is created. The problem with this switch comes when you restore this image back out to a hard drive. This switch will cause ghost to adjust the partition boundaries on the destination drive if they are not standard. So for example, if the source HD has 32 sectors per track (SPT) and ghost image is created, when the image is restored back out to a hard drive, ghost will adjust the partition boundaries if the disk geometry is different on the destination drive and make appropriate changes in the partition table. This will obviously result in different hash values being generated. This command line option is configurable in the actual ghost application under the options->Image/Tape tab:



-IR
This command stands for "image raw" and it too makes a bit-level image resulting in an exact duplicate. The difference in this switch is that ghost will ignore the disk geometry on the destination drive when the image is restored and create the image exactly as it was on the source. An image created with the -IR switch will result in the same overall drive hash as the original, ASSUMING it is restored out to a hard drive of the same exact size. This option does NOT appear in the ghost options tab and is a command line switch only.

Ghost (with any switch) DOES not make an image file (.gho extention) that is a raw bitstream image like 'dd' does. A look at a ghost image file in a hex editor will show you that there is a header with information that ghost uses to restore the image correctly and was not on the source drive, typically the first six sectors of the image file. Then the actual bitstream copy of the source drive follows and the footer used by the ghost utility is at the end of the ghost image file. Ghost allows you to compress the image of the source drive when the image is made. This has no effect on the data when it is restored; it only affects the data as it sits in the ghost image file (.gho).

The only appropriate command line option for use when making a forensic image is the "-IR" option. Although not a common forensic tool and often believed to be unacceptable for forensic use, current versions of ghost can make an exact duplicate of a hard drive when the -IR command line option is used.

The only other problem is that there is no easy way to tell which switch was used when the image was created. If you try and look at an image that was created with the -ID or -IR switch with Ghost Explorer, an error message will appear stating that one of those command line options was used, but does not tell you which:



If you look at the details pane when restoring the image, a disk image created using the -IR command line switch will say "RAW DISK IMAGE":



An image created using the -ID command line switch will just show the file system type:



There is also no way to validate the image's integrity. I opened a ghost image file with a hex editor and erased several references to a file and ghost happily restored the image without reporting an error. Since there is no way to generate hash values for blocks or the entire HD source from within ghost, you would have to take a baseline hash BEFORE ghost is used. Then when restored that baseline hash could be compared to the restored drive hash, again using an external tool outside of ghost.

To summarize, the important things to remember if you are using ghost to create an image or if you accept a ghost image are:

If using ghost to create an image:
Create a baseline hash of the source drive before using ghost
Use ghost with the "-IR" command line switch
Make a ghost image of the "disk" not just a partition
Hash the .gho file for reference (convenience)

When accepting a ghost image file:
Ask for documentation on which command line switches were used
Verify via the details pane when restoring the image
Verify it is an image of the entire disk, not just a logical partition
Ask for a baseline source hash from before ghost was used
Verify the restored image hash to the baseline

*Note - all testing and screenshots were done using ghost 2003.