While I do not believe there would be forensic procedure problems running multiple tools against a write blocked FAT32 disk at the same time is there something I am not thinking of? Never been trained on that and want to be sure.
Would like to use IEF 6.5 and EnCase 6.19 Case Processor @ the same time.
Thank you,
Mike
Prime Focus Forensics
Mike,
Q "While I do not believe there would be forensic procedure problems running multiple tools against a write blocked FAT32 disk at the same time is there something I am not thinking of? Never been trained on that and want to be sure. Would like to use IEF 6.5 and EnCase 6.19 Case Processor @ the same time."
A On my forensic stations, from my own experience, I am able to only run one tool at a time (IEF or OSForensics or Forensic Explorer) on a specific forensic image file.
I cannot explain the technical reason why each of my forensic tools requires sole control of the forensic image being processed (be it directly or as a mounted virtual drive), but there apparently is one.
In other words, I have to have more than one forensic workstation and copies of the forensic image files created (one for each tool being run) if I want to run two or more tools concurrently.
Regards,
Larry
Your main concern is changing the evidence. Assuming you have a properly functional write-blocker, that isn't an issue.
So, as far as I can think, the only issue with running multiple processes would be that the disk is forced to try perform multiple reads from multiple locations. So, things may slow down. Your keyword search may take longer.
Regarding why only one program can access a forensic evidence file, I think that is a Windows issue rather than a forensic program one. Just guessing.
While I do not believe there would be forensic procedure problems running multiple tools against a write blocked FAT32 disk at the same time is there something I am not thinking of?
Perhaps Windows. There is not one single way to access a device – there are many. And you can't really be certain that one tool opens the device in a way that allows for other processes to read from it – it could open with exclusive read access, preventing any other tool from get access — or getting locked out if another tool already has access. (If you want the details, check out the system call CreateFile(). I know that my own programming tends to the conservative, and I prefer to go for exclusive access just to keep things simple.)
Actually – I would rather expect a forensic tool to try to get exclusive access to the device.
Anyway, you can't philosophize about this, you simply have to test it out. Just make sure that you *have* tests to verify that it works. Otherwise, how can you say you have verified that it does work?
In particular, you want to make sure that there isn't any confusion about what process is reading what sector. If you read sector 312, you don't want to get sector 1045 due to a bug in the disk routines.
From an evidence preservation perspective, I don't think you have any problems assuming your write blocker works. From a performance perspective, you have a big problem.
Most tools already hammer evidence drives pretty badly during processing. I've seen EnCase throw 12 things at a single drive on my 8 core machines. Spinning platter drives can't handle this. Adding something else on top of that won't just make it half as fast, it will make it much, much slower than that.
If you're processing overnight, it might work to do this, but if you're around to kick off the next tool processing, it's faster to let one run and then start the next later.
Most tools already hammer evidence drives pretty badly during processing. I've seen EnCase throw 12 things at a single drive on my 8 core machines. Spinning platter drives can't handle this. Adding something else on top of that won't just make it half as fast, it will make it much, much slower than that.
Solution is obvious, however SSD is expensive and small in comparison to mechanical drives, you can use them when the material is small. Backing up a job can be done over lunch from SSD to mechanical drives in case of failure (which some SSD is prone to, since it is still a young technology), especially when running them in a raid configuration, and the original images/material always have to be stored on a mechanical drive (at least for now until assurance levels rise).
I have been using SSD extensively since the first generation, including PCI Express mounted SSD and the performance benefits are clear, but you have to be aware of its limitations and make sure you adapt the system accordingly. This is a problem that will solve itself when the prices starts to go down. For a corporation who do lots of numbercrunching like forensics, it is a necessary investment that will save lots of time and give a good ROI.
Since the conversation has moved to SSDs…
I've mostly solved the capacity problem by going with an array of SATA SSDs connected to a real RAID card (an Intel RS25DB080 in my case). With four 512GB SSDs (Samsung 840 Pro) in RAID 0 I can get over 1GB/s throughput, which is pretty damn good. Down side is I have to secure erase the drives regularly because the controller doesn't support TRIM commands. But, that's not formatted FAT32.
If you have a spinning disc drive as your evidence, just be mindful that throwing too much at the drive will make processing much, much slower. It's might be faster to image the drive to an SSD and then process from there unless you're doing something really, really simple.