sleuthkit-users Mailing List for The Sleuth Kit (Page 174)
Brought to you by:
carrier
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(1) |
Feb
(20) |
Mar
(60) |
Apr
(40) |
May
(24) |
Jun
(28) |
Jul
(18) |
Aug
(27) |
Sep
(6) |
Oct
(14) |
Nov
(15) |
Dec
(22) |
2004 |
Jan
(34) |
Feb
(13) |
Mar
(28) |
Apr
(23) |
May
(27) |
Jun
(26) |
Jul
(37) |
Aug
(19) |
Sep
(20) |
Oct
(39) |
Nov
(17) |
Dec
(9) |
2005 |
Jan
(45) |
Feb
(43) |
Mar
(66) |
Apr
(36) |
May
(19) |
Jun
(64) |
Jul
(10) |
Aug
(11) |
Sep
(35) |
Oct
(6) |
Nov
(4) |
Dec
(13) |
2006 |
Jan
(52) |
Feb
(34) |
Mar
(39) |
Apr
(39) |
May
(37) |
Jun
(15) |
Jul
(13) |
Aug
(48) |
Sep
(9) |
Oct
(10) |
Nov
(47) |
Dec
(13) |
2007 |
Jan
(25) |
Feb
(4) |
Mar
(2) |
Apr
(29) |
May
(11) |
Jun
(19) |
Jul
(13) |
Aug
(15) |
Sep
(30) |
Oct
(12) |
Nov
(10) |
Dec
(13) |
2008 |
Jan
(2) |
Feb
(54) |
Mar
(58) |
Apr
(43) |
May
(10) |
Jun
(27) |
Jul
(25) |
Aug
(27) |
Sep
(48) |
Oct
(69) |
Nov
(55) |
Dec
(43) |
2009 |
Jan
(26) |
Feb
(36) |
Mar
(28) |
Apr
(27) |
May
(55) |
Jun
(9) |
Jul
(19) |
Aug
(16) |
Sep
(15) |
Oct
(17) |
Nov
(70) |
Dec
(21) |
2010 |
Jan
(56) |
Feb
(59) |
Mar
(53) |
Apr
(32) |
May
(25) |
Jun
(31) |
Jul
(36) |
Aug
(11) |
Sep
(37) |
Oct
(19) |
Nov
(23) |
Dec
(6) |
2011 |
Jan
(21) |
Feb
(20) |
Mar
(30) |
Apr
(30) |
May
(74) |
Jun
(50) |
Jul
(34) |
Aug
(34) |
Sep
(12) |
Oct
(33) |
Nov
(10) |
Dec
(8) |
2012 |
Jan
(23) |
Feb
(57) |
Mar
(26) |
Apr
(14) |
May
(27) |
Jun
(27) |
Jul
(60) |
Aug
(88) |
Sep
(13) |
Oct
(36) |
Nov
(97) |
Dec
(85) |
2013 |
Jan
(60) |
Feb
(24) |
Mar
(43) |
Apr
(32) |
May
(22) |
Jun
(38) |
Jul
(51) |
Aug
(50) |
Sep
(76) |
Oct
(65) |
Nov
(25) |
Dec
(30) |
2014 |
Jan
(19) |
Feb
(41) |
Mar
(43) |
Apr
(28) |
May
(61) |
Jun
(12) |
Jul
(10) |
Aug
(37) |
Sep
(76) |
Oct
(31) |
Nov
(41) |
Dec
(12) |
2015 |
Jan
(33) |
Feb
(28) |
Mar
(53) |
Apr
(22) |
May
(29) |
Jun
(20) |
Jul
(15) |
Aug
(17) |
Sep
(52) |
Oct
(3) |
Nov
(18) |
Dec
(21) |
2016 |
Jan
(20) |
Feb
(8) |
Mar
(21) |
Apr
(7) |
May
(13) |
Jun
(35) |
Jul
(34) |
Aug
(11) |
Sep
(14) |
Oct
(22) |
Nov
(31) |
Dec
(23) |
2017 |
Jan
(20) |
Feb
(7) |
Mar
(5) |
Apr
(6) |
May
(6) |
Jun
(22) |
Jul
(11) |
Aug
(16) |
Sep
(8) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
|
Feb
|
Mar
(16) |
Apr
(2) |
May
(6) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(16) |
Dec
(13) |
2019 |
Jan
|
Feb
(1) |
Mar
(25) |
Apr
(9) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Seth A. <set...@su...> - 2006-01-03 19:41:15
|
On Fri, Dec 30, 2005 at 08:58:10PM +0100, Paul Bakker wrote: > Just use dd with conv=3Dnoerror,sync as arguments.. > (Take bs small as that is the size of data is "skips" on error If you=20 > want to be REALLY thorough use bs=3D1, but be ready to wait for a LONG ti= me!) The dd_rescue tool will try to make the best of both worlds here: http://www.garloff.de/kurt/linux/ddrescue/ The two block sizes are a performance optimization. Large block sizes result in superior performance, but in case of errors, you want to try to salvage every single sector. So hardbs is best be set to the hardware sector size (most often 512 bytes) and softbs to a large value, such as the default 16k. |
From: Matt K. <mku...@ma...> - 2006-01-03 15:19:38
|
If it works, 'conv=sync,noerror' works great, but I have run into situations where it did not work. For whatever reason, dd would hang at a certain block even with that option specified. I ended up looking at the size of the output file after dd hung and estimated the location of the bad spot. I then began reading one block at a time until I found the one that was bad. I then narrowed my block size down and read smaller blocks noting those that were bad. At the end of this process, I had a series of dd files. I created zero'd dd files from /dev/zero to replace the bad sections and used dd to piece everything back together into a single image. Pain in the rear, but it works. You just have to keep track of the individual files and put them back together in the correct order. -Matt > Hi Colby, > > While you could manually put all the parts together.. It is easier to > let dd do it for you!.. > > Just use dd with conv=noerror,sync as arguments.. > > This way all unreadable data is written as a 0 on the destination and dd > continues on after an error... > > dd if=/dev/hdXX of=imagefile conv=noerror,sync bs=1k > > (Take bs small as that is the size of data is "skips" on error If you > want to be REALLY thorough use bs=1, but be ready to wait for a LONG time!) > > I hope this helps, > Paul Bakker > > Colby Gutierrez-Kraybill wrote: > > > > > Hello, > > > > I am attempting to recover data from a physically damaged disk. I > > was able to dd > > the first GB (including partition info) of the disk and I can run the > > sleuthkit tools > > and do find some useful info on it. However, to get at the rest of > > the disk, I manually > > skipped past the damaged sectors on disk using dd and was able to > > read another > > much larger block of data (16GB) and then some shorter sections after > > that > > (5x500MB each). I noted down which sectors this blocks were started > > physically > > on the slice. Now I am trying to sort out if I can put these pieces > > back together > > enough so that I can use the regular sleuthkit tools on the whole > > fragmented > > mess. Is this doable? Is there a recipe for working through this? > > > > - Colby |
From: Paul B. <p.j...@br...> - 2005-12-30 19:58:09
|
Hi Colby, While you could manually put all the parts together.. It is easier to let dd do it for you!.. Just use dd with conv=noerror,sync as arguments.. This way all unreadable data is written as a 0 on the destination and dd continues on after an error... dd if=/dev/hdXX of=imagefile conv=noerror,sync bs=1k (Take bs small as that is the size of data is "skips" on error If you want to be REALLY thorough use bs=1, but be ready to wait for a LONG time!) I hope this helps, Paul Bakker Colby Gutierrez-Kraybill wrote: > > Hello, > > I am attempting to recover data from a physically damaged disk. I > was able to dd > the first GB (including partition info) of the disk and I can run the > sleuthkit tools > and do find some useful info on it. However, to get at the rest of > the disk, I manually > skipped past the damaged sectors on disk using dd and was able to > read another > much larger block of data (16GB) and then some shorter sections after > that > (5x500MB each). I noted down which sectors this blocks were started > physically > on the slice. Now I am trying to sort out if I can put these pieces > back together > enough so that I can use the regular sleuthkit tools on the whole > fragmented > mess. Is this doable? Is there a recipe for working through this? > > - Colby > > > > ------------------------------------------------------- > 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 > > |
From: Colby Gutierrez-K. <co...@ge...> - 2005-12-30 19:52:34
|
Hello, I am attempting to recover data from a physically damaged disk. I was able to dd the first GB (including partition info) of the disk and I can run the sleuthkit tools and do find some useful info on it. However, to get at the rest of the disk, I manually skipped past the damaged sectors on disk using dd and was able to read another much larger block of data (16GB) and then some shorter sections after that (5x500MB each). I noted down which sectors this blocks were started physically on the slice. Now I am trying to sort out if I can put these pieces back together enough so that I can use the regular sleuthkit tools on the whole fragmented mess. Is this doable? Is there a recipe for working through this? - Colby |
From: Philippe de R. <phi...@ww...> - 2005-12-28 21:04:37
|
Hello, I have just installed TST to learn more about the Macosx file system. When I do df -h, I get the following: Filesystem Size Used Avail Capacity Mounted on /dev/disk0s3 74G 12G 62G 16% / devfs 97K 97K 0B 100% /dev fdesc 1.0K 1.0K 0B 100% /dev <volfs> 512K 512K 0B 100% /.vol ... What are devfs, fdesc and <volfs>? Can I analyze /dev/disk0s3 with mmls? When I do mmls /dev/dsik0s3, I get a message saying that the disk is read-only. Should I sudo mmls / dev/dsik0s3? Many thanks. Philippe |
From: esrkq y. <es...@ya...> - 2005-12-13 12:51:08
|
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 |
From: Dave G. <all...@ya...> - 2005-12-13 01:37:31
|
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 |
From: youcef b. <ybi...@ya...> - 2005-12-12 23:35:34
|
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 |
From: Chuck <chu...@gm...> - 2005-12-12 18:07:15
|
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 > |
From: esrkq y. <es...@ya...> - 2005-12-12 00:24:15
|
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 |
From: Rich T. <te...@ap...> - 2005-12-12 00:03:24
|
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 |
From: Angus M. <an...@n-...> - 2005-12-11 19:54:06
|
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 |
From: esrkq y. <es...@ya...> - 2005-12-11 17:47:35
|
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/ |
From: Kalisiak A. C. <Ale...@ni...> - 2005-12-01 15:26:24
|
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 |
From: Brian C. <ca...@sl...> - 2005-12-01 08:04:36
|
That improvement is part of a larger improvement of adding "logical" searches in addition to just sector-level searches. That has been on the todo list for a while. After I finish up my dissertation in the next couple of months, these types of improvements should be made. brian On Nov 30, 2005, at 5:27 AM, esrkq yahoo wrote: > Hi, > > I recently downloaded the latest versions of tsk and > autopsy > and my general impression was (as a non expert user) > is that it does seem to have moved on a good step > since I last used it. Everything seemed to work great > (I only found one bug though I admit it could be user > error). > > The last time I used Autopsy (at the beginning of the > year) there was one feature that I wished it had and > when I used it again recently I again 'missed' this > feature. > > In fact, back in January Brian posted a request for > some feedback on Autopsy entitled: 'Autopsy Case > Management Gripes' > > I posted a reply to that and one of my 'gripes' at the > time was > .....copy and paste begin ...... > > One other suggestion (not to do with case management) > that would have saved me loads of time recently is > having an extra button on the key word search results > screen in Autopsy. The extra button would begin a > batch process that would look up the filename (and > extension) of every hit and put the filename next to > each hit. This would save loads of time because if > you are most interested in say Word Docs you could in > the first instance only look at those hits that are > word documents. Taking it a stage further the results > could be displayed in a navigable tree form with each > branch representing a different file type. At the > moment you have to visit every hit and manually > 'click' the MFT link to get the filename and type. I > know there would be a time overhead in a batch process > like this but at least it would all be done non > interactively (ie you can go for some lunch while > it's all happening). > > ---- paste finish ------- > > OK, maybe the navigable tree thing is a bit of a > stretch but if you could sort the results by filename > (and maybe also show the MD5SUM) that would be useful > as the same search string is found in many instances > of the same file and when browsing through the results > you find yourself checking out the same text over and > over. Often I find I just want to scan an individual > file quickly once and if it is not relevant then > ignore all other occurrences of it and move onto the > next one. > > The few times I used Autopsy this feature would have > been a real time saver. I think many users would find > this feature useful (what do others think?). > > Back in January you suggested this feature wouldn't be > a huge job to add :-) - however I realise your to do > list must be huge. > > Anyway Brian, thankyou for this useful and enjoyable > programme. |
From: <fu...@gm...> - 2005-11-30 17:11:39
|
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üngliche 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) > > I was wondering the same thing a day or two ago.... > > > esrkq yahoo <es...@ya...> wrote: Hi, > just checking whether the list is still alive :-) > > Last post I got was 26th Oct. > > > > > > ___________________________________________________________ > To help you stay safe and secure online, we've developed the all new > Yahoo! Security Centre. http://uk.security.yahoo.com > > > ------------------------------------------------------- > 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 > > > -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie |
From: Rich T. <te...@ap...> - 2005-11-30 16:42:14
|
I was wondering the same thing a day or two ago.... esrkq yahoo <es...@ya...> wrote: Hi, just checking whether the list is still alive :-) Last post I got was 26th Oct. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ------------------------------------------------------- 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 |
From: esrkq y. <es...@ya...> - 2005-11-30 10:27:25
|
Hi, I recently downloaded the latest versions of tsk and autopsy and my general impression was (as a non expert user) is that it does seem to have moved on a good step since I last used it. Everything seemed to work great (I only found one bug though I admit it could be user error). The last time I used Autopsy (at the beginning of the year) there was one feature that I wished it had and when I used it again recently I again 'missed' this feature. In fact, back in January Brian posted a request for some feedback on Autopsy entitled: 'Autopsy Case Management Gripes' I posted a reply to that and one of my 'gripes' at the time was .....copy and paste begin ...... One other suggestion (not to do with case management) that would have saved me loads of time recently is having an extra button on the key word search results screen in Autopsy. The extra button would begin a batch process that would look up the filename (and extension) of every hit and put the filename next to each hit. This would save loads of time because if you are most interested in say Word Docs you could in the first instance only look at those hits that are word documents. Taking it a stage further the results could be displayed in a navigable tree form with each branch representing a different file type. At the moment you have to visit every hit and manually 'click' the MFT link to get the filename and type. I know there would be a time overhead in a batch process like this but at least it would all be done non interactively (ie you can go for some lunch while it's all happening). ---- paste finish ------- OK, maybe the navigable tree thing is a bit of a stretch but if you could sort the results by filename (and maybe also show the MD5SUM) that would be useful as the same search string is found in many instances of the same file and when browsing through the results you find yourself checking out the same text over and over. Often I find I just want to scan an individual file quickly once and if it is not relevant then ignore all other occurrences of it and move onto the next one. The few times I used Autopsy this feature would have been a real time saver. I think many users would find this feature useful (what do others think?). Back in January you suggested this feature wouldn't be a huge job to add :-) - however I realise your to do list must be huge. Anyway Brian, thankyou for this useful and enjoyable programme. Paul. ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com |
From: esrkq y. <es...@ya...> - 2005-11-30 09:45:09
|
Hi, just checking whether the list is still alive :-) Last post I got was 26th Oct. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com |
From: <fu...@gm...> - 2005-10-26 17:41:55
|
Hi sleuthkit users The new version 0.3 of the All-in-1-step-GUI for the Sleuthkit is out now. The idea behind Allin1 is to perform time consuming steps with the sleuthkit in one row or scheduled. It's now fully written in Python, has some bugfixes and also the option to perform Foremost on the images in a Sleuthkit project. You can get more information on: http://www.netmon.ch/allin1.html Any suggestion, bug report or whatsoever is very welcome! Thank you and regards David -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++ |
From: Brian C. <ca...@sl...> - 2005-10-13 19:41:06
|
It's been a while, but TSK 2.03 and Autopsy 2.06 are now available. They are mostly feature upgrades (there is 1 important bug fix in TSK for AMD64 users though!). The biggest new feature is Unicode support (which was kindly funded by I.D.E.A.L. Technology) for all file systems. Autopsy also now supports Unicode and has new a new CSS HTML design. All AMD64 users should upgrade because the previous versions of MD5 and SHA1 produced incorrect values. http://www.sleuthkit.org/sleuthkit/ MD5: 79821dedfcefba9f0e9e873edcb8aaa5 http://www.sleuthkit.org/autopsy/ MD5: 4acb0b5854939748d9c5f58bd28ac2a5 Also, there is now a sleuth kit store on cafepress so that you can have the latest in forensic-ware fashion! http://www.cafepress.com/sleuthkit/ brian |
From: <Geo...@ao...> - 2005-10-13 00:46:13
|
Hello, as the file _http://members.aol.com/pfcviewer/pfcview.jar_ (http://members.aol.com/pfcviewer/pfcview.jar) seems to be corrupted (may be it was uploaded in ascii mode?) here are some other tools that can read PFC-files: - "AOL-Dump" (German only), _http://www.datanorm-software.de/aol-dump/aol-dump.htm_ (http://www.datanorm-software.de/aol-dump/aol-dump.htm) , is freeware, can export as MBOX. Drawbacks: removes all HTML tags & embedded pictures are lost. Also it seems that date & time of the messages are not correct (sometimes +/- 10 years :-) ) - "Goodbye A*L" (german & english), _http://www.rkerbitz.de/goodbye/_ (http://www.rkerbitz.de/goodbye/) is shareware but not sold anymore, but the trial version can show and export messages (only one by one, that's the restriction) into EML-files. Works good with embedded pictures (I had just some problems with german "Umlaut"-characters). - "E-Mail-Umzugshelfer" (german only), _http://reiser-software.de/dl_mail.html_ (http://reiser-software.de/dl_mail.html) , is shareware and writes both EML and MBOX files. I've only tested the trial version: it even shows messages correctly that AOL's software does not display anymore (e.g. german users suffer from disappearing special characters every time when there is a new AOL version...) Unfortunately the trial version shortens messages (but at least those with attachment or embedded pictures are shown completely) BTW: This is the only usefull information I have ever found on the PFC binary format: _http://members.aol.com/fvongordon/pfc/_ (http://members.aol.com/fvongordon/pfc/) _http://members.aol.com/fvongordon/pfc/PFC-Details.zip_ (http://members.aol.com/fvongordon/pfc/PFC-Details.zip) |
From: Brian C. <ca...@sl...> - 2005-10-05 14:08:40
|
What are the error messages? brian On Oct 3, 2005, at 10:08 PM, Monserrat Ramirez wrote: > Hello everybody! > > I'm sure that i am doing smething wrong with the > compile process of the kit... I know that the only > thing that have to do is to run the make command... Am > I missing something? Maybe libraries? any tip? I=B4m > using Solaris 8. > > Thanks a lot in advance, > > Monserrat. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, =20 > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > > |
From: Monserrat R. <mrg...@ya...> - 2005-10-04 03:08:36
|
Hello everybody! I'm sure that i am doing smething wrong with the compile process of the kit... I know that the only thing that have to do is to run the make command... Am I missing something? Maybe libraries? any tip? I´m using Solaris 8. Thanks a lot in advance, Monserrat. |
From: Tom G. <tom...@gm...> - 2005-10-03 10:21:51
|
Hi Slade, I actually saw this presentation when it was given at Blackhat USA, and although it brought some of the problems of forensic analysis to the attention of those not in the field (some of my collegues found it interesting), I'd say that it didn't really bring anything new to the table. Most of the techniques that they mentioned have been used or understood for years (although they do mention this a few times) such as timestamp modification. The EnCase example, where the date was set sufficiently in the past, was fairly interesting but isn't exactly something someone who wanted to remain hidden would use! The logging exploitation techniques would have has more value if an example was given, and the tactic of not putting files in System32 isn't groundbreaking either. File signature modification and hash modification are also an old tactics that are only really a problem if your investigations throw out huge sets of data without some form of secondary validation. (Side note: avoiding signature matching is more interesting using the old technique of cat'ing a filesystem onto the end of a binary to make the tools think it is a standard ELF binary, which can then be mounted using mount's "offset" option) I don't mean to sound overly critical of this presentation, because as mentioned earlier it *did* bring these issues to the attention of non-forensic examiners. However, hearing the way the presentation was put over and the discussion afterwards, you'd be forgiven for thinking the sky was falling. Most of the issues are very old and can be fixed using minor tweaks in software and by using proper investigation methodologies. Personally, I'd be more interested in seeing more hidden data storage in filesystems and parsing bugs in common forensics tools which prevent data from even being displayed to the examiner. Those are the kind of issues to be worried about, especially as the people in the know probably aren't too keen on revealing them to the world :-) Regards, Tom Goldsmith |