sleuthkit-users

RE: [sleuthkit-users] Is list still alive

[Kalisiak A. C. <Ale...@ni...>]

My hard drive died back in October and I lost everything. When I built =
the
new one up, I completely forgot I was on this list, it's been so quiet!

. . .

Funny me saying that on this list.=20

"my hard drive died. . .i lost everything"

-----Original Message-----
From: sle...@li...
[mailto:sle...@li...] On Behalf Of
fu...@gm...
Sent: Wednesday, November 30, 2005 12:11 PM
To: sle...@li...
Subject: Re: [sleuthkit-users] Is list still alive

Same on linux forensics. Everybody on vacation or heavily at work?

Whatever, I'll do some promo then:
Allin1 for Sleuthkit - do everything in 1 turn:
http://www.netmon.ch/allin1.html

cya

> --- Urspr=FCngliche Nachricht ---
> Von: Rich Thompson <te...@ap...>
> An: sle...@li...
> Betreff: Re: [sleuthkit-users] Is list still alive
> Datum: Wed, 30 Nov 2005 08:41:52 -0800 (PST)
>=20
> I was wondering the same thing a day or two ago....
>  =20
>=20
> esrkq yahoo <es...@ya...> wrote:  Hi,
> just checking whether the list is still alive :-)
>=20
> Last post I got was 26th Oct.
>=20
>=20
>=20
>=20
>  =20
> ___________________________________________________________=20
> To help you stay safe and secure online, we've developed the all new
> Yahoo! Security Centre. http://uk.security.yahoo.com
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =
log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =
SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>=20
>=20
>=20

--=20
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

[sleuthkit-users] Comparing two similar dd disk images

[esrkq y. <es...@ya...>]

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
were deleted through normal housekeeping processes
from Drive-A sometime before Drive-A was 'copied' to 
Drive-B AND therefore the contents of these files
never hit the platters of Drive-B.  If this were the
case then no suggestion of foul play.

b) The Drive-A to Drive-B copy was an imaging process
rather than a file copying process AND the relevant
files in question were 'scrubbed' from Drive-B before
it was sent to the second forensic examiner and
therefore he never had the benefit of seeing them.
The timeline produced by Autopsy/Sleuthkit shows
plenty of file activity going on after March 2004 upto
early April 2004.  

The Big Question
Armed only with the information and material (dd
images) I already have (in other words without having
to ask any further questions) is there anyway (using
Autopsy/Sleuthkit) I can get an indication as to
whether the drive copy of Drive-A to Drive-B was a
file copy process or an imaging process.  Bear in mind
that although the images represent much the same set
of information they are in fact separated by 9 months
normal business activity.

Other Info
----------
The dd images are 'partition images' not whole disk
images.
I am neither a computer forensic expert or legal
expert.  

I know the provenance of the Drive-B image can be
called into question as the two forensic examiners
effectively examined two different 'Documents' but it
would still be great to know whether if was a
file-copy process or imaging process.

This is a civil action not criminal and the files that
may have been scrubbed are to do with an accounting
programme and a financial spreadsheet.

Thanks in advance for any suggestions.

Cheers,
JP
 




		
___________________________________________________________ 
Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/

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

[Angus M. <an...@n-...>]

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
> were deleted through normal housekeeping processes
> from Drive-A sometime before Drive-A was 'copied' to
> Drive-B AND therefore the contents of these files
> never hit the platters of Drive-B.  If this were the
> case then no suggestion of foul play.
>
> b) The Drive-A to Drive-B copy was an imaging process
> rather than a file copying process AND the relevant
> files in question were 'scrubbed' from Drive-B before
> it was sent to the second forensic examiner and
> therefore he never had the benefit of seeing them.
> The timeline produced by Autopsy/Sleuthkit shows
> plenty of file activity going on after March 2004 upto
> early April 2004.
>
> The Big Question
> Armed only with the information and material (dd
> images) I already have (in other words without having
> to ask any further questions) is there anyway (using
> Autopsy/Sleuthkit) I can get an indication as to
> whether the drive copy of Drive-A to Drive-B was a
> file copy process or an imaging process.  Bear in mind
> that although the images represent much the same set
> of information they are in fact separated by 9 months
> normal business activity.
>
> Other Info
> ----------
> The dd images are 'partition images' not whole disk
> images.
> I am neither a computer forensic expert or legal
> expert.
>
> I know the provenance of the Drive-B image can be
> called into question as the two forensic examiners
> effectively examined two different 'Documents' but it
> would still be great to know whether if was a
> file-copy process or imaging process.
>
> This is a civil action not criminal and the files that
> may have been scrubbed are to do with an accounting
> programme and a financial spreadsheet.
>
> Thanks in advance for any suggestions.
>
> Cheers,
> JP
>
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Exclusive Xmas Game, help Santa with his celebrity party -
> http://santas-christmas-party.yahoo.net/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

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

