sleuthkit-users Mailing List for The Sleuth Kit (Page 203)
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: Brian C. <ca...@sl...> - 2003-07-28 05:58:41
|
On 27 Jul 2003 18:02 PDT you wrote: > I was taking a look at a FAT32 partition the other day under both > Autopsy/Sleuthkit (v.latest) and EnCase (v.3.22) and I noticed something > a bit strange. It looked like EnCase was showing a number of (deleted > and overwritten) files that were not showing up in Autopsy. > Unfortunately, I didn't have much time to investigate, but the one thing > that I noticed in the time that I had was that the MAC times as shown by > EnCase appeared to be NULL. I haven't had a chance to look at the > Autopsy/Sleuthkit code, but is it possible that 'wiped' MAC times could > cause a file not to show up in Autopsy? Indeed they can. The current logic for FAT partitions is that the write time must have a non-zero time. That is because it is the only file that is required by spec to be updated. Since the others are optional in the spec, The Sleuth Kit does not require them to be non-zero. I guess I could change that though. The next version will have it removed. Do you know how files existed though with no times? If wiping tools were used, then I would also expect them to wipe the file name and other useful information too. brian |
From: Keith R W. <kw...@be...> - 2003-07-28 04:24:45
|
Thanks for the feedback. I commented out the line in autopsyfunc.pm, but still had the problem with not finding the dll. I saw where it was resetting the PATH later on in the initialization file and commented out that line as well, but to no avail. After flailing around a while I finally decided to take a look inside the autopsy script itself. It was doing the same thing with resetting the PATH to be blank. I commented out that line and things took off. Also thanks for the comment on the image file. I had a fundamental misunderstanding of how it was working. I thought the image import was actually doing the "dd" for me. Sorry for the total ignorance, but I am just learning. Thanks again krw Brian Carrier wrote: >On 25 Jul 2003 19:24 PDT you wrote: > > > >>I am running on a windows 2000 workstation with cygwin installed. When I >>try to add an image to a case file it tells me that it can't find: >>cygwin1.dll on the path, even though the path has /bin on it. The error >>is coming from fsstat. >> >> > >Autopsy removes the original path, try and remove that line in >Autopsy and see if it works. it is line 75 in autopsyfunc.pm: > $ENV{PATH} = ""; > >Remove that, restart, and try it again. I haven't done much with >Autopsy and CYGWIN before, but maybe others on this list can >provide assistance. > > > > >>When I try to run fsstat from the command line I get the following: >>$ /cygdrive/d/sleuthkit/bin/fsstat.exe /cygdrive/a >>/cygdrive/d/sleuthkit/bin/fsstat: /cygdrive/a: read superblock: Is a >>directory >> >> >> > >The Sleuth Kit tools need a file system image to process. The >mounted directory does not give The Sleuth Kit the needed >information. You will have to make an image of the partition >(using a 'dd' port for example) and run the tools on that >image. > >brian > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >sleuthkit-users mailing list >https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >http://www.sleuthkit.org > > > |
From: Brian C. <ca...@sl...> - 2003-07-27 21:54:33
|
On 25 Jul 2003 19:24 PDT you wrote: > I am running on a windows 2000 workstation with cygwin installed. When I > try to add an image to a case file it tells me that it can't find: > cygwin1.dll on the path, even though the path has /bin on it. The error > is coming from fsstat. Autopsy removes the original path, try and remove that line in Autopsy and see if it works. it is line 75 in autopsyfunc.pm: $ENV{PATH} = ""; Remove that, restart, and try it again. I haven't done much with Autopsy and CYGWIN before, but maybe others on this list can provide assistance. > > When I try to run fsstat from the command line I get the following: > $ /cygdrive/d/sleuthkit/bin/fsstat.exe /cygdrive/a > /cygdrive/d/sleuthkit/bin/fsstat: /cygdrive/a: read superblock: Is a > directory > The Sleuth Kit tools need a file system image to process. The mounted directory does not give The Sleuth Kit the needed information. You will have to make an image of the partition (using a 'dd' port for example) and run the tools on that image. brian |
From: Adam P. U. <uc...@ac...> - 2003-07-27 21:36:55
|
Hey All, I was taking a look at a FAT32 partition the other day under both Autopsy/Sleuthkit (v.latest) and EnCase (v.3.22) and I noticed something a bit strange. It looked like EnCase was showing a number of (deleted and overwritten) files that were not showing up in Autopsy. Unfortunately, I didn't have much time to investigate, but the one thing that I noticed in the time that I had was that the MAC times as shown by EnCase appeared to be NULL. I haven't had a chance to look at the Autopsy/Sleuthkit code, but is it possible that 'wiped' MAC times could cause a file not to show up in Autopsy? Sorry for the sketchy information... if I can free up some more time I'll see what else I can dig up. Thoughts??? (Thanks for all you efforts Brian!) Cheers! -Adam |
From: Keith R W. <kw...@be...> - 2003-07-26 02:22:45
|
I am running on a windows 2000 workstation with cygwin installed. When I try to add an image to a case file it tells me that it can't find: cygwin1.dll on the path, even though the path has /bin on it. The error is coming from fsstat. When I try to run fsstat from the command line I get the following: $ /cygdrive/d/sleuthkit/bin/fsstat.exe /cygdrive/a /cygdrive/d/sleuthkit/bin/fsstat: /cygdrive/a: read superblock: Is a directory The mounted disks look like: $ df Filesystem 1k-blocks Used Available Use% Mounted on C:\cygwin\bin 5218904 4401768 817136 85% /usr/bin C:\cygwin\lib 5218904 4401768 817136 85% /usr/lib C:\cygwin 5218904 4401768 817136 85% / a: 1423 1 1422 1% /cygdrive/a c: 5218904 4401768 817136 85% /cygdrive/c d: 24639648 15229440 9410208 62% /cygdrive/d g: 8225152 496896 7728256 7% /cygdrive/g h: 60204032 15603712 44600320 26% /cygdrive/h j: 2096320 1619584 476736 78% /cygdrive/j The only thing I have done on disk a is wipe it "forensically clean", created three small text files, and deleted two of them. I don't know if this is related to cygwin or I am just doing something wrong. Any help or guidance would be greatly appreciated. Thank you, krw |
From: Brian C. <ca...@sl...> - 2003-07-24 19:57:06
|
On 24 Jul 2003 12:45 PDT you wrote: > I have a Novell Filesystem Image file. > > How would I examine this file? It does not appear that the Sleuth kit > supports the NCPFS (Novell Filesystem). Any suggestions? There was a thread on this a while back forensics@securityfocus. http://lists.jammed.com/forensics/2002/07/index.html#17 It lists a Linux driver and ontrack. If you can get it mounted read only under Linux, then you can use mac-robber to collect the MAC times and make a timeline of activity with 'mactime' in The Sleuth Kit. brian |
From: Albert E. W. C. <ae...@AB...> - 2003-07-24 19:44:43
|
I have a Novell Filesystem Image file. How would I examine this file? It does not appear that the Sleuth kit supports the NCPFS (Novell Filesystem). Any suggestions? -- Albert E. Whale, CISSP http://www.abs-comptech.com ---------------------------------------------------------------------- ABS Computer Technology, Inc. - ESM, Computer & Networking Specialists Sr. Security, Network, and Systems Consultant Founding Board of Directors of Pittsburgh FBI - InfraGard |
From: Pepijn V. <vi...@fo...> - 2003-07-24 07:34:40
|
Hi Brian, I acknowledge that problem indeed. The patch is just meant for those who = happen to run a Linuxflavour and happen to use Foremost (like myself). I = too hope that Foremost develops a little bit further, and maybe this = patch helps a little in that direction too ;)=20 Keep up the good work with your projects! Regards, Pepijn -----Oorspronkelijk bericht----- Van: Brian Carrier [mailto:ca...@sl...]=20 Verzonden: Wednesday, July 23, 2003 9:19 PM Aan: Pepijn Vissers; sle...@li... Onderwerp: Re: [sleuthkit-users] A patch to use Foremost-0.64 with = Autopsy 1.71 / 1.73 Just as an FYI to other users, I have been reluctant to integrate=20 foremost into Autopsy because it only runs on Linux. I am trying=20 to keep all of Autopsy's features available on all systems (BSDs,=20 Solaris, etc.). =20 I have been waiting to help port foremost to other OSs, but other projects always turn up... =20 Thanks Pepijn! Hopefully this patch will be used when we can get foremost on other platforms. =20 brian On 22 Jul 2003 00:45 PDT you wrote: > Hi people, >=20 > Foremost is a tool which can recover data from unallocated space by=20 > user definable headers and optionally footers. It runs on most Linux=20 > distributions. I thought it would be handy to be able to integrate=20 > this into Autopsy, along with the option to edit the configuration=20 > file. Well, here is the patch. Effort has been made to respect the=20 > original format of the 'base/autopsyfunc.pm'. |
From: Brian C. <ca...@sl...> - 2003-07-23 19:18:59
|
Just as an FYI to other users, I have been reluctant to integrate foremost into Autopsy because it only runs on Linux. I am trying to keep all of Autopsy's features available on all systems (BSDs, Solaris, etc.). I have been waiting to help port foremost to other OSs, but other projects always turn up... Thanks Pepijn! Hopefully this patch will be used when we can get foremost on other platforms. brian On 22 Jul 2003 00:45 PDT you wrote: > Hi people, > > Foremost is a tool which can recover data from unallocated space by user definable headers and optionally footers. It runs on most Linux distributions. I thought it would be handy to be able to integrate this into Autopsy, along with the option to edit the configuration file. Well, here is the patch. Effort has been made to respect the original format of the 'base/autopsyfunc.pm'. |
From: Pepijn V. <vi...@fo...> - 2003-07-22 07:43:31
|
Hi people, Foremost is a tool which can recover data from unallocated space by user = definable headers and optionally footers. It runs on most Linux = distributions. I thought it would be handy to be able to integrate this = into Autopsy, along with the option to edit the configuration file. = Well, here is the patch. Effort has been made to respect the original = format of the 'base/autopsyfunc.pm'. The patch can be downloaded from=20 http://www.fox-it.com/files/autopsy-foremost.patch.tar.gz (MD5: http://www.fox-it.com/files/autopsy-foremost.patch.tar.gz.md5) Foremost 0.64 can be downloaded from http://foremost.sourceforge.net. The foremost.conf file format has been adapted for use with Autopsy. You = can use foremost_converter.pl to convert your original configuration = file. Parsing an original foremost.conf will result in errors. Files and directories =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - autopsy-foremost.patch This is the patch for 'configure' and 'base/autopsyfunc.pm' - pict/ This directory contains the custom .jpg's for the web interface. These should be copied to the autopsy 'pict'-directory. - foremost_converter/ This directory contains a sample.foremost.conf for use with autopsy, a conversion script for original foremost.conf-files=20 and an original foremost-0.64 conf file. Please read the conversion script source code for additional details. Feel free to comment on or off list.=20 Best regards, --=20 P. Vissers Forensic IT Consultant Fox-IT Experts in IT Security! Haagweg 137=20 2281 AG RIJSWIJK=20 T 070 336 9999=20 F 070 336 9990=20 I www.fox-it.com=20 Disclaimer: This email may contain confidential information. If this = message is not addressed to you, you may not retain or use the = information in it for any purpose. If you have received it in error, = please notify the sender and delete this message. We try to screen out = viruses but take no responsibility if this email contains a virus. =20 =20 |
From: Brian C. <ca...@ce...> - 2003-07-15 15:28:43
|
Interesting. That mail client removed the '+' from the email. Once again, the '+' was missing and the correct line is: unless ((defined $inode) && ($inode =~ /^[0-9\-]+$/) && brian On Tuesday, July 15, 2003, at 10:20 AM, Brian Carrier wrote: > > > To finish this thread from last week, there is a bug in 'sorter'. The > regular expression that parses the output of 'ils' was missing a ' ' > and therefore some of the entries were not being processed. > > Line 531 should be: > > unless ((defined $inode) && ($inode =~ /^[0-9\-] $/) && > > and not: > > unless ((defined $inode) && ($inode =~ /^[0-9\-]$/) && > > I'm finishing up some new tools for listing disk partitions and would > like > to wait a few days until they are done before I release a new version. > Let me know if you want me to send you a fixed copy of the file before > then. > > brian > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps1 > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
From: Brian C. <ca...@sl...> - 2003-07-15 15:20:07
|
To finish this thread from last week, there is a bug in 'sorter'. The regular expression that parses the output of 'ils' was missing a ' ' and therefore some of the entries were not being processed. Line 531 should be: unless ((defined $inode) && ($inode =~ /^[0-9\-] $/) && and not: unless ((defined $inode) && ($inode =~ /^[0-9\-]$/) && I'm finishing up some new tools for listing disk partitions and would like to wait a few days until they are done before I release a new version. Let me know if you want me to send you a fixed copy of the file before then. brian |
From: Brian C. <ca...@sl...> - 2003-07-11 03:36:52
|
> Using ils and icat (ver 1.62) on an NTFS partition image I was able to > identify and recover an additional 20 files that sorter did not > automatically bring back. > > It seems that since sorter's call to "fls -rp" doesn't see these "lost" > files, sorter won't try to retrieve them from the output of ils. It would be > great to be able to recover these unallocated inodes en masse with sorter in > the same way that removed inodes are handled. How are you defining unallocated inodes versus removed inodes? Did you mean removed files? > > Before I go further, is this possible within the current structure of > sorter, or will a different approach be needed? I'm not quite sure what you are looking for. What inodes did you identify using 'ils' that 'sorter' did not find? 'sorter' runs 'ils -m' on the image to identify the unallocated used inodes. The same code processes the 'ils' file as the 'fls' files (except extension checks aren't done ...). The last issue of The Sleuth Kit Informer gives a detailed design overview of 'sorter' if you are interested: http://www.sleuthkit.org/informer/sleuthkit-informer-5.html#internals brian |
From: Reava, J. [IT/0200] <jef...@ph...> - 2003-07-10 19:40:59
|
Using ils and icat (ver 1.62) on an NTFS partition image I was able to identify and recover an additional 20 files that sorter did not automatically bring back. It seems that since sorter's call to "fls -rp" doesn't see these "lost" files, sorter won't try to retrieve them from the output of ils. It would be great to be able to recover these unallocated inodes en masse with sorter in the same way that removed inodes are handled. Before I go further, is this possible within the current structure of sorter, or will a different approach be needed? Thanks, Jeff Sample output from fls and ils: from "fls -f ntfs -rp ntfs_deleted.dd" ... r/r * 125-128-4: del_ery.html r/r * 126-128-3: del_es.rtf r/r * 127-128-4: del_ican Revolution.doc r/r * 121-128-3: del_ory.xls from "ils -f ntfs -m ntfs_deleted.dd" ... 0|<ntfs_deleted.dd-Df10.xls-dead-121>|0|121|33279|-rwxrwxrwx|1|0|0|0|20992|1 057683497|1057627477|1057683626|512|0 0|<ntfs_deleted.dd-Df9.doc-dead-127>|0|127|33279|-rwxrwxrwx|1|0|0|0|43520|10 57683497|1057627379|1057683626|512|0 This communication is intended solely for the use of the addressee and may contain information that is legally privileged, confidential or exempt from disclosure. If you are not the intended recipient, please note that any dissemination, distribution, or copying of this communication is strictly prohibited. Anyone who receives this message in error should notify the sender immediately and delete it from his or her computer. |
From: Chuck W. <chu...@ne...> - 2003-07-03 14:23:23
|
Thanks for the response, Brian. You have pretty much confirmed what I suspected from my testing. Ideally, it would be nice to include the boot sector, FAT, directory entries, and probably even slack space in "unallocated" since you don't see it with normal mounting of the filesystem. Then you can mount the filesystem and doing standard searching with strings and grep you could get all the "allocated" space and then look at the .dls file you could look at all the "unallocated" space and not miss anything or search anything twice. I don't know how easy that would be to implement, though, and I really don't know how useful it would be because now you can just search the "original" and see everything, right? Thanks and have a great holiday. Chuck >>I have a question about searching in Autopsy. What is the difference >>between the "Unallocated" searching and the "Original" searching >>specifically. That is, does the "Original" search only allocated space >>(logical files) or does it search the entire drive, including allocated >>and unallocated space? I assume that the "Unallocated" search does not >>search logical files, but what about deleted files? > > > The unallocated search uses all of the unallocated blocks in the > image. The 'dls' tool goes through the allocation bitmap and extracts > out the unallocated blocks and saves them to a file. The unallocated > search is a grep of that. So, deleted content that has not been > overwritten will be in there. > > >>Part of the reason that I am confused by this is that I have done some >>testing and found that the "original" searches would find text in the >>boot sector of a floppy disk where the "unallocated" search would not. > > > Yes, the boot sector is considered allocated space so it would not > be found in the "unallocated" search. I was recently playing with > another forensic tool though and it considered the super blocks > and boot sectors to be unallocated because they were not part of > files. |
From: Brian C. <ca...@sl...> - 2003-07-03 03:48:42
|
On 02 Jul 2003 19:55 PDT you wrote: > Hi all, > > I have a question about searching in Autopsy. What is the difference > between the "Unallocated" searching and the "Original" searching > specifically. That is, does the "Original" search only allocated space > (logical files) or does it search the entire drive, including allocated > and unallocated space? I assume that the "Unallocated" search does not > search logical files, but what about deleted files? The unallocated search uses all of the unallocated blocks in the image. The 'dls' tool goes through the allocation bitmap and extracts out the unallocated blocks and saves them to a file. The unallocated search is a grep of that. So, deleted content that has not been overwritten will be in there. > > Part of the reason that I am confused by this is that I have done some > testing and found that the "original" searches would find text in the > boot sector of a floppy disk where the "unallocated" search would not. Yes, the boot sector is considered allocated space so it would not be found in the "unallocated" search. I was recently playing with another forensic tool though and it considered the super blocks and boot sectors to be unallocated because they were not part of files. brian |
From: Chuck W. <chu...@ne...> - 2003-07-03 02:53:47
|
Hi all, I have a question about searching in Autopsy. What is the difference between the "Unallocated" searching and the "Original" searching specifically. That is, does the "Original" search only allocated space (logical files) or does it search the entire drive, including allocated and unallocated space? I assume that the "Unallocated" search does not search logical files, but what about deleted files? Part of the reason that I am confused by this is that I have done some testing and found that the "original" searches would find text in the boot sector of a floppy disk where the "unallocated" search would not. Thanks for your help and have a good day! Chuck Willis |
From: Domingo C. <do...@es...> - 2003-06-26 17:44:16
|
----- Original Message ----- From: "Brian Carrier" <ca...@sl...> To: "Domingo Cardona" <do...@es...>; <sle...@li...> Sent: Thursday, June 26, 2003 6:58 PM Subject: Re: [sleuthkit-users] NTFS problems. > > > On 26 Jun 2003 08:48 PDT you wrote: > > > When do you get the message? > > - When trying to make a symlink to Evidence Locker. > > Ok, then that is where the "not an NTFS image" error came from. > The seek error came from testing the image to verify it was > indeed the correct file system type. Can you send me the exact > seek error message? > > > Do any of the "modes" work? > > -Sorry, I don't eactly know what you mean. > > The "modes" are once the image has been imported you can view > it from different "modes" such as files or data units. But, I guess > it never got that far. > > > The file system imported with no errors though correct? > > - Sorry, I don't exactly know what you mean. I made a bit to bit copy > > with "dd". > > Did you 'dd' the entire disk or the individual partitions? Autopsy and > The Sleuth Kit both require a partition and not a disk. In other words, > if you used Linux, did you 'dd' /dev/hda or /dev/hda1? > > brian > I dd'ed /dev/hda... any solution to get /dev/hda1 from the image file? Domingo. |
From: Brian C. <ca...@sl...> - 2003-06-26 17:37:26
|
On 26 Jun 2003 10:21 PDT you wrote: > > > > I dd'ed /dev/hda... any solution to get /dev/hda1 from the image file? check out: http://www.sleuthkit.org/informer/sleuthkit-informer-2.html#split I'm confused about what you got a seek error though. The Sleuth kit should have returned an error about an invalid file system before the seek error occured. I'll have to look into that more. Can you send me the output of the following: dd if=image.img count=1 | xxd That will put the first sector of the image you collected in a hexdump format. I want to find out why the sanity check did not work. No sensitive data is located in there. brian |
From: Brian C. <ca...@sl...> - 2003-06-26 16:58:50
|
On 26 Jun 2003 08:48 PDT you wrote: > When do you get the message? > - When trying to make a symlink to Evidence Locker. Ok, then that is where the "not an NTFS image" error came from. The seek error came from testing the image to verify it was indeed the correct file system type. Can you send me the exact seek error message? > Do any of the "modes" work? > -Sorry, I don't eactly know what you mean. The "modes" are once the image has been imported you can view it from different "modes" such as files or data units. But, I guess it never got that far. > The file system imported with no errors though correct? > - Sorry, I don't exactly know what you mean. I made a bit to bit copy > with "dd". Did you 'dd' the entire disk or the individual partitions? Autopsy and The Sleuth Kit both require a partition and not a disk. In other words, if you used Linux, did you 'dd' /dev/hda or /dev/hda1? brian |
From: Domingo C. <do...@es...> - 2003-06-26 15:48:06
|
> > > On 26 Jun 2003 07:12 PDT you wrote: > > I made an image "image.img" with dd from a hard disk wich contained a WindowsXP partition (NTFS) and now Autopsy says: > > > > " offset read random seek error... image.img not NTFS File System" (more or less) > > Domingo, I'm going to need some more data. > > When do you get the message? Do any of the "modes" work? The > file system imported with no errors though correct? How big is the > file system image? Did you copy, move, or symlink into the evidence > locker? > > The seek error comes when the tools try to read past the end of the > file system image. The "img is not a NTFS file system" error message > though comes from a much different place and you should not get > the seek error before the NTFS magic check. So, there are two tools > that are being run by Autopsy and giving different errors. > > thanks, > brian > When do you get the message? - When trying to make a symlink to Evidence Locker. Do any of the "modes" work? -Sorry, I don't eactly know what you mean. The file system imported with no errors though correct? - Sorry, I don't exactly know what you mean. I made a bit to bit copy with "dd". How big is the file system image? - 20 Gbytes. Did you copy, move, or symlink into the evidence locker? - Already answered. I tried to symlink... Thanks Brian. |
From: Brian C. <ca...@sl...> - 2003-06-26 15:13:05
|
On 26 Jun 2003 07:12 PDT you wrote: > I made an image "image.img" with dd from a hard disk wich contained a WindowsXP partition (NTFS) and now Autopsy says: > > " offset read random seek error... image.img not NTFS File System" (more or less) Domingo, I'm going to need some more data. When do you get the message? Do any of the "modes" work? The file system imported with no errors though correct? How big is the file system image? Did you copy, move, or symlink into the evidence locker? The seek error comes when the tools try to read past the end of the file system image. The "img is not a NTFS file system" error message though comes from a much different place and you should not get the seek error before the NTFS magic check. So, there are two tools that are being run by Autopsy and giving different errors. thanks, brian |
From: Domingo C. <do...@es...> - 2003-06-26 14:09:11
|
Hi all,=20 I made an image "image.img" with dd from a hard disk wich contained a = WindowsXP partition (NTFS) and now Autopsy says: " offset read random seek error... image.img not NTFS File System" (more = or less) Could anybody help me with this issue? Thanks in advance. |
From: Brian C. <ca...@sl...> - 2003-06-16 16:25:38
|
On 15 Jun 2003 12:33 PDT you wrote: > Hi: > > Having just found this amazing tool kit I'm wondering about what is the 'best' way to go about recovering deleted files. My Debian distro came with older docs which recommended at least 220% free disk space for processing the nonallocated portion of a partition. > > I am processing a 13 gig partition, 9 gig of which is unallocated. I have a 20 gig partion that I can use to process the data on. > > If I understand the docs correctly I can use Autopsy on a full 'file system image' of the target partition? What I don't know is, does Autopsy also require this 220% free space? If so, then I don't have the necessary space and I will have to use dls. 220% wouldn't hurt. There are two ways to do this. One is to set Autopsy up to point to the raw device and run it as root. Then you can analyze the disk w/out making an image. When you add an image just use '/dev/hdaX' and do a symlink. The other way is to use 'dd' and make an image of it: # dd if=/dev/hdaX bs=2k of=blah.dd Then, import that into autopsy. The 'dd' method may require the ~200%. > If I can use Autopsy, will it allow me to retrieve deleted files? Also, what how do I create an image of the target partition? I could create an empty image and then copy the partition data over, but that leaves out the nonallocated data - the part I'm interested in. It depends on what you want to recover. EXT3FS deletes many of the pointers in deleted files, so recovery is not point and click. If there are keywords that you want, then Autopsy can help with that. If you want to "carve" out files, then use the 'foremost' tool. It looks for known headers and footers. You can run it on just the unallocated data (the 'dls' output, which can also be created from the keyword search mode of Autopsy). foremost.sourceforge.net brian R |
From: Gary M. W. <wit...@so...> - 2003-06-15 19:31:33
|
Hi: Having just found this amazing tool kit I'm wondering about what is the 'best' way to go about recovering deleted files. My Debian distro came with older docs which recommended at least 220% free disk space for processing the nonallocated portion of a partition. I am processing a 13 gig partition, 9 gig of which is unallocated. I have a 20 gig partion that I can use to process the data on. If I understand the docs correctly I can use Autopsy on a full 'file system image' of the target partition? What I don't know is, does Autopsy also require this 220% free space? If so, then I don't have the necessary space and I will have to use dls. If I can use Autopsy, will it allow me to retrieve deleted files? Also, what how do I create an image of the target partition? I could create an empty image and then copy the partition data over, but that leaves out the nonallocated data - the part I'm interested in. Once again, I am grateful for any help. Thanks in advance, Gary -- |