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

RE: [sleuthkit-users] Image searching qurestion

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

Splitting the file into the partitions worked. 

Thanks, Brian, and dorkus, for the help.

Niall.  

-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...] 
Sent: Tuesday, March 30, 2004 12:45 AM
To: Eagle Investigative Services, Inc. 
Cc: sle...@li...
Subject: Re: [sleuthkit-users] Image searching qurestion

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


On Mar 29, 2004, at 10:20 PM, Eagle Investigative Services, Inc. wrote:

> I have a file, called 17g.dd, which is an image of an NTFS drive (not 
> the
> partition)
>
> When I went to add the image, Autopsy would not let me add it as an 
> ntfs file system. I could only add it as raw.

Autopsy only supports file system images.  For info on splitting the disk
into partitions, see:

http://www.sleuthkit.org/informer/sleuthkit-informer-2.html#split
http://www.sleuthkit.org/informer/sleuthkit-informer-12.html#mmls

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAaQlUOK1gLsdFTIsRAo+GAJ9hi8hpLoKLkigFmh93YgTR2loZqQCfRb6G
2zkxB/ur1VqscyMjRCdOfu4=
=/iSj
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] Image searching qurestion

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

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

On Mar 30, 2004, at 2:55 AM, Enda Cronnolly wrote:
> What happens Brian if you are working with a corrupt filesystem from a
> system crash, and the parition is not mountable? is it possible to 
> analyse
> fragments / chunks of a damaged partition using the filesystem rules?

It depends on why the image is corrupt.  TSK doesn't do a full check of 
the FS before it starts to analyze it.  Autopsy checks the image when 
importing into Autopsy by running the 'fsstat' tool on the image to see 
if it can read the superblock and other general file system data.  That 
goal of that is to detect when users enter the wrong file system type.

TSK tools will process a file system image until they encounter an 
error.  They will not try to fix the error or "guess" what the correct 
value is.  TSK also ignores the "dirty" status of a file system, as 
marked in the super block (or equivalent).

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAaXuvOK1gLsdFTIsRAsUPAJ9xKoYJ64XBI3/YyZ8zTjXVfsQpSgCfcyWN
3lE0aWjd9r817dsZAmb2iBk=
=rXYW
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] Image searching qurestion

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

Quoting: "Brian Carrier"
> On Mar 29, 2004, at 10:20 PM, Eagle Investigative Services, Inc. wrote:
>
> > I have a file, called 17g.dd, which is an image of an NTFS drive (not
> > the
> > partition)
> >
> > When I went to add the image, Autopsy would not let me add it as an
> > ntfs
> > file system. I could only add it as raw.
>
> Autopsy only supports file system images.  For info on splitting the
> disk into partitions, see:

What happens Brian if you are working with a corrupt filesystem from a
system crash, and the parition is not mountable? is it possible to analyse
fragments / chunks of a damaged partition using the filesystem rules?

This is fairly common with NTFS where a key part of the fs gets corrupted
during a crash, but presumably there is a large portion of the filesystem
that is "ok" and still written with the filesystem rules.

 -Enda

Re: [sleuthkit-users] Image searching qurestion

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

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


On Mar 29, 2004, at 10:20 PM, Eagle Investigative Services, Inc. wrote:

> I have a file, called 17g.dd, which is an image of an NTFS drive (not 
> the
> partition)
>
> When I went to add the image, Autopsy would not let me add it as an 
> ntfs
> file system. I could only add it as raw.

Autopsy only supports file system images.  For info on splitting the 
disk into partitions, see:

http://www.sleuthkit.org/informer/sleuthkit-informer-2.html#split
http://www.sleuthkit.org/informer/sleuthkit-informer-12.html#mmls

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAaQlUOK1gLsdFTIsRAo+GAJ9hi8hpLoKLkigFmh93YgTR2loZqQCfRb6G
2zkxB/ur1VqscyMjRCdOfu4=
=/iSj
-----END PGP SIGNATURE-----

[sleuthkit-users] Image searching qurestion

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

I have a file, called 17g.dd, which is an image of an NTFS drive (not the
partition)

When I went to add the image, Autopsy would not let me add it as an ntfs
file system. I could only add it as raw.

When I load the image file into Autopsy, I don't have the ability to do a
file type analysis on it, only a keyword search. 

I'd like to use the File Type feature on this image. Is that possible?

Niall. 

Re: [sleuthkit-users] dcat feature request

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

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


