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

[sleuthkit-users] Hash "Magic" File?

[Sherwood M. <she...@ph...>]

Any suggestions on where I might download a decent hash file that is ready
for use with Autopsy?

Thanks
Sherwood McGowan
The Phoenix Group
Executive Protection & Investigation

[sleuthkit-users] Recovering unallocated using Autopsy

[A Z <fbs...@er...>]

I am a first time user of this software, so far it seems fairly easy. I
have a situation where I had a 80gb drive mount mistakenly rm -rf'd on.
This drive was immidiately taken offline (unmounted End of March 2003 ).
So nothing new would have been written to it. I only need to recover one
portion of it.

I'll cut paste the info on this Directory:

-------------------------

Pointed to by file:
/home/share/80gb1/CF-dls (deleted)
File Type:
empty 
MD5:
d41d8cd98f00b204e9800998ecf8427e
Details:
inode: 18429696 
Not Allocated 
Group: 1684 
uid / gid: 0 / 0 
mode: ---------- 
size: 0 
num of links: 0 

Inode Times: 
Accessed: Sun Mar 23 05:48:25 2003 
File Modified: Sun Mar 23 05:48:25 2003 
Inode Modified: Sun Mar 23 05:48:25 2003 

--------------------------

On the File Analysis list, it says this directory cannot be expanded into.
I Can't seem to export anything either.
When I tried to use sorter via file type on the entire drive image, it 
skips all unallocated:

--------------------------
Files (38911) 

Allocated (123) 
Unallocated (38788) 
Files Skipped (38911) 

Non-Files (38911) 
'ignore' category (0) 
--------------------------


My question is what is the best method to recover all the file that had 
existed under the CF-dl's directory ( about 4gb worth of JPGs )


Any guidance will be appreciated.

Thanks!

RE: [sleuthkit-users] Unable to import ignore hash db into Autops y

[Baskin, B. <ba...@dc...>]

Thank you for the quick reply.  The mistake was mine, in which I did =
not
have the NSRL files present at the time of install.  Since it was over =
a
week between install and putting a case in, the fact escaped my mind.  =
I
re'make'd Autopsy with the NSRL files inplace, the indexing commenced, =
and I
was able to add a host with the NSRL file.

I have taken your comments on the validity of NSRL under consideration. =
 I'm
working with Mary Shriner, teaching Autopsy/Solaris investigations, so =
that
may be a point that we may bring up within the class.  We won't be =
teaching
the NSRL as a known good, but I will be on the lookout for whatever =
changes
you have coming.

Thank you
Brian Baskin

-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...]
Sent: Wednesday, October 22, 2003 4:21 PM
To: Baskin, Brian
Cc: 'sle...@li...'
Subject: Re: [sleuthkit-users] Unable to import ignore hash db into
Autopsy



On Wednesday, October 22, 2003, at 01:26  PM, Baskin, Brian wrote:

> I am a new member of the mailing list, so forgive me if this is a=20
> topic that's been previously covered.
>

Nope, it hasn't been covered before.

> When running Autopsy, I create my case, and proceed to add a host to=20
> it.=A0 I give the host a directory name, description, time zone, and =
the=20
> path to the ignore hash file (/data/nsrlfile).=A0 The NSRL file is a=20
> comma-delimited ASCII database.=A0 When I click to add the host,=20
> everything starts fine.

The NSRL is configured at installation time because it is not platform=20
specific.  You should have been prompted for its location when you=20
installed Autopsy (unless you did it from one of the RPMs maybe).  The=20
host-based databases are for platform specific hashes or case-specific=20
hashes.  So, this includes the hashes from the system before it was=20
deployed, child porn pictures, or Solaris rootkits etc.

