Encase 6.8 Date off 47 Days

"How can 3 recovered deleted internet searches show the exact same timestamp within Encase?"

Lastly, was the time and date correct on the computer system at time of examination?

Please bear in mind this is not my field. I will do my best to answer.

The files were recovered from a recovered folder which had been overwritten by windows.
The web browser was internet explorer.
The ie history does not contain these searches.
The computer was off one minute from GMT according to the TI so that is a minor issue when we are discussing 47 days.

In other words, there is a difference of 47 days from the time the local TI says the search was made to the actual date.

Without any actual details, it seems inconceivable that two investigators (presumably reasonably experienced), looking at the same evidence, would come up with that kind of difference between them . The only possibility I can think of is that either (or both) used a tool that didn't translate the time stamp(s) correctly, but on the other hand it is almost standard procedure to double-check important evidence – i.e. both reports are expected to explain how the double-checking was performed.

The first impression is that it whould be easy for each of the investigators to repeat the other investigator's work (with the same tools, if possible), and verify that they do get the same data. (Or even a third party.) If so, things would become a bit clearer – and if they can't, they would have become a lot clearer.

One possibility (again, in the absence of tehnical details) appears to be that they *aren't* looking at the same evidence. One is looking at one set of time stamps, the other at another. That also assumes some degree of lack of professionalism, as it suggests that the results can't have been properly double-checked, but I hope it's clear I'm more or less guessing here.
But the reports should be reasonably clear as to what the sources of the information actually are – they should not just make it look as if the information had appeared out of thin air.

Athulin hit the nail on the head.

For an investigator to not use a secondary tool to verify times and dates is quite irregular and any evidence prepared to report level would normally be checked with a fine tooth comb (Normally). For there to be such a large time discrepancy then either the tool used to perform the time and date analysis is misreporting due or unreliable. Or the data from within the file is being misinterpreted.

If it is IE then it is likely the file containing these internet search hits is in fact an Index.dat, this is a database fie used by IE to manage browsing functions including the browsing history.

This page will clarify at a basic level the time and date stamps within an index.dat file

http//www.stevebunting.org/udpd4n6/forensics/index_dat1.htm

To answer the last part, I have never ever come across this in any examination.
?

We have absolute evidence of multiple perjuries by prosecution witnesses. Not he said, he said but irrefutable evidence of perjury in areas other than the computer. Not mistakes, perjury.

If this is true then why are you wasting time trying to disprove anything the computer examiners have said?

All I can see (figuratively) are red flags popping up all over the place.

If this is true then why are you wasting time trying to disprove anything the computer examiners have said?

I don't feel this is a waste of time.

Something related happened in Texas where a (non-computer) expert was shading his testimony and many innocent people went to prison. It screwed up their local justice system something fierce.

Now if Encase 6.8 really caused three overwritten files to be off 47 days, isn't that worth noting? Since no one on the forum responded that they had seen anything remotely similar, I would think that would be worth investigating.

But if Encase isn't responsible, you can imagine where that leaves us.

You would be better served by asking your independent expert who examined the images to come to these forums and pose the questions.

I feel there are some vital details that you are not conveying simply due to being unfamiliar with the software and the forensic processes.

But again, if the prosecution case has already involved perjury which you can prove, then anything else is irrelevant because the case will fail when you and your legal representative prove this perjury.

Based on what you've told us here the only evidence on the computers they are referring to is the alleged Google searches.

Their expert says one thing and yours says another. If both are indeed experts and accepted as such by the court then the Judge will take both their testimony on equal value and then will be forced to look at the remainder of the evidence to make a determination. If the prosecution have lied and you say you can prove it, then you will win.

I also gave you the hint that you can look at getting evidence directly from Google. If you didn't make those searches when they say you did then Google have the records that can prove it. Simple application to the judge to get the information from Google may get what you need, according to the media here in Aus Google is quite co-operative with the system over there.

You are fixating on trying to prove EnCase is at fault and ignoring everything else which can help you.

If the data is overwritten then you can not recover it - its gone (full stop).

If the data has been deleted and the index records that refer to it have been overwritten then it may be recovereable. The problem then is that you often need to make assumptions as to what the data is, in laymans terms by looking at the structure for known patterns. The problem, in this scenario, is that the space occupied by the file is now in a great mass of data known as unallocated and it is not impossible, or that unusual, for data from one file to be immediately followed by similar looking data from another. If you put them together you can get odd results.

You need to post examples though - if you base ANYTHING on what you read on here from your (self confessed) amateur interpretation of the reports/evidence then all you are getting is educated guesses. If your account of the facts is wrongh in anyway then any answers will likely be wrong.

A few things

a) This is an ongoing case, right? Bear in mind that this is a public forum. Also bear in mind any allegations you might want to make (or not).

b) Saying "there is a lot of log rolling" in relation to statements about Police corruption is a good way of annoying a lot of people who might otherwise help.

c) This is not the place to find validation for your personal ideas about what might and might not have happened to your data.

d) This is surely something for both of your experts to figure out between themselves or, if they can't, in court.

Having said that editing an Internet history record is not simply a case of changing the file time on a bunch of files. Browsers almost always store these dates and times in a database - which is not easily editable.

The following is just a possible guess as to why these dates may have been used. Please do not take this information as being the definitive answer or any form of legal advice as without the full information it is not possible to say 100% that the following is correct. However, I believe this explanation would be more likely than someone tampering with the evidence.

The dates are quite possibly correct but it *may* be that their interpretation to the data they relate to is incorrect.

When a file is identified by EnCase as being overwritten then it has identified a deleted file where the MFT entry (assuming NTFS) has not been overwritten but the file data has (or at least the starting cluster has). EnCase is showing that the pointer exists even though the file does not. The MFT entry will contain the date, filename, etc of the original file. However, the location of where the pointer is pointing will likely contain data. It is possible that this data (or at least some of this data) has nothing to do with the original MFT entry. If you have a copy of EnCase open and point it at an overwritten file you need to look at the bottom of the EnCase window to see the path of the file that actually now occupies that location.

A very crude example that makes a number of assumptions is shown below

* "history.file" is created on 01/01/2013 and a search for "forensics" is run
* Number of days elapses.
* "history.file" is deleted (maybe by the user or part of browser cache cleanup)
* New "history.file" is created on 07/01/2013. It happens to use the same location on disk as the original "history.file".
* Later on that day a search for "not forensics" is run
* On 08/01/2013 the computer is imaged & examined

EnCase sees the "history.file" generated on 01/01/2013 as an overwritten file and recovers the date etc from the MFT entry. The data it is pointing to happens to belong to the new "history.file" created on the 07/01/2013. Initial look at the overwritten file entry *may* give the appearance that the search "not forensics" was run on 01/01/2013. However, a look at EnCase to find the overwriting file should provide a file with the correct date, i.e. 07/01/2013.

Examination of any dates contained within the data (rather than the MFT entry) will also help to corroborate or disprove anyone's assertions.

The created date of a history file may not be the date that your search was run. e.g. a history file could be created 2 weeks ago and constantly written to. The created date and last written date may provide a time frame when your search was run but not an actual date and time.

This is all just hypothetical theorizing and you really need to get your expert to actually check this information. The above may not be applicable in your case as I have had to make a number of assumptions (e.g. that you are referring to the dates contained within the MFT entry) as to what you or someone else has seen.