On Mar 29, 2004, at 9:29 AM, nighty wrote:

> I just found something, but I'm not sure, whether it's a bug.

bug / oversight ... same thing.  This functionality for raw types is 
documented in the man pages etc, but I forgot about it when I added 
support to Autopsy for raw / swap images.  It is now SF bug 925382.

> Therefor I suggest, that it would be fine, to give dcat the capability 
> to
> show a range of units, similar to what dls does, and of course adjust 
> Autopsy
> to this.

I agree with your suggested fix.  I may even make a flag to specify the 
data unit size.

> PS.: It would also be a useful feature, when the user could remove 
> images,
> hosts and cases from Autopsy

Yea, I know.  I'm just paranoid about having 'rm -rf' commands in my 
code.  Hosts and cases are easy to delete by hand because it is just 
the directory that needs to be removed.  There are no config files that 
you have to clean up.

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAaEnGOK1gLsdFTIsRAiQSAJ9RHOJ1IwQFseEmyE8q1ZkPEtdnSACdH4Dg
NUy76AmmIBnTcExLrXR+1EM=
=meXz
-----END PGP SIGNATURE-----

[sleuthkit-users] dcat feature request

[nighty <nig...@gm...>]

Hello,

I just found something, but I'm not sure, whether it's a bug.
I used Autopsy (I tested it on 1.75 and 2.0) and switched to Data Analysi=
s=20
Mode in order to check some unit's content. Now it appears, that if I am=20
using a raw image (without filesystem) and want to view more than one uni=
t,=20
Autopsy gives me a wrong unit content. I want to give you an example of w=
hat=20
Autopsy does, using dcat:

dcat -a -f raw /PATH_TO_IMAGE/foo.dd 4000 512

this gives me the ascii output of the 4000th 512 byte unit. Fine!
Now, when telling Autopsy to show me 2 units, Autopsy gives me the same=20
output, as if I had done a

dcat -a -f raw /PATH_TO_IMAGE/foo.dd 4000 2048

So he does not show me unit 4000-4003, but the 4000th 2048 byte unit.

When using a image with a filesystem, there is no problem, only with raw=20
images this occurs.

Therefor I suggest, that it would be fine, to give dcat the capability to=
=20
show a range of units, similar to what dls does, and of course adjust Aut=
opsy=20
to this.
So I could perform a

dcat -a -f raw /PATH_TO_IMAGE/foo.dd 4000-4003 512

Best regards,

Harald Katzer

PS.: It would also be a useful feature, when the user could remove images=
,=20
hosts and cases from Autopsy

Re: [sleuthkit-users] Autopsy 2.0

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

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

> When I specify an image location as :
>
> /dev/hdd/hdd1/17g.dd
>
> It says it can't find the image file, although the image file
> is defintely there.
>
> My only option that actually worked was to point it to:
>
> /dev/hdd

What operating system are you using?  If this is Linux, then /dev/hdd 
is typically a block device file and it makes sense that you can read 
it.  You shouldn't be able to make files inside of /dev/hdd, so I'm not 
sure how you could have created the files (unless the OS has changed 
the device layout and /dev/hdd/ is actually a directory).

What do you get if you do an 'ls -l' on /dev/hdd/hdd1/17g.dd ?  
Typically you would mount /dev/hdd1 to some directory (/mnt/ say) and 
specify /mnt/17g.dd.  Unless the OS does some type of automounting.

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAaC89OK1gLsdFTIsRAt8kAJ9cjp+dDbuZJzSoc7+lzuUaZfJgMQCfel46
VycU8LliD4EqhS1tzxbqPv0=
=ECt+
-----END PGP SIGNATURE-----

[sleuthkit-users] Autopsy 2.0

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

Hello, 

I've dd'd 5 NTFS images to one drive and I'm trying to load 
each image individually into Autopsy. 

When I specify an image location as : 

/dev/hdd/hdd1/17g.dd

It says it can't find the image file, although the image file 
is defintely there. 

My only option that actually worked was to point it to: 

/dev/hdd

which is the entire 200gig drive and takes a long time to search. I'd
like to be able to search the individual dd files. 

Any ideas?

Niall. 

Re: [sleuthkit-users] Sleuth Kit Bootable CD

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

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

On Mar 24, 2004, at 4:42 AM, Devshi Odedra wrote:
> I am new to this and wonder if any one can help with instructions on
> how to incorporate Autospy into Sleuth Kit bootable CD. Any help
> appreciated.

