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

[sleuthkit-users] Re: Future of indexing in Autopsy and Sleuthkit

[Simson L. G. <si...@lc...>]

Paul,

Here are some issues you may not have considered:
>
> Issue 1:
> I think it is advisable to limit the indexed character range to only=20=

> alphanumeric characters instead of the current limitation of all=20
> printable ASCII characters.

If you limit to printable ASCII characters, there will be problems for=20=

people outside the US (or people working with data outside the US). You=20=

need to be able to handle roman characters with accents. These are=20
normally represented with high-bits. If the user searches for an e,=20
they probably want to match on =E8 and =E9 and possibly other e's as =
well.

Then you have the issue of Arabic, Hebrew, and 16-bit characters.

At a minimum, I think that you should transparently handle codepages=20
and coerce them into 7-bit ASCII. But ideally you should handle=20
UNICODE, UTF-8, UTF-16, etc. Or do something for Arabic.
>
> Issue 2:
> Human readability of the files. A speedup in the indexed searching=20
> process and a redeuction of the size of the used files can be=20
> accomplished by changing the format of the index files. The=20
> consequence is that these cannot be read by a human anymore (No more=20=

> text-format file). The consequences are the following:
>  - POSITIVE: Speed of searches is increased
>  - POSITIVE: Size of used files is reduces
>  - NEGATIVE: Files cannot be checked anymore with the human eye.

I do not think that this is important. The index files should be in=20
binary; create a tool to browse or view them.

[sleuthkit-users] Future of indexing in Autopsy and Sleuthkit

[Paul B. <ba...@fo...>]

=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

As some people may already know, I am in the process of adding an =
Indexed Search feature to Autopsy and Sleuthkit, which are Open Source =
filesystem forensic tools.

I have some issues that concern these additions and I would like to get =
community members' opinions on some of these. So anyone who is using =
Autopsy/Sleuthkit or just wants to give his/her opinion: Feel free to =
give your opinion and let me know if I should or should not implement =
these features/issues.

Issue 1:
I think it is advisable to limit the indexed character range to only =
alphanumeric characters instead of the current limitation of all =
printable ASCII characters. The consequences are the following:
 - POSITIVE: The size of the used index files is smaller (Now it's the =
size of the strings file of an image) Which is quite huge if you have =
just copied a 80 Gb partition.
 - NEGATIVE: Indexed Searching on other characters will not be possible =
anymore.
 - POSITIVE: It will be easier to search for substrings of words, which =
is not yet possible at the moment. (It is possible in both versions, but =
will take a huge extra space if used on the original charachter range)
 - POSITIVE: Searching will be even quicker.

Issue 2:
Human readability of the files. A speedup in the indexed searching =
process and a redeuction of the size of the used files can be =
accomplished by changing the format of the index files. The consequence =
is that these cannot be read by a human anymore (No more text-format =
file). The consequences are the following:
 - POSITIVE: Speed of searches is increased
 - POSITIVE: Size of used files is reduces
 - NEGATIVE: Files cannot be checked anymore with the human eye.

For the moment this are the issues. Maybe more will come..

- --
Paul Bakker

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
E ba...@fo...
57A6 C5EA 55E4 CC1C A967 B13C F8C0 C0FB 8135 E225

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.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPss3KvjAwPuBNeIlEQKRXwCg7CS05qSRSxlLxW6Z30wwnj0SQzUAmwbv
s4OvNJhBlhByW5cZcx9tyuUq
=3D//+o
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] wrong filesystem ?

[Antoine J. <aja...@lp...>]

On Tuesday 20 May 2003 16:49, Brian Carrier wrote:
> The 'dls' tool with out the 'eb' will extract the unallocated space,
> so that will allow you to just run foremost or keyword searches on
> just the unallocated space.  Freebsd deletes the pointers from the
> inode structure to the data fragments, so there is no easy way to
> recover.  The last issue of the Sleuth Kit Informer had a quick blurb
> on using the group layout of a UNIX file system to recover files:

OK, I'll have a deeper lookt on all of that.
Thanks a lot for you suggestions.

Antoine

Re: [sleuthkit-users] wrong filesystem ?

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

