ProDiscover Problems

Video Summarizing the Problem

Response from Creator of ProDiscover

I don't completely understand the explanation--it doesn't seem like this is the whole problem. But I'll be very interested to see the updated version and test it.

We have reviewed and tested the issues you reported. The first issue is problem with reading first two clusters in FAT12 partitions. In FAT12, cluster numbers start with 2, the 0th cluster being the boot information and the first cluster is directory structure. We were not handling them properly in that we were only reading first 512 bytes (one sector) of these group of sectors and displaying information. We have fixed this issue by handling reading logic for the first two clusters.

The issue with the logical floppy secure wipe was that we are using a third party algorithm to erase logical disks, to be DoD compliant for logical secure wipes. This "canned algorithm" is creating problem. Suppose, a file of 512 bytes is saved, then it occupies more than one sector on the disk. The algorithm we were using is only erasing 512 bytes. We have corrected this and will round the file size to the cluster boundary, which will fix the problem. BTW, the logical secure wipe is an old concept (as old as floppy disks) of writing random data to a logical file system. This process is only provided for DoD spec requirements and is not recommended for use in Forensics. I would always recommend wiping a disk at the physical level with a known pattern. This process ensures that you wipe any unallocated/slack space ad is visually verifiable.

Thank you for taking the time to report these issues. They are both corrected and will release with the next product update.

Christopher L. T. Brown, CISSP, DFCP
Technology Pathways LLC
Founder & CTO

Details of Other Tests

1. Cluster Contents Incorrect
2. Failure to Wipe Floppy Disk
3. Using Windows XP and a Real Hard Disk
4. Downloadable Test Images

Vendor Notification

Cluster Contents Incorrect

http://old.honeynet.org/scans/scan24/

I am using Windows 7 in a Fusion virtual machine, on a Mac OS X host.

I downloaded it, verified the MD5, and unzipped it.

Here's the MD5 hash of the unzipped image.dd raw file:

I started ProDiscover Basic and loaded the image.dd file.

Here's the version of ProDiscover I used:

I viewed the image.dd file in Cluster view, which shows the raw data in hex.

Here's the first sector--the MBR:

Here's the second sector--the start of the FAT. It begins with the three bytes F0 FF FF, as explained here:

http://chenpro.com/Comp_Virus/structure_of_disk.htm

This article tells me to expect the second copy of the FAT in sector ten (0A in hex):

http://www.eit.lth.se/fileadmin/eit/courses/eitn50/Projekt1/FAT12Description.pdf

But this is what ProDiscover shows in sector A--the F0 FF FF is not there!

I tried a Search to find it:

The results say it should be in cluster A.

What's going on? I opened the original image.dd file in HxD, a simple hex editor.

Here's sector 1, starting with the F0 FF FF:

Here's sector 10, starting with the F0 FF FF:

HxD also shows that all the sectors between 1 and 10 are empty--filled with 00 bytes.

But ProDiscover shows them filled with data, like this:

What's going on? What am I doing wrong?

Failure to Wipe Floppy Disk

This procedure was recommended here:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002195

I connected the virtual floppy to a VMware Windows 7 machine, formatted the floppy, and filled it with text files containing many repeats of the word "SPAM":

HxD shows the SPAM on the floppy:

I used ProDiscover Basic's "Tools", "Secure Wipe" function:

I expected the disk to be zeroed, but that's not what ProDiscover did.

The MBR is still there:

The first FAT contains the F0 FF FF mark, but nothing else:

The second FAT also contains the F0 FF FF mark, but nothing else:

The root directory still contains most of an old filename "SPAM.TXT":

This might seem like a small problem, but it's not! The "Secure Wipe" did not erase all the data, it just overwrote the active data. Here's what ProDiscover did to the contents of the SPAM files:

Now let's test this using a floppy disk with a corrupted FAT, which I got here:

http://old.honeynet.org/scans/scan24/

This floppy contains data of a potentially sensitive nature.

Here's some sensitive text:

Here we see the end of a JPG image, with the end-of-file mark FF D9, followed by a password:

(I redacted the image to avoid interfering with students doing the Honeynet challenge.)

I ran the ProDiscover "Secure Wipe" on this disk, and here's the result:

The text has been overwritten:

But the other data remains on the disk:

(I redacted the image to avoid interfering with students doing the Honeynet challenge.)

This is not a proper forensic wipe at all!

Using Windows XP and a Real Hard Disk

I made an 8 MB FAT-16 partition on the disk:

I filled it with SPAM:

It's almost completely full:

The directory structure for FAT-16 shows that the starting cluster is at an offset of 0x1a, starting from the first character in the filename:

Here's the directory, viewed in the HxD hex editor.

The directory entry for the SPAM.TXT file starts at byte 10080 with the file name.

Bytes 1009A and 1009B contain the address of the first cluster. Right now they hold 02 00.

In the hex editor, I changed byte 1009A to 00. This creates an incorrect cluster number of 00 00.

I made a new project in ProDiscover and added the physical hard drive.

ProDiscover now shows sector 2 filled with SPAM, which is incorrect.

Here's the sector that contains the directory. ProDiscover incorrectly reports it as full of SPAM.

Here is HxD, showing the correct contents of sector 2 (all zeroes):

Here's the actual directory on the disk. It's not full of SPAM, of course.

Thanks to "var x" for help with the hardware.

Downloadable Test Images

To use them, do these three steps:

1. Download & Extract

Each archive contains a text file with hashes to verify accuracy, if you wish to.

NTFS-1.dd.7z       NTFS-1.E01.7z

2. View in ProDiscover

3. View in Another Tool

FAT32 Test Images

FAT32-DD.7z       FAT32-E01.7z

How These Images Were Made

Then I converted that disk to NTFS with the Windows command-line tool CONVERT to create the NTFS sample partition. I acquired it with FTK Imager.

Thanks to "varx" for the idea to CONVERT the disk.

Vendor Notification