There are already several bootable CDs that include The Sleuth Kit and 
Autopsy.  If you are referring to the Penguin Sleuth Kit CD, then it 
already includes The Sleuth Kit and Autopsy.

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

brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAYdgQOK1gLsdFTIsRAqgAAJ9Y0XsqChTRQ3qrDS3GrEW91ox2MACfXZjD
ePh9Rc9Gfx3xJ65Y1fKoGsA=
=CqsZ
-----END PGP SIGNATURE-----

[sleuthkit-users] Sleuth Kit Bootable CD

[Devshi O. <Dev...@pa...>]

Hi,

I am new to this and wonder if any one can help with instructions on
how to incorporate Autospy into Sleuth Kit bootable CD. Any help
appreciated.

Thanks


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: [sleuthkit-users] Re: [sleuthkit-announce] Autopsy v2.00 Release

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

On Mar 19, 2004, at 4:22 PM, Angus Marshall wrote:

> On Friday 19 March 2004 20:15, Brian Carrier wrote:
>> Version 2.00 of Autopsy has been released.
>>
>> http://www.sleuthkit.org/autopsy
>
> Looks nice - it's certainly cured the zombie problem that I noticed a 
> while
> back on Fedora & Redhat. It feels slicker too.

Yea, it turned out that was a Perl 5.8 issue.  They changed the way 
that signals are handled in 5.8, which resulted in zombies on some 
systems and the missing command output.   Unfortunately, now I get some 
errors about "Can't ignore child signal" (or something), but the 
zombies are gone.

> Well done and thanks!

thanks.

sleuthkit.org is having some problems, so use the mirror if needed:

http://sleuthkit.sf.net

brian

Re: [sleuthkit-users] Re: [sleuthkit-announce] Autopsy v2.00 Release

[Matthew M. S. <msh...@th...>]

> Looks nice - it's certainly cured the zombie problem 

Looks like they need you in Milwaukee Brian, as we know that with the
Dawn comes The Dead!

Sorry, I just couldn't resist!

Great work as always Brian!

[sleuthkit-users] Re: [sleuthkit-announce] Autopsy v2.00 Release

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

On Friday 19 March 2004 20:15, Brian Carrier wrote:
> Version 2.00 of Autopsy has been released.
>
> http://www.sleuthkit.org/autopsy

Looks nice - it's certainly cured the zombie problem that I noticed a while 
back on Fedora & Redhat. It feels slicker too.

Well done and thanks!

[sleuthkit-users] Autopsy v2.00 Release

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

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

Version 2.00 of Autopsy has been released.

http://www.sleuthkit.org/autopsy

The biggest change is the internal design (which you should not notice) 
and the live analysis support.  Check out the last Sleuth Kit Informer 
for more details on the live analysis mode.  Basically, autopsy will 
create a directory that you can burn to a CD and plug it into a running 
UNIX system so that you can check out some logs and other stuff on a 
suspect system and not modify the A-Times and be affected by rootkits.

There are some other minor updates as well.


MD5:  73873b4af937cf11354f681b0c269f50

Signature of autopsy-2.00.tar.gz:
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQBAW0y5OK1gLsdFTIsRAp8tAJ9P1qP5NrlC8RHl9vrCcPX+Wjzj+QCeNIVt
g05FdzWmEY+BVX8GJAFYEac=
=Jlej
- -----END PGP SIGNATURE-----


brian
  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAW1TeOK1gLsdFTIsRArRdAJwLE5GtG/LHmYSXWb1ucD6ZmuoASQCfT/x3
LtYF0xrhA4S5Ueo/u/yniUk=
=ci3L
-----END PGP SIGNATURE-----

[sleuthkit-users] Re: [sleuthkit-developers] Slack space and icat

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

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

Ok, bug fixed.  Stupid error using an unsigned variable.  The same 
problem existed in the FFS code and is now fixed.  The new versions can 
be found here:

sleuthkit.sf.net/sleuthkit/ffs.c
sleuthkit.sf.net/sleuthkit/ext2fs.c

One of the things that I forgot on the list of goals for v2 (and Knut 
Eckstein reminded me of) is that I want to go through the code and get 
rid of all of the uses of size_t and addr_t type variables and move to 
int32_t and u_int32_t because the sizes and signs for the different 
platforms is too confusing.

brian