Antoine Jacoutot <aja...@lp...> said:

> On Monday 19 May 2003 21:20, Brian Carrier wrote:
> > The 'dls -e' should be equivalent to using 'dd'.  So, I would expect
> > it to work.  What happens if you use 'dd' and grab the first 100 MB
> > and run the sleuth kit tools on that:
> 
> It did work, thanks a lot :)

Can you image the partition with 'dd' and compare it with the 'dls' iimage?  They 
"should" be the same since you gave 'eb'.  Are they the same size?  

> Now, I don't want to ask stupid questions on the list, so I was 
> wondering if there was some kind of howto somewhere for recovering 
> files.
> I tried to use the Coroner Toolkit before knowing about your software, 
> but I realised that it would take a month of more to recover my data 
> (30Go), so I was wondering if there was a way to extract only the 
> needed data from the image instead of all.

Actually, there is no "easy" way to recover files.  If the file types have a structure that 
is known by 'foremost' (on sourceforge), then you can run it (on Linux only) and 
recover some of the data.    

The 'dls' tool with out the 'eb' will extract the unallocated space, so that will allow you 
to just run foremost or keyword searches on just the unallocated space.  Freebsd 
deletes the pointers from the inode structure to the data fragments, so there is no 
easy way to recover.  The last issue of the Sleuth Kit Informer had a quick blurb on 
using the group layout of a UNIX file system to recover files:

    www.sleuthkit.org/informer

brian

Re: [sleuthkit-users] wrong filesystem ?

[Antoine J. <aja...@lp...>]

On Monday 19 May 2003 21:20, Brian Carrier wrote:
> The 'dls -e' should be equivalent to using 'dd'.  So, I would expect
> it to work.  What happens if you use 'dd' and grab the first 100 MB
> and run the sleuth kit tools on that:

It did work, thanks a lot :)
Now, I don't want to ask stupid questions on the list, so I was 
wondering if there was some kind of howto somewhere for recovering 
files.
I tried to use the Coroner Toolkit before knowing about your software, 
but I realised that it would take a month of more to recover my data 
(30Go), so I was wondering if there was a way to extract only the 
needed data from the image instead of all.
Englidh is not my first language and I'm having a hard time 
understanding autopsy.

Thanks a lot for your former answer.

Regards.

Antoine

Re: [sleuthkit-users] wrong filesystem ?

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

Antoine Jacoutot <aja...@lp...> said:

> Hi !
> 
> I am new to data recovery.
> I stupidly "rm" the content of an entire partition under FreeBSD.
> Of course, the data was very important, so I decided using the 
> sleuthkit+autopsy.
> Now, after issuing the command:
> "bin/dls -be -f freebsd /dev/ad5s1e > /mnt/image.dd",
> I have after a couple of hours, an image.dd file that's 28Go big.
Until 
> that, no problem.
> After that, I want to use autopsy to search the image content, but
when 
> I tell him to add /mnt/image.dd it tells me this is not a freebsd 
> filesystem image ...
> What did I do wrong ?

Antoine,

The 'dls -e' should be equivalent to using 'dd'.  So, I would expect
it to work.  What happens if you use 'dd' and grab the first 100 MB
and run the sleuth kit tools on that:

# dd if=/dev/ad5s1e of=/mnt/image2.dd bs=1m count=100
# bin/fls -f freebsd /mnt/image2.dd

It will likely report a read error, but it should pass the initial
sanity check.  If so, then the 'dls' did not make the right image. 
You may want to run 'fls' on the image.dd file as well because there
could be an error in the autopsy check (It was just added to the last
release).

thanks,
brian

[sleuthkit-users] wrong filesystem ?

[Antoine J. <aja...@lp...>]

Hi !

I am new to data recovery.
I stupidly "rm" the content of an entire partition under FreeBSD.
Of course, the data was very important, so I decided using the 
sleuthkit+autopsy.
Now, after issuing the command:
"bin/dls -be -f freebsd /dev/ad5s1e > /mnt/image.dd",
I have after a couple of hours, an image.dd file that's 28Go big. Until 
that, no problem.
After that, I want to use autopsy to search the image content, but when 
I tell him to add /mnt/image.dd it tells me this is not a freebsd 
filesystem image ...
What did I do wrong ?

