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

[sleuthkit-users] Using Autopsy and the Sleuthkit

[Horner, J. J (JH8) <ho...@y1...>]

Where can I find a good intro to using these packages?  I've got them
installed, installed the NSRL hash sets, and I've got an image loaded to
examine.  I can generally find most things, but I am unsure how to exclude
from my file listings any file that appears to be normal (a.k.a. matches the
hash for a known good OS file).

Any Autopsy HOWTOs anywhere?

Thanks,


J. J. Horner (Jon)
CISSP,CCNA,C3E,CHSS,CHP
NCI Information Systems, Inc.
office: 865-576-0585
cell  : 865-680-1369 

"Individualists Unite!  Dyslexics Untie!"

[sleuthkit-users] No help in archives.

[Chris B. <CBo...@ca...>]

I am new to autopsy. I tried to find answers in the archives but it
looks like they don't go back far enough. I got my case started 'autopsy
-d /mnt/sda1' which gave me the new case screen. I named the case
Mallory and it looks like it created the directory /mnt/sda1//Mallory. I
then went to add the host and it keeps telling me that it is a invalid
host value? I used '/mnt/sda1 and every other  possible combination with
the same result. I checked my write permissions to where I am trying to
send it and that is not a problem. A little help please.=20
=20
Chris Bolyard
=20
Canyon County Sheriff's Office
1115 Albany Street
Caldwell ID  83605
=20
454-7248
=20
cbo...@ca...
=20
=20
=20

Re: [sleuthkit-users] File attributes on a Linux second extended file system

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

On Friday, January 9, 2004, at 04:44  PM, McMillon, Matt wrote:

> I have a file that I believe was deleted after setting chattr +s on it.
> Is there any way to confirm this?

You can look for a fragment that has all zeros in it .. :)

> Some scripts were found that show
> that the user knew how to do this, but can't confirm that it was done 
> on
> a particular file.

If you have an older version of LInux where the block pointers are not 
wiped, then you can see if the file points to blocks that have zeros.  
If you can figure out the inode that the file used, then you can try 
'istat' or the Meta Data mode of Autopsy and see if it says "Secure 
Delete".  I'm not sure if the attribute flags are cleared when the file 
is deleted.

brian

[sleuthkit-users] File attributes on a Linux second extended file system

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

I have a file that I believe was deleted after setting chattr +s on it.
Is there any way to confirm this?  Some scripts were found that show
that the user knew how to do this, but can't confirm that it was done on
a particular file.

Thank!

--
=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.
Quis custodiet istos custodus? =20

Re: [sleuthkit-users] Mactime output

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

Tranh,

How did you make the body file?  Somehow there were two entries in the 
body file before mactime was run. It looks like you ran 'ils' and 
'fls'.  Did you also run mac-robber?  You only need to run ils and fls.

brian


On Friday, January 9, 2004, at 04:00  PM, Thanh Tran wrote:

> Hi,
> I ran mactime on a EXT2 partition and got the
> following output.  It seems like the listing of the
> filenames are somehow duplicated.  Although the file's
> names appear differently (one without the "./" and one
> with the "./"), it is the same file and everything
> else is also the same.  Please let me know what is the
> cause of this.  Thanks.
> P.S: Attached is the mactime text output.
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus<mactime>

[sleuthkit-users] Mactime output

[Thanh T. <ttr...@ya...>]

Hi,
I ran mactime on a EXT2 partition and got the
following output.  It seems like the listing of the
filenames are somehow duplicated.  Although the file's
names appear differently (one without the "./" and one
with the "./"), it is the same file and everything
else is also the same.  Please let me know what is the
cause of this.  Thanks.
P.S: Attached is the mactime text output.

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

[sleuthkit-users] FIDES04 registration - Please circulate.

[Angus M. <an...@n-...>]

Pre-registration for FIDES04 (in Edinburgh on 1st and 2nd March) is now open 
at http://fides04.n-gate.net/

The full programme will be announced within the next two weeks.

We have had a good response to the call for papers. Submissions have been 
received from the USA, Norway, India and UK.

Re: [sleuthkit-users] Tool announcement: Forensic Hash Database

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

Matthias,

