Re: [sleuthkit-users] Comparing two similar dd disk images

[Dave G. <all...@ya...>]

The replies to date are spot on - it would help to
know what file system and OS the partition has.

Regarding the Changed dates: If the OS and file system
are of a Unix flavor, the Changed dates correspond to
the date and time the affected file's metadata (inode,
dates, times...) was changed.  This can sometimes be
synonymous with a Create date in that the date can
represent the date a particular file was created on
the resident system.  However, the Changed date does
not always equate to a Create date.

That said, if all the files have the same Changed
date, it would be reasonable to suspect a chance the
Changed date was the date the files were copied in
your case.  With some operating systems, I've seen
where Create dates of files copied part and parcel
with a folder (directory) copy were maintained and
only the folder (and it's two children, . and ..)
Create date changed.  If all your folder
Create/Changed dates are the same, and their child
files are different and varied, that could indicate a
copy, folder by folder, depending on OS and media
used.  A good way to know would be to design a test
using the same OS and same conditions to copy some
folders and see what you get.

Barring that, in parallel to what others have added, a
deep review of file dates and times, especially of
dates associated with known system related files, such
as commands, would be the way I would go.  As a rule,
a true image (even of a single partition) operation
should not cause Changed dates to change.

It's hard to get too precise here, I find myself
running tests in many cases where mac times are
critical to verify what I think I remember to be
righteous :)

Knowing exactly what the person, who did the last copy
(or image), did would be the surest bet.  For example,
notes or log files detailing an image operation or a
logical copy.  Given your question, I'm guessing
that's not an option, but figured I'd state the
obvious anyway.

Good Luck

Dave Gilbert

--- youcef bichbiche <ybi...@ya...> wrote:

> Hi,
> If you tell us what filesystem is in place and what
> OS/version was operating at the time that would help
> in shedding more light on the MAC time behaviour.
> 
> regards
> 
> youcef
> 
> --- esrkq yahoo <es...@ya...> wrote:
> 
> > Hi Angus,
> > 
> > --- Angus Marshall <an...@n-...> wrote:
> > 
> > > Not sure what you're telling us - are you saying
> > > that Drive A was imaged then 
> > > allowed back into service as a "live" drive for
> 9
> > > months before it was then 
> > > copied to Drive B ? 
> > > 
> > Yes.  That is what happened.  The forensic
> examiner
> > turned up and imaged the server and then left
> (with
> > the image) but the drive remained and was put
> > straight
> > back into service.  The idea being to create
> minimal
> > disruption to the company.
> > 
> > > Either way, a correct imaging process would
> > preserve
> > > all timestamps and copy 
> > > all data in unallocated space (slack, deleted
> > etc.).
> > > A file copy would 
> > > usually result in modified timestamps (e.g.
> > creation
> > > dates would most likely 
> > > change) and no copying of data in unallocated
> > space.
> > 
> > Following your advice I've just had a look in
> > Autopsy
> > at the two filesystems to try and compare dates on
> > files.  It is a mixed picture.  Autopsy creates a
> > table in the 'file analysis' section that goes
> >  Written Accessed Changed.
> > Comparing the two images a lot of directories ie
> > entries that are listed in Autopsy as a dot (.) or
> > double dot (..) have a newer Written date but many
> > of
> > the files in those directories retain their
> original
> > written date but have newer Accessed and Changed
> > dates.  All a bit confusing really.  One other
> weird
> > thing - many of the files on the original image
> have
> > a
> > 'Changed' date in Autopsy that is the same date
> that
> > I
> > happen to know is the same day that the disk was
> > imaged by the forensic examiner. I don't know what
> > the
> > Changed date represents in Autopsy - surely it is
> > the
> > same as the Written date ?  But hang on, maybe the
> > written date in Autopsy is the original Creation
> > date
> > (which I thought was preserved if files are file
> > copied) and the changed date is the date of any
> > subsequent change to the file that is written to
> > disk.
> > 
> > 
> > All a bit complicated at this time of night :-)
> > 
> > Thanks for your input.
> > 
> > JP.
> > --- Angus Marshall <an...@n-...> wrote:
> > 
> > > Not sure what you're telling us - are you saying
> > > that Drive A was imaged then 
> > > allowed back into service as a "live" drive for
> 9
> > > months before it was then 
> > > copied to Drive B ? 
> > > 
> > > Either way, a correct imaging process would
> > preserve
> > > all timestamps and copy 
> > > all data in unallocated space (slack, deleted
> > etc.).
> > > A file copy would 
> > > usually result in modified timestamps (e.g.
> > creation
> > > dates would most likely 
> > > change) and no copying of data in unallocated
> > space.
> > > Hence, if Drive B was 
> > > "sterile" before the copy, there should be
> nothing
> > > visible/recoverable from 
> > > unallocated and timestamps on the live files are
> > > probably incorrect, 
> > > indicating a file copy process. On the other
> hand,
> > > if Drive B is an image of 
> > > Drive A + 9 months live running, any interesting
> > > data in unallocated space 
> > > could well have been overwritten during normal
> > > operation.
> > > 
> > > I'd probably start by producing timelines for
> both
> > > drives and looking at the 
> > > deleted files and creation stamps on the live
> > files.
> > > 
> > > On Sunday 11 December 2005 17:47, esrkq yahoo
> > wrote:
> > > > Hi,
> > > >
> > > > This is a simple story but just need a few
> steps
> > > to
> > > > tell it so please bear with it :-)
> > > >
> > > > 1) Hard disk (call it Drive-A) is imaged in
> > approx
> > > > June 2003 by a forensic examiner and is
> subject
> > of
> > > a
> > > > forensic report.
> > > >
> > > > 2) March 2004 company that owned Drive-A goes
> > > bust.
> > > >
> > > > 3) March 2004, Drive-A is retrieved from
> company
> > > > offices and 'copied' (don't know whether a
> file
> > > copy
> > > > or imaged) onto a new hard drive (call it
> > > Drive-B).
> > > >
> > > > 4) April 2004 Drive-B is sent off to a
> different
> > > > forensic examiner and is again subject of a
> > > forensic
> > > > report.
> > > >
> > > > 5) I have Drive-A image (dd file) and Drive-B
> > > image
> > > > (dd file) on my computer.
> > > >
> > > > 6) Clearly much of the contents of Drive-A
> image
> > > is
> > > > also on Drive-B image since they have the same
> > > > heritage separated by about a 9 month time
> span
> > of
> > > > normal business activity.
> > > >
> > > > 7) However - it appears as though certain
> > relevant
> > > > files that were on Drive-A image are not
> present
> > > on
> > > > Drive-B image.  In other words the second
> > forensic
> > > > examiner did not have the benefit of seeing
> > these
> > > > files as he examined Drive-B (although he must
> > > have
> > > > known they had existed as he read the report
> > > produced
> > > > by the first forensic examiner).
> > > >
> > > > 8) Using Autopsy/Sleuthkit I have searched
> high
> > > and
> > > > low for contents of these files on Drive-B
> image
> > > and
> > > > they can not be found in Allocated or
> > Unallocated
> > > > space.
> > > >
> > > > 9) To my mind this could be explained by:
> > > > a) The Drive-A to Drive-B copy was a 'file
> copy'
> > > > process rather than an imaging process AND the
> > > files
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com