Thanks a lot for your help.

Regards.

Antoine

Re: [sleuthkit-users] Hashing Database Creator

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

I agree with Jesse's reply on the cftt list for using 'md5deep'.  It is a cool tool.

brian


Jason Fuller <efo...@ho...> said:

> To All:
> 
> Is there a product, preferably open-source, that will create a hash set 
> database of all files on a hard drive or CD-ROM?
> 
> For example, I would like to create a hash set of an "image build" that I 
> use here at work (all known "good values"). Another example, would be 
> hashing an in-house program that we use.
> 
> I am interested in creating my own hash set for use with Sleuthkit and 
> Autopsy (Linux).
> 
> Like always, thank you in advance for you Time and Knowledge.
> 

[sleuthkit-users] Hashing Database Creator

[Jason F. <efo...@ho...>]

To All:

Is there a product, preferably open-source, that will create a hash set 
database of all files on a hard drive or CD-ROM?

For example, I would like to create a hash set of an "image build" that I 
use here at work (all known "good values"). Another example, would be 
hashing an in-house program that we use.

I am interested in creating my own hash set for use with Sleuthkit and 
Autopsy (Linux).

Like always, thank you in advance for you Time and Knowledge.

Jason Fuller
efo...@ho...

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

Re: [sleuthkit-users] Timezone not working correctly

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

Autopsy sets the 'TZ' environment variable when it runs things, so the
time zone setting is actually a Linux thing and not an Autopsy thing.
 I'm not familiar with the Australian time zone settings.

If you enter a timezone setting that Linux does not understand, it
will return the times in GMT.  I would look into the Redhat docs to
see how they defined the timezone names.

brian


Sparrow <sp...@au...> said:

> Hi,
> 
> When I run the timeline option in Autopsy v1.71 on my Red Hat 8.0
machine, the report doesn't show the correct times.  The image is
Windows XP NTFS and I configured Autopsy with timezone AEST10AEDT.  To
get the correct time I need to enter AEST13AEDT which is not a valid
timezone as Australia is UTC+10 when in Standard time and UTC+11 for
Daylight saving time. Has anyone had a similar problem?
> 
> thanks
> Helen
> 
> 
> 
> _____________________________________________________________
> The best email provider on today's market, sign-up now for as low as
$20.00 AUD per year!    http://www.aussiemail.com.au
> 
> _____________________________________________________________
> Select your own custom email address for FREE! Get
yo...@yo... w/No Ads, 6MB, POP & more!
http://www.everyone.net/selectmail?campaign=tag
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> 
> 



-- 

Re: [sleuthkit-users] Timezone not working correctly

[Adam D. <ad...@fo...>]

Hi Helen,
I know NTFS store all MAC times in GMT, so you have to add 10 hours when looking at any of the dates.

Mabye thats the problem as the linux NTFS support will show the GMT times when mounting. 


Regards

Adam

(PS. Good to see a fellow aussie on the list)

On Thu, May 08, 2003 at 08:16:42PM -0700, Sparrow wrote:
> Hi,
> 
> When I run the timeline option in Autopsy v1.71 on my Red Hat 8.0 machine, the report doesn't show the correct times.  The image is Windows XP NTFS and I configured Autopsy with timezone AEST10AEDT.  To get the correct time I need to enter AEST13AEDT which is not a valid timezone as Australia is UTC+10 when in Standard time and UTC+11 for Daylight saving time. Has anyone had a similar problem?
> 
> thanks
> Helen
> 
> 
> 
> _____________________________________________________________
> The best email provider on today's market, sign-up now for as low as $20.00 AUD per year!    http://www.aussiemail.com.au
> 
> _____________________________________________________________
> Select your own custom email address for FREE! Get yo...@yo... w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users

-- 