This looks promising.  Having a single database that can be updated 
will likely scale better than the current hfind method when using hash 
keeper (which has tons of small databases) and NSRL.

BTW, I've added the "add-on" programs to the download sections of The 
Sleuth Kit and Autopsy.  I included this one, the Indexing patch, the 
foremost patch, and the Unicode patch.  If I forgot any, let me know.

brian

On Tuesday, January 6, 2004, at 04:42  PM, Matthias Hofherr wrote:

> Hello list,
>
> I just finished the initial release of my new GPL project called 
> Forensic
> Hash Database. The goal of the project is to  combine the various 
> hashsum
> sources (NIST NSRL, HashKeeper, KnownGood, Dan Farmer's hashsum archive
> etc.) into a single RDBMS (relational database management system).
> Currently, the database of choice is PostgreSQL, others may follow.
> With an perl-based importer tool, the above mentioned sources may be
> imported into the database. By applying a patch to The Sleuth Kit, 
> hfind
> and sorter may be used in conjunction with the database.

[sleuthkit-users] Sleuth Kit 1.76 Release

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

The 1.76 version of The Sleuth Kit is available at:

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

MD5: 6879b74be4cb2c964935286a11459202

This is mostly a bug fix release.  A more detailed list of changes can 
be found in the CHANGES file in the distribution.

Bug Fixes
o Extra entries were printed from the FAT table in 'fsstat'
o The size of EXT3FS files bigger than 2GB was incorrect
o 'icat -h' was not hiding the holes in the file
o Data storage and printing types for file sizes were incorrect
o 'ffind' could crash with the root directory of a FAT image
o The usage of _ALLOC and _UNALLOC internal flags was not consistent

New Features
o Added support for OS X 10.3
o Upgraded the file version from 3.41 to 4.07


brian

[sleuthkit-users] Tool announcement: Forensic Hash Database

[Matthias H. <mat...@mh...>]

Hello list,

I just finished the initial release of my new GPL project called Forensic
Hash Database. The goal of the project is to  combine the various hashsum
sources (NIST NSRL, HashKeeper, KnownGood, Dan Farmer's hashsum archive
etc.) into a single RDBMS (relational database management system).
Currently, the database of choice is PostgreSQL, others may follow.
With an perl-based importer tool, the above mentioned sources may be
imported into the database. By applying a patch to The Sleuth Kit, hfind
and sorter may be used in conjunction with the database.

Next features on the TODO list are:
- an Autopsy (version 2.0) integration patch
- implement hfind as daemon for persistent database connection
- management web gui
- export tool for database export to flatfiles in HashKeeper, NIST
NSRL,graverobber, md5sum/sha1sum format
- update feature for importer

The Forensic Hash database is currently tested on Linux (Debian) systems.

Download: http://www.forinsect.de/forensics/

Feedback, suggestions, ideas etc. are always welcome.

Matthias

-- 
Matthias Hofherr
mail: mat...@mh...
web: http://www.forinsect.de
gpg: http://www.forinsect.de/pubkey.asc

Re: [sleuthkit-users] Autopsy Cookies

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

Hi Brian,

Am Die, 2004-01-06 um 03.59 schrieb Brian Carrier:
> Therefore, I propose to, by default, not use a cookie if the "remote"=20
> host is 'localhost' or 127.0.0.1.  All other hosts will use a cookie=20
> and there will be a '-c' flag to force a cookie for multiuser localhost=20
> environments.  The '-C' flag will still exist to force no cookies for=20
> the remote host scenario.   I'm also looking into adding an SSL Perl=20
> module so that a remote connection can be easily encrypted.
NO objections at all. I like both ideas (especially the SSL part).=20
Concerning the commandline options I agree too. All these changes will
make autopsy much easier to work with.

Cheers,

Ralf
--=20
Ralf Spenneberg
RHCE, RHCX

Book: VPN mit Linux
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] Autopsy Cookies

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

One more survey question for v2.  The default behavior of autopsy is 
currently to have the random cookie in the URL, which is there to 
prevent unauthorized viewing from the host that has been specified 
(localhost by default).  You can skip the cookie with '-C' or by 
editing the 'conf.pl' file (which I usually do).  I'm assuming that 
most people use autopsy on a single user system with localhost and 
therefore the cookie is not needed and it  becomes annoying.

