How can I answer this the best definitive way?
I replied to this in the EnCase forum, but perhaps it would be useful to to post the suggestion here also, with some elaborations.
I'd try to make a kind of Ishigawa/fishbone diagram – often used to do a root cause analysis in quality work. And to begin with I'd probably split the original hypothesis into subtasks, such as 1) insert faked evidence file in image, 2) insert faked evidence file on drive, 3) copy original evidence to new drive, and so on.
Then, for each of these I'd work backwards list what different methods there are for accomplishing the goal, and also what forensic traces each would leave. It's useful to be as simpleminded as possible here, so as not to miss traces from simpleminded fakers.
And then, for each of those methods, use the knowledge of forensic traces, reformulate the method in several ways to avoid just those traces, and then again figure out what other forensic traces that more complex approach could be expected to produce, and also what time it would take. This is probably best done as plain brainstorming.
For instance, copying the original drive to a new drive using dd would leave a slack space unless the drives were exactly the same size. Using ghost to copy the volume, and then format the new drive and restore the volume would leave clean free blocks, and perhaps cause block allocation patterns according to the order of the files, and may even cause a more modern MBR to be used, if another system was used. Both methods would retain registry contents, which may contain original HDD connection SATA/PATA information, original HDD serial number, etc. And next attempt would be to figure out how to get around registry data.
Also, a new drive will have SMART attributes that don't fit the usage patterns of the original drive less power-on hours, fewer power cyclings, etc. (Can SMART attributes be modified? What traces would that leave …)
And so on, and so on, refining the methods repeatedly. For files that are referenced elsewhere in the image (AV logs, download logs, etc.) it becomes very complex, as those files in turn would need to be faked by the same methods already analysed for the faked image file, and so on. (It's useful to keep track of time – when time to fake becomes absurd, it's time to abandon that particular line – or consider the possibility that chain of custody records also have been faked. You get the idea.)
Then it's a question of analyzing the result, identifying key tests (in this case, fle system time stamp inconsistencies is probably one such), and then see if they are present. If not, keep testing until some suitable ending criterion has been reached out of time, out of money, or perhaps even out of mind.
AddedThere's a nice short story by Chesterton in the collection The Paradoxes of Mr. Pond that illustrated the basic idea a package must be sent from a department of state, and it's secret so it must not be intercepted. Mr Pond suggests avoiding security transports, and instead send it by ordinary mail. And then he asks what would the enemy do if they knew we would do that? Try to intercept it. So Pond sends thousands of identical packages. What would the enemy do if they knew that we would do that? Try to get their hands of the real package, and alter the address. So Mr Pond instructs the post office to hold all packages with altered or modified addresses. So what does the enemy do when they learn that? The title of the story is 'Pond the Pantaloon', and it begins with a red pencil that makes very black marks.
Just a small point that may be of interest to Patrick's last comment regarding FTK Imager.
In tests that I have carried out where an image was acquired using FTK Imager through a Tableau Write blocker, the software actually reports the Drive model and Serial Number as that of the write blocker and not the HDD itself.
To take it one step further, my tests also showed that the Logicube Talon reported the details of the drive correctly.
EnCase acquisition through the same write blocker recorded the drive details correctly.
DD For Windows reported the correct make and model of the drive but again showed the serial number of the write blocker.
I know this is going off subject a little, but something I thought may be of use.
In tests that I have carried out where an image was acquired using FTK Imager through a Tableau Write blocker, the software actually reports the Drive model and Serial Number as that of the write blocker and not the HDD itself.
I'm using the T35es, and as I recall, I got a different report depending on whether I attached via eSATA or USB. Normally I wouldn't have had 2 FTK Imager logs for the same drive to compare but I had an issue whilst doing an eSATA acquisition and tried acquiring via USB. The images are in my evidence locker so I can't just go check that right now without interfering with my CoC.
I believe the eSATA image reported the drive details, but the USB image reported it as a USB attached device. I'll do some testing later perhaps and double check.
I work for the Defense.
The defendant claims the encase Evidence file that the Prosecution provided has been tampered with.He believes that they have inserted images, adjusted the timestamps, and then copied that tampered drive to a second drive to make the Encase “Evidence” files from.
How can I answer this the best definitive way?
Thank you!
I do a lot of defense work and once and a while a defendant will make such a claim.
It is simple to disprove this as long as the defense expert does a proper examination of the case as a whole and then the evidence specifically. I am not going to tell you how to do it, since if you are working as a defense "expert" you should already know this.
FYI, I have never seen a valid claim of evidence tampering by law enforcement in the several hundred cases I have done. They would really need to have an overwhelming motivation to take that kind of risk.
sdjoslin has not responded to so many considered replies to his very first post, good luck with that defence!
http//