Technical Consultant
-----------------------------------------------------------------------
FORENSIC DATA SERVICES PTY LIMITED
http://www.forensicdata.com.au
------------------------------------------------------------------------
The information contained in this e-mail is confidential and is
intended solely for the addressee. If you received this e-mail by
mistake please notify us immediately and delete all copies of this
message. You must not disclose or use in any way the information in the
e-mail. It is the responsibility of the recipient to virus scan this
e-mail and any attachments included.

[sleuthkit-users] Timezone not working correctly

[Sparrow <sp...@au...>]

Hi,

When I run the timeline option in Autopsy v1.71 on my Red Hat 8.0 machine, the report doesn't show the correct times.  The image is Windows XP NTFS and I configured Autopsy with timezone AEST10AEDT.  To get the correct time I need to enter AEST13AEDT which is not a valid timezone as Australia is UTC+10 when in Standard time and UTC+11 for Daylight saving time. Has anyone had a similar problem?

thanks
Helen



_____________________________________________________________
The best email provider on today's market, sign-up now for as low as $20.00 AUD per year!    http://www.aussiemail.com.au

_____________________________________________________________
Select your own custom email address for FREE! Get yo...@yo... w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

Re: [sleuthkit-users] Questions on new version

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

Eagle Investigative Services <in...@ea...> said:

> I've installed the 1.71 version of Autopsy and 1.61 version of
Sleuthkit on
> my SUSe Linux
> machine and I have a couple of questions
> 
> 1. When I run ./autopsy, I get the URL as  usual, and I paste
> it into my browser and the program runs. The bitmap image
> however, shows 1.70, not 1.71. Is this normal?

Yea, the graphic is for the major version which is 1.7X.  If you click
on the image, then it brings you to the 'about' section which has the
exact version.


> 2. What is the purpose of the symbolic link in the sleuthkit
installation?
> I created a directory called sleuthkit, and created the symbolic
link, which
> appears in that directory just fine. However, I'm not sure why I
would link
> a new directory
> to an existing directory? Can anyone shed some light?

You don't have to create the generic directory and the symbolic link.
 The installation will make a directory such as autopsy-1.71.  The
goal of the symbolic link is to just reference 'autopsy' and skip the
version number.  For example, /usr/local/autopsy links to
/usr/local/autopsy-1.71.  

The generic directory is more useful for the sleuth kit than autopsy.
 Then, you can have all the binaries always in your path and you can
install new versions of the slueth kit with out reconfiguring an older
version of Autopsy.  

brian

Re: [sleuthkit-users] Malformed utf-8 character

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

Interesting.  Have you created any special category regular
expressions in the config file or are you just using the standard ones?  

If you are using the standard ones, it looks like the output of
running 'file' has some unicode values that Perl does not like.  What
version of Perl are you using?  Does it happen just a few times or
does it happen for each file in the system?

brian

Jason Fuller <efo...@ho...> said:

> I keep having an error:  "...malformed utf-8 character" at 
> "/usr/local/sleuthkit/bin/sorter line 791"
> 
> Can anyone provide assistance on this matter?
> 
> Am I missing any information within my investigation by having these
errors?
> 
> What do these errors mean?
> 

[sleuthkit-users] Questions on new version

[Eagle I. S. <in...@ea...>]

I've installed the 1.71 version of Autopsy and 1.61 version of Sleuthkit on
my SUSe Linux
machine and I have a couple of questions

1. When I run ./autopsy, I get the URL as  usual, and I paste
it into my browser and the program runs. The bitmap image
however, shows 1.70, not 1.71. Is this normal?

2. What is the purpose of the symbolic link in the sleuthkit installation?
I created a directory called sleuthkit, and created the symbolic link, which
appears in that directory just fine. However, I'm not sure why I would link
a new directory
to an existing directory? Can anyone shed some light?

Thanks!

Niall.

[sleuthkit-users] Malformed utf-8 character

[Jason F. <efo...@ho...>]

I keep having an error:  "...malformed utf-8 character" at 
"/usr/local/sleuthkit/bin/sorter line 791"

Can anyone provide assistance on this matter?

Am I missing any information within my investigation by having these errors?

What do these errors mean?

Thank you in advance.

Jason Fuller
efo...@ho...




_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[sleuthkit-users] Testers for indexed searching in Autopsy and Sleuthkit