On Mar 10, 2004, at 4:06 PM, Epsilon wrote:

> --- Brian Carrier <ca...@sl...> wrote:
>>
>> On Feb 18, 2004, at 1:58 PM, Epsilon wrote:
>>
>>> I'm getting a very large (>500 MB) file when using the -s option
>> with
>>> icat when I should be getting a file that's around 40 KB.  I'm
>> using
>>> sleuthkit-1.67.  Anyone else seeing this?
>>
>> Wow.  What file system type?  Can you send the output of running
>> 'istat' on it?
>
> OK, I've been meaning to respond to this for a while.  I'm now using
> sleuthkit-1.68 under Fedora Core 1 with latest patches applied.  I'm
> using the honeypot.hda5.dd image from here:
>
> http://honeynet.org/misc/files/challenge-images.tar
>
> And here's the exact command I'm running:
>
> $ ./icat -s -f linux-ext2 honeypot.hda5.dd 1604 > inode-1604-all.out
>
> After about 5 seconds I ^C it and run icat w/o the -s:
>
> $ ./icat -f linux-ext2 honeypot.hda5.dd 1604 > inode-1604-data.out
>
> Look at the results:
>
> $ ls -l *.out
> -rw-r--r--    1 ep   users    141107200 Mar 10 16:01 inode-1604-all.out
> -rw-r--r--    1 ep   users      119671 Mar 10 16:01 inode-1604-data.out
>
> I'm expecting to see inode-1604-all.out to be 122880 bytes in size
> (4096 * 30 clusters).  Is this a wrong assumption?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAT9ucOK1gLsdFTIsRAqn2AJ0U0L/JA/AxZ+dl2Vl5n6uRjLXDSwCePJx4
qyTQvjU7ZF2QRhEwkF0qzVA=
=mGQ8
-----END PGP SIGNATURE-----

[sleuthkit-users] *** DFRWS 2004 Announced ***

[Kalil D. C. AFRL/I. <Dan...@rl...>]

Hello All,

The 2004 Digital Forensic Research WorkShop is on for August in Baltimore,
Maryland, USA. In addition, the Call for Papers is ready for your review.
This year's event will address two major objectives:

- Start building wider community consensus for a digital
forensic/investigative framework in the field
- Explore the implications of varied response time needs in applying digital
forensics across domains

We invite all to take a look at the Call for Papers and consider submitting
your ideas in research, applications and analysis or come to participate in
the discussion and debate that promises, as always, to be lively and
informative. So come ready for dialog, exploration, collaboration and to
have some good times with other motivated professionals who share a common
purpose:

"Identifying facts in a virtual reality"

We look forward to seeing many of you this summer in Baltimore!

Details can be found at www.dfrws.org.

Dan

Re: [sleuthkit-users] Re: sleuthkit-users digest, Vol 1 #121 - 1 msg

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