The error is because the host-based databases must be in the md5sum=20
format of 'HASH    name'.  Although, the Perl error of the unitialized=20
value needs to be fixed (i'll get on that and make it more pretty).

On this topic though (and it was covered in one of the recent Sleuth=20
Kit Informers), the NSRL is no longer used in the file type sorting as=20
a 'known good' database.  The NSRL includes both known good and known=20
bad files and there is not an easy way to distinguish between the two.  =

So, I have removed the NSRL functionality from file type sorting until=20
a solution is identified.

brian


>
> It creates the host directory, the gives the following output:
>
> Exclude Database has not been indexed - it will be as an md5sum file
> -------------------------------------------------------
> Use of uninitialized value in concatenation (.) on string at=20
> /tools/autopsy-1.74/autopsyfunc.pm line 9304, line 1.=A0 Invalid =
md5sum=20
> format in file.
>
> "SHA-1", "Filename", "FileSize", "ProductCode", "OpSystemCode", =
"MD4",=20
> "CRC32", "SpecialCode" Extracting Data from Database (/data/nsrlfile)
>
> Now, eventhough that message appears, the host is added, and I can=20
> continue on with the case.=A0 But, I'm under the impression that the=20
> ignore has database is not being used.=A0 Is this something that has=20
> seen before, and could someone give guidance on how to use these hash =

> databases.
>
>
> Brian Baskin
> DCITP
>

Re: [sleuthkit-users] Unable to import ignore hash db into Autopsy

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

On Wednesday, October 22, 2003, at 01:26  PM, Baskin, Brian wrote:

> I am a new member of the mailing list, so forgive me if this is a=20
> topic that's been previously covered.
>

Nope, it hasn't been covered before.

> When running Autopsy, I create my case, and proceed to add a host to=20=

> it.=A0 I give the host a directory name, description, time zone, and =
the=20
> path to the ignore hash file (/data/nsrlfile).=A0 The NSRL file is a=20=

> comma-delimited ASCII database.=A0 When I click to add the host,=20
> everything starts fine.

The NSRL is configured at installation time because it is not platform=20=

specific.  You should have been prompted for its location when you=20
installed Autopsy (unless you did it from one of the RPMs maybe).  The=20=

host-based databases are for platform specific hashes or case-specific=20=

hashes.  So, this includes the hashes from the system before it was=20
deployed, child porn pictures, or Solaris rootkits etc.

The error is because the host-based databases must be in the md5sum=20
format of 'HASH    name'.  Although, the Perl error of the unitialized=20=

value needs to be fixed (i'll get on that and make it more pretty).

On this topic though (and it was covered in one of the recent Sleuth=20
Kit Informers), the NSRL is no longer used in the file type sorting as=20=

a 'known good' database.  The NSRL includes both known good and known=20
bad files and there is not an easy way to distinguish between the two. =20=

So, I have removed the NSRL functionality from file type sorting until=20=

a solution is identified.

brian


>
> It creates the host directory, the gives the following output:
>
> Exclude Database has not been indexed - it will be as an md5sum file
> -------------------------------------------------------
> Use of uninitialized value in concatenation (.) on string at=20
> /tools/autopsy-1.74/autopsyfunc.pm line 9304, line 1.=A0 Invalid =
md5sum=20
> format in file.
>
> "SHA-1", "Filename", "FileSize", "ProductCode", "OpSystemCode", "MD4",=20=

> "CRC32", "SpecialCode" Extracting Data from Database (/data/nsrlfile)
>
> Now, eventhough that message appears, the host is added, and I can=20
> continue on with the case.=A0 But, I'm under the impression that the=20=

> ignore has database is not being used.=A0 Is this something that has=20=

> seen before, and could someone give guidance on how to use these hash=20=

> databases.
>
>
> Brian Baskin
> DCITP
>

[sleuthkit-users] Unable to import ignore hash db into Autopsy

[Baskin, B. <ba...@dc...>]

I am a new member of the mailing list, so forgive me if this is a topic
that's been previously covered.

Specs:
Sun SPARC Ultra 5 (32-bit) running SunOS 8
Autopsy 1.74
SleuthKit 1.65
perl 5.6.1
gcc 2.95.3
NIST NSRL hash database (1.2 and 2.2x versions)

When running Autopsy, I create my case, and proceed to add a host to it.  I
give the host a directory name, description, time zone, and the path to the
ignore hash file (/data/nsrlfile).  The NSRL file is a comma-delimited ASCII
database.  When I click to add the host, everything starts fine.
It creates the host directory, the gives the following output:

Exclude Database has not been indexed - it will be as an md5sum file
-------------------------------------------------------
Use of uninitialized value in concatenation (.) on string at
/tools/autopsy-1.74/autopsyfunc.pm line 9304, line 1.  Invalid md5sum format
in file.
"SHA-1", "Filename", "FileSize", "ProductCode", "OpSystemCode", "MD4",
"CRC32", "SpecialCode" Extracting Data from Database (/data/nsrlfile)

Now, eventhough that message appears, the host is added, and I can continue
on with the case.  But, I'm under the impression that the ignore has
database is not being used.  Is this something that has seen before, and
could someone give guidance on how to use these hash databases.


Brian Baskin
DCITP

Re: [sleuthkit-users] Extract data stream from ext2 directory

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

On Saturday, October 18, 2003, at 05:56  PM, SecMan wrote:

> I am analyzing a dd of an ext2 (linux) file system that has a "hidden" 
> data
> stream in a subordinate director (/adir)
> after teh file names conatined in the directory there is a bunch of 
> data -
> how can I extract it for firther analysis?

Do you mean that after the directory entries in the directory fragments 
that there is data that you are interested in?  I've never heard of 
that before.  How do you know it is there?

Well, if it is the case that it follows the directory entries, then 
find out the inode number of the directory (it should be the same inode 
as the '.' entry) within '/adir'.  Then use 'icat' or the Meta Data 
mode of autopsy and plug in that address.  You'll have to parse out the 
directory entries from the data block, but your data should be there.

brian

[sleuthkit-users] Extract data stream from ext2 directory

[SecMan <se...@ta...>]

I am analyzing a dd of an ext2 (linux) file system that has a "hidden" data
stream in a subordinate director (/adir)
after teh file names conatined in the directory there is a bunch of data -
how can I extract it for firther analysis? 

Thomas G Conley, GSEC

[sleuthkit-users] DD Split and Physical MD5

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

OK I need some assistance.  Whats the best way to md5
an image that has been split into 640mb chunks??  I
need to verify my pre and post acquisition hash
values...  But I use split during acquisition and the
files are now 640mb, the original drive was 3.2gb.... 
so now I have like 5 dd images.

help????

I know I could cat them together but they are on a
fat32 drive that has a 2gb file size limit.

Thanks in advance,
Rich

[sleuthkit-users] Re: [linux_forensics] DD Split and Physical MD5

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

On Thursday, October 16, 2003, at 09:03  PM, Rich Thompson wrote:

> OK I need some assistance.  Whats the best way to md5
> an image that has been split into 640mb chunks??  I
> need to verify my pre and post acquisition hash
> values...  But I use split during acquisition and the
> files are now 640mb, the original drive was 3.2gb....
> so now I have like 5 dd images.
>
> help????
>
> I know I could cat them together but they are on a
> fat32 drive that has a 2gb file size limit.

cat should work with a pipe:

# cat img.01 img.02 img.03 | md5sum

brian

RE: [sleuthkit-users] OS X Errors

[McMillon, M. <Mat...@qw...>]

The strings wrapper is installed, but I'll verify that autopsy is using =
it and not the other (not sure why it would, but you never know.)  =
Although with previous version of autopsy the queries wouldn't run at =
all--the negative byte offset error was not fatal in this case, i.e. =
some results were still returned.

My buddy ran an "extra super-duper" wiping program on the drive.  I =
believe the program changes the file names to something from /dev/random =
(or similar) before deleting them, which may explain the existence of =
the no-printable character in the fls data.  It also does funky things =
with the drive head placement while writing data, which could cause some =
additional weirdness.

> Errors:
>
> Error parsing string: -/- * 0:  =A9=A3'@`=DF  =A9=A3$@'2@?<@(=EDM
> Error parsing string: ^=E7=FF=BF=D5 @p%@`!      0000.00.00 00:00:00 =
(GMT)     =20
>  0000.00.00 00:00:00 (GMT)       0000.00.00 00:00:00 (GMT)       0     =

>   0       0

Wow!  What is happening is that the 'fls' tool is looking in the=20
directory for deleted file name entries.  The above data met its=20
requirements for a valid deleted structure.  There are currently no=20
name checks because it is possible to make file names with=20
non-printable ASCII.  Autopsy though, will only accept printable ASCII.=20
  Therefore, I must either update Autopsy so that it reads unprintable=20
ASCII (although you would never see it in the browser ..) or add some=20
constraints into 'fls'.  Either way, you can ignore the message.  It=20
processed the rest of the entries after it found the error.

> ERROR: Negative byte offset (-89) Your version of strings likely does
> not support large files

Did you install the strings script for OS X?  The strings that comes=20
with OS X doesn't support the same flags as binutils and this script=20
converts the syntax (if you put it in /usr/local/bin).

	http://prdownloads.sourceforge.net/autopsy/strings?download

brian

Re: [sleuthkit-users] OS X Errors

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

On Monday, October 13, 2003, at 09:15  AM, McMillon, Matt wrote:

> I'm consistanly getting these two errors on a Redhat 7.3 ext3 image. =20=

> Also, the OS X compliled fsstat does not seem to differnitate between=20=

> ext2 & 3.

The only difference between ext2 and ext3 is that ext3 has a journal,=20
but The Sleuth Kit does not read the journal so there should be no=20
difference.

> Errors:
>
> Error parsing string: -/- * 0:  =A9=A3'@`=DF  =A9=A3$@'2@?<@(=EDM
> Error parsing string: ^=E7=FF=BF=D5 @p%@`!      0000.00.00 00:00:00 =
(GMT)     =20
>  0000.00.00 00:00:00 (GMT)       0000.00.00 00:00:00 (GMT)       0    =20=

>   0       0

Wow!  What is happening is that the 'fls' tool is looking in the=20
directory for deleted file name entries.  The above data met its=20
requirements for a valid deleted structure.  There are currently no=20
name checks because it is possible to make file names with=20
non-printable ASCII.  Autopsy though, will only accept printable ASCII.=20=

  Therefore, I must either update Autopsy so that it reads unprintable=20=

ASCII (although you would never see it in the browser ..) or add some=20
constraints into 'fls'.  Either way, you can ignore the message.  It=20
processed the rest of the entries after it found the error.

> ERROR: Negative byte offset (-89) Your version of strings likely does=20=

> not support large files

Did you install the strings script for OS X?  The strings that comes=20
with OS X doesn't support the same flags as binutils and this script=20
converts the syntax (if you put it in /usr/local/bin).

	http://prdownloads.sourceforge.net/autopsy/strings?download

brian=

[sleuthkit-users] OS X Errors

[McMillon, M. <Mat...@qw...>]

I'm consistanly getting these two errors on a Redhat 7.3 ext3 image.  =
Also, the OS X compliled fsstat does not seem to differnitate between =
ext2 & 3.


Errors:

Error parsing string: -/- * 0:  =A9=A3'@`=DF  =A9=A3$@'2@?<@(=EDM=20
Error parsing string: ^=E7=FF=BF=D5 @p%@`!      0000.00.00 00:00:00 =
(GMT)       0000.00.00 00:00:00 (GMT)       0000.00.00 00:00:00 (GMT)    =
   0       0       0=20


ERROR: Negative byte offset (-89) Your version of strings likely does =
not support large files

Matt

--
=20
Matt McMillon, GSEC
Staff Engineer - Qwest Corporate Security
=20
PGP Public Key: =
http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x2E0ABABE
=20
Only the named recipient(s) should read this e-mail and/or it's =
attachments. It may contain privileged or confidential information.  If =
you are not a named recipient or you received this e-mail by mistake, =
please notify me immediately by reply e-mail and delete this message. =
Jusqu'ici tout va bien. =20

Re: [sleuthkit-users] RH9 install issue?

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

On Tuesday, October 7, 2003, at 01:26  AM, Eagle Investigative 
Services, Inc. wrote:

> Hi,
>
> I've just installed aleuthkit which seemed to install
> without a glitch, and during the autopsy install, I got
> as far as where it asked for the evidence directory, and
> after I entered the created directory, the install
> quits and I'm taken back to a shell prompt.
>
> Autopsy is not installed.
>
Niall,

What do you mean by "not installed"?  Is there an 'autopsy' file in the 
directory?  You will need to run autopsy by using "./autopsy" from 
within the directory where you compiled it.  Autopsy is not copied to 
any of the system directories that are in your path.  You will need to 
copy it to a different location or change your path if you want to run 
it without "./autopsy".

If the autopsy file does not exist, then there is a strange problem 
because the configure script doesn't do much of anything after you 
enter the evidence locker location.  Did it say "Settings saved to 
conf.pl"?

brian

[sleuthkit-users] RH9 install issue?

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

Hi, 

I've just installed aleuthkit which seemed to install 
without a glitch, and during the autopsy install, I got 
as far as where it asked for the evidence directory, and 
after I entered the created directory, the install 
quits and I'm taken back to a shell prompt. 

Autopsy is not installed. 

Any ideas?

Niall.

Re: [sleuthkit-users] Autopsy on MacOSX

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

Philippe,

You need the developers package from the Apple website (it is free).  
That will give you the C compiler that you need to install The Sleuth 
Kit and Autopsy using the instructions in the tar ball.  For Autopsy, 
there is also a script that you can put into /usr/local/bin/ and it 
makes the 'strings' that comes with OS X look like the GNU binutils 
strings.  The instructions for that are in the comments of the script 
file (which is in the downloads section of sleuthkit.org).

brian


On Saturday, October 4, 2003, at 10:38  AM, philippe jarlov wrote:

>
> Hello
>
> Can someone explain me how I can install autopsy on MacOS X ? please
>
> Thank you
>
> Philippe Jarlov

[sleuthkit-users] Autopsy on MacOSX

[philippe j. <phi...@wa...>]

Hello

Can someone explain me how I can install autopsy on MacOS X ? please

Thank you

Philippe Jarlov


-- 

www.logirc.org
(logiciel de monitoring spécifique)

http://monitoring.tuxfamily.org
(référencement de liens et documentation
en français sur Linux)

Re: [sleuthkit-users] Autopsy "File Analysis" problem

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

> I have just installed the Sleuthkit 1.65 and Autopsy 1.74 on a RH9
> system. During installation everything seemed fine, but now,
> unfortunately, the "File Analysis" mode in Autopsy seems to be broken.
> Alle files are displayed like this:
>
> Error parsing string: r/r * 5: Jimmy Jungle.doc (_IMMYJ~1.DOC)
> 2002.04.15 14:42:30 () 2002.09.11 00:00:00 () 2002.09.11 08:49:48 ()
> 20480 0 0
>
Stefan,

This is a known problem that I have not been able to reproduce.  
Hopefully you can help with this.

This error occurs because you used an invalid timezone when you set the 
host up.  There should be a timezone value in between the '()' in the 
above line.  For example, my output is '2002.04.15 14:42:30 (EST)' for 
the SOTM.  Whenever I test this by making up an invalid timezone, it 
defaults to GMT and there is '(GMT)' in the line.  All of my systems 
return some timezone value in the parenthesis.

I would like to add a check to add 'GMT' when no timezone is given by 
the system, but I first need to verify that the default value is 
actually GMT.  To test this, we need a non-FAT image because FAT does 
not use timezones (hence why my times are the same as yours for the 
SOTM).  So, if you could run the following as 'root', we can use your 
Linux file systems as a test (assuming that you have EXT3FS and not 
Resier).

# istat -f linux-ext3 -z blah /dev/hda1 2

# istat -f linux-ext3 -z GMT /dev/hda1 2

The first will get the MAC times from the root directory with a made up 
timezone and it should have no timezone in the '()'.  The second will 
run it with a valid timezone and should have '(GMT)'.  Can you let me 
know the time difference between the two outputs, or ideally send the 
outputs to me (you can do it off list).

thanks,
brian

[sleuthkit-users] Autopsy "File Analysis" problem

[Stefan D. <st...@st...>]

Hello to everyone,

I have just installed the Sleuthkit 1.65 and Autopsy 1.74 on a RH9
system. During installation everything seemed fine, but now,
unfortunately, the "File Analysis" mode in Autopsy seems to be broken.
Alle files are displayed like this:

Error parsing string: r/r * 5: Jimmy Jungle.doc (_IMMYJ~1.DOC)
2002.04.15 14:42:30 () 2002.09.11 00:00:00 () 2002.09.11 08:49:48 ()
20480 0 0

I have already tried to install a perl 5.6 package from RH7.3, with no
effect. Any clues?

Thanks in advance,
Stefan
-- 
Stefan Divjak alias st...@st...
Graz, Austria, Europe, Earth

Re: [sleuthkit-users] Autopsy - Incorrect Cookie error

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

[Lets try this again since the ca...@sl... email didn't go=20
through]


On Friday, September 5, 2003, at 09:50  PM, Prachid T. wrote:

> Hi,
> I'm using autopsy-1.74 and sleuthkit-1.65 with
> Perl 5.8 on Slackware (kernel 2.4.21).
> =A0
> I got a problem when I try to 'ADD HOST'.
> It lead to 'Add a New Host To Diskette' page, but all
> image files are not shown.

The images are added after the host is added.  Each case can have 1+=20
hosts and each host can have 1+ images.  So, just create the host and=20
then you can add the images.  It sounds like you are expecting the=20
older version of Autopsy though.  It has changed and you enter the path=20=

for the images now.

> =A0I went to log file and found this...
> Sat Sep=A0 6 12:44:19 2003: Case diskette opened
> Sat Sep=A0 6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
> Sat Sep=A0 6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
> Sat Sep=A0 6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
> Sat Sep=A0 6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
> Sat Sep=A0 6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
> I'm wondering if anyone has this problem?

These are different.  You probably restarted Autopsy and did a refresh=20=

on the browser and the cookie value (the big random number in the URL)=20=

had changed.

brian

[sleuthkit-users] Autopsy - Incorrect Cookie error

[Prachid T. <pr...@cs...>]

Hi,
I'm using autopsy-1.74 and sleuthkit-1.65 with
Perl 5.8 on Slackware (kernel 2.4.21).

I got a problem when I try to 'ADD HOST'.
It lead to 'Add a New Host To Diskette' page, but all
image files are not shown.

I went to log file and found this...
Sat Sep  6 12:44:19 2003: Case diskette opened
Sat Sep  6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
Sat Sep  6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
Sat Sep  6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
Sat Sep  6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2
Sat Sep  6 12:44:23 2003: ERROR: Incorrect Cookie from:192.168.0.2

I'm wondering if anyone has this problem?

Prachid T.

Re: [sleuthkit-users] autopsy install problem

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

[my sleuthkit.org email is having some issues, so I'll respond from 
this acct]


On Tuesday, September 2, 2003, at 05:36  PM, m0t...@ne... wrote:
> I am trying to install The Sleuthkit (v1.65) and Autopsy (v1.74) to an 
> Open BSD 3.3 system.
>
> Sluethkit installs with the following messages:
>
> scooby# make
> cd src/fstools; make "CC=gcc" MAKELEVEL=
> gcc -DOPENBSD3 -DVER=\"1.65\" -I../misc -O -Wall -g  -c fs_buf.c
> In file included from fs_buf.c:30:
> fs_tools.h:201: #error "This operating system is not supported"
> *** Error code 1

Oops, my bad.  Edit src/fstools/fs_tools.h and make line 140

#if defined(OPENBSD2) || defined (OPENBSD3)

instead of just:

#if defined(OPENBSD2)

I'll have it fixed in the next release.

> When I try to install Autopsy, I am prompted with the following:
> Enter The Sleuth Kit Directory:
> /usr/local/sleuthkit-1.65/bin
> The Sleuth Kit was not found (try again):
>
> What exactly is the Autopsy install looking for, and where is it 
> normally installed?  Did the error(s) in the sleuthkit install have 
> anything to do with this?  Any suggestions?
>
Yea, the tools were not created because The Sleuth Kit installation 
failed.  Make the edit, redo make, and then do 'make' for autopsy.  I 
can send you a copy of the updated header file if needed.


brian

[sleuthkit-users] autopsy install problem

[<m0t...@ne...>]

I am trying to install The Sleuthkit (v1.65) and Autopsy (v1.74) to an Open BSD 3.3 system.

Sluethkit installs with the following messages:

scooby# make
cd src/misc; make "CC=gcc" MAKELEVEL=
gcc -DOPENBSD3 -DVER=\"1.65\" -O -Wall -g  -c mymalloc.c
gcc -DOPENBSD3 -DVER=\"1.65\" -O -Wall -g  -c error.c
gcc -DOPENBSD3 -DVER=\"1.65\" -O -Wall -g  -c strerror.c
gcc -DOPENBSD3 -DVER=\"1.65\" -O -Wall -g  -c split_at.c
ar rv aux_lib.a mymalloc.o error.o strerror.o split_at.o
ar: creating archive aux_lib.a
a - mymalloc.o
a - error.o
a - strerror.o
a - split_at.o
ranlib aux_lib.a
cd src/hashtools; make "CC=gcc" MAKELEVEL=
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c md5.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c md5c.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.  -o ../../bin/md5 md5.o md5c.o
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c sha1.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.  -o ../../bin/sha1 sha1.o
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c hfind.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c nsrl.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c tm_lookup.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c md5sum.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.   -c hk.c
gcc -DOPENBSD3 -DVER=\"1.65\"  -O -Wall -g -I.  -o ../../bin/hfind hfind.o nsrl.o tm_lookup.o md5sum.o hk.o
cd src/fstools; make "CC=gcc" MAKELEVEL=
gcc -DOPENBSD3 -DVER=\"1.65\" -I../misc -O -Wall -g  -c fs_buf.c
In file included from fs_buf.c:30:
fs_tools.h:201: #error "This operating system is not supported"
*** Error code 1

Stop in /usr/local/sleuthkit/src/fstools.
*** Error code 1

Stop in /usr/local/sleuthkit/src/fstools (line 22 of Makefile).
*** Error code 1

Stop in /usr/local/sleuthkit (line 17 of Makefile).

When I try to install Autopsy, I am prompted with the following:
Enter The Sleuth Kit Directory:
/usr/local/sleuthkit-1.65/bin
The Sleuth Kit was not found (try again):

What exactly is the Autopsy install looking for, and where is it normally installed?  Did the error(s) in the sleuthkit install have anything to do with this?  Any suggestions?

Thanks for any help.
Randy




________________________________________________________________
The best thing to hit the internet in years - NetZero HiSpeed!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month -visit www.netzero.com to sign up today!

Re: [sleuthkit-users] Sleuth Kit 1.65 and Autopsy 1.74 Release

[Ralf S. <li...@sp...>]

Am Fre, 2003-08-29 um 00.44 schrieb Brian Carrier:
>=20
>=20
> New versions of both tools are on the website.
RPM-Versions updated:
https://www.spenneberg.com/6.html?subject=3D%2FForensics%2F

Cheers,

Ralf
--=20
Ralf Spenneberg
RHCE, RHCX

Book: Intrusion Detection f=FCr Linux Server   http://www.spenneberg.com
IPsec-Howto				     http://www.ipsec-howto.org
Honeynet Project Mirror:                     http://honeynet.spenneberg.org

[sleuthkit-users] Sleuth Kit 1.65 and Autopsy 1.74 Release

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

New versions of both tools are on the website.



http://www.sleuthkit.org/sleuthkit/index.php

http://www.sleuthkit.org/autopsy/index.php



MD5 (sleuthkit-1.65.tar.gz) = f736a71f7cf849f681a382f1d30ea2c8

MD5 (autopsy-1.74.tar.gz) = 89041a2f18340ab884df3f4627a2e0fb



Major Highlights include:

- Bug fixes with keyword searching

- Support for raw and swap data

- Removed NSRL as a known good database until a better solution

  can be found to seperate them from the known bad entries

- The Perl 5.8 buffer issues are better handled.  



brian

RE: [sleuthkit-users] Feature request

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

Niall,

I understand the "big picture" use for the functionality, but there
needs to be more than just a flag for 'sorter'.  The Sleuth Kit
doesn't really do automatic file recovery right now.  TSK only
processes what the file system says.  For example, a deleted FAT
file has the starting cluster, but the rest of the FAT entries are 
likely wiped.  Therefore, all TSK will do is recover that first cluster.
You can manually extract the remaining X clusters that make up
the file, but it is a manual process that 'sorter' will not do for you.

Furthermore, if the cluster that the deleted file name points to has
been reallocated and belongs to a new file, TSK does not check for
that and will report the type of the new cluster.  So, you may
get very wrong results for deleted files with TSK.  The automated
process can occur in the future, but it hasn't yet.

The main goal for 'sorter' is to provide the equivalent to the
thumbnail view of EnCase and also do it for more than just images.

thanks,
brian


On 20 Aug 2003 08:33 PDT you wrote:

> Brian,
> 
> >>I don't know how useful it would be though
> >>because The Sleuth Kit doesn't automatically do file recovery.
> 
> Think about:
> 
> 1. Many times we (investigators) get called by attorneys and
> clients to look at their computers, or the computers belonging
> to their clients. In the civil litigation world, the money
> is doled out slowly and carefully. Telling someone that it
> will take 10 hours to get all deleted images, at $150 per hour
> is not appetizing. Especially since you have the to issue the caveat
> that we may or may not find what they want.
> 
> Being able to print off pages of preview thumbnails of deleted
> messages would allow an investigator to simply import his partition image,
> run sorter with the Deleted Only flag, and let the software run.
> 
> The print off the pages of graphic file previews and take those
> to the client.
> 
> Total investigator hands-on time invested? Probably 2 hours, or
> $300, tops. Sorter does the work.
> 
> If the preview thumbnails show some derogatory content, then the
> customer is much more comfortable spending more money to retrieve
> or restore those graphic files with timelines etc.
> 
> 2. SMART has an option to only list deleted files. (All files, not
> just graphic image files). and then export the graphic files if you like.
> 
> 3. Encase (as it has been described to me) offers exactly what I describe
> in scenario 1.
> 
> Also, having a list of deleted files in text format, by name, would
> be useful....something like
> 
> DELETED: c\Documents And Settings\Microsoft Word\Iloveyour***.doc
> DELETED: c\Roxio\Music Files\SongIBurnedForMyLover.mp3
> 
> Just an idea....
> 
> >>I was actualy considering making an option to take the deleted files
> >>out of 'sorter' because I have found they clutter the whole thing
> >>up more than they help.
> 
> Well, I just ran it on an NTFS image . I checked some of the files that the
> preview
> showed as deleted (maybe 5 or 6 files) and they were, in fact, deleted
> files.
> 
> I figured since they were marked as deleted in the browser, it wouldn't
> be a big deal to separate them in sorter (I am not a coder, just an assumer)
> 
> I'll go back and see if I can find any that are marked deleted that are not
> correct.
> 
> For the preview, I *think* it would be safe enough to have something that
> would show files that APPEARED to be deleted, and then have further analysis
> to prove if in fact they were deleted.
> 
> Maybe two separate output folders?
> 
> I see the option as a "whet your appetite" option for clients, and others.
> 
> Niall.
> Eagle Investigative Services, Inc.
> 
> 
> 
> 
> 
> -----Original Message-----
> From: sle...@li...
> [mailto:sle...@li...]On Behalf Of Brian
> Carrier
> Sent: Wednesday, August 20, 2003 9:58 AM
> To: in...@ea...; sle...@li...
> Cc: sle...@li...
> Subject: Re: [sleuthkit-users] Feature request
> 
> 
> 
> 
> On 19 Aug 2003 23:52 PDT you wrote:
> > It'd be really nice if the sorter would allow you to choose
> > only deleted files when searching for images.
> >
> > It'd also be very useful since many times, as an investigator
> > I'm only interested in deleted files.
> >
> > Is there a way to modify sorter on the fly to accomplish this?
> 
> I guess I could add that. I don't know how useful it would be though
> because The Sleuth Kit doesn't automatically do file recovery.  For
> a FAT deleted file, it will find the first sector (which should work for
> running 'file' on it), but I'm not sure about other file systems and
> such.  Even if it found the header with FAT, the full file will only
> be recovered if it is done by hand.
> 
> I was actualy considering making an option to take the deleted files
> out of 'sorter' because I have found they clutter the whole thing
> up more than they help.  I was just running it on a Linux system
> and it hundreds of deleted file entries and almost none of them
> were correct.
> 
> In what scenarios do you think it will be useful?
> 
> brian
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Dice.com.
> Did you know that Dice has over 25,000 tech jobs available today? From
> careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
> best hiring companies. http://www.dice.com/index.epl?rel_code=104
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Dice.com.
> Did you know that Dice has over 25,000 tech jobs available today? From
> careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
> best hiring companies. http://www.dice.com/index.epl?rel_code=104
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>