Therefore, I propose to, by default, not use a cookie if the "remote" 
host is 'localhost' or 127.0.0.1.  All other hosts will use a cookie 
and there will be a '-c' flag to force a cookie for multiuser localhost 
environments.  The '-C' flag will still exist to force no cookies for 
the remote host scenario.   I'm also looking into adding an SSL Perl 
module so that a remote connection can be easily encrypted.

Any problems with this plan?

brian

[sleuthkit-users] autopsy command line

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

I think I'm going to change the command line arguments for autopsy v2 
and wanted to get some feedback.  Actually, I'm looking for any 
suggestions of changes (even minor ones) that people would like to see 
in v2.

The current method is to give no arguments and it defaults to localhost 
and port 9999:

     # ./autopsy

Or, you can specify just the port:

     # ./autopsy 8000

Or, you can specify the port and remote host:

     # ./autopsy 8000 10.0.0.1

I propose to keep the default method that defaults to 9999 and 
localhost.  The port seems to change the least, so I propose that it is 
easier to specify the remote host (which will be needed for incident 
response) without specifying the port.  Therefore, the following would 
be valid:

     # ./autopsy 10.0.0.1

To change the port, the '-p 8000' flag would be needed.

     # ./autopsy -p 8000 10.0.0.1

Anyone have major issues with that?  This is similar to how ssh and 
telnet work.

While I'm at it, has anyone had issues or conflicts with port 9999?  
Does anyone have a good reason to change it?

brian

[sleuthkit-users] Beta of Autopsy v2.00

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

Happy New Year everyone.  Over the holidays, I was able to perform the 
architecture redesign of Autopsy.

The current design is 3 years old and has one main file that is 10.000+ 
lines of code.  The new design is more modular and has 17 files and 
will be easier to add new features to.  The new design will be released 
as version 2.0 after I add some new incident response features.

The external look of the program is the same, so you shouldn't see a 
difference.  If you would like to use the new design before the full 
version is released, let me know (off list).  There maybe a few URLs 
and windows that didn't get a complete upgrade and I would like to find 
those and get any design feedback before 2.0 is released.

thanks,
brian

Re: [sleuthkit-users] NSRL question

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

Mike,

You want to have one big NSRLFile.txt file.  I'm not sure of the 
details of all of the NSRL versions, but some of the distributions have 
multiple NSRLFile.txt files because they don't all fit on once CD.  
Concatenate the NSRLFile.txt files together into one file and give that 
location to Autopsy.  So, it would be something like:

cat NSRLFile-1.txt NSRLFile-2.txt > NSRLFile.txt

That database will need to be indexed by Autopsy / Sleuth Kit and then 
it can be used.

brian


On Wednesday, December 31, 2003, at 04:38  PM, Michael Dundas wrote:
> I've been using autopsy for some time now, but not with the NSRL 
> database.  I've downloaded the entire database, format-15.  It is in 
> many ZIP files.  How does one make this work with autopsy?  I know you 
> indicate the location of the NSRL DB during installation, but what is 
> one to do with all these zip files?  Do you unzip them all, then 
> append the data in the files in the zip files to one big file? If 
> there are scripts written to do this, I'd like to know where one can 
> get a copy?  If not, happy to write them, but don't understand the end 
> goal?  Maybe I'm making this too complicated.  Any help appreciated.

[sleuthkit-users] NSRL question

[Michael D. <sle...@du...>]

I've been using autopsy for some time now, but not with the NSRL 
database.  I've downloaded the entire database, format-15.  It is in 
many ZIP files.  How does one make this work with autopsy?  I know you 
indicate the location of the NSRL DB during installation, but what is 
one to do with all these zip files?  Do you unzip them all, then append 
the data in the files in the zip files to one big file? 
If there are scripts written to do this, I'd like to know where one can 
get a copy?  If not, happy to write them, but don't understand the end 
goal?  Maybe I'm making this too complicated.  Any help appreciated.

Thanks,
/Mike.

-- 
----------------------------------------------------------------------
People above policy, reason above rule, common sense above compliance.
    - Anonymous

Re: [sleuthkit-users] Problem compiling sleuthkit with macos X.3

[Enda C. <en...@co...>]