[esrkq y. <es...@ya...>]

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
> > were deleted through normal housekeeping processes
> > from Drive-A sometime before Drive-A was 'copied'
> to
> > Drive-B AND therefore the contents of these files
> > never hit the platters of Drive-B.  If this were
> the
> > case then no suggestion of foul play.
> >
> > b) The Drive-A to Drive-B copy was an imaging
> process
> > rather than a file copying process AND the
> relevant
> > files in question were 'scrubbed' from Drive-B
> before
> > it was sent to the second forensic examiner and
> > therefore he never had the benefit of seeing them.
> > The timeline produced by Autopsy/Sleuthkit shows
> > plenty of file activity going on after March 2004
> upto
> > early April 2004.
> >
> > The Big Question
> > Armed only with the information and material (dd
> > images) I already have (in other words without
> having
> > to ask any further questions) is there anyway
> (using
> > Autopsy/Sleuthkit) I can get an indication as to
> > whether the drive copy of Drive-A to Drive-B was a
> > file copy process or an imaging process.  Bear in
> mind
> > that although the images represent much the same
> set
> > of information they are in fact separated by 9
> months
> > normal business activity.
> >
> > Other Info
> > ----------
> > The dd images are 'partition images' not whole
> disk
> > images.
> > I am neither a computer forensic expert or legal
> > expert.
> >
> > I know the provenance of the Drive-B image can be
> > called into question as the two forensic examiners
> > effectively examined two different 'Documents' but
> it
> > would still be great to know whether if was a
> > file-copy process or imaging process.
> >
> > This is a civil action not criminal and the files
> that
> > may have been scrubbed are to do with an
> accounting
> > programme and a financial spreadsheet.
> >
> > Thanks in advance for any suggestions.
> >
> > Cheers,
> > JP
> >
> >
> >
> >
> >
> >
> >
>
___________________________________________________________
> > Yahoo! Exclusive Xmas Game, help Santa with his
> celebrity party -
> > http://santas-christmas-party.yahoo.net/
> >
> >
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log
> > files for problems?  Stop!  Download the new AJAX
> search engine that makes
> > searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
> >
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > sleuthkit-users mailing list
> >
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

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

[Chuck <chu...@gm...>]

I would look at OS system files that are the same (hashes match)
between the two images.  If they occupy different sectors, that is a
good sign that the second copy was a copy, not an image.  A file
defragment operation could have made the change (if the older image
has the file fragmented), but there should be quite a few system files
that are not fragmented to compare.  Good luck.

Chuck

On 12/11/05, 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
> > > were deleted through normal housekeeping processes
> > > from Drive-A sometime before Drive-A was 'copied'
> > to
> > > Drive-B AND therefore the contents of these files
> > > never hit the platters of Drive-B.  If this were
> > the
> > > case then no suggestion of foul play.
> > >
> > > b) The Drive-A to Drive-B copy was an imaging
> > process
> > > rather than a file copying process AND the
> > relevant
> > > files in question were 'scrubbed' from Drive-B
> > before
> > > it was sent to the second forensic examiner and
> > > therefore he never had the benefit of seeing them.
> > > The timeline produced by Autopsy/Sleuthkit shows
> > > plenty of file activity going on after March 2004
> > upto
> > > early April 2004.
> > >
> > > The Big Question
> > > Armed only with the information and material (dd
> > > images) I already have (in other words without
> > having
> > > to ask any further questions) is there anyway
> > (using
> > > Autopsy/Sleuthkit) I can get an indication as to
> > > whether the drive copy of Drive-A to Drive-B was a
> > > file copy process or an imaging process.  Bear in
> > mind
> > > that although the images represent much the same
> > set
> > > of information they are in fact separated by 9
> > months
> > > normal business activity.
> > >
> > > Other Info
> > > ----------
> > > The dd images are 'partition images' not whole
> > disk
> > > images.
> > > I am neither a computer forensic expert or legal
> > > expert.
> > >
> > > I know the provenance of the Drive-B image can be
> > > called into question as the two forensic examiners
> > > effectively examined two different 'Documents' but
> > it
> > > would still be great to know whether if was a
> > > file-copy process or imaging process.
> > >
> > > This is a civil action not criminal and the files
> > that
> > > may have been scrubbed are to do with an
> > accounting
> > > programme and a financial spreadsheet.
> > >
> > > Thanks in advance for any suggestions.
> > >
> > > Cheers,
> > > JP
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> ___________________________________________________________
> > > Yahoo! Exclusive Xmas Game, help Santa with his
> > celebrity party -
> > > http://santas-christmas-party.yahoo.net/
> > >
> > >
> > >
> >
> -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do
> > you grep through log
> > > files for problems?  Stop!  Download the new AJAX
> > search engine that makes
> > > searching your log files as easy as surfing the
> > web.  DOWNLOAD SPLUNK!
> > >
> >
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > > _______________________________________________
> > > sleuthkit-users mailing list
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > > http://www.sleuthkit.org
> >
> >
> >
> -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do
> > you grep through log files
> > for problems?  Stop!  Download the new AJAX search
> > engine that makes
> > searching your log files as easy as surfing the
> > web.  DOWNLOAD SPLUNK!
> >
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > sleuthkit-users mailing list
> >
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
>
>
>
>
> ___________________________________________________________
> To help you stay safe and secure online, we've developed the all new Yaho=
o! Security Centre. http://uk.security.yahoo.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

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

