Hi Rich2005
I'm not a computer forensic expert or an Encase user. All I know is that this was a key piece of evidence based on the time of a chat log. The prosecution presented the time of that chat log as evidence but the defendent then produced evidence that he could not have been using a computer at that time. Just before the trial started the prosecution then claimed that the time stated for that chat log was incorrect due to a bug in the Encase software they used to examine the computer. They claimed that the bug had caused Encase to make an incorrect adjustment from BST to GMT, adjusting in the wrong direction, resulting in a 2 hour error.
The judge accepted this claim, however the defence disputed it saying that if their was indeed an error, it was human error on the part of the forensic expert, who happened to be a police officer.
Is it possibly a bug or is it most likely human error. As I say, I have no knowledge of the workings of Encase, and neither of course did the judge and jury. Does it even make an automatic adjustment.
Yes it has to account for timezone/DST changes, so it's perfectly feasible there was a flaw in how whichever offset was applied by the software was done, if of course we're talking about the timestamps of the file rather than within it. Without knowing the facts obviously it could be either human error or the software, you can apply whatever timezone settings you want, so that could have been done wrong, or the software may have had a fault with it's implementation of the timezone/dst offsets.
Then, like the opening post say, doesn't this bring the whole integrity of Encase into question
You shouldn't where reasonably possible rely on any software 100% If there's one thing that you can be confident of, with any reasonably complicated bit of software, there WILL be bugs. So ideally the people at the time perhaps would have verified their dates and times with another tool and/or manually. But lets face it the reality of the world is that extra verification might get overlooked in a time/budget pressured world. (i'm not saying that's right - but may just be the case). Although I would also probably argue that EnCase should do more testing of releases against various data sets prior to each release.
As I say though, once an issue was identified, if the prosecution have acknowledged/identified/explained any offset timewise there shouldn't be an issue again. Though as I say ideally you'd have a defence expert to help confirm what actually was the case.
Hi Rich2005
Is it possibly a bug or is it most likely human error. As I say, I have no knowledge of the workings of Encase, and neither of course did the judge and jury. Does it even make an automatic adjustment.
Good question. I know a few investigators that have passed off errors as 'software bugs'. I would say get him to repeat it and show how to replicate it yourself. If he can't or won't you may have your answer…
Can I just make sure that we are all singing from the same hymn sheet?
I understood, from the EnCase info, that the bug/feature/phenomenon applies to LEF (Logical Evidence Files) exhibt.L01 not to image files exhibit.E01.
Is this correct?
Then, like the opening post say, doesn't this bring the whole integrity of Encase into question
Integrity is a property of people, not software.
At the risk of flaming, this thread is ridiculous. Someone somewhere had some case where some timestamp in some format on some filesystem in some evidence from some computer running some operating system set to some timezone using some form of daylight savings time adjustment interpreted by some examiner's computer running some operating system set to some timezone using some form of daylight savings time adjustment parsed by some version of some tool may have been off by an hour, and therefore there's a bug in the tool???
I'd need to understand and control for all these variables, doing lots of experiments, before commenting, let alone testifying.
Jon
Jon, thanks for your response on this matter.
There are many meanings of the word integrity. It is not just a property of people. Integrity can be applied to many things. In computing terms I see no reason why it can't be applied to software or data, to mean consistency and free from corruption.
I understand from your reply, and your comments earlier in this thread, that there are a number of variables that need to be considered. In fact this has been an education to me and I much appreciate your input. However surely if there was a bug within Encase that produced a 2 hour error, as suggested by this computer forensic expert, someone on here would have heard of it by now.
Right on Jon. There may be all sorts of errors, flaws, omissions, misleading and poorly understood facts that could lead to an incorrect and unsupportable conclusion. But we do not have enough to go on here.
I think the question is a valid question, but it requires an expert analysis of all the facts and issues involved. Even if the error or flaw exists or an examiner error is involved it sounds like the prosecution has identified and explained it to the satisfaction of the judge. The proper analysis of the facts sounds like it is obtainable, but the lack of an opposing expert potentially prevented that from occurring.
Maybe the EnCase bug or examiner error was an issue in this ruling but it would require more data and facts for an expert to get to it in my opinion.
However tools have faults, examiners make mistakes, but these can be overcome by knowledgeable examiners what ever side they are on.
Then, like the opening post say, doesn't this bring the whole integrity of Encase into question
Integrity is a property of people, not software.
<<<snipped>>
Jon
However surely if there was a bug within Encase that produced a 2 hour error, as suggested by this computer forensic expert, someone on here would have heard of it by now.
I wouldn't make that assumption either. D It makes sense to ask, of course, but careful testing would reveal the truth. I once discovered what I believe was a +/- 1 hour bug in OLE timestamps (old-format MS Office docs); I've never seen anything about this before or since. Sadly, I did not write things down and validate at a later time.
Jon