Quoting: "Michel Roukine"
> I'm trying to "make" sleuthkit under macos X  10.3.2, and then :
>
> [bonite:/usr/local/sleuthkit] troy# make
> cd src/misc; make "CC=gcc" MAKELEVEL=
> unsupported system: Darwin.7.2.0
> make: *** [defs] Error 1
> make: *** [no-perl] Error 2
> [bonite:/usr/local/sleuthkit] troy#
>
>
> I suspect there is something wrong, but maybe someone may help me  :^)

Take a look at the archives, Nov 15th:

http://sourceforge.net/mailarchive/forum.php?forum_id=10358&max_rows=25&styl
e=flat&viewmonth=200311&viewday=15

Brian's advice is:

I haven't upgraded to Panther yet, so I didn't notice this problem. It
 is a simple fix though.  Edit the src/makedefs file and on line 38 is
 the entry:

      Darwin.6.*) DEFS="-DDARWIN"
          ;;

 You can either change the 6 to a 7 and not try and compile it under OS
 X 10.2 or you can make two more lines below that entry with:

      Darwin.7.*) DEFS="-DDARWIN"
          ;;

 I'll fix that in the next release.


HTH

 -Enda.

[sleuthkit-users] Problem compiling sleuthkit with macos X.3

[Michel R. <mi...@ro...>]

Hi,

I'm trying to "make" sleuthkit under macos X  10.3.2, and then :

[bonite:/usr/local/sleuthkit] troy# make
cd src/misc; make "CC=gcc" MAKELEVEL=
unsupported system: Darwin.7.2.0
make: *** [defs] Error 1
make: *** [no-perl] Error 2
[bonite:/usr/local/sleuthkit] troy#


I suspect there is something wrong, but maybe someone may help me  :^)

Thanks in advance,


Michel Roukine

RE: [sleuthkit-users] TCT

[Altheide, C. B. <Alt...@nv...>]

> -----Original Message-----
> From: Thanh Tran [mailto:ttr...@ya...] 
>  
> Hi,
> Is it true that TCT tools don't work with EXT3
> filesystem?  Thanks.
> 

No.

Cory Altheide
Senior Network Forensics Specialist
NNSA Information Assurance Response Center (IARC)
alt...@nv...

[sleuthkit-users] TCT

[Thanh T. <ttr...@ya...>]

Hi,
Is it true that TCT tools don't work with EXT3
filesystem?  Thanks.

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

[sleuthkit-users] Call for Papers - FIDES04

[Angus M. <an...@n-...>]

Call for Papers - Forensic Insitute Digital Evidence Symposium (FIDES04).

FIDES04 will be held in Edinburgh on 1st & 2nd March 2004.

We are inviting proposals for papers & workshops/tutorials.

Abstracts should be submitted to the programme chair (Angus Marshall,
University of Hull) by e-mail,
no later than 7th January 2004. Authors will be notified by January 21st
2004 and full papers will be required by February 21st 2004.

