Hello all,
I am new and have never been involved in a real forensic case. Anyone ever have their tools challenged in court based on the OS or service pack the tool was designed to run on? Like if you have a tool designed to run on XP SP2 and on your forensic machine your running SP3. Even though the tool may run perfectly fine, but the vendor won't come out and say it works fine.
But at the same time, if you are not up to date with OS patching on your forensic machine can that be brought against you as well? I appreciate the help.
I am new and have never been involved in a real forensic case. Anyone ever have their tools challenged in court based on the OS or service pack the tool was designed to run on? Like if you have a tool designed to run on XP SP2 and on your forensic machine your running SP3. Even though the tool may run perfectly fine, but the vendor won't come out and say it works fine.
I have been asked such questions in Court and in deposition as part of a Daubert challenge. The issue goes to the second of the two Daubert test prongs reliability. Reliability includes such things as whether the process followed was accepted by your peers and whether it is reproducible. If you use vendor supported configurations, you can usually address the reproducible part because, presumably, supported configurations are tested configurations.
But at the same time, if you are not up to date with OS patching on your forensic machine can that be brought against you as well? I appreciate the help.
That would depend upon whether the patching involved vulnerabilities which could otherwise corrupt the evidence. For example, there have been at least a few instances where hardware/software manufactures have released firmware/software fixes to address known problems with acquisition. If you don't apply these prior to acquiring your data you may be challenged. I've been asked to provide not only serial numbers or license numbers, but also software and firmware revision numbers.
On the other hand, patching in the middle of a case can be problematic and there are better ways to protect your system, like making it standalone, which help to mitigate the most serious risks.
Unlike companies like Oracle, for instance, which typically identifiies not only the OS but the mandatory service packs/hot fixes, many vendors only say the version of Windows supported, without a complete list of tested hotfixes. This makes sense as there can be hundreds or even thousands of patches/hotfixes in the life of a Windows system and it would not be practical to test every possible configuration. Instead, it is more practical to identify when patches/hotfixes cause problems which is why I wouldn't add to my problems by applying these during a case unless I had no choice.
If you are new at this, the most important thing that you have is your credibility. If someone asks you why you chose to use an unsupported configuration when a supported configuration is not a hardship, how do you respond in a credible manner?
Best thing to do is to stick with tested, supported configurations and patch only what and when it is necessary.
Thanks a lot for your advice, i will keep it in mind.
I'm no professional, but I don't understand why would you need to patch anything if you are working from an image? I thought forensics was done outside any OS anyway, so you shouldn't be using tools that depend on an OS right? Courts actually rely on user mode tools? That is nuts, because anything could change, perhaps without you even knowing. Viruses could be running mad and infect your tool and perform many actions unsuited for an investigation. It is like conducting an investigation in the middle of a crowded room. I don't see any purpose to run *inside* their image, it seems sketchy to me.
I'm no professional, but I don't understand why would you need to patch anything if you are working from an image? I thought forensics was done outside any OS anyway, so you shouldn't be using tools that depend on an OS right? Courts actually rely on user mode tools? That is nuts, because anything could change, perhaps without you even knowing. Viruses could be running mad and infect your tool and perform many actions unsuited for an investigation. It is like conducting an investigation in the middle of a crowded room. I don't see any purpose to run *inside* their image, it seems sketchy to me.
In the question you should consider yourself to be working outside your image, but you still have to work on something. ( Well, I guess you could print it out and do it by hand …. ) It is this examination machine that is in question. Lets not make any accusations pointed at any particular manufacuters, but it has, in the past, come to light that perhaps certain software or hardware doesn't perform as expected - thus any results derived from these particular versions would be useless. I know of many examiners who will use multiple versions of a given package because one version will do one thing correctly, where a later version doesn't and vice versa.
Generally, it is considered good practice, as mentioned above, to have examination machines as stand-alones, in lockable rooms, so as to minimise the question of outside actors such as hackers &/or viruses. It is also good practice to have an AV running on your examiniation machine just incase.
At this point, I'd also add that best practice dictates verification of results using multiple alternate tools, so hopefully you could defend anything in court in any case, prefarably from first principles at a byte level.
It is becoming less unusual to work *inside* images, but these are contained in virtual machine environments, where, effectively the machine is isolated from the operating system. In such cases, I'd say that best practice dictates the same precautions of being off the network, controlled environment, current AV on the host and relevant patches for functionality applied to all software &/or hardware in use.
I hope that clarifies slightly ?
I can tell you from experience that VMs do not act like real machines in all cases. For instance, you might have a driver that reads the HD quite well but on real hardware it bombs. Some and probably all VMs do not support PCI devices and if they do they certainly do not support RAID controllers.
My point is that you need software that boots the system (theirs would be best) into a known operational state (let's say real mode to make disk access easy) which can read your image and grant you low-level byte access to the image (on real-hardware) where the MFT (or FAT, or whatever) can be analyzed to find everything you need to know to allow you to piece together the FS and create a time line of events based on timestamps.
Basically you need a boot loader and a kernel that acts like a disk editor which runs on real hardware and can read but not load your image.
I can tell you from experience that VMs do not act like real machines in all cases. For instance, you might have a driver that reads the HD quite well but on real hardware it bombs. Some and probably all VMs do not support PCI devices and if they do they certainly do not support RAID controllers.
Worse - some malware now detects VMs and behaves accordingly -/
My point is that you need software that boots the system (theirs would be best) into a known operational state (let's say real mode to make disk access easy) which can read your image and grant you low-level byte access to the image (on real-hardware) where the MFT (or FAT, or whatever) can be analyzed to find everything you need to know to allow you to piece together the FS and create a time line of events based on timestamps.
Why not just create a copy of the disk and boot on the original hardware ? This is the only way that you can know for sure that you are seeing the same things.