[Paul B. <ba...@fo...>]

=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I work at a company doing Forensic IT investigations in the Netherlands =
called Fox-IT (http://www.fox-it.com). We are working on an all-Linux =
environment for Forensic research.

As the main Forensic tool we would like to use Autopsy/Sleuthkit. As it =
is missing some features in comparison to (commercial) Windows products, =
we've decided to contribute and add some new features to Autopsy and =
Sleuthkit. We're doing this in cooperation with Brian Carrier of @stake.

One of the major missing features is indexed searching. Indexed =
searching greatly speeds up searches for words during investigations.

We created a first implementation for indexed searching in Autopsy and =
Sleuthkit. This e-mail is to inform the users of this new addition and =
to request testers as the code is still in beta. After the addition has =
been successfully tested it will be submitted for integration in Autopsy =
and Sleuthkit.

Indexed searching requires the creation of two additional files (And =
thus will require additional diskspace). The total size of these files =
is comparable to the size of the strings file generated from an image. =
For the creation however, twice the space of the strings file is =
required.

It has been tested on a Debian Linux system and on a number of forensic =
images. The speedup for searching is very great (Searches on a 5 Gb =
image file for a single word in less than 1 second (Resulting in 11866 =
hits), compared to 168 seconds using the regular grepping on the strings =
file).

For the indexed search two files are required: a "mangled strings" file =
and an "index" file.
The creation of the "mangled strings" file requires the strings file for =
the image. The process is split in two parts (but are combined within =
Autopsy) and takes about 68 minutes to complete for a 3.5 Gb strings =
file, resulting in a 4.0 Gb "mangled strings" file. During the proces =
about 8.5 Gb of temporary space is required!
The creation of the "index" file requires the "mangled strings" file and =
takes about 5 minutes to complete for the aforementioned 4.0 Gb file. =
The resulting "index" file is only 5 Mb in size.

Features:
 - Tools for Indexed searching in sleuthkit.
 - Creation of necessary files integrated into Autopsy interface.
 - Indexed Search field (At the bottom of the "Keyword search" page).
 - Case insensitive searching.

There are still some limitations:
 - Only the ASCII character set is recognized for indexing.
   This is because the meaning of Unicode characters depends on the
   context. This makes it very hard to index these. If somebody knows
   how this could be integrated in the utilities, I will gladly add
   the functionality.
 - Only able to search for single words.
   Option for combining multiple searches will be added in a later
   version (In addition to the option to recall search results).
 - Only start of words can be searched.
   e.g. the original word is "baseball". A search for "base" will
   match, a search for "ball" will not. In the future I will expand
   the indexing functionality. This will require a lot of additional
   diskspace (So this option comes at a price).
 - No regex searches possible. (It is almost impossible to combine
   indexed searching with regex.)

The available patches are for Autopsy 1.71 and Sleuthkit 1.61. They add =
a first (beta) version of indexed searching to Autopsy.

It is still in beta and therefore I would greatly appreciate it if =
people would test the indexed searching on other machines and images and =
send their problems, feedback and feature requests to me.

All feedback is appreciated! My goal is to add useful features (like =
indexed searching) to Autopsy and Sleuthkit. This requires feedback! ;-)

Please send an e-mail to me if you'd like to test the patches.


- --
Paul Bakker

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
E ba...@fo...
57A6 C5EA 55E4 CC1C A967 B13C F8C0 C0FB 8135 E225

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.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPre/s/jAwPuBNeIlEQIQjACePe0LIhqbp9VoWEwHw7tXKPslGV8AnRy9
/SuxnfOWHs5a5j0YkQ8ZLKIT
=3DZikc
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] Unallocated files in Solaris

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

brian hutson <bh...@ne...> said:

> hello
> i am at present examining a Solaris 8 system that has a large number
> of files
> deleted around the period of a possible break in. My understanding
> is that
> Solaris unlinks deleted filenames from metadata thus making retrieval of
> unallocated data very difficult. Is this correct?


Yes, that is correct.  Solaris removes the link between the file name
and meta data structure and the link between meta data structure
(inode) and the fragments.  


