Indexing & Physical drive

[e.eis]

Hi. Thanks for this fantastic program.

I've two questions:

1) It's possible to "Create Index" of entire Physical Drive? (In the cascade list is listed only a letter associated at the logical partition. Example: "C:\" "D:\"...)

2) It's possible to allow multiple sessions of indexing?

Thanks.

[David (PassMark)]

You can only index 1 volume at a time in a single instance of OSF.

But you can run multiple instances of OSF to index multiple drives at the same time.

Doing this makes a lot of sense if you have a multi-core CPU and multiple hard drives. But if you have one slow hard drive with multiple volumes on it, then indexing both volumes at the same time can lead to a lot of additional disk seeking (not an issue on a SSD however, as seek times are very low).

[e.eis]

Hi, I tried to create two instances of OSForensic, but indexing engine goes crazy and crashes often.

[Michael (Passmark)]

When an index fails it should generate a log file at the following location under your user documents folder.

PassMark\OSForensics\lastfailedindexlog.txt

Could you email this file to us at the details listed on the contact us page.

[mcaley]

Interesting indexing results

I am evaluating this program for use in education programs and I'm having an issue indexing unallocated space. I used this program to break the password on a test zip file and was very impressed with how fast it brute forced a 6 character password. I then inserted the password into the unallocated space of a test image and I started running into some issues. I can't seem to get unallocated sectors added to the index. If I select for the index to run over files and unallocated it only indexes the files. If I run only over unallocated it appears to work as it has 166 unique words, but will not save the index because no logical files were indexed. I just wanted to test running the index against the zip as it is one of my favorite features of another forensic suite. Am I running into a limitation of the free version?
I've tried running it over the mounted image and over the USB drive I cloned to create the image with the same results.

[David (PassMark)]

In Step 2 of the index creation, are you selecting a 'whole drive' or just a folder?
How full was the drive to start with? Doesn't sound like there was much unallocated space.
Was the USB drive FAT or NTFS formatted or something else?

At the end of the indexing process, it should be possible to click on 'Open log' to see what was actually indexed. You can then right click in the log window to save the log to a file. It might be helpful to E-Mail us the log for this test image.

but will not save the index because no logical files were indexed

This would normally mean that no files AND no unallocated clusters were found.

[mcaley]

I am selecting whole drive in step 2. The image that I am using has two text files on it so the majority of the drive is unallocated space. The image is 247 MB in size. It is formatted FAT. It is a full .dd image with unallocated. I can view it in a hex editor. This is also how I implanted the password into unallocated space.

As for indexing unallocated, I would understand the results if no unallocated clusters were found, except for the fact that it reported 166 unique words found. Where did the words come from? I'll email the log file and some screen shots.

[Ray (PassMark)]

We have investigated this and can now confirm that there is a bug in the unallocated clusters indexing function in the current release (v1.0.1005)

This has been fixed for the next release. Thanks for bringing it to our attention.

[David (PassMark)]

There is a beta release of OSF V1.1 that should now address this issue. Any feedback would be welcome.

[htp1]

I think many people will have time-intensive processes, such as indexing, run overnight while unattended. If you could allow configuration of indexing so that while it only does one partition at a time, it could do multiple partitions or drives in a serial fashion. In the interface this could appear as a check box of the partitions and drives associated with the case, instead of the current drop-down. I think such a modification would be widely appreciated, as it would save time and the need to check on the progress of an indexing session just to be aware of when it was time to start the next session for the same case. I have few cases that have only one partition or drive that needs to be indexed; most cases have multiple partitions and drives that must be indexed.

[David (PassMark)]

Thanks for the suggestion. We have made a note of it.

What you can do in the current release is run multiple instances of OSF to index different data at the same time. This should work well in the case where you are indexing different drives. In the case of indexing different partitions on the same drive, it can still work, but can lead to thrashing the disk a bit. That is to say the indexing process spends some of its time seeking between the 2 partitions rather than doing any actual indexing. But with more and more people using SSDs, which have very low seek times, this becomes less of an issue.

If you investigating disk images, (and not physical drives) then it can make sense to get the image on to a SSD before you start (if it will fit). A SSD with a multicore CPU will be able to handle a large number of parallel tasks.