[youcef b. <ybi...@ya...>]

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
> > > were deleted through normal housekeeping
> processes
> > > from Drive-A sometime before Drive-A was
> 'copied'
> > to
> > > Drive-B AND therefore the contents of these
> files
> > > never hit the platters of Drive-B.  If this were
> > the
> > > case then no suggestion of foul play.
> > >
> > > b) The Drive-A to Drive-B copy was an imaging
> > process
> > > rather than a file copying process AND the
> > relevant
> > > files in question were 'scrubbed' from Drive-B
> > before
> > > it was sent to the second forensic examiner and
> > > therefore he never had the benefit of seeing
> them.
> > > The timeline produced by Autopsy/Sleuthkit shows
> > > plenty of file activity going on after March
> 2004
> > upto
> > > early April 2004.
> > >
> > > The Big Question
> > > Armed only with the information and material (dd
> > > images) I already have (in other words without
> > having
> > > to ask any further questions) is there anyway
> > (using
> > > Autopsy/Sleuthkit) I can get an indication as to
> > > whether the drive copy of Drive-A to Drive-B was
> a
> 
=== message truncated ===



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

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 

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

[esrkq y. <es...@ya...>]

Many thanks to all who have replied.  

The original (drive-A) server os was Windows 2000 and
the filesystem ntfs.  The second image (drive-B)is
also of an ntfs partition.  Neither image contains the
Windows 2000 System files which I believe resided on a
separate boot partition.  I've asked my friend about
sending out the timelines but he is unwilling to (but
thankyou for your kind offer Angus :).  I have also
learned of an additional complication - it appears as
though the employee who copied the contents of Drive-A
to Drive-B (2 months prior to Drive-B being handed
over to the 2nd forensic examiner) had access to a
tape backup system which I suppose he could have used.

Also:

Dave Gilbert Said --
>   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 

That is interesting Dave because this has definitely
happened in this case.  Many of the folder
create/changed dates are the same (and newer) but the
underlying files have retained their original dates. 
But, having said that - it is a mixed picture.  I
think Drive-B began life as a folder by folder copy
but subsequently stuff was deleted and moved / copied
around.  This has led to a mixture of some files with
their original dates and some with newer dates.

As already stated by others, to really get to the
bottom of it a deep review would be needed and at the
moment it is probably not warranted.  At the present
time it is enough that the 'important files' that were
on Drive-A are not on Drive-B and in the fist instance
that requires an explanation from the other side.

Just as an aside, I've been reading a bit about file
slack space and I was wondering if Drive-B had
originally been imaged from Drive-A (as opposed to
file copied) the last cluster of many of the files
would contain the same slack content as on Drive-A. 
If I could setup a test comparing the last cluster of
each file between Drive-A and Drive-B and found a
significantly high correlation between them would that
provide a valid indicator suggesting Drive-B was
imaged?

Although I couldn't find a definitive source on the
internet I gathered from what I did find that a file
by file copy would not retain the slack content.

Once again thanks for all the suggestions,
JP 






		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

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

[Rich T. <te...@ap...>]

See my comments marked in -

Sopunds interesting- keep us posted on your progress I'd love to know what you find.

Rich Thompson
www.apfor.com

esrkq yahoo <es...@ya...> 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.

WAS Drive-A put back in use after the original image???  From description of the case, it sounds like maybe it was.  

b) The Drive-A to Drive-B copy was an imaging process
rather than a file copying process AND the relevant
files in question were 'scrubbed' from Drive-B before
it was sent to the second forensic examiner and
therefore he never had the benefit of seeing them.
The timeline produced by Autopsy/Sleuthkit shows
plenty of file activity going on after March 2004 upto
early April 2004.  

- I was going to say look for files prior to March 2004.  Sounds like a file copy process, since that would make the create date on some files, the day they were copied.

The Big Question
Armed only with the information and material (dd
images) I already have (in other words without having
to ask any further questions) is there anyway (using
Autopsy/Sleuthkit) I can get an indication as to
whether the drive copy of Drive-A to Drive-B was a
file copy process or an imaging process.  Bear in mind
that although the images represent much the same set
of information they are in fact separated by 9 months
normal business activity.

Other Info
----------
The dd images are 'partition images' not whole disk
images.

- so no Images of the entire drive, or at least an MD% of the entire drive (a or b)??

I am neither a computer forensic expert or legal
expert.  

I know the provenance of the Drive-B image can be
called into question as the two forensic examiners
effectively examined two different 'Documents' but it
would still be great to know whether if was a
file-copy process or imaging process.

This is a civil action not criminal and the files that
may have been scrubbed are to do with an accounting
programme and a financial spreadsheet.

- do you know the MD5 of the file in question?  If that can be established you can at least prove they were looking at the same file (if you could find it)

Thanks in advance for any suggestions.

Cheers,
JP
 




  
___________________________________________________________ 
Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org