Has anyone heard of a bug in EnCase which would alter file times? I am working on an appeal which hinges on an alibi where the original prosecution report states that file access times were an hour later than on the image, and specifically that this has been changed by a bug in EnCase. No forensic expert was called to rebutt this and the client was convicted pretty much on this statement.
This doesn't make a whole lot of sense. MFT timestamps are in UTC. For viewing purposes, EnCase (and other software) allows you to set the timezone so that the MAC dates are displayed in local time.
It is possible that there could be a flaw, here, but to actually change the MFT timestamps would require that EnCase altered every MFT record.
Not very likely.
In any event, as others have mentioned, you can always carve out the MFT records, yourself, and use something like Craig Wilson's decode to get the UTC times then apply the offset, yourself.
As an aside, I ALWAYS do that as a sanity check. That is to say, I always confirm the displayed timestamp with the timestamp in the MFT just to make sure that they match.
Really to emphasis what Sean is saying - there is no reason in 2011 for someone doing forensics not to have multiple tools for checking MAC times off an MFT. As a habit/SOP I always dump out the MFT and run in another program MFT Analyzer, MFT Ripper, MFT Parser (just to name a few) as well as create a file/dir listing in FTK Imager to cross check and do independent MFT verification. Takes little time (you can do while other things are running) and these programs are low cost or free. And if you are using EnCase you can see the stampings in the raw view to decode - again to reiterate what Sean said.
Part of the forensic process is setting a controlled environment and being skeptical about what you are seeing. You need to take a few minutes as you start each case analysis to gather a few data points and outputs to confirm that what you are seeing in one program is accurate in comparison in another. Most, if not all, programs geared towards forensics are still translating and interpreting very raw data glomned together. You should take the time to know how the program unglomns it. Apologize for the use of such technical terms.
It's all very interesting, and very useful, information.
Thanks guys
There are probably a lot of people who are just not as skilled as you are or are new to the business, and could use some help in this particular area.
Maybe you could post a small step by step to help others
Really to emphasis what Sean is saying - there is no reason in 2011 for someone doing forensics not to have multiple tools for checking MAC times off an MFT. As a habit/SOP I always dump out the MFT and run in another program MFT Analyzer, MFT Ripper, MFT Parser (just to name a few) as well as create a file/dir listing in FTK Imager to cross check and do independent MFT verification. Takes little time (you can do while other things are running) and these programs are low cost or free. And if you are using EnCase you can see the stampings in the raw view to decode - again to reiterate what Sean said.
Part of the forensic process is setting a controlled environment and being skeptical about what you are seeing. You need to take a few minutes as you start each case analysis to gather a few data points and outputs to confirm that what you are seeing in one program is accurate in comparison in another. Most, if not all, programs geared towards forensics are still translating and interpreting very raw data glomned together. You should take the time to know how the program unglomns it. Apologize for the use of such technical terms.
Maybe you could post a small step by step to help others
I thought he pretty much did - if a new forensic bod couldnt follow what was said using the free tools that were mentioned then possibly they need to have a career rethink.
If somethin is crucial to a case then it needs to be verified with a second tool.
Ok, I'll take a stab at it (for NTFS). Disclaimer This is a an example, only, and I won't guarantee that it will work for ALL NTFS implementations now or in the future, but it should.
Download dcode from here
http//
Load your image into whatever forensic tool you are using and go to the Master File Table. Each record should begin with the characters "FILE" and be 1024 bytes in length. In EnCase there are scripts to identify the MFT record associated with the file or you can search for the file name within the MFT (but you'll need to know a bit more about the MFT to be sure you have the correct record).
Each MFT record consists of a number of attributes. Two of these, the STANDARD_INFORMATION and FILE_NAME attribues contain date records. The offset to the start of the attributes is contained in the two bytes starting at offset 20 of the MFT record (usually either 48 or 56 bytes).
The STANDARD_INFORMATION attribute has a header and resident attributes starting with "10 00 00 00" for 24 bytes after which the next 24 bytes are the four 8 byte dates. If you bookmark these in EnCase and choose "Windows Date/Time" as the Data Type you'll see the records displayed as UTC times (or you can chose "Windows Date/Time(Localtime)" to see the dates and times with whatever timezone offset you have selected).
The FILE_NAME attributes (there may be more than one; why is left to the reader), begin "30 00 00 00". The file dates are the four 8 byte records at offset 8 from the start of the attribute stream which, again, is described by the two bytes starting at offset 20 of the attribute record.
Now, the question was whether EnCase had a bug which altered these attributes and I know of no such bug but it would be difficult to imagine since it would mean that EnCase would have to change every STANDARD_INFORMATION and FILE_NAME attribute for all files supposedly corrupted. But it is possible that there could be a bug in the way that these timestamps were rendered by some part of the program (I have seen that for some EnScripts that carve MFT records).
The above method will let you look at the raw data to decode the dates if you suspect an EnCase error.
Dcode is a nice little program if you want to verify EnCase formatting or if you are using a hex editor that does not have the formatting options of EnCase.
Either way, the actual dates are so easily verified, manually, that there is no excuse for NOT doing it when dealing with timestamps which are critical to the expert's opinion. Certainly, this should not have been an issue at trial (though it is unfunny what passes for expertise in this field).
Can anyone tell me what defect reference 24149 found in version 6.11 of encase is. Apparently the defect was corrected in version 6.13. Can anyone tell me what the release notes for v6.13 said about this correction.
Can anyone tell me what defect reference 24149 found in version 6.11 of encase is. Apparently the defect was corrected in version 6.13. Can anyone tell me what the release notes for v6.13 said about this correction.
Bump.
Can anyone please tell me anything about this "defect" and the correction.
I'm both amazed and disappointed that nobody seems to know anything about this defect.
Pete, what difference does it make what bugs were in a long-superseded version of EnCase? The comments posted in this thread demonstrate that forensic examiners recognize that all software has bugs, so we don't place our trust in any one tool. There are lots of ways to examine file metadata in the MFT and elsewhere, so again, what difference does it make what defects existed in an old version of EnCase?