On Tuesday 02 March 2004 03:06, Ëﲨ wrote:
> Dear all!
> 	I am really confusing some phrases in the computer forensics field. And
> there is little articals talking about that. :( The most confusing is
> between "computer forensics" and "forensic computing", "computer forensic"
> and "computer forensics". Anybody could tell me the diffrence? Thanks a
> lot!
> Bob

The three phrases seem to be used interchangeably. Being pedantic, Forensic 
Computing is correct as "forensic" is an adjective used to mean "relating to 
courts or law". However, forensic computing in that sense could also relate 
to the application of any computing technique to a part of the legal process.

Personally, I prefer to talk about digital evidence recovery, DE analysis and 
DE presentation to distinguish between parts of the process.

[sleuthkit-users] Autopsy v2 beta 2 available

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

I have another beta of autopsy available if anyone wants it.  This one 
has the Incident Response / Live Analysis mode working.  I didn't keep 
notes of who got the first version of the beta, so send me an email for 
this one even if you got the first one.

How the Live Analysis works:
1.  Install autopsy on a system like normal
2.  Run the 'make-live-cd' script
3.  That script will create a 'live-cd' sub-directory and copy all 
needed TSK, grep, and strings files to it.
4.  Burn that directory to a CD
5.  Run autopsy from the CD with the '-i' flag for every device you 
want to examine live.  The '-i' flag takes three arguments: device, 
file system type, mount point.  Also specify which host you will be 
connecting to it from:

./autopsy -i /dev/hda5 linux-ext3 / -i /dev/hda8 linux-ext3 /usr/ 
10.1.88.54

6.  It will give you the normal URL and cookie (use -C to not use a 
cookie).

7.  The live version of autopsy will not do:
- logs
- notes
- do file type sorting
- save kwsearch results
- make strings files or unallocated space files of hard disk
- make timelines
- (anything else that I forgot that makes a file).

brian

[sleuthkit-users] Sleuth Kit v1.68

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

There is a new version of TSK out.  Only a few changes, but I wanted to 
get the bug fixes out in the official release.

http://sleuthkit.sourceforge.net/sleuthkit/download.php

MD5: 0826e4b6b3e116a81b40a007d5948e88
(the sleuthkit.org site will be updated later today)


Bug Fixes:
- FAT times were an hour too fast during daylight savings.  Now use 
mktime() instead of manual calculation.  Reported by Randall  Shane. 
(BUG: 880606)
- Indirect block pointer blocks would not be identified by the ifind 
tool.  Reported by Knut Eckstein (BUG: 902709)

Updates:
- 'hfind -i' now reports the header entry as an invalid entry.  The 
first header row was ignored.
- Added fs->seek_pos check to fs_read_random.

brian

Re: [sleuthkit-users] Previewing drives

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

>> It shouldn't.  The Sleuth Kit opens the image files (or devices)
>> read-only so it will not make any changes.  If the disk is mounted on 
>> a
>> live system, then the disk maybe changed by loading the processes for
>> The Sleuth Kit or Autopsy, but that would be the OS changing the disk
>> because any process is running.
>
> An exception being Reiser perhaps? where the journal gets modified 
> even on
> read only mounts? Or does the SluethKit have its own filesystem drivers
> rather than the stock system ones?

Well, TSK/Autopsy doesn't support Reiser...  But, TSK doesn't rely on 
any kernel drivers (which is why you can, for example, examine NTFS and 
EXT3FS on a Solaris box).  Therefore, the bug in the Linux kernel with 
respect to EXT3FS (and Reiser) doesn't apply to TSK.

brian

Re: [sleuthkit-users] Previewing drives

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

 "Brian Carrier"
>
> On Feb 25, 2004, at 12:37 PM, Jon Nelson wrote:
>
> > Does anyone know if using the device name (e.g., /dev/hda1) as the
> > image
> > file for Autopsy will alter the drive?
>
>
> It shouldn't.  The Sleuth Kit opens the image files (or devices)
> read-only so it will not make any changes.  If the disk is mounted on a
> live system, then the disk maybe changed by loading the processes for
> The Sleuth Kit or Autopsy, but that would be the OS changing the disk
> because any process is running.

An exception being Reiser perhaps? where the journal gets modified even on
read only mounts? Or does the SluethKit have its own filesystem drivers
rather than the stock system ones?

 -Enda.

Re: [sleuthkit-users] Previewing drives

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

On Feb 25, 2004, at 12:37 PM, Jon Nelson wrote:

> Does anyone know if using the device name (e.g., /dev/hda1) as the 
> image
> file for Autopsy will alter the drive?


It shouldn't.  The Sleuth Kit opens the image files (or devices) 
read-only so it will not make any changes.  If the disk is mounted on a 
live system, then the disk maybe changed by loading the processes for 
The Sleuth Kit or Autopsy, but that would be the OS changing the disk 
because any process is running.

brian

[sleuthkit-users] Previewing drives

[Jon N. <qu...@li...>]

Does anyone know if using the device name (e.g., /dev/hda1) as the image
file for Autopsy will alter the drive?

I tested this with a floppy and the MD5 did not change.  I was going to d=
o
some more intensive testing, but I don't want to re-invent the wheel.

One reason I would want to do this is to eliminate large drives from a
case without having to image them, while still getting the functionality
of Autopsy.

TIA,

Jon

--=20
Trooper Jon S. Nelson, Linux Certified Admin., CCNA
Pa. State Police, Bureau of Criminal Investigation
Computer Crimes Unit
Work: 610.344.4471 Cell/Page: 866.284.1603
jon...@st...

RE: [sleuthkit-users] user doc?

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

-----Original Message-----
> From: samwun [mailto:sa...@hg...] 
> Sent: Friday, February 13, 2004 10:38 AM
> To: sle...@li...
> Subject: [sleuthkit-users] user doc?
> 
> 
> Dear all,
>  
> Is there any detailed documentation about how to use sleuthhkit?
> 
> 
> Thanks
> Sam

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

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