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

[sleuthkit-users] E2recover....

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

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

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

Re: [sleuthkit-users] Zombies

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

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.

Re: [sleuthkit-users] Zombies

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

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

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). Interestingly - they're not what I was brought up to consider 
real zombies. They do die when the parent process is killed.

Re: [sleuthkit-users] Zombies

[Brian C. <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 
> 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?  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).

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

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

thanks,
brian

[sleuthkit-users] Zombies

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

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

500       2264  0.0  0.4  4416 1064 ?        S    12:44   0:00 /bin/bash -c ps 
x |grep -q '[m]ozilla' && mozilla -remote "openURL(`echo 
'http://localhost:9000/37201582871632651365/autopsy'`, new-window)" || mozil     
la 'http://localhost:9000/37201582871632651365/autopsy'
500       2283  4.5 11.7 49740 29296 ?       S    12:44   0:48 
/usr/lib/mozilla-1.4.1/mozilla-bin http://l     
ocalhost:9000/37201582871632651365/autopsy
500       2292  0.0 11.7 49740 29296 ?       S    12:44   0:00 
/usr/lib/mozilla-1.4.1/mozilla-bin http://l     
ocalhost:9000/37201582871632651365/autopsy
500       2293  0.0 11.7 49740 29296 ?       S    12:44   0:00 
/usr/lib/mozilla-1.4.1/mozilla-bin http://l     
ocalhost:9000/37201582871632651365/autopsy
500       2294  0.0 11.7 49740 29296 ?       S    12:44   0:00 
/usr/lib/mozilla-1.4.1/mozilla-bin http://l     
ocalhost:9000/37201582871632651365/autopsy
500       2296  0.0 11.7 49740 29296 ?       S    12:44   0:00 
/usr/lib/mozilla-1.4.1/mozilla-bin http://l     
ocalhost:9000/37201582871632651365/autopsy
500       2318  0.0 11.7 49740 29296 ?       S    12:44   0:00 
/usr/lib/mozilla-1.4.1/mozilla-bin http://l     
ocalhost:9000/37201582871632651365/autopsy
root      2401  0.0  0.0     0    0 pts/1    Z    12:44   0:00 [autopsy 
<defunct>]
root      2417  0.0  0.0     0    0 pts/1    Z    12:45   0:00 [autopsy 
<defunct>]
root      2429  0.0  0.0     0    0 pts/1    Z    12:45   0:00 [autopsy 
<defunct>]
root      2431  0.0  0.0     0    0 pts/1    Z    12:45   0:00 [autopsy 
<defunct>]
root      2454  0.0  0.0     0    0 pts/1    Z    12:45   0:00 [autopsy 
<defunct>]
root      2455  0.0  0.0     0    0 pts/1    Z    12:45   0:00 [autopsy 
<defunct>]
root      2458  0.0  0.0     0    0 pts/1    Z    12:45   0:00 [autopsy 
<defunct>]
root      2467  0.0  0.9 10620 2296 pts/1    S    12:45   0:00 /usr/bin/perl 
-wT ./autopsy 9000 localhost


Anyone happen to know of a cure for this ? 

(Fedora Core1, custom 2.4.22 kernel)

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

Re: [sleuthkit-users] Using mac-robber

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

> I'm thinking of moving from "grave-robber" to
> "mac-robber".  Could anyone tell me if "mac-robber"
> has everything that "grave-robber" has and more?  Or
> "grave-robber" has some functionalities that
> "mac-robber" doesn't have.  Thanks.

Tranh,

They are MUCH different.  mac-robber only grabs the MAC time info 
(grave-robber -m I think) and that is it. grave-robber copies binaries, 
grabs logs and lots of other things that I have forgotten.  I found 
grave-robber to be too big for incident response and this is the more 
focused version.  mac-robber can send the data to a remote host with 
netcat, which can't be done in grave-robber (which writes data to the 
local system or a network share).  I actually find mac-robber only 
useful in scenarios where The Sleuth Kit doesn't support the platform.  
The Sleuth Kit will give you the timelines with deleted files and it 
can bypass the kernel rootkits.

brian

[sleuthkit-users] Using mac-robber

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

Hi,
I'm thinking of moving from "grave-robber" to
"mac-robber".  Could anyone tell me if "mac-robber"
has everything that "grave-robber" has and more?  Or
"grave-robber" has some functionalities that
"mac-robber" doesn't have.  Thanks.
  

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

Re: [sleuthkit-users] Recovering Deleted Partition?

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

> For anyone that may be interested, I've found this tool called 
> "gpart", and a brief description from the pkg-desc in FreeBSD ports 
> gives me:

Yea, this is the tool that I would recommend as well for this function.

> Guessed primary partition table:
> Primary partition(1)
>   type: 007(0x07)(OS/2 HPFS, NTFS, QNX or Advanced UNIX)
>   size: 4886mb #s(10008424) s(63-10008486)
>   chs:  (0/1/1)-(1023/14/63)d (0/1/1)-(10590/14/55)r

This shows that gpart thinks that sectors 63 to 10008486 are for the 
partition.  It is actually fairly easy to figure out the location of 
the first partition because it typically starts in sector 63.  Check 
out the Sleuth Kit Informer #2 if you need help using 'dd' to extract 
the partitions.

http://www.sleuthkit.org/informer/

brian

[sleuthkit-users] Recovering Deleted Partition?

[Matt C. <mat...@ho...>]

Note to self: investigate more before begigng for help...

For anyone that may be interested, I've found this tool called "gpart", and 
a brief description from the pkg-desc in FreeBSD ports gives me:

Port:   gpart-0.1h
Path:   /usr/ports/sysutils/gpart
Info:   Tries to recover lost partition tables and file systems

*sigh* anyway, it gave me the following information about my disk image:

Begin scan...
Possible partition(Windows NT/W2K FS), size(4886mb), offset(0mb)

* Warning: short read near sector(10018701), 64512 bytes instead of 66048. 
Skipping...
End scan.

Checking partitions...
Partition(OS/2 HPFS, NTFS, QNX or Advanced UNIX): primary
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 007(0x07)(OS/2 HPFS, NTFS, QNX or Advanced UNIX)
   size: 4886mb #s(10008424) s(63-10008486)
   chs:  (0/1/1)-(1023/14/63)d (0/1/1)-(10590/14/55)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r


Hopefully that will get me somewhere. :)

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca

[sleuthkit-users] Recovering Deleted Partition?

[Matt C. <mat...@ho...>]

Hello list!

I've used the Sleuthkit with Autopsy quite successfully for the Challenges 
from HoneyNet, and I decided to kick it up a notch.

I asked a friend to use an old 5GB hard drive, and just write a bunch of 
stuff to the disk, and record what files he'd like to have recovered (this 
is just for practice, BTW). Anyway, he ended up formatting and deleting the 
partition on the disk. (FAT32 partition).

I made an image of the disk, and tried importing it into autopsy. Whoops. 
Aparently it doesn't like images of whole disks. No problemo, I'll follow 
the "split" document I saw. Oh... I have no partitions available... hmmm

How would I go about recovering these partitions? I remember seeing a tool 
for this donkey's years ago, but it was in DOS, and that was on a proper 
disk. I'm working with an image in FreeBSD. I haven't been able to find any 
tools to recover the partition tables. :(

Does anyone have any recommendations, or know of a way to recover then in 
sleuth?

Thanks!
MM

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca

Re: [sleuthkit-users] Recovering deleted files using autopsy

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

On Thursday, December 4, 2003, at 03:44  PM, Thanh Tran wrote:

> Hi,
> I'm using Autopsy and Sleuthkit to test the recovery
> of a deleted file on a Linux file system.  However,
> when I got to the "File Analysis" part of Autopsy,
> even though I saw the deleted file in red, I don't see
> any info regarding "inode", and the date showed up as
> 0000.00...GMT.   How do I view the content of the
> deleted file if I don't know the inode number?

You don't :)  EXT3FS stores the file name in a different structure than 
the inode (where the block pointers are located).  When a file is 
deleted in Linux, the link between the name structure and the inode is 
deleted (older versions of Linux didn't do this).  So, everything is 0 
for the deleted file because there is no way to get that information 
from the file name.

> Using
> Meta Data I could view the content at a particular
> inode but I don't know the inode of the deleted file.

Even if you had the inode number, the link between the fragments (where 
the deleted data is located) and the inode are also cleared, so you 
won't get much that way either.  Another way to find the inode (not 
that it will help much though) is to make a timeline and figure out the 
inode based on deletion time (if you know roughly when that was).  It 
was much easier before they changed the way that Linux deleted files...

>  Does anyone know how the recovering and viewing
> content of a deleted file is possible using Autopsy?
> Do I need to use "lazarus" instead?

You can try lazarus, or foremost.  foremost is much faster and the 
results are easier to parse through for common file formats that it has 
a configuration file for.  Extract the unallocated space (in the image 
details of Autopsy from the Case Gallery view) and run one of the 
carving tools on that.

> Thanks.
> P.S: I was able to guess the inode number of the
> deleted file by looking at the allocation list and was
> able to see the content.  However, I wonder if there
> is an "automatic" way for this.

Inodes are allocated by block group, so that can help you narrow down 
the ones you look at.  you can find the inode ranges per group in the 
file system details view.

brian

[sleuthkit-users] Recovering deleted files using autopsy

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

Hi,
I'm using Autopsy and Sleuthkit to test the recovery
of a deleted file on a Linux file system.  However,
when I got to the "File Analysis" part of Autopsy,
even though I saw the deleted file in red, I don't see
any info regarding "inode", and the date showed up as
0000.00...GMT.   How do I view the content of the
deleted file if I don't know the inode number?  Using
Meta Data I could view the content at a particular
inode but I don't know the inode of the deleted file. 
Does anyone know how the recovering and viewing
content of a deleted file is possible using Autopsy? 
Do I need to use "lazarus" instead?  Thanks.
P.S: I was able to guess the inode number of the
deleted file by looking at the allocation list and was
able to see the content.  However, I wonder if there
is an "automatic" way for this.


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: [sleuthkit-users] Who can undelete some files on my Linux server ?

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

On Monday, November 17, 2003, at 06:26  PM, Steven Depuydt - 
LogiSoft.be wrote:

> Hi,
>
> I have deleted 2 MySQL databases on my Linux server (RedHat 7)
> I don't have a recent backup.
>
> I have tried the 'Sleuth Kit', but I can't figure out HOW it his 
> working.

Have you tried to use Autopsy as well?  Autopsy makes the process much 
easier.

     http://www.sleuthkit.org/autopsy

> Who can un-delete my databases for me ?

If you can get Autopsy running and import the image, then you can 
browse to the original location and try and export it.  You maybe lucky 
because you have Red Hat 7 and the block pointers of the deleted file 
may not have been cleared.  Your best bet is to stop using this machine 
and move the disks to another system so that you don't overwrite the 
data you want to recover.

good luck.

brian

[sleuthkit-users] Who can undelete some files on my Linux server ?

[Steven D. - LogiSoft.b. <st...@lo...>]

Hi,

I have deleted 2 MySQL databases on my Linux server (RedHat 7)
I don't have a recent backup.

I have tried the 'Sleuth Kit', but I can't figure out HOW it his working.

Who can un-delete my databases for me ?
I am willing to pay you for your time.

Thanks.

Steven

RE: [sleuthkit-users] Recovering unallocated using Autopsy

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

Hi AZ & list,

> foremost does not work/compile on freebsd.=20

Yeah, that is too bad. I contacted the authors once about porting the
program, but never got a response.

If you _have_ linux installed, you could try a patch I wrote for using
Foremost in the graphical Autopsy GUI ;)

You could give it a try. Installation instructions are here:
http://sourceforge.net/mailarchive/forum.php?thread_id=3D2813215&forum_id=
=3D
10358

---
P. Vissers			t 070 - 336 99 99
Fox-IT 			f 070 - 336 99 90
Haagweg 137			e vi...@fo...
2281 AG  Rijswijk		i www.fox-it.com=20

Disclaimer: This email may contain confidential information. If this
message is not addressed to you, you may not retain or use the
information in it for any purpose. If you have received it in error,
please notify the sender and delete this message. We try to screen out
viruses but take no responsibility if this email contains a virus.

=20


=20

Re: [sleuthkit-users] New Release of Sleuth Kit and Autopsy

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

On Sunday, November 16, 2003, at 12:38  AM, Francesco Schiliro wrote:

> Hi Brian,
>
> Downloaded your new release of Sleuth kit and Autopsy.
>
> =A0I=92ve been using Mac OSX as my operating system to run Sleuth =
Kit.=A0=20
> However after I installed the new version 10.3 (Panther) and then=20
> tried to install Sleuth Kit, I got the following when I ran make;
>
Francesco,

I haven't upgraded to Panther yet, so I didn't notice this problem. It=20=

is a simple fix though.  Edit the src/makedefs file and on line 38 is=20
the entry:

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

You can either change the 6 to a 7 and not try and compile it under OS=20=

X 10.2 or you can make two more lines below that entry with:

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

I'll fix that in the next release.

Does Panther have a better version of 'strings'?  I.e. one that=20
supports '-t d' and other GNU binutils flags?

thanks,
brian=

[sleuthkit-users] New Release of Sleuth Kit and Autopsy

[Francesco S. <sch...@bi...>]

Hi Brian,

 

Downloaded your new release of Sleuth kit and Autopsy.

 

I've been using Mac OSX as my operating system to run Sleuth Kit.
However after I installed the new version 10.3 (Panther) and then tried
to install Sleuth Kit, I got the following when I ran make;

 

cd src/misc; make "CC=gcc" MAKELEVEL=

unsupported system: Darwin.7.0.0

make: *** [defs] Error 1

make: *** [no-perl] Error 2

 

Any advise?

 

 

Regards

 

Frank

[sleuthkit-users] New Release of Sleuth Kit and Autopsy

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

Hello all,

There are new releases of both The Sleuth Kit and Autopsy.

The Sleuth Kit 1.66:
     *  Bug Fixes
           o fls -r would generate duplicate deleted NTFS file names
           o Would not compile under OpenBSD 3
           o sorter results would go into different categories depending 
on version of Perl and its internal sorting order
           o ffind now reports the attribute name for NTFS
     * Major New Features
           o icat shows slack space with '-s'
           o Solaris x86 disk label (VTOC) support added

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

Autopsy 1.75:
     *  Bug Fixes:
           o Better error handling and messages
     * Updates:
           o Graphics load better now.

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

brian

[sleuthkit-users] icat -s

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

Does anyone use the '-s' flag with icat?  It is currently setup to 
allow you to specify the type and id value for an NTFS inode, but you 
can also specify the type and id using the normal 123-128-1 inode 
address.  I am adding a flag to allow 'icat' to also show the slack 
space of the file and '-s' seems to be the most logical.  Autopsy 
doesn't use '-s' with icat and I no longer know why I added that flag.

So, if no one uses it, then I will replace it with the slack space 
option.

brian

Re: [sleuthkit-users] Recovering unallocated using Autopsy

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

Just a follow up.

foremost does not work/compile on freebsd. I have to hold off on this 
project till I install linux on another machine and move the affected 
drive over.

Just thought you might like to know.

Thanks again.


On Sun, 9 Nov 2003, A Z wrote:

> Thank you sir.
> 
> I shall attempt to run foremost after I'm done with lazarus .. atleast 
> that way I would know which blocks not to search.
> 
> Shall let you know if it worked :)
> 
> - A Z
> 
> On Sun, 9 Nov 2003, Brian Carrier wrote:
> 
> > > Are you aware if Foremost would run on FreeBSD?
> > 
> > I don't know.  I haven't tried it.  I know that there are a few Linux 
> > specific commands, but haven't done much at getting around those.   I 
> > have been meaning to get it working on OS X.
> > 
> > > Would foremost work on the unallocated extraction by unrm as well?
> > 
> > Yes.  'foremost' just looks at data (like lazarus) and doesn't care 
> > about the file system type.  So, it can analyze the entire file system 
> > or just the unallocated.
> > 
> > > And what was the procedore to extract unallocated via autopsy?
> > 
> > If you go the 'keyword search' mode or the 'details' mode of the image, 
> > then there is an option to extract the unallocated space.  This uses 
> > the 'dls' tool in The Sleuth Kit, which is basically the same tool as 
> > 'unrm' in TCT.
> > 
> > brian
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] Recovering unallocated using Autopsy

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

Thank you sir.

I shall attempt to run foremost after I'm done with lazarus .. atleast 
that way I would know which blocks not to search.

Shall let you know if it worked :)

- A Z

On Sun, 9 Nov 2003, Brian Carrier wrote:

> > Are you aware if Foremost would run on FreeBSD?
> 
> I don't know.  I haven't tried it.  I know that there are a few Linux 
> specific commands, but haven't done much at getting around those.   I 
> have been meaning to get it working on OS X.
> 
> > Would foremost work on the unallocated extraction by unrm as well?
> 
> Yes.  'foremost' just looks at data (like lazarus) and doesn't care 
> about the file system type.  So, it can analyze the entire file system 
> or just the unallocated.
> 
> > And what was the procedore to extract unallocated via autopsy?
> 
> If you go the 'keyword search' mode or the 'details' mode of the image, 
> then there is an option to extract the unallocated space.  This uses 
> the 'dls' tool in The Sleuth Kit, which is basically the same tool as 
> 'unrm' in TCT.
> 
> brian
> 

Re: [sleuthkit-users] Recovering unallocated using Autopsy

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

> Are you aware if Foremost would run on FreeBSD?

I don't know.  I haven't tried it.  I know that there are a few Linux 
specific commands, but haven't done much at getting around those.   I 
have been meaning to get it working on OS X.

> Would foremost work on the unallocated extraction by unrm as well?

Yes.  'foremost' just looks at data (like lazarus) and doesn't care 
about the file system type.  So, it can analyze the entire file system 
or just the unallocated.

> And what was the procedore to extract unallocated via autopsy?

If you go the 'keyword search' mode or the 'details' mode of the image, 
then there is an option to extract the unallocated space.  This uses 
the 'dls' tool in The Sleuth Kit, which is basically the same tool as 
'unrm' in TCT.

brian

Re: [sleuthkit-users] Recovering unallocated using Autopsy

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

Thank you for your reply.

I am using Freebsd. Foremost seems to be for Linux.
I am not quite sure how to extract unallocated space using autopsy.
At this very moment I am using tct's lazarus on my unrm.output .. I so far 
It hasn't hit an *.i.txt yet ( or image file ), in the last 10 hours.

I am using a 180gb drive to do all this, and have left my 80gb drive alone 
since making the dd image for autopsy and unrm for tct, just incase I need 
to look at the 80gb again in the future.

Are you aware if Foremost would run on FreeBSD?
Would foremost work on the unallocated extraction by unrm as well?
And what was the procedore to extract unallocated via autopsy?

Thanks again!

- A Z



On Sun, 9 Nov 2003, Brian Carrier wrote:

> 
> On Saturday, November 8, 2003, at 05:00  PM, A Z wrote:
> 
> > 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:
> 
> I'm assuming that you are using a UFS or EXT?FS file system.  Most file 
> systems now clear out the values in the data structures when a file is 
> deleted and therefore you cannot see the directory contents and sorter 
> cannot examine the deleted files.
> 
> > 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 )
> 
> Your best bet would be to try 'foremost', foremost.sourceforge.net.  
> Normally, you would be able to restrict the amount of disk space that 
> you would have to search because you could just look at one block 
> group, but because you have 4GB, that is likely bigger than just one 
> block group and the images are all over the disk.  So, I would extract 
> the unallocated space (which an be done in Autopsy) and then run 
> foremost on the resulting file (which will be in the 'output' folder in 
> the evidence locker and have an extension of '.dls'.
> 
> brian
> 

Re: [sleuthkit-users] Hash "Magic" File?

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

On Saturday, November 8, 2003, at 11:45  PM, Sherwood McGowan wrote:

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

I don't know of any sites that have hashes for just 'hfind' / Autopsy, 
but what types of hashes are you looking for?  You can use the NIST 
NSRL, 'hfind' supports hashkeeper (although Autopsy does not), and you 
can make your own with 'md5sum'.

brian

Re: [sleuthkit-users] Recovering unallocated using Autopsy

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

On Saturday, November 8, 2003, at 05:00  PM, A Z wrote:

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

I'm assuming that you are using a UFS or EXT?FS file system.  Most file 
systems now clear out the values in the data structures when a file is 
deleted and therefore you cannot see the directory contents and sorter 
cannot examine the deleted files.

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

Your best bet would be to try 'foremost', foremost.sourceforge.net.  
Normally, you would be able to restrict the amount of disk space that 
you would have to search because you could just look at one block 
group, but because you have 4GB, that is likely bigger than just one 
block group and the images are all over the disk.  So, I would extract 
the unallocated space (which an be done in Autopsy) and then run 
foremost on the resulting file (which will be in the 'output' folder in 
the evidence locker and have an extension of '.dls'.

brian