sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

Re: [sleuthkit-users] Missing deleted files when viewing a FAT32 partition

[Brian C. <ca...@sl...>]

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

Re: [sleuthkit-users] Using autopsy/sleuthkit under cygwin

[Keith R W. <kw...@be...>]

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
>
>  
>

Re: [sleuthkit-users] Using autopsy/sleuthkit under cygwin

[Brian C. <ca...@sl...>]

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

[sleuthkit-users] Missing deleted files when viewing a FAT32 partition

[Adam P. U. <uc...@ac...>]

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

[sleuthkit-users] Using autopsy/sleuthkit under cygwin

[Keith R W. <kw...@be...>]

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

Re: [sleuthkit-users] Novell Filesystem

[Brian C. <ca...@sl...>]

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

[sleuthkit-users] Novell Filesystem

[Albert E. W. C. <ae...@AB...>]

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

RE: [sleuthkit-users] A patch to use Foremost-0.64 with Autopsy 1.71 / 1.73

[Pepijn V. <vi...@fo...>]

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'.

Re: [sleuthkit-users] A patch to use Foremost-0.64 with Autopsy 1.71 / 1.73

[Brian C. <ca...@sl...>]

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'.

[sleuthkit-users] A patch to use Foremost-0.64 with Autopsy 1.71 / 1.73

[Pepijn V. <vi...@fo...>]

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

Re: [sleuthkit-users] using sorter to recover files from unallocated inodes, not just r emoved ones

[Brian C. <ca...@ce...>]

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

Re: [sleuthkit-users] using sorter to recover files from unallocated inodes, not just r emoved ones

[Brian C. <ca...@sl...>]

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

Re: [sleuthkit-users] using sorter to recover files from unallocated inodes, not just r emoved ones

[Brian C. <ca...@sl...>]

> 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

[sleuthkit-users] using sorter to recover files from unallocated inodes, not just r emoved ones

[Reava, J. [IT/0200] <jef...@ph...>]

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.

Re: [sleuthkit-users] Difference in Keyword Searching between Unallocated and "Original"

[Chuck W. <chu...@ne...>]

   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.  

Re: [sleuthkit-users] Difference in Keyword Searching between Unallocated and "Original"

[Brian C. <ca...@sl...>]

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

[sleuthkit-users] Difference in Keyword Searching between Unallocated and "Original"

[Chuck W. <chu...@ne...>]

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

Re: [sleuthkit-users] NTFS problems.

[Domingo C. <do...@es...>]

----- 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.

Re: [sleuthkit-users] NTFS problems.

[Brian C. <ca...@sl...>]

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

Re: [sleuthkit-users] NTFS problems.

[Brian C. <ca...@sl...>]

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

Re: [sleuthkit-users] NTFS problems.

[Domingo C. <do...@es...>]

>
>
> 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.

Re: [sleuthkit-users] NTFS problems.

[Brian C. <ca...@sl...>]

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

[sleuthkit-users] NTFS problems.

[Domingo C. <do...@es...>]

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.

Re: [sleuthkit-users] Autopsy vs dls

[Brian C. <ca...@sl...>]

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 

[sleuthkit-users] Autopsy vs dls

[Gary M. W. <wit...@so...>]

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


--