Keynote speaker will be Derek Wyatt MP. Chairman of the Associated
Parliamentary Internet Group (APIG - http://www.apig.org.uk)

Selected papers will be published in the Spring 2004 issue of the
International Journal of Digital Evidence (http://www.ijde.org). We are
grateful to IJDE for their assistance and collaboration.

Abstracts (up to 500 words) should be e-mailed (in RTF, TeX, LaTeX or .txt)
to fi...@n-...

Suggested topics include :

* Digital Evidence Recovery & Analysis techniques
* Courtroom presentation aids (visualisation, interpretation,
reconstruction)
* Evidential quality standards & maintenance
* Intelligence gathering (e.g. data mining)

Presenters should allow about 20 minutes for presentation + 10 minutes for
questions/discussion.
Workshops/tutorials should be designed for about 3 hours duration.

More information about the Forensic Institute :
(http://www.forensicinstitute.org/)
More information about FIDES04 will be published at
http://fides04.n-gate.net/ as it becomes available.

Re: [sleuthkit-users] Zombies

[Angus M. <an...@n-...>]

On Sunday 14 December 2003 20:50, Enda Cronnolly wrote:
> Quoting: "Angus Marshall"
>
> > The good news - using lynx doesn't cause the same problem. I wonder if
>
> there's
>
> > something out of spec about the way konqueror and mozilla are handling
> > the HTTP streams - would the HTTP version matter ? (I'm wondering about
> > keepalives). Interestingly - they're not what I was brought up to
> > consider real zombies. They do die when the parent process is killed.
>
> 'http keepalives' are particular to http1.1, which you should be able to
> disable in the browser settings and try again!
>
>  -Enda.

OK - I've tried it with keepalives disabled, pipelining disabled and HTTP/1.0 
forced.

Still getting the zombie problem.

[sleuthkit-users] RE: sleuthkit-users digest, Vol 1 #116 - 4 msgs

[Maldonado, F. <fma...@ws...>]

please unsubscribe me from this list.

Thanks.

-----Original Message-----
=46rom: sle...@li...
[mailto:sle...@li...]On Behalf Of
sle...@li...
Sent: Monday, December 15, 2003 8:13 PM
To: sle...@li...
Subject: sleuthkit-users digest, Vol 1 #116 - 4 msgs


Send sleuthkit-users mailing list submissions to
	sle...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
or, via email, send a message with subject or body 'help' to
	sle...@li...

You can reach the person managing the list at
	sle...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sleuthkit-users digest..."


Today's Topics:

   1. Re: Zombies (Brian Carrier)
   2. Re: Zombies (Angus Marshall)
   3. Re: Zombies (Enda Cronnolly)
   4. E2recover.... (Thanh Tran)

--__--__--

Message: 1
Date: Mon, 15 Dec 2003 02:35:07 -0500
Subject: Re: [sleuthkit-users] Zombies
Cc: sle...@li...
To: Angus Marshall <an...@n-...>
=46rom: Brian Carrier <ca...@sl...>

On Saturday, December 13, 2003, at 08:04  AM, Angus Marshall wrote:

> I've been running some fairly long analysis sessions using Autopsy
> 1.75/Sleuthkit 1.66 recently and have noticed my system running slower=20
> and
> slower over time.....
>
> Checking ps shows that there are a *lot* of zombied processes hanging=20
> around
> in the system. Closer inspection suggeste it may be some unwanted=20
> interaction
> between KDE-launched mozilla and autopsy in fact. Here's the ps output=20
> for
> the latest session (just started) :

Wow, these all exist just from opening the main menu window=3F  Autopsy=20
does a wait for the children processes, so I wonder what is unique=20
about this setup that causes the children to stay around.  I'm=20
surprised that Mozilla is in a non-zombie state.  I'll add a bug entry=20
and look into this.  Can you try a different browser and see if the=20
same thing happens (lynx will even work).

> And on an unrelated note - would anyone object to me posting a call=20
> for papers
> for a conference (digital evidence), that I'm chairing early next=20
> year, on
> this list =3F

Nope.  You may want to also consider the DFSci list at=20
http://www.dfrws.org/listsrv/.

thanks,
brian



--__--__--

Message: 2
=46rom: Angus Marshall <an...@n-...>
Organization: Dis-
To: Brian Carrier <ca...@sl...>
Subject: Re: [sleuthkit-users] Zombies
Date: Mon, 15 Dec 2003 20:17:22 +0000
Cc: sle...@li...

On Monday 15 December 2003 07:35, Brian Carrier wrote:
> On Saturday, December 13, 2003, at 08:04  AM, Angus Marshall wrote:
> > I've been running some fairly long analysis sessions using Autopsy
> > 1.75/Sleuthkit 1.66 recently and have noticed my system running slower
> > and
> > slower over time.....
> >
> > Checking ps shows that there are a *lot* of zombied processes hanging
> > around
> > in the system. Closer inspection suggeste it may be some unwanted
> > interaction
> > between KDE-launched mozilla and autopsy in fact. Here's the ps output
> > for
> > the latest session (just started) :
>
> Wow, these all exist just from opening the main menu window=3F  Autopsy
> does a wait for the children processes, so I wonder what is unique
> about this setup that causes the children to stay around.  I'm
> surprised that Mozilla is in a non-zombie state.  I'll add a bug entry
> and look into this.  Can you try a different browser and see if the
> same thing happens (lynx will even work).

OK - tried it with konqueror - openend an existing case and got this :=20

root     19727  1.7  2.6 10472 6680 pts/2    S    20:12   0:01 /usr/bin/perl=
=20
-wT ./autopsy 9000 localhost
root     19822  0.2  0.0     0    0 pts/2    Z    20:13   0:00 [autopsy=20
<defunct>]
root     19825  0.7  0.0     0    0 pts/2    Z    20:13   0:00 [autopsy=20
<defunct>]

The good news - using lynx doesn't cause the same problem. I wonder if there'=
s=
=20
something out of spec about the way konqueror and mozilla are handling the=20
HTTP streams - would the HTTP version matter =3F (I'm wondering about=20
keepalives). Interestingly - they're not what I was brought up to consider=20
real zombies. They do die when the parent process is killed.




--__--__--

Message: 3
=46rom: "Enda Cronnolly" <en...@co...>
To: <sle...@li...>
Subject: Re: [sleuthkit-users] Zombies
Date: Sun, 14 Dec 2003 20:50:46 -0000

Quoting: "Angus Marshall"
>
> The good news - using lynx doesn't cause the same problem. I wonder if
there's
> something out of spec about the way konqueror and mozilla are handling the
> HTTP streams - would the HTTP version matter =3F (I'm wondering about
> keepalives). Interestingly - they're not what I was brought up to consider
> real zombies. They do die when the parent process is killed.

'http keepalives' are particular to http1.1, which you should be able to
disable in the browser settings and try again!

 -Enda.




--__--__--

Message: 4
Date: Mon, 15 Dec 2003 12:51:57 -0800 (PST)
=46rom: Thanh Tran <ttr...@ya...>
To: sle...@li...
Subject: [sleuthkit-users] E2recover....

Hi,
Does anyone know what other tools out there that have
similiar kind of functionalities as e2recover=3F=20
Thanks.

__________________________________
Do you Yahoo!=3F
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/



--__--__--

_______________________________________________
sleuthkit-users mailing list
sle...@li...
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users


End of sleuthkit-users Digest



This email and any attachments thereto may contain private, confidential, and=
 =
privileged material for the sole use of the intended recipient. Any review, =
copying, or distribution of this email (or any attachments thereto) by others=
 =
is strictly prohibited. If you are not the intended recipient, please contact=
 =
the sender immediately and permanently delete the original and any copies of =
this email and any attachments thereto.

Re: [sleuthkit-users] E2recover....

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

On Monday, December 15, 2003, at 03:51  PM, Thanh Tran wrote:

> Hi,
> Does anyone know what other tools out there that have
> similiar kind of functionalities as e2recover?

For EXT2FS?  Not that I know of.  Of course that tool doesn't really 
work with the new EXTxFS file systems anymore since the block pointers 
are wiped.

brian

Re: [sleuthkit-users] Zombies

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

>
> OK - tried it with konqueror - openend an existing case and got this :
>
> root     19727  1.7  2.6 10472 6680 pts/2    S    20:12   0:01 
> /usr/bin/perl
> -wT ./autopsy 9000 localhost
> root     19822  0.2  0.0     0    0 pts/2    Z    20:13   0:00 [autopsy
> <defunct>]
> root     19825  0.7  0.0     0    0 pts/2    Z    20:13   0:00 [autopsy
> <defunct>]
>
> The good news - using lynx doesn't cause the same problem. I wonder if 
> there's
> something out of spec about the way konqueror and mozilla are handling 
> the
> HTTP streams - would the HTTP version matter ? (I'm wondering about
> keepalives).

I know I previously ran into systems that would have tons of children 
processes because the parent wasn't getting the signal and the 'wait' 
command was never run, but I can't think of which system it was.  The 
'lynx' testing may not have generated as many zombies because it won't 
download the images for the buttons.  Did this happen with the previous 
version of Autopsy too?  I changed some of the signal handling in the 
last version so that a '.' is printed when the system is performing big 
operations like searching and calculating MD5 hashes.  I can't imagine 
that would cause the child signal to be ignored though.

I can't recreate it here with Redhat 8 or OS X.  It could be an HTTP 
thing.  I haven't been using a Perl module for HTTP, but maybe I should 
:).  I'll look into that since I am doing a big redesign of Autopsy 
right now.

thanks,
brian