> Apart from doing string searches etc. is there anything else I can
do? Using the
> data unit menu to display the data in autopsy does not show anything
readable e.g 

Looking at random fragments takes a LONG time and is usually not
useful.   The first thing is to extract the unallocated space, which
can be done from the keyword search mode.  That file can than be
examined fragment by fragment in the data unit mode.  A more useful
approach would be to run tools like 'foremost' on the unallocated data.  

If you are very desperate and the data of found files is very
important, try the following (not intended for the average user):

- Get the inode number of the parent directory where the deleted files
are located
- Identify which Cylinder Group the parent directory is in (meta data
mode)
- Identify the fragments that are in the same cylinder group
- Run 'dls' by hand for the fragments in the range:
  # dls -f solaris img.dd 123456-2345678
- Examine the unallocated data for just that group.

brian

Re: [sleuthkit-users] recovering large files using Autopsy

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

Terry,

Matt's reply gives a good summary about why FAT file recovery is
difficult.  You may observe that other tools can recover the file
though.  They guess what clusters the file was using on the disk, even
if they were not consecutive.  Autopsy and The Sleuth Kit do not do
any of the guessing.  It has been on the TODO list for quite a while,
but one of those things that has not been written yet.  For small
files, it is easy to do by hand (refer to some of the recent Honeynet
Scan of the Months for examples).  But, for large files it is not easy.  

Autopsy only knows the starting cluster of the file, the size of the
file, and what clusters are allocated.  So, it gave you the contents
of the first cluster (8k).  


brian


Terry Fernandez <Ter...@mc...> said:

> In the File Analysis component of Autopsy (v1.70),  I can see the
> deleted file and the size with the metadata information. When I try to
> export it only 8KB is exported, while the file size shown is around
> 185MB. I am sure I am missing a step somewhere, Can you assist. The
> image is a FAT32 partition  and the file in question is a pst file.
> 
> Terry Fernandez
> Tel: 312.260.3223
> Vnet: 894.3223
> 
> 



-- 

Re: [sleuthkit-users] recovering large files using Autopsy

[Matthew M. S. <mm...@ta...>]

Terry Fernandez wrote:

 > In the File Analysis component of Autopsy (v1.70),  I can see the 
deleted file and the size with the metadata information. When I try to 
export it only 8KB is exported, while the file size shown is around 
185MB. I am sure I am missing a step somewhere, Can you assist. The 
image is a FAT32 partition  and the file in question is a pst file.
 >
 > Terry Fernandez
 >
 > Tel: 312.260.3223
 >
 > Vnet: 894.3223
 >
Terry-

Whoa, I've been here before. Here is the long and short of it.... You 
most likely won't be able to recover the entire file.

As I'm sure you've seen with deleteted NTFS files, it's a rather simple 
process to export the deleted file. However with deleted FAT32 files, 
Autopsy does not perform a file re-assembly. A much more through 
explanation could be provided by the group, however the simple truth is, 
portions of your deleted file has most likely been reallocated to other 
files on the disk.

Here's the basic problem, you've got a 185 meg file, that's roughly 
378,880 (512 byte) sectors. Now, chances are that file has not been 
written to the disk sequentially, it's rare to find 185 megs of free 
space in nice simple sequential sectors. However, for our example, let's 
say it is.

Now let's look at what you know, the starting sector and the size, right?

Let's say the starting sector is 654321 and you know you need to go 
378,880 sectors. You can take this information to the Data Unit tab and 
punch in the starting sector and number of sectors you need to go and it 
will return to you the output, your file.

Now, quite honestly I don't expect this to give you the completely 
accurate file. Why? Well there's a very good chance the file was not 
written sequentially, second, the FAT File allocation Table doesn't 
retain the any information as to where the rest of the file is.

There is a way to figure out how much of the file your are missing. Go 
to the Metadata tab, you will be provided with a complete file 
allocation table, you won't find your starting sector there as it is 
deallocated, however you will see how many sectors within your possible 
file start and end have been allocated to other files.

A good rule of thumb to consider when recovering deleted files from a 
FAT parition, smaller is better.

Honestly, your best course of action may be keyword searches against the 
drive, I can't remember, but pst files may contain some text based content.

Now, this is all based on reading, experience, and luck.

Someone on this list may have some better suggestions.

Good Luck!

Matt
mm...@ta...

[sleuthkit-users] recovering large files using Autopsy

[Terry F. <Ter...@mc...>]

In the File Analysis component of Autopsy (v1.70),  I can see the
deleted file and the size with the metadata information. When I try to
export it only 8KB is exported, while the file size shown is around
185MB. I am sure I am missing a step somewhere, Can you assist. The
image is a FAT32 partition  and the file in question is a pst file.

Terry Fernandez
Tel: 312.260.3223
Vnet: 894.3223

Re: [sleuthkit-users] mounted origin filesystems ?

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

Josep M Homs <jm...@me...> said:
> I wonder if it's really desirable to make the dd images from a live
> system mounting the origin hacked filesystems from it , and transferring 
> the images with ssh / nc to the analisys host , or if it would be also 
> correct to do it with the origin hacked system up and running with the 
> filesystems mounted.
> Would I find any problems with the second option ?


I'm not sure if I fully understand the question.  Are you booting from a trusted OS 
with the first option (such as the FIRE or knoppix Linux CD)?   And the second 
scenario you are using the suspect OS?  

Both of them will work, but in the second scenario you risk having an image that is 
not complete.  Since it may take 10 or 15 minutes to image, a lot can change at the 
begining of the disk that was imaged at time X versus time X+15 when the end of the 
disk is imaged.  

The other downside, is that you can not generate an MD5 of the disk before imaging 
in scenario 2.  That means that you cannot verify that the imaging generated an 
acurate copy.

Also, in the future it could be possible for attackers to modify the OS so that a live 
acquisition does not copy invalid data  (the equivalent of a modified 'ls' now).

brian

[sleuthkit-users] mounted origin filesystems ?

[Josep M H. <jm...@me...>]

Hi ,
I wonder if it's really desirable to make the dd images from a live
system mounting the origin hacked filesystems from it , and transferring 
the images with ssh / nc to the analisys host , or if it would be also 
correct to do it with the origin hacked system up and running with the 
filesystems mounted.
Would I find any problems with the second option ?
Any suggestion on this topic ?

Best regards ,
Josep M Homs

Re: [sleuthkit-users] Viewing Image files in autopsy

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

Rich,

> Howdy,
> 
> I am a new user to the Sleuthkit and Autopsy (love 'em
> BTW) and have a question.  Whne veiwing the case,
> under file analysis I see the files represented, cool,
> and when I click on them I get a frame at the bottom
> with some info about them.  But how do I view the
> files, especially jpg/gif types (or any type for that
> matter).  When I click 'export' it wants to export a
> raw file but it won't show me the pic after I export
> it.

If the 'File Type' value has the string 'image data', 'HTML document', or 'bitmap data' 
in it, then Autopsy will provide a 'View' link next to the 'export' button.  Click on that 
and it will show the actual image or HTML page.  If the file type is not one of the 
above, then it may not really be a graphic image.  The 'File Type' is identified using 
the 'file' command.  

> 
> What am I doing wrong??  I accidentally got a word
> file to open, BUT it was called image.dls in the
> export folder nothiong like its file name from the
> file analysis.

The 'image.dls' file is likely the file that was created when you told Autopsy to 
extract the unallocated data.  The '.dls' extension is used to identify the files created 
by 'dls', which is done from the keyword search mode.

brian

[sleuthkit-users] Viewing Image files in autopsy

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

Howdy,

I am a new user to the Sleuthkit and Autopsy (love 'em
BTW) and have a question.  Whne veiwing the case,
under file analysis I see the files represented, cool,
and when I click on them I get a frame at the bottom
with some info about them.  But how do I view the
files, especially jpg/gif types (or any type for that
matter).  When I click 'export' it wants to export a
raw file but it won't show me the pic after I export
it.

What am I doing wrong??  I accidentally got a word
file to open, BUT it was called image.dls in the
export folder nothiong like its file name from the
file analysis.

Am I being a bonehead and missing something
obvious????
Help!

Thanks in